A Toy Universe in Our Heads
In which three random guys, talking about three semi-related things, show us how to design better software.
First, Venkatesh Rao, speaking to Shane Parrish on the Knowledge Project.
• Mental models are less about how the world works and more about internal consistency.
• Why? The universe is an extraordinarily confusing place. The information we receive through our retinas alone would make our heads explode.
• We’ve evolved to process this fire hose of information in a way that allows us to map it to a ‘toy universe’ inside our heads.
• When we shut our eyes and make a decision, for example, what school to apply for college, we are playing with this ‘toy universe’.
• For our mental models to work it has to be two things. 1. Simple. 2. Internally consistent.
That’s the function of mental models: simplicity and coherence.
Sound about right? Now let’s switch gears into software development.
Next up, Alan Cooper, from this seminal 1995 book About Face.
“Software interfaces are often designed by engineers who know exactly how the software works.”
• I’d add to this and say even great software developers have a limited understanding of how the software works, they may know specifics, but rarely the whole stack.
“…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.”
• This is generous — Even developers don’t care how a program is implemented. They may rely on their working knowledge (for example, understanding why the program is throwing an error), but they usually just want to buy tickets to Tahiti, or reserve a seat for the new Star Wars film.
• “…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.
So, we can see that software that doesn’t consider the mental models of the user, is doomed to fail.
Finally, enter Daniel Jackson, MIT Professor.
• Software construction needs design, not science.
• In the context of constructing a building, designers and engineers have a few key differences. Designers are concerned with visible elements, like doors, windows and walls. Engineers, in contrast, columns, beams and trusses.
• In software, it’s a similar division.
• Designers and engineers 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.
• If the ‘elements’ used by the developer to achieve their goals are functions and objects, what does the designer use?
• Daniel Jackson thinks it’s mainly “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 the user ‘use’ it, or work within it.
• Twitter would be pretty hard to understand if you didn’t get the concept of ‘following’.
• Concepts can be evaluated by their purpose.
• The purpose of the ‘trash’ concept, in the Mac Finder is to “allow undo of deletions.”
• If you delete a file, it moves to a special folder (trash). You can restore it from there, but emptying it removes contents for good (and makes space on the disk).
In a well-designed system, each concept is motivated by one purpose.
And purposes, are really just the structured needs of users.
Don’t recreate the universe. Leverage mental models and concepts to build working, well designed software.