If you’re in the business of creating enterprise software for profit, you slot into one of three basic categories:
- You’re focused on the value the solution can provide to the customer. Think product managers.
- You’re focused on the feasability of getting the product actually built and running. Think developers (aka programmers and coders).
- Or, lastly, you’re focused on usability – ensuring the customer’s users can actually understand the product’s capabilities, use these to achieve business goals, and do so as quickly as possible and with the least amount of training as possible. All of this is the province of User Experience (UX). And this is an article about that most fundamental layer of design in UX, the one that UX designers start with.
Just as you wouldn’t start building a skyscraper without a blueprint, you wouldn’t start coding an application without a plan as to its intended purpose, structure, and users. In UX, we broadly refer to such considerations, collectively, as the product’s “Information Architecture” (IA). IA is a poorly understood concept, but an important one, especially for those who build or use health IT applications. Below are eight basic things to know about IA.
Table of Contents
IA is not AI
‘IA’ stands for information architecture. ‘AI,’ being the big, hot-button term we’re all familiar with, stands, of course, for artificial intelligence.
IA is not technical
‘Data architecture’ and ‘information architecture’ are two different things. The former has a direct effect on the technical dimensions of a shared information environment (such as IMO Studio). The latter has an indirect effect and sits at a higher level of abstraction. Deciding to migrate from AWS to Azure, for example, has implications for your data architecture, but not for your information architecture. The latter need not change. Put in the simplest (if not the most reductive) terms possible, data architecture is for computer science majors. Information architecture is for humanities majors.
IA is complex
In what is probably the most well-respected book on the subject of IA, the authors offer four discrete definitions and write, “Were you expecting a single definition? Something short and sweet? Dream on!”
Of the four definitions they offer, the one most germane to our UX initiatives at IMO currently is this one:
The art and science of shaping information products and experiences to support usability, findability, and understanding.
IA is invisible
So much of what UX designers do can be pointed to by users and other stakeholders. A nicely logical click-through of sequential screens. A beautifully laid-out webpage with engaging colors and images. Delightful micro-interactions featuring fashionable icons and entertaining animations. But when it comes to IA, there’s nothing the user can see or point to.
Think of it like chess. What do you see? A checkered grid of squares and an array of symbolic game pieces. With these, would you have everything you need to play the game? What if you didn’t know the rules? Could you play then?
No, of course not. In this analogy, IA constitutes the rules. The UI is just the checkerboard and game pieces. Without an underlying framework describing their meaning, purpose, and capability, they’re useless.
It is true to say, therefore, that the single most important dimension of chess (and our software, analogously) is always unseen. This is as it should be. Be assured, however, that if it’s NOT there, your users will notice. And not in a good way.
IA is more than just sitemaps
While it cannot be seen, IA can absolutely (and usually must) be described! UX designers describe things in the artifacts they create and socialize. The IA artifact we’re all most familiar with is the sitemap.
All Web-based information environments should have a sitemap, but as its name implies, you wouldn’t stop there unless you were dealing with a static website.
For expansive, dynamic and complex information environments, IA artifacts can include similarly expansive and complex “service blueprints,” “strategy reports,” and “content models.”
When you’re looking at a diagram in relation to a design effort, odds are you’re being invited to understand its information architecture. In such artifacts, nuance is flushed out, meaning is assigned, and distinctions formalized. These aren’t nice-to-haves. They’re vital and foundational.
IA encompasses four key “systems”
Because consistency drives usability, not every design decision can be handled anecdotally, or in isolation. And to drive consistency, one must systematize. Therefore, most web-based information environments invoke four discrete “systems” that guide its use.
As with chess, IA describes the rules for each of these four systems. In chess, rules facilitate gameplay. In software, rules promote usability, findability, and comprehension. The four systems are:
- Organizational
- Labeling
- Navigation
- Search
It wouldn’t do, for example, to navigate parts of your enterprise application using breadcrumbs, and navigate other, similar parts, with the browser’s back button. If you’re having this conversation, you’re talking about IA.
IA is driven by research
The UX charter is to ensure your product is usable. The UX team cannot do that until we ourselves understand its purpose and business context. Often, we cannot fully understand its purpose and business context without research.
Indeed, the success of your product will occasionally teeter on the knifes’ edge of your designer’s curiosity. Pretty comps* hastily tossed into the implementation meat-grinder without a foundation informed by research can doom adoption as sure as the sun rises in the morning. The short-term gain of “yay, we’re making demonstrable progress!” is rarely worth the long-term pain of “oh dear, no one’s using our product.”
When UX talks about research, we mean activities such as these:
- Stakeholder interviews
- Analysis
- User story mapping
- Heuristic evaluation
- Content mapping
IA is probably what’s happening while you’re waiting for UX
Whatever form it takes, in whatever phase it’s in, IA is vital. And so far we’ve described it as invisible to the user and as something that involves research. Unfortunately, these two facets can make it difficult for product stakeholders to understand just what the heck is taking UX so long to whip up a few screens and hand them off to dev. The reality is that research takes time and what it produces isn’t easily captured. And because IMO’s products invariably involve highly-complex, arcane, and nuanced medical data, UX research cycles will occasionally take more time than they would if we were selling widgets.
At IMO, we gladly take that time – at every stage – to help build the best possible clinical terminology, normalization, and data quality solutions. That is our commitment to one another, as colleagues, and to all of our customers across the healthcare ecosystem.
To learn more about IMO’s suite of solutions, click here.
*short for “comprehensive layouts” which describe for developers what the screen or screen components should look like.
