Can your users find the information and functions they’re looking for? Can your users understand the concepts and terminology used in your application?
Information Architecture is concerned with organizing information – concepts, entities, relationships, functionality, events, content – into a coherent structure or “information space” that is comprehensible, navigable, and searchable.
Information Architecture is a broad term, and not everyone agrees on what exactly the field covers. At the minimum, it involves naming and classifying concepts and entities, planning a navigation system, and designing search functionality. For most software projects, I would argue that Information Architecture should also include many parts of an application’s general conceptual design, including the framework for how users perceive tasks, workflow, and the saving of content or data.
Let’s explore some of the aspects of Information Architecture that you’ll need to think about when planning and designing a new application or website.
For “static” websites and applications that are mostly geared towards letting users browse and search content as opposed to creating or working with content – most intranets, library sites, static content websites, and e-book readers fall into this category – you generally need to consider the following:
- Domain modelling
What are the concepts, entities, and events from the business domain that are represented in your application, how are they related, and what constraints are involved?
- Naming and labelling
Are the concepts and entities named clearly, correctly, and consistently? Names are what the human mind uses as a simple “handle” for complex or abstract concepts, names help us distinguish one concept from another, and names allow people to reason about and discuss concepts, so a proper naming system is critical for making a complex system learnable and usable.
Can some or all of the concepts or entities be organized into categories and hierarchical inheritance relationships?
- Navigation and wayfinding
How does the user move around the application and access content or data? Is there a content hierarchy such as a table of contents or a sitemap, and how frequently is it likely to change? How does the user perform navigation – by means of menus, trees, maps, hyperlinks, or other controls, or is navigation primarily done via searching? How does the user know where in the application or content hierarchy they currently are? Are there some navigation targets (e.g., pages, screens, or dialogs) that are only accessible in certain contexts, such as part of a task sequence?
- Search and indexing
How is search functionality presented to the user? What search options are available? How are results presented? How is content indexed and how is data queried for fast retrievability and optimum search results quality?
- General visual presentation
How are typography, iconography, color, layout, and other design elements used to establish a consistent visual language and visual hierarchy that will (1) communicate the relative importance of the elements, and (2) reveal the relationships between entities?
For “dynamic” applications that allow users to create or edit content or perform processing that changes the state of the application’s data, then in addition to the aspects covered above, you also need to consider the following aspects, which I would argue are also part of the application’s Information Architecture:
- Tasks and workflow
How is the application’s functionality presented? How are tasks selected and how are they completed? For tasks that involve processing by multiple users, how are the tasks and their intermediate states managed and presented?
- Transaction and persistence concept (user-level, not technical)
How and when is the user’s work saved? Does the user have to click a “Save” button or are all changes saved automatically? Are database concepts like “commit” and “rollback” exposed to the user, or hidden? In a concurrent environment, what happens when two users try to access the same data simultaneously? Are records or files locked to prevent one user overwriting the other user’s changes, or is another strategy used? When do changes become effective or visible to other users? Is a history of versions kept?
Does all of this sound complicated? Don’t worry – over the next few months, this blog will gradually but systematically address everything you need to know to successfully design the information architecture for your application.