All kinds of people use models. Economic models, for example, help economists make sense of complex relationships between entities engaged in trade. Meteorological models help climate scientists predict the weather. These models are themselves complex, but they are simpler versions of the underlying system. The system itself might be chaotic, but the model renders it accessible to us. Simplicity by degree.
In designing web sites I create models that visualize the sites’ underlying structures. Look under the hood of a run-of-the-mill e-commerce site, for example, and you’ll see an elaborate network of concepts. Product families? Product versions? Product variations? Related products? Compatible products? Dependent products? Sadly, there isn’t a one-size-fits all scheme that makes sense of all this. Selling cybersecurity solutions is different from selling sports equipment.
I know what you’re thinking, only because I’ve heard it before: Why make things so complicated? Why don’t you just design some screens and see what works?
Here’s why I like using models:
Models give us a common language
When you’re talking about complicated things, it helps to use a consistent vocabulary.
- For example: Working on a site about educational materials for kids, the metadata conflated topics (like dinosaurs and space) with hobbies (like cooking and crafts). To make sure we knew what we were talking about, I included normalized language in the site’s structural model.
Models highlight the essential relationships
A key aspect of models is showing the way ideas connect to each other. Drawing attention to some relationships gives them more weight, and perhaps implies they need to be expressed in the user experience.
- For example: On this kids educational web site, there are online resources for parents related to the kids content. It was important to show the relationship between the stuff for the kids and for the parents. I used the model to reflect these relationships.
Models help us understand what’s important
By elevating certain concepts in the model, you’re making sure you pay attention to them. Ultimately, your design work will reflect these priorities.
- For example: Early in the project with the kids educational content, we realized how important it was to nail down different usage scenarios. We created a model that exposed how the experience changed for a user over time.
Models expose new ideas
Perhaps most importantly, models give us a view into these complicated ideas. They give us something tangible, so our explorations into and considerations of these concepts are tactile.
- For example: By modeling usage scenarios, we identified different ways to market the site to prospective users. Knowing parents would be looking at certain types of content based on how they got there, we could anticipate positioning sign-up appropriately.
In short, I can’t design a screen, much less form a hypothesis, unless I have a better understanding of the site’s underlying concepts.
In 2014, Christina Wodtke asked me to meet up with her to talk about modeling. I’d done a few concept models, like the Passover one above, and written about them in my first book, Communicating Design. She wanted to interrogate me about my process. She invited Stephen Anderson along, a master visualizer. Christina recorded the outcome of that conversation, and several others in a mini-memoir of visualizing: How to Make a Concept Model.
It was a conversation that, apparently, stuck in Stephen’s head. Now a couple years later, Stephen reveals his concept modeling tiles, a physical tool that describes aspects of modeling. He explains that while other sketching/modeling books focus on the recipe, he wanted to expose the underlying frameworks and elements that tie them all together.
Not me. As I reflect on my process for modeling, I see how much I rely on recipes–pre-existing patterns. My thought process entails applying one of these patterns to the concepts, the “ingredients” that come from the system I’m trying to model. I have a handful of starting point “templates”, and when it’s time to create a model, I pull one out and apply it to the topic at hand.
Modeling isn’t just about the finished product. It’s about the process, too.
Mostly I start with a list of ideas that go together, and see what emerges after moving them around the page a bit. After an iteration or two, I start to see the essential themes, what I call the central story, what I want people to take away from the model. The final product may not look like the original template, yet the template is crucial for me to wrap my head around the system, and find that story.
Applying these templates happens in parallel to my ever-increasing understanding of that story, implying that modeling isn’t just about the finished product, but the process, too.
These are the templates I use, time and again:
When I’m thinking about a process or a flow, I generally start with a series of steps, a simple linear model. Linear models may not be the final output, but they provide a strong backbone as the starting point. Most user journey maps start out as a linear model, a description of the process users undergo to achieve a goal. Research and elaboration helps us identify edge cases and divergent scenarios.
Nathan (my business partner) created a simple model to explain his framework for managing design systems. Start-Spread-Sustain is, essentially, a linear model, explaining that organizations must first build a basic design system, grow the number of products using it, and then establish processes for maintaining it. Reality is, of course, far more complex. Activities may overlap or double-back, but this language helps organizations picture the trajectory.
If one template dominates my portfolio, surely it is the triangular model. My worldview apparently skews toward seeing things as three interconnected concepts. I love that triangles have points, and that every point is connected to the other two points: no relationship is excluded. I love that I can speak about the points or the relationships between them, which can serve as connectors or intersections. I love that triangles are stable shapes and can serve as the foundation of a more complex diagram.
For a workshop on design management, I’ve been thinking about what designers want. Managers need to understand not just their team’s aspirations, but what it takes to nurture them. After brainstorming a list of essentials, I grouped them together, seeing (of course!) three key aspects emerging. Once those were arranged in a triangle, I saw that those aspects could vary by degree, and that a designer’s capability governed them. “Capability” became a fourth aspect, the point of a tetrahedron, connected to the three others.
The two-by-two is the classic framework used by business management schools the world over. Plot two scales against each other and you have four quadrants. These four quadrants represent different extremes or states, and each one has a unique relationship to every other one.
When I began thinking deeply about the early portion of the design process–what some people call discovery or strategy–I realized that linear models were insufficient to describe it. Discovery is inherently chaotic, with activities following the needs of the product. Insufficient insights about users means cranking up the user research. Lack of clarity around the design problem means sketching ideas to shed light on what works and what doesn’t. This model sought to describe the relationships between those activities, and moreover explain why this chaos exists.
Similar to the two-by-two, a matrix plots interesting data points on two axes. These axes could be anything, though we often see time as the horizontal axis and some other value as the vertical. Project plans are a type of matrix, with chunks of time plotted horizontally and workstreams or tasks or team members plotted vertically. EightShapes uses a tool called a “doneness matrix” to measure the completeness (horizontal) of individual design elements (vertical).
For the educational content site, I used a matrix model to describe how templates changed in different scenarios. The scenarios ran horizontally, and described situations like “not logged in” or “first-time user”. The vertical axis captured the different templates we’d designed. At each intersection, say topic + first-time user, I showed a thumbnail of the screen. Looking up and down, we could see how, within a given scenario, each template compared. Looking across we could see how a single template changed in different scenarios.
When someone compares their web site content to an iceberg or their product concept as “Fitbit for home cooks,” they’re using metaphor. Metaphors can be powerful ways to model complex systems, drawing parallels to a familiar, simple concept. Metaphors like icebergs and Fitbit have prominent features that help amplify aspects of your concept. They imply a specific framework (eg: 90% of something being invisible) which may illuminate your concepts in a new way.
In working with the American Chemical Society to establish a strategy for their online search, I sought to explain the complex interrelationships of search. It was difficult to escape the idea of an ecosystem, which beautifully captures the interactions between content, keywords, and the search engine. Ecosystem, however, is decidedly in the life sciences. The right metaphor was staring me in the face: a chemical reaction. I used an equation to show how great results depends on the right combination of elements (content, keyword, and metadata).
One model I’ve been using more and more is the card. I don’t know if it’s my personal obsession with board games, but cards are appealing for modeling complex things. With the card model, each aspect of the system I’m modeling gets its own card. At its simplest, a card has a short phrase describing the concept. I can add a short description. I can adorn cards with additional categories (suits? teams?) and metadata (baseball stats?). Suddenly, a once complex abstract system has a tangible representation. If you can break your concept down into a set of components, you can create cards.
Since developing Surviving Design Projects, a game about conflict resolution on creative teams, I frequently use cards to model behaviors. Behaviors have different tenors and intents. Cards allow me to identify behaviors by these different “suits”. This example is a slide from a workshop on collaboration describing how principles of optimizing projects manifest as “moves” you can make. To make sure a project scope is fully defined, for example, you can Examine Minutia of Project Definition.
For another project, I worked with my stakeholder to develop a five-year strategy for their web team. At the end of the project we modeled their strategy using a set of cards, where each card represented an initiative. We had six “suits,” describing various types of initiatives like standards, process improvements, and working groups. The initiatives aligned to four different areas of focus and 10 different programs. Because we condensed initiatives to a set of cards, we could show how a single initiative reflected each of these perspectives.
This list is not comprehensive: there are lots of other templates for visual models (circular orbits, Venn diagrams, org charts) but the six above tend to be my favorites.
Models may start out in one of these templates, but only as a way to get something on paper, to see how the system’s components relate to each other. These initial forays help me understand what questions I still have. They help me recognize what’s important and interesting. They help me form a story.
Looking for more great advice on documenting design decisions? I wrote a whole book on the topic, now in its second edition. Communicating Design is for sale at Amazon.
Need help modeling your digital product or defining a strategy? EightShapes can contribute or drive projects to get you to a product definition and vision. Find out more at eightshapes.com.