Information architecture (IA) is a complex subject. The term IA can encompass a wide variety of design considerations and methodologies. I’ve recently run an IA project that focuses on a few aspects of our documentation site, so I decided a post about it may be interesting. I’m hoping the post may help people to wrap their minds around IA before getting into the nitty gritty of such a large topic.
In essence, the focus of our recent information architecture project was to help readers find the information they need. We focused on developers, because they form a significant part of our audience. We looked at three user flows:
- Entering at the top of the site, looking to explore the products.
- Entering the site on a page that’s deep in the information hierarchy, coming from a web search or external link and looking for a specific answer.
- Using the information on a given page.
I’m using the term “top of the site” to mean the conceptual, introductory pages that usually occur first in a navigational structure.
Readers entering from the top of the site
Some readers enter the site in exploratory mode. By that I mean they’re looking for an overview of the product or products, and want to be led through the concepts in a logical flow.
The destinations of your links depend on your analysis of where your readers want to go. For example, user research may show that people want to see a product overview followed by a getting-started guide. Your organisation may also want to help people find a summary of support options or contact the sales team.
Readers entering the site on a specific page deep in the information hierarchy
Many readers enter a site via searching on the web, or by a link that someone else has supplied in a forum or a help article. These readers start their experience of your site on a page that’s deep in your hierarchy of information. They may find the answer to their specific question on the first page they land on, but then they probably want to learn more about the product or tool. Or perhaps they don’t find the answer on the first page they encounter, and they want to look further.
In this case, the navigational elements on and around the page are very important. People need context, to figure out where they are and how they can move around the site to get more information. Here’s a good way to think about it: Every Page is Page One.
Readers getting information from a given page
The structure of a page is an important part of information architecture too. The page needs to provide context, perhaps simply in the form of the navigation aids discussed above. The page may also need to cater for readers who already have a good technical knowledge, and just need a quick orientation of where and how to do something. Other readers may need a detailed step-by-step guide.
In the case of API documentation or other developer-focused docs, the quick guide may be just a code sample, as we discovered in our recent user studies. There’s some information in my post about the Google Maps APIs tutorials.
More about IA
That was a quick introduction to some concepts of information architecture. Here’s more detail from various sites:
Tech writing and IA
Do you have any experiences to share about technical writing and information architecture, perhaps from a different angle that what I’ve described? I’d love to hear about your experiences too!
This week I’m attending STC Summit 2014, the annual conference of the Society for Technical Communication. Where feasible, I’ll take notes from the sessions I attend, and share them on this blog. All credit goes to the presenters, and any mistakes are mine.
This session will look a practical examples of top-down and bottom-up information architecture and will illustrate where top-down fails, and how to create a bottom-up architecture to replace or to supplement your top-down approach.
Traditionally, information architecture organises knowledge from the top down. As examples, Mark showed us the Map of the System of all Human Knowledge from the Encyclopedia of Diderot & d’Alembert, the Linnaean classification system, and the Dewey Decimal system.
One of the simplest forms is the table of contents. You start with a general concept, and then drill down to the details. Such classifications tend to end with a category of “miscellaneous” items.
Sometimes tables of contents even act as a classification scheme, such as a clickable classification of organisms.
Another form is a system which lets you find out what medical problem you have, by progressively narrowing down your symptoms.
Mark showed us other examples of hierarchical organisation of data. Then he showed how hierarchies don’t necessarily meet a user’s needs. For example, if you’re looking for a convertible car, and the information on a car sales site is organised by year/transmission/price… and eventually by body type, you’ll need to move up and down the hierarchy a lot before you find what you want.
We will never find the hierarchy that will suit all users’ needs, because people have different needs.
Such systems let you choose the things that are important to you. For example, a car sales site may have a set of various selection criteria in a side panel, such as price, transmission, mileage, year. You can choose to fill in some selection criteria and not others, and so find what you need.
There’s a big technological difference here. Paper can’t provide faceted classification, but computers can.
This is still top down. It’s a collection of taxonomies that define the things people are interested in, with respect to buying cars. It works, because most people buying cars know this particular taxonomy. But it won’t help people who don’t know the taxonomy. There are still classification problems.
Experts classify, the rest of us name things
A nice quotation from Mark:
“Experts classify. Everyone else names.”
Looking at flowers, and pansies in particular, the scientific classification of a pansy isn’t particularly useful to most of us. Looking at a Google search for common names of pansies:
- Searching for “stepmother flower”, you find plenty of information and images for pansies. That’s good. In such cases, a search engine like Google works.
- Searching for “football flower” shows images of pansies, and also of footballs made of flowers. Some good, some potentially confusing.
- Searching for “Three faces under a hood” is particularly interesting says Mark. Looking at the images, you see a pansy (good), a girl in a hood, two people under the hood of a car, and a composite photograph showing the three faces of Mt Hood.
None of the classification systems scale well. Tables of contents can get immensely long. Mark showed some examples from a book and an online help system.
There’s often too much variety, which leads to complexity and unevenness
Mark quoted David Weinberger: “Everything is miscellaneous”.
Everything flows to the Web
We shouldn’t attempt to push content into channels. Reuse is a big subject, often for the sake of being able to deliver the same content to multiple channels.
Problem, says Mark! There are no channels any more. All content flows to the web.
If people search for something on the Web, they will find the most popular hit – which will probably be your most popular product, even if published a few years ago.
Moving towards bottom up
What happens when someone does a search and ends up on a page in your content? They don’t start at the top. They start on the page that Google sends them to.
Mark isn’t saying we should throw away all the top down architecture. But we do need to start adding bottom up information architecture to our content.
Looking at Wikipedia: it’s highly organised. There are various links and ways to move around. But it’s not ordered. Organised, yes. Ordered, no. The links point to related information, which provides a type of semantic clustering.
Dynamic semantic clustering
Mark showed us examples of information clusters that are dynamically organised:
- Twitter hash tags
- RSS feeds
- Forums. Sometimes these are organised by number of votes.
Linking interesting connections without making a bowl of spaghetti
Most of the problems that people find are the irregular associations, and multiple connections. If things are regularly organised, people don’t usually have problems. So we need to help people with the irregular associations.
In a bottom up architecture, it’s easy to link to the interesting associations. If you tried to map all these associations from the top down, you’d soon have an incomprehensible bowl of spaghetti. In a bottom up architecture, the links show connections that are relevant in this context.
“A topic in a bottom up architecture is a hub of its local subject space.”
How do you make sure people don’t get lost?
This was a question from the audience. Marks’ answer was that you have to design the content for a bottom up architecture. You can’t just take the content from a top down hierarchy and put it into a bottom up system.
You must build context into the subject matter. Context in the table of contents doesn’t matter, but context within the subject matter does. Every page is page one, so every page must start by establishing the context. “Where am I.”
How can you filter the links based on the reader’s context?
In a tech comm point of view, you must have a systematic design for linking. A taxonomy is vital here. So, a taxonomy is not used for generating a table of contents, but instead for organising your links.
What about procedures and workflows?
What if a sequence must be performed in order? Mark’s answer is that a procedure should be the subject of a single topic. In top down design, a table of contents should not express a workflow, although it often does. So, workflow is one of the most important use cases for a bottom up architecture.
A person from the audience mentioned that you can illustrate workflow via a progress bar or images illustrating steps, which can link to steps in a complex workflow.
Due to lively discussion with the audience throughout the presentation we ran out of time a bit, so Mark ran quickly through the types of topics in a bottom up architecture:
- Workflow topics. We mentioned these above.
- Pathfinder topics. These are about how you get from a business topic to an action in the system.
- Big picture topics.
Walled garden or bazaar
Mark finished by comparing the top down approach (a walled garden) to the bottom up approach (a bazaar). The main difference: in the pictures Mark showed us, the bazaar had people in it. 🙂
It was a pleasure and a privilege to hear you speak.
I’m attending STC 2012, the annual conference of the Society for Technical Communication. The first session on Tuesday morning is “Modeling Information Experiences: A Recipe for Consistent Architecture”, by Andrea Ames and Alyson Riley.
It’s 8:30 in the morning, and many people had a gooooood night last night. So tones are somewhat subdued. I’m yearning for another coffee. The presenters, Andrea and Alyson, are looking very game. They’ve promised to start on time, as they have a lot to say. This should be good!
Aim of the session
The aim of the session was to help people “deliver a consistent information experience across a broad set of content, audiences, or business requirements. Learn how user-centered experience modeling can help you deliver world-class information architecture. Explore examples from IBM’s work with abstract models and discover methods for using experience models at the team and enterprise level.”
A theme of the presentation was that information architecture (IA) is about both art and science. The art side of it involves creating a simple, elegant experience out of complexity.
The session is about defining a model. Models help us blend art and science in ways that give us consistent results. Note that a model is not the final result, the information architecture. Instead, the model is an abstract, to which you apply the details of your project in order to arrive at the architecture.
Building a model forces you to go through the process of knowing who your user is. The model is at a fairly high level, with the result that it is flexible and can scale. Building the model helps business people think, and helps the users think too. Models also help information architects to focus on user needs and business strategy. Models also encourage us to focus on the outcomes rather than on the rules.
The goal is an invisible architecture that allows people to focus on the things they need to get done. People (users) want to think about their goals, rather than about navigating our frameworks in order to get things done.
The four models in IBM’s information architecture toolbox:
- Use model
- Content model
- Access model
- Information model
A use model defines the ideal interactions between users and information: what people need, why they need it, what they’re doing when they need it, and how they’ll use it.
This model is a user experience concept, as well as an information concept. The use model for information describes things like this: If we need labels, what type of information does the user need about that label, and what combination of interaction and visual design can I create to give all the information the user needs?
You will use personas and role descriptions within a use model. You will also develop scenarios that describe how people interact with content, and what they are trying to do with it.
IBM’s content model is topic-based. The model defines the standard building blocks of content, from the atomic level to larger outcomes including subject, presentation, taxonomy and metadata.
Think about how you can reuse your atomic information elements, and help the company get more value from them. Perhaps you can make money from them, such as by exposing them on the web. The goal is to define standard information deliverables. Then you get into the templates.
Progressive disclosure is part of this model. This model brings together all the different access methods. It defines a vision of how people will find the information, including organisation, structure, search, browse, and more.
The aim is to define the overarching strategy for how people will access your information.
This is very much a model of models. It brings together the content bits, how people are using them, and how they can get to them.
For example, define what a common welcome experience looks like, or a common installation experience.
This looks like a lot of work. It doesn’t need to be. Take small steps, and start simply. Prioritise the most important goals for your business. For example, pick the area of navigation.
Alyson and Andrea believe that their models are largely(80-90%) transferable to other organisations.
For me, this presentation was a bit too abstract. The slides were text-based and conceptual. It would have been good to see some practical examples, or perhaps just walk through the steps of defining a simple model and how the model is used.
I admired the enthusiasm and energy with which Alyson and Andrea presented their information. It’s obvious that the models provide great benefit to their teams, business and users. It will be very interesting to see how well the models transfer to other organisations.
Last week I attended the 2009 Australasian Online Documentation and Content Conference (AODC) in Melbourne. This blog post is part of a series about some of the AODC sessions I attended.
Here are some notes I took from the session on a pattern language for information architecture, by Matthew Ellison. I hope these notes are useful to people who couldn’t be at the conference this year.
Pattern Language for Information Architecture
Matthew introduced pattern languages by saying that they may give you a practical way of capturing the techniques that work for you — a way of documenting the golden rules.
A pattern language is a structured method for describing good design practices within a specific field. Michael Hughes has done a lot of work on pattern languages in our field. Pattern languages establish a rule of thumb. They do not offer a rigid solution, but something you can use again and again when similar situations arise in a particular environments.
Pattern languages in architecture
Pattern languages were first developed about thirty years ago, originating in the architecture field. Matthew was very taken with Christopher Alexander’s book A Pattern Language: Towns, Buildings, Construction (1977). It even smells nice, says Matthew. The structure of the book, its pictures and diagrams, and the quaint language make it a book you can dip into and enjoy. It covers a wide field, from the design of towns down to the design of doorknobs.
Matthew showed us an example pattern from the book: “A Place to Wait”.
- The pattern starts with the problem: “The process of waiting has inherent conflicts in it.”
- Then it proposes the solution. As an example of the quaint language used: the pattern suggests that you should “…fuse the waiting with some other activity — newspaper; coffee; pool tables; horseshoes… where you can draw a person waiting into a reverie; quiet…”
- Then there’s a really cute little sketch of what a waiting area might look like.
Pattern languages for UI design
Another field that uses pattern languages is user interface (UI) design. Matthew showed us what such a pattern formula (template) might look like. Once again, they start with a statement of the problem, then tell you where such a pattern would be used. Next the pattern offers a solution and some form of illustration.
One such pattern in UI design is “Pagination”. Matthew showed us how the list of pages at the bottom of Google search and various other sites all fit this pattern.
Pattern languages for information architecture
What do information architects do? There are a few definitions. A good one is that information architects are responsible for the overall organisation of content.
How can design patterns help? They allow content providers to apply tested architectures to improve the user’s experience.
Matthew listed the following types of design patterns:
- Interface and layout (window and page layout).
- Structure of information and navigation dynamics (TOC, related links, popups).
- Content (information types, writing style and the way we assemble the content we write).
An example of an information architecture pattern: “Breadcrumbs”. The problem is: Users need to know their location in the document’s hierarchical structure, so that they can browse back to a higher level in the hierarchy. Matthew showed us some examples of breadcrumbs in various applications.
Suggested components of an information architecture pattern:
- The problem.
- Usage (where the pattern is used).
- The solution (a short bulleted list that describes the golden rule — fairly flexible and not too prescriptive).
- An illustration.
- The rationale (the reason why you would use this solution).
Matthew took us through some more information architecture patterns: “Content taxonomy”; “Signposting”; “Popups”. I don’t have any notes from this part of the session — I got too wrapped up in watching the examples. Matthew is sure to have the details 🙂
Michael Hughes proposed a design pattern for contextual help, to determine when and how we might use such help. Matthew showed us an example of embedded help from Microsoft Excel that conformed to the design pattern.
We looked at some design patterns in a few state-of-the-art online documents. One example is the UK Daily Telegraph online newspaper. Matthew discussed the design objectives of this site, and how they might relate to online documentation too. Notice the design elements, such as:
- Signposting and visual breadcrumbs, near the top of the page.
- Search, always at the top. Search is very important in all online newspapers.
- List of related articles.
- Related RSS feeds.
- Link to in-depth background information that supports the story.
- Link to feature article.
Comparing a sports report and a current affairs item, they are visually and spatially very much the same. This makes it easy to use these newpapers online.
We also looked at a government site showing UK planning and building regulations. It also has a standardised pattern, with each element in a predictable place.
How can we define our design patterns?
Matthew suggests the following steps:
- Create your pattern statements (problem, usage, solution, rationale, etc).
- Decide whether the pattern statements fit into a style guide.
- Decide whether to enforce your patterns, e.g. by building them into an XML schema or DTD.
There are different opinions about whether a design pattern would fit into a style guide. IBM talks about enforcing your design patterns in structured authoring via XML, e.g. as DITA topic specialisations or map domains.
Thank you for another very cool and informative presentation, Matthew.