The men who are cursed with the gift of the literal mind are the unfortunate ones who are always busy with their nets and neglect the fishing.
– Rabindranath Tagore, Sadhana
Modeling is the most critical underused design skill. The ability to examine a domain abstractly — to consider its components, how they relate to each other, and how they allow people to achieve their goals — is essential to designing complex systems that balance the needs of users with the organization’s strategic goals and, more broadly, social well-being.
And yet, few design teams work at this level. Most are wrapped up in discussions about UI-level work. We need to think in terms of systems, not screens. The teams that develop “design systems” (a phrase I increasingly dislike) do so to gain cohesiveness and speed — not to liberate themselves to work more abstractly. The result is visually consistent (and maybe even pleasing) shells over ill-considered systems.
If you have a good design system, you can hide the fact that you're not very good at interaction design.
— Fredrik Matheson (@movito) January 24, 2021
Case in point: @MicrosoftTeams "start new call" window. At first glance, it looks well-organized and easy to operate. Can you see what isn't working here? (Hint: Fitts's law) pic.twitter.com/O5M8ijAXGE
Much of my teaching these days converges on modeling skills. It’s the focus of the first third of my graduate systems class at CCA and the hands-on activities in my current professional workshops. There’s a sense of urgency in getting the word out: As we move more of our social interactions online, we need to find ways of ensuring digital systems genuinely serve our needs. We can’t do it by focusing exclusively on screen-level interactions.
There are several models to consider. I often focus on three:
- mental models, which represent users’ understanding of the interaction domain,
- conceptual models, which represent the concepts and actions systems must expose to users, so they can accomplish their goals, and
- implementation models, which represent how we will implement the system.
Many people conflate these three models, but they serve very different (and complementary) needs.
Mental models are the easiest to understand. Many designers are already familiar with Indi Young’s book on the subject or have seen diagrams from the book. The popular “jobs to be done” framing also treads this ground. Designers have methods to get a high-level understanding of users’ goals and expectations. It’s one of the key outcomes of solid user research.
The other two models are harder to get across.
Conceptual models deal with the concepts a system must expose to users, so they can achieve particular goals using the system. If the system is a bank’s website that lets you pay your credit cards, it must show you several key concepts, including credit card and bank account. Some concepts might have variants (e.g., internal bank account vs. third-party bank account.) Each concept must enable and accept specific actions (e.g., transfer, pay, set up, edit, etc.) The conceptual model aims to clarify distinctions between these concepts and explain the relationships between them.
When mapping a conceptual domain, it’s easy to get tripped up with implementation details. When we start rendering distinctions and relationships, we may start thinking about the system’s technical capabilities and constraints and how we might use them effectively and efficiently. The ensuing implementation model is an important part of the process, but it’s different from the conceptual model.
Some of us — especially the more engineering-minded — may be tempted to add implementation details to the conceptual model. It’s a mistake. The conceptual model should focus on serving user needs, including making the system understandable to people with different proficiency levels. We must think about how we’ll implement the system, but this comes after we’ve thought through what we’re implementing.
Ultimately, we want to understand 1) how users think about the subject domain and 2) what the system needs to show them, so they can get things done. Some subject domains might be very familiar to users, in which case there isn’t a wide gap between 1) and 2). But some domains will be unfamiliar, in which case 2) must be carefully designed to level-up users’ understanding. Knowing how the system might be implemented will ease the design process, but we shouldn’t confuse the system’s technical implementation with the concepts it must present.