With the migration of traditional SaaS apps to microservices, information architecture has gotten more and more relevant for good design. Information architecture is the design of information to enhance accessibility and organization. It’s the point where design meets workflow efficiency.
There is a bit of a split between big IA and little IA. Big IA affects every part of the design process to optimize workflow and information efficiency. Little IA is more concerned with making sure information is focused on presentation and retrieval. Big IA includes little IA, but little IA is much more specific in its application.
Why Big IA
There’s ultimately a disagreement between whether big IA or little IA is most applicable in design. Some design purists argue that information architecture should stay its lane and focus on how information is accessed and used in isolation and design should trump this. This approach isn’t necessarily wrong, but it’s definitely a bit misguided in most applications.
Thinking in terms of big IA means thinking in terms of the big picture. How the data is used by the user is just as important as how the data is accessed. A purist approach can be used when designing the actual data processing, but the human element needs to be considered at all times. An app which is theoretically the best but lacks the polish to attract users probably won’t take off or make it.
Big IA and User Experience
Big IA factors into how information is used as well as how it is stored, accessed, presented, etc. How is your data going to be used? If you can’t answer this, then how do you have any hope of storing it efficiently? When is it better to be more right or quicker?
These are all questions which need to be answered to properly design an app or site. Sometimes it’s worth throwing out a bit of accuracy (e.g. cached data for faster calculations) for speed and efficiency. If the data is just to see a trend, but is used a lot, it’s almost always worth making faster. You may want to round or otherwise format data if there’s a lot of data on a page and it makes it easier to fit necessary data in. Use case dictates function which dictates design.
The user experience isn’t just composed of the appearance, but how smoothly everything comes together. How accessible is the site? How intuitive is the layout? These are all things which need to be considered to bring information architecture in line with the user experience.
IA in Microservices
Sane handling of information architecture becomes even more important with microservices. Since microservices tend to be distributed, the ease of accessing data determines how well a solution works in a practical sense. Each inefficiency creates a bottleneck in the overall process.
Where does your data ultimately come from? Are their inefficiencies with how you access or store the data? Can these inconsistencies be overcome? The more of these questions you can answer, the easier it is to shape your overall process for a smooth user experience and a smooth development process.
Sometimes, the inclusion of a process to cache data and the latency it entails is worth it. Other times, the slow down and inefficiency of gathering data live is required for accuracy. Weigh what is required and what is acceptable for each given function. A page may have multiple forms it can take with each being equally correct for different use cases.
If you use a REST API for your microservice, you especially need to shape how it provides data. Do you provide JSON, or something else? Most REST APIs use JSON, so if you don’t, do you have a good reason to not do so?
Does your API allow bulk calls or is it limited to a call at a time? I’ve seen REST API decisions turn a service into a massive heap of technical debt from not scoping everything out ahead of time. A shortcut today can be a headache for months.
Big IA in UI and UX
UI stands for User Interface and UX stands for User Experience (with the implication of being a process). The UI needs to comply to the principles of the UX in order to work. A UI which doesn’t fit the UX leads to a product which is disjointed at best, and nonfunctional the rest of the time.
Information architecture impacts the UI for both big IA and little IA, but big IA affects both the UI and the principles behind little IA. The way information is applied and presented affects the user experience which affects the design. As the process of development continues, the design affects the user experience which affects the information architecture. They are all intertwined.
Applying Big IA to UI and UX
Despite the fact that IA, UI, and UX are all interconnected, there has to be a conscious effort to complement the various stages of design. A great user interface which doesn’t fit the ideal user experience is a waste after all. A workflow must be designed, then the information architecture and UX design needs to flow from it. The UI is the actual implementation of these two complementary forces.
Storyboard out your product. What is each page which is necessary doing? You don’t need it to look good (yet), but you have to know what the purpose of each page is and what the data is used for. As you refine the vision of how the product works, you can understand the flow of data in the context of user experience.
Focusing on the whole allows you to then refine the individual bits. A responsive panel needs to be fast, but a drill down into the data needs to be accurate. You can save time on the panel by knowing that the data can be cached while spending more time tweaking the query for the accurate pages so it’s smoother.
Big IA is UX. UX is big IA. The two become one in the same, but stay two sides to the same coin. As one gets better, so does the other unless you’ve missed the mark badly.
Seeing the Trees for the Forest
It can be alright to sacrifice a bit of accuracy for speed for certain things, but where do you draw the line? In my opinion, the whole debate of big IA versus little IA stems from purism. Should we draw the line for information architecture where traditional UX begins or should we let them flow naturally into one another? I let them blend and go with the flow, but don’t lose sight of what makes each one distinct.
Taking a purist approach can help even if you are strongly in favor of big IA. As you refine the more general UX concerns and how information interfaces with them, you can focus on the actual application of information as it is stored and retrieved. A forest full of sick trees isn’t good for much, so make each individual bit as good as you can. Don’t let a disease in the process fester because all you saw was the canopy.
Putting It All Together
Whether you are a proponent of little IA or big IA, thinking in terms of big IA can help change the design to focus on the overall user experience. If you fail to apply information architecture in the design of your product, you end up with bottlenecks and inefficiencies. A product which is polished but doesn’t tie everything together ends up disjointed and fractured.
On the other hand, a product which only focuses on the whole might miss many smaller issues which leads to an inefficient product. Focus on the whole, but don’t forget to make sure the details are good too. By applying techniques from big IA into UX and UI design, and tempering them with attention to detail and idealistic purism, you can design a product which looks good, works well, and is easy (or at least easier) to develop and maintain.
Featured image by Public Co from Pixabay