The 3 Design Models

How good design connects the user and the product

Are you computer literate? Do you have computer skills? Should you?

No!

Computer literacy is nothing more than an excuse for forcing you to stretch your thinking to understand machine logic, rather than software driven products having functionality that meets your way of thinking.

In this article I will lay down the fundamentals for a UX Design approach that bridges the gap between machine logic and human thinking. I will explain the three different models that are in play:

  • The Mental Model – the way the human mind envisions how the product works.
  • The Implementation Model – the technical way the product works.
  • The Interpretation Model – the bridge between the two; the interface.

We will look at a few examples to illustrate why we need to change the way we approach digital product development. Next we will have a closer look at the three models described above.

What's the Problem?

Digital products originate from the hard work of developers and marketers.

Marketers

Marketers understand and quantify opportunities. They introduce and position a product. However, their input in the design process usually limits itself to a list of requirements. These requirements are not about what the user needs or wants, but about chasing the competition, to-do lists and guesses based on market surveys.

Contrary to what you might think, users have difficulty to state what they need. When you ask them questions about the products they use, most focus on low-level tasks and workarounds to flaws.

Unfortunately, a list of features does not lead to great solutions for complex technology. The feature “easy to use” does nothing to improve the situation.

Developers

Developers have a lot of input in the design process. They are in charge of building the product. They decide what gets built. And yet, they too have a different set of criteria than the users. Good developers are focused on solving technical problems. They are focused on meeting deadlines and following best practices.

They are often given incomplete and confusing instructions. They are therefore forced to make decisions that impact the user experience without knowledge, information and even enough time.

So, the people responsible for the creation of digital products and solutions rarely take into account the user’s goals, needs, and motivation. Not only that, they do strongly consider market trends and technical limitations. How is this ever going to end well?

Guy Punches Screen

The results of bad product design are products that irritate, reduce productivity, and fail to meet user needs.

Digital products can be outright rude. They often blame users for making mistakes that are not their fault, or at the very least should not be. Software frequently makes irrational demands, or asks patronizing questions like “Are you sure?” at the wrong moment. These products fail to interact with any form of decency. They forget information we tell them and have no clue what we want next.

Software driven products assume that we are technology savvy.

  • In Microsoft Word, renaming a document requires the use of “Save As…”, after which you will need to locate the original document on your “C-drive” and delete it.
  • If you save a document, then print and close it, you’re asked if you want to save it once more, implying that printing the document has changed it.
  • Heaven forbid you rename a document in the File Explorer and then click on it within Microsoft Word in the “Recent Documents” list; the program will get very upset with you.

Programs require you to move around looking for functionality that should be at your fingertips. Dangerous commands, on the other hand, are presented right in front of you, ready to cause havoc and disaster.

Three Critical Error Messages

When a software program stops working, its communication is horrible. An error has occurred. Bad enough as it is, it is a critical error, or an unexpected error, or even worse, an unknown error. And all you can do is click “OK”.

  • How is it ever ok that an error has occurred?
  • When is an error to be expected; isn’t an error always unexpected? Or do programmers actually build in errors to make you angry?
  • Who should know about these errors? Should you as a user know the errors the program itself calls unknown? What nonsense is this?
  • And all you can do is click “OK”… as if you agree with what is happening… “nice software program, we are ok!”

The simple truth is that the digital industry has little understanding of what it takes to make users happy. Programmers are often required to choose between ease of coding and ease of use. Their performance is judged by how well they code, and whether they meet the next deadline. Their choices are easy to understand once we realize this.

What is missing is a repeatable, predictable, and analytical process for transforming understanding your users into products that meet their needs and if possible are fun to use. The days are long gone where engineering and marketing alone were enough to produce desirable products. The modern triad of product development includes capability, viability, and desirability. If any one of these three foundations is neglected in a product, that product will not be successful.

The Three Models of Good Design

The process mentioned in the previous paragraph should consider three models.

3 Models of Design Balanced
  • The Implementation Model (shown on the right).
  • The Mental Model (shown on the left).
  • The Interpretation Model (sitting in the middle).
The Implementation Model

Any machine has a mechanism to accomplish its purpose. Moving, mechanical elements, controlled by electronic switches, and all that good stuff that makes the apparatus work.

Software products don’t have those moving parts, but here these are replaced with code and algorithms that interact with each other.

The implementation model therefore is the total of “parts” that make the product do what it does.

The Mental Model

People do not need to know the exact workings of products they use. They create cognitive shorthands for explaining it in their mind. These shorthands are good enough to cover their interactions with the product, but by no means come close to how the product works technically.

For instance, I like a healthy smoothy for breakfast. Whenever I plug the blender into a wall outlet, I imagine the electricity flowing like water from the socket to the blender through the power cable. In reality, the alternating current changes direction many times each second. Using the blender does not require me to understand this, or even know this.

The conceptual model, or mental picture I paint in my head is enough to get my tasty smoothy.

With digital products the difference between the workings of the product and the mental picture painted by the user becomes bigger and bigger. Most people still view their mobile phone as a “telephone” while in reality it is a “radio transceiver” that swaps antennas multiple times per minute. Knowing this does not help us use the phone though.

The distance between implementation and mental models becomes even larger with software products. The complexity of the underlying code makes it impossible to see the connection between your actions and the program’s reactions. When you use Adobe Photoshop, AutoDesk AutoCAD or Adobe Premiere Pro to do your work, your mental model will differ immensely from what is really going on inside the implementation model.

While a user’s mental model does not necessarily has to be true or accurate, it should allow him to work effectively and efficiently.

The Interpretation Model

This is more commonly known as the Interface. It is how the product is presented to the user, how its functionality is presented to the user. It is an attempt, made by designers and developers, to interpret the technical bits and pieces in such a way the user can understand and use the program.

This interpretation should not be an accurate representation of what really is going on.

Interface closer to implementation model than wanted.

Unfortunately, in many cases the interface represents the technical model far more than it represents the user’s mental model.

In software, the interpretation model should be different from the actual processing structure of the program. It quite often is not. The ability to present the software’s functioning independently of its real functions is far more important in digital products than in any other product. In general, offering an interpretation model that follows the implementation model too closely will have a major impact on the user’s ability to learn and use the program.

From a developer’s point of view it makes sense to provide a button for every function, a text for every piece of data, a page for every transaction, and a dialog box for every module. This will accurately reflect the infrastructure of engineering efforts, but it does nothing to provide efficient mechanisms to the user, who is looking to achieve his goals. In the end, the product will confuse and alienate the user and fail.

User interfaces and interactions designed by engineers, who of course know precisely how the software works, lead to an interpretation model that is very much in line with its implementation model. To these engineers, that model is logical, accurate, and useful; they are convinced they have done a good job. Unfortunately, the majority of the users will not agree.

A simple example is the use of tools based on mathematical algorithms to represent and manipulate information structures. Let’s say we have a database containing books in a library. We want to ask that database the following question:

  • Show me all books from Agatha Christie and Julia Mei.

The criterion for this query would look like:

  • [Author] = “Agatha Christie” OR [Author] = “Julia Mei”.

Mathematical thinking is an implementation model trap that is particularly easy for programmers to fall into. They solve problems by thinking mathematically, so they naturally assume this is appropriate for user interfaces. Everybody should be computer savvy after all. Everyone knows math, now don’t they?

Any application that interacts with users in Boolean expressions is doomed to fail. It is unreasonable to expect users to deal with this confusion. Users use human language, not Boolean math.

User Centered Design - The wrong approach
Interface closer to the mental model.

We tend to make mental models that are simpler than reality. So, if we create interpretation models that are simpler than the implementation models, we help our users to better understand the product. One of the best ways a software product can assist the user is by putting a simple face on a complex process. As a result, user interfaces that are consistent with our mental models are far superior to those that just reflect the implementation models.

These days there is a whole industry busy trying to achieve just that. User Centered Design is the holy grail of today’s software design teams.

Unfortunately, most attempts fail from the start. Trying to bring the user interface closer to the user will move it away from the implementation model, so to speak. In the end we have a user friendly interface, aiming to get things done for the user, trying to communicate with a technical system that has been left behind and still cannot facilitate the user’s needs and goals. The user will once again be left frustrated and unsatisfied with the product.

Focusing on just the user interface is a big mistake. The underlying implementation model remains the driving force of the digital product. Putting on a nice coat of paint does not change that. We need a different approach to make our users really happy.

User Centered Design - Done the right way
Tailor the application

If we want to give our users great digital experiences, we need to involve them in the development process right from the start.

Instead of trying to bring our users closer to the implementation model (which has proven to be a futile exercise for many, many years), or bringing the interpretation model closer to the user (which doesn’t solve anything when the software still doesn’t deliver), we should bring the implementation model closer to the user.

This means building products that users actually want to use. Sounds obvious, I know. But in real-life apparently it is not so simple.

The planning of complex, digital products requires a significant upfront (!) effort by professional designers, who are at that point not at all interested in delivering pixel perfect working demo’s every two weeks. This involves understanding how the people using the product live and work, and designing product behavior and form that supports and facilitates that human behavior. This is what is called Interaction Design.

Interaction Design is not just about aesthetics, not just about how things should look; it is based on an understanding of your users and proven cognitive principles. This is best done in an iterative process, which is good news as it creates a link to the development process.

Recognizing User Goals

User goals are often quite different from what we might guess them to be. When companies start to focus on users, they tend to pay too much attention to the tasks the user engages in and not enough on their goals in performing these tasks.

  • What are user goals?
  • How can we identify them?
  • How do we know that they are indeed real goals and not tasks forced upon users by poorly designed tools and business processes?
  • Are goals the same for all our users?
  • Do goals change over time, and if so, by how much and how fast?

A goal is the expectation of an end condition, whereas both activities and tasks are intermediate steps that help someone reach a goal or set of goals.

This is an important point to understand. Let’s look at an office clerk, working in our accounting department. Is his goal to process that stack of invoices efficiently? Most likely not. The clerk is probably more interested in “doing a good job”, “remaining focused while doing boring repetitive work”, “getting a promotion”, “getting a raise”, “getting home in time to take care of the kids”, etc., etc. Processing the invoices is one of the business goals of that clerk’s employer.

Hence, most goals are personal. They are not connected to the work we do at that moment, they are not connected to the task we are performing. They are not connected to the business goals that are in play.

Products designed and built to achieve business goals alone will eventually fail. Personal goals of users need to be addressed. When the user’s personal goals are met by the design, business goals are achieved far more effectively.

Most commercially available software, websites and digital products fail to meet user’s goals at an alarming rate. They are very good though in:

  • Making users feel stupid.
  • Causing users to make mistakes.
  • Requiring too much effort to operate.
  • Not providing an engaging and enjoyable experience.

Remarkably, these same products fail to achieve their business goals:

  • Invoices don’t get processed all that well.
  • Customers do not get serviced on time.
  • Decisions do not get supported properly.

Goals are driven by human motivations and therefore they change very slowly, if at all, over time. Activities and tasks are more transient, as they are based on whatever technology is available at that specific moment.

Bringing a gun

For instance: a businessman traveling from Amsterdam to Paris in the early 1800s would have liked to travel quickly, comfortably and safely. He would have hired a horse pulled carriage and brought along a big gun for safety. Today that businessman would still like to travel under the same conditions, but book a seat on an airplane, where he would be frowned upon if he tried to bring his gun.

The goals have stayed the same, yet the activities and tasks to get to these goals could not be more different.

Design based only on activities and tasks runs the risk of trapping the design in a model imposed by outdated technology, or a model that meets the goals of an organization without meeting the goals of their users. Looking at the goals allows you to leverage technology and eliminate irrelevant tasks and to streamline activity. If the task is to enter 2000 names into a database, a well designed data-entry form won’t satisfy the user nearly as much as an automated process that imports those names from the accounting system.

The research and analytical process that precedes the pixel-perfect prototype is essential for understanding and implementing user goals in your digital products:

  • Stakeholder interviews,
  • User interviews,
  • Market research,
  • User models,
  • User stories,
  • Content hierarchies,
  • Content models,
  • Wireframes.

These are all important steps to get to know your users and their goals and needs. Only then will you be able to create digital products that will be useful, enjoyable and sustainable.

Future articles in this blog will take a closer look at each of these steps. Until next time!