Lately, I have taken time to read books that have helped form a fundamental understanding of building and designing user interfaces. The one book that has has taken my attention is titled The Design of Everyday authored by Don Norman.
Don Norman was one of the original user experience designers at Apple and has written a whole host of books around design and usability. One of the main points he consistently holds is: If the user is having a bad time with the product, it's the designer's fault, not the user.
In the book he outlines seven core principles of design:
Discoverability
Affordances
Signifiers
Constraints
Feedback
Mapping
Conceptual Model
In short the above summarize to this:
Discoverability: The ability for a user to figure out what are the features or expected experience of the product that they are using.
Affordances: What the canvas or the foundation hint or "affords" the user to do with the product? Example: A brick path affords to be walked on, a door handle affords that it can be used to open the door.
Signifiers: How does someone interact and precisely apply the intended action? Example: The save button on a phone screen signifies that you touch at that spot to save your changes.
Constraints: Limiters that narrow down and make the intended use more clear. Example:
Feedback: Immediate confirmation of user action that validates the user action. Example: The little "whoop" sound when you send a text message on your iPhone.
Mapping: A controls relation to the product/experience. Example: The left arrow on your keyboard will make the cursor go left and the opposite is true for the right. If were anything different, it would not make sense or feel natural.
Conceptual Model: The mental model that a user forms inside of their head of how something works. This is the users truth, whether it is complete or not. Good design helps create a full and robust conceptual model for the user to understand easily.
How does any of this matter to building processes or standard operating procedures (SOP's) in our businesses? The first step is to equate product/experience = business process/system, because at the end of the day - your system is a "product" that someone is using. Your co-workers, team or organization are your customers.
Usually when there is a new process or system introduced into a company it is a top-down approach. The leaders of an organization will come up with a great idea or react to an existing problem and seek to fix it using a step-by-step process to standardize the actions of all the employees in a company. SOP's work great in highly ordered tasks: Do 1, 2, then 3, repeat. Where they start falling apart is when there are more complex tasks with various inputs that need to be standardized.
For instance - setting goals and measuring results for team members. There are multiple ways to tackle this particular problem, but the end result is that some people in the organization succeed and some come up short. There so many modifiers that could influence the outcome, so what can be done?
Rather, the question should be: what is not working here? And this is where I (generally) agree with Mr. Norman. It's not the user, it's the design of the system.
Let's go through the principles again and equate them to business systems and processes.
Discoverability
Here are some questions to ask: can my team members walk into my organization and easily find out what is expected of them? Can a new team member walk on and get into the groove quickly? Do managers need to micromanage their direct reports to get results? Do I need to micromanage to get the proper inputs?
All these questions try to get at one thing: can someone quickly get a general picture of what is expected of them for a given situation. If they can't - that's where we need to look at the next six principles to see where we can run some improvement.
Affordances
The foundation of an organization lies in it's culture. The nitty gritty details of it's culture will inform (afford) a person on what is possible and what is perceived as not possible. Creating a culture that has public values, principles and healthy norms will afford itself to an environment where the associate can go and create new systems, bring up ideas in meetings and be an active collaborator on big decisions. The opposite is also true: if there is a crumbling culture, one does not know where to contribute due to fear, confusion or apathy.
This piece is so critical, because organizations that have a poor culture always have a much tougher time adopting systems that could make them grow faster or become more profitable, everyone is watching their back or blaming each other!
To use a painting metaphor: Culture is the canvas of an organization and the quality of that canvas will afford the user to how confident they can be that their work will matter for the long term.
Signifiers
Signifiers direct exactly where a person can apply their input into the process or system. If there are no signifiers, then there are going to be random inputs. Imagine if our phone were just a screen of blank app blocks. No colors, no icons, just blocks. How would we know which button was for text messages? Calls? Email? Only through trial and error would we find out which button did which action.
"what do I do now? Trial and Error?"How are our team members supposed to know where to go, or where to apply their skill if there are no clear signifiers of where to do so? It ends up being a trial and error, wild goose chase that ends only in frustration and pain.
This is especially the case if we have the wrong signifiers for what we want. Going back to the button example. If that button said "Save" but the action was "Cancel" that would be a mind bending loop of frustration. If in our organizations we said "Collaborate!" but in our meetings there is no room for others to speak, or if we say "Safety is important!" but don't talk about outside of the weekly safety huddle, why are we then frustrated and confused when there is no collaboration or a safety violation happens?
Constraints
Constraints are exactly how they sound, they dictate what can't or shouldn't be done. It could be capabilities, ethics or specifications laid out from the top. Constraints also can be set by the creator of the process, you guide your users to have a narrow scope of choices to make.
I'm sure you are familiar with the concept of decision paralysis - when there is too much choice, you freeze up. Give your target audience less choice and more clear direction on where they need to go. There is an interesting dilemma when building constraints - you can direct the user down a path where they don't want to go, or give them information that might seem helpful, but influence their decision making process in the wrong way.
In Thinking Fast and Slow by Daniel Kahneman, Chapter 15 is dedicated to the idea of less is more. Over several studies that he did that where people had to evaluate and rank the probability of multiple situations, and the situation that had more detail or told a better story got ranked higher a majority of the time over the logically correct answer. To illustrate, here is a modified example from the original found on page 162:
A. The Giants will win the game
B. The Giants will be behind in the first quarter
C. The Giants will be behind in the first quarter but will win the game
C was consistently ranked higher than B, even though B is logically more probable (it hurts). But C sounds like a better story and potentially fits better into the narrative or bias that the user has. We need to be sure when creating systems, we are not unintentionally leading people astray in our pursuit of making a system easier to use, by giving more detail.
Feedback
Feedback is necessary so that the user knows when they take an action, that action is confirmed. This could take the form of a notification, email or verbal feedback - just ensure that your user or team is getting information that is relevant to them.
Mapping
Mapping is useful to think about when creating a system, since it will help the user intuitively know how to use the system. Consider this quote on page 23 of The Design of Everyday Things -
"A device is easy to use when the set of possible actions is visible, when the controls and displays exploit natural mappings"[...]"Natural mapping, by which I mean taking advantage of spatial analogies that lead to understanding."Mapping in a physical sense - like a switch, is easy to understand. Or even our digital "Save" button is relatively easy natural mapping. But in a business system, it takes some work to design a process that feels natural to the person being put to the task to use the system. This requires studying, watching and listening how one works and attacks tasks.4
Conceptual Models
Conceptual Models are a natural summary of all the other principles combined to form a picture in your users head. It answers the question "Why does this even matter". If a system does lend itself to have good conceptual model, the user understands what input they put into the system to make it work will know exactly what they are impacting down the line.
Think about when you are creating reports, if the data is junk and input incorrectly - it's pretty useless. But in order to get a user to care about putting the little extra effort to get good data in, you have to bring them along and show them why it matters and what their data input is impacting. If it's too complicated to explain or provides minimal value, there might be revisions needed to the system to get it streamlined so that your users can understand it.
is your system the top or bottom? Are you sure?Summary
In closing, ensure that the business system, SOP, whatever it is - drives the most value to your end users. Take a step back and go through this checklist to see if it meets all these standards, if it doesn't go back and get it there so it does - you will see a much smoother implementation and acceptance of it!
//Miles