A Toy Universe in Our Heads
The image of the world around us, which we carry in our head, is just a model. Nobody in his head imagines all the world, government or country. He has only selected concepts, and relationships between them, and uses those to represent the real system — Jay Wright Forrester
This is nothing new for any user centered designer, but considering Jay’s hypothesis, product designers must be especially deliberate and careful to mitigate the seeping complexity of software.
Below, I’ve paraphrased three unique, modern thinkers, as they discuss the subject of mental models, and how they relate to software design.
First, Venkatesh Rao, speaking to Shane Parrish on the Knowledge Project.
- Mental models are more about internal consistency than how the world actually works.
- Why? The universe is an extraordinarily confusing and complex place.
- We’ve evolved to process the firehose of information of life in a way that allows us to map it to a ‘toy universe’ inside our heads.
- For our mental models to be effective they have to be both simple and internally consistent.
That’s the function of mental models: simplicity and coherence.
Next up, Alan Cooper, from his seminal 1995 book About Face.
- “Software interfaces are often designed by engineers who know exactly how the software works.”
- “…the result is software with a manifest model very consistent with its implementation model. This is logical and truthful, but not very effective. The user doesn’t care all that much about how a program is actually implemented.”
- “…the complexity of implementation can make it nearly impossible for the user to see the connections between his actions and the programs’s reaction…Even if the connections were visible, they would remain inscrutable.”
Software that doesn’t consider the mental models of the user, or maps too closely to the specifics of implementation, is doomed to fail (or hard to use).
Finally, enter Daniel Jackson, speaking on the subject of “ Rethinking Software Design”.
- Both designers and developers of software are largely concerned with system and the users of the system. But like in construction, their goals diverge.
- If the goals of an engineer is to ensure a stable, performant, correct, maintainable system, the goals of the designer are largely making the system enjoyable, learnable and effective for the user.
- The developer uses elements like functions and objects to achieve their goals and the designer has ‘concepts’ that explain how software works.
- For example, Twitter can be explained by the concepts of ‘tweets’, ‘hashtags’ and ‘following someone’. These small concepts help explain the system, and help people to use it. Twitter would be pretty hard to understand if you didn’t get the concept of following.
- Concepts can be evaluated by the purpose that drives them. For example, the purpose of the ‘trash’ concept, is to “allow undo of deletions.”
- And purposes, are really just the structured needs of users.
The challenge is, how might we talk about the purposes and concepts we design in practical terms? In my experience, software designers spend most their time in the weeds rather than in ivory towers. Theory is quickly brushed aside if it’s not useful to shipping and iterating work.
At the very least, Daniel’s ideas are a helpful frame to evaluate work and determine what ‘successful’ software might mean in your context.
And remember, don’t recreate the universe.
