You are not the user of the software you are designing or approving
You are not the user. If you are the CEO, CTO, chief network architect, software developer – you aren’t the user of the software or systems that you are building, or at least, you aren’t the primary user. What you are looking for isn’t what your customer or employee is looking for. And the vocabulary you use isn’t the vocabulary your customer is using, and may not be what your partners say either.
Two trivial examples:
- I recently had my hair cut, and the stylist asked me, “Do you need any product?” Well, I don’t use product. I use shampoo. “Product” is stylist-speak, not customer-speak.
- For lunch one day, I stopped at a fast-food chain. Yes, yes, I know, not the healthiest. When my meal was ready, I heard over the speaker, “Order 143, your order is up.” Hmm. Up? In customer-speak, it should have been, “Your order is ready.”
In the essay, “You Are Not the User: The False-Consensus Effect,” Raluca Budiu observes:
While many people who earn a living from developing software will write tons of programs to make their own life easier, much, if not most, of their output will in fact be intended for other people — people who are not working in a cubicle nearby, or not even in the same building. These “users” are usually very different than those who write the code, even in the rare case where they are developers: they have different backgrounds, different experiences with user interfaces, different mindsets, different mental models, and different goals. They are not us.
Badiu defines the false-consensus effect as, “The false-consensus effect refers to people’s tendency to assume that others share their beliefs and will behave similarly in a given context.” And that is more than designing cool software. Good design, and avoiding a false consensus, requires real-life situations with real-life customers or end users.
The way I navigate a grocery store is not the way that the store’s designer, or store’s manager, navigates it. It’s certainly not the way that the store’s manager navigates it. Or its chief risk officer. That’s why grocery stores spend a fortune observing users and testing different layouts to not only maximize sales and profitability, but also maximize the user’s satisfaction. A good design often requires a balance between the needs of the designer and the needs of the users.
My wife was recently frustrated when navigating an insurance company’s website. It was clearly not designed for her use case. Frankly, it’s hard to imagine anyone being satisfied with that website. And how about the process of logging into a WiFi network in a hotel, airport, or coffee shop? Could it be more difficult?
Focus on the User Experience
The Nielsen Norman Group, experts in usability, have offered a list of “10 Usability Heuristics of User Interface Design.” While Jakob Nielsen is focused on the software user experience, these are rules that we should follow in many other situations. Consider this point:
Match between system and the real world: The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
Yes, and how about
Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
That’s so familiar. How many of us have been frustrated by dialog boxes, not knowing exactly what will happen if we press “Cancel” or “Okay”?
Design Thinking
The article “Design Thinking” from Sarah Gibbons talks about what we should do when designing systems. That means getting them in front of real people:
Prototype: Build real, tactile representations for a subset of your ideas. The goal of this phase is to understand what components of your ideas work, and which do not. In this phase you begin to weigh the impact vs. feasibility of your ideas through feedback on your prototypes.
Test: Return to your users for feedback. Ask yourself ‘Does this solution meet users’ needs?’ and ‘Has it improved how they feel, think, or do their tasks?’
Put your prototype in front of real customers and verify that it achieves your goals. Has the users’ perspective during onboarding improved? Does the new landing page increase time or money spent on your site? As you are executing your vision, continue to test along the way.
Never forget, you are not the user.
