In his preface to Information Architecture: Designing Environments for Purpose (2004), Peter Morville wrote about the origins of the polar bear book. He said:
Lou [Rosenfeld] pitched the idea of an information architecture book to Lorrie LeJeune at O’Reilly in 1996. She didn’t bite. But a year later, she called us back. At industry conferences, Lorrie kept hearing web developers complain about a pain with no name. Users couldn’t find things. Sites couldn’t accommodate new content. It wasn’t a technology problem. It wasn’t a graphic design problem. It was an information architecture problem, we explained, and so began the book.
A pain with no name. The phrase has stuck with me. I’ve seen many teams experiencing this strange affliction. You know it’s the pain with no name because sufferers don’t know how to describe it. They know how to talk about usability issues, accessibility issues, and technology issues. They know when the logo needs to be bigger, or when pages aren’t loading fast enough. But the pain with no name eludes them. Something isn’t right, but they don’t know how to describe it. They may tell you people aren’t using the system because it’s missing key features, or that they spent a fortune on the redesign and users aren’t responding as expected. But they don’t know how to point to exactly what’s wrong with the thing.
Often, what’s wrong is that they skipped a critical step in the design process: they didn’t work through a conceptual model of the system before moving on to creating its user interface. A conceptual model is an abstract representation of:
the main concepts the system will expose to its users,
how those concepts relate to each other to help users accomplish their purposes within the system, and
the language that will be used to describe those concepts so users can understand them.
In other words, it’s an articulation of the system as a whole (as opposed to its components) as users will experience it. Producing solid conceptual models requires that designers understand the components of the system, the causal relationships between them, and the mental models users bring to the interaction. Therefore, they require research and iteration.
Conceptual models make stakeholders nervous. Why? Because they’re not user interfaces. Stakeholders want to see progress. They expect designers to produce artifacts that look like screens. Conceptual models don’t look like screens; they’re “boxes and arrows” diagrams. Getting to the stage where you can produce a conceptual model takes lots of work, and at the end of that effort, you have… a diagram. Developers can’t do anything with abstract diagrams; they want specs they can build against. Executive Vice Presidents can’t do anything with them either; they want comps to drop into PowerPoint decks. Conceptual models don’t help them do their jobs. They’re also difficult to validate on their own because many people have a hard time mapping abstract diagrams to user interfaces.
As a result, conceptual models are often seen by both designers and stakeholders as a burden. They resist calls to work them out. But conceptual models are the opposite of a burden. A good one will clarify hidden complexity and highlight overlooked opportunities. It’ll guide the team to produce user interfaces that are coherent, clear, and solve real problems for the user. Conceptual models help teams avoid the pain with no name. Alas, as with the pain with no name, many people don’t even know what to call them or how important they are. But now that you do, you can help relieve their pain.
Amazon links on this page are affiliate links. I get a small commission if you make a purchase after following these links.