A couple of months ago I finally bought a new car. As a tech geek, I was most excited about all the accompanying gadgets—bluetooth phone, nav system, drive settings, dual screens, etc.
Unfortunately, when I started setting everything up, I was super disappointed by the clunky UX of these systems. They made even the most common tasks painful. The simple act of calling my wife required digging through four levels of navigation:
- Activate the phone on the steering wheel
- Select “Favorites” list
- Select contact from a static list of favorites that I first had to set up.
- Select the “Call” option within the contact.
Sure, clicking four buttons isn’t the hardest thing in the world, but while I’m driving, each one of these actions is a dangerous distraction that could lead to an accident.
The worst part is that these poor design choices are so easily avoided. For example, it’s obvious that people typically view a contact because they want to call them. Why make a driver choose between equally weighted “Call” and “Delete” actions, especially when it’s so hard to hit the right button while driving? How often is a person going to delete a contact while in the car anyway?
In response to this disappointing experience, I did the only rational thing any UX professional would do: I went to work and complained to my co-workers. After listening to my spirited ranting, our lead product designer turned to me and said plainly, “Assaf, the system was designed by engineers.” He then popped his headphones back in and went back to work, leaving me to reflect on his words.
The more I thought about it, the more obvious it was he was right. It’s not important whether Infiniti actually employed any UX professionals, but the undeniable truth of his insight was that the system was clearly designed from an engineer’s perspective.
Engineers think of everything in terms of systems. I know this because I am one. (So were my father and grandfather.) After nearly a century of engineer thinking indoctrination, the thought process has been hard-wired into my brain.
An engineering system has a specific set of features and configuration options. We engineers spend a lot of time organizing these features into logical structures to make them easy to implement, cheap to maintain, and configurable to maximize re-use.
As a result, we have a strong tendency to design UIs that reflect the underlying systems we’ve spent so much time and effort implementing. Looking at the Infiniti phone system from earlier, it makes sense from an engineer’s perspective:
- User selects the “Phone” system.
- System lists all “Phone” features.
- User selects “Contacts” feature.
- System lists all objects in “Contacts” list.
- User selects a contact object.
- System lists actions available on that object.
This reads like a well organized API. All features are listed, organized, and exposed to the user in a logical hierarchical structure. Unfortunately, people aren’t APIs.
Breaking the Engineering Mindset
The “Box Design Concept” meeting scene from HBO’s Silicon Valley perfectly captures how engineers think about UX. (https://www.youtube.com/watch?v=V3jxWCJUPQQ).
Many engineers believe that they can’t do UX because they aren’t designers, artists, or some other creative type. Designers speak an altogether different language, asking abstract questions about spirit animals and using vague terms like “shared aesthetic vocabulary.”
As engineers, we may not be interested in aesthetics or emotional journeys, but we are still very much interested in making things that work.
The key to good UX is to understand that “design” isn’t about decoration, it’s about making something that works. Think of the user as the final integration in the application stack.
While we might not be able to re-wire the firmware in our brains to care about spirit animals and aesthetic vocabularies, there are a few simple things we can do to hack UX and make sure our systems actually deliver the value that we worked so hard to create.
The first step towards being better at UX is to embrace user-centered design. This means focusing on the user instead of the system. You don’t need a PhD in psych or human computer interaction to do this, just a couple of handy questions.
Who is using the system?
The first step is to identify the user. Are they a corporate executive or a 12-year-old kid? Are they the truck driver or the logistics manager? The user is the system your app needs to integrate with, so answer to this question is critical.
Ask this question up front and don’t move on until you have a good answer. You don’t need detailed personas, but you do need a good idea of who your audience is. If you identify multiple audiences, ask yourself if one interface can effectively serve all of them or if they need different interfaces.
Asking the question of “Who” gets you off on the right foot and, just as importantly, makes sure everyone is on the same page. You’d be amazed how many engineering meetings I’ve been to where no one has asked this question.
Why are they using the system?
Now that we know who is using the system, we need a clear idea of why. What problem do they have that needs to be solved? What immediate pain can the system relieve for them? What tasks are they trying to accomplish?
Engineers often don’t ask this question because they assume the answer lies in the system’s feature list. Take the following example:
“The user is reading the sales report because they want to see sales numbers.”
No one just wants to see sales numbers. Why do they want to see sales numbers? What specifically are they looking for? For example, do they regularly check actual vs. forecast closed sales mid-month and email their team if the numbers are low? Ask “Why” multiple times until you get to a real answer.
With a little digging, you’ll find people’s workflows are surprisingly few and reliably simple. Ask “why” a driver is using a phone, and you’d learn that a driver is more likely to call his wife than delete her from his contact list.
In what context are they using the system?
Engineers implicitly assume the user is quietly sitting at their desks, focused on the system in front of them. Not coincidentally, that happens to be what the engineer is doing while designing the system.
In real life, context of use drastically changes how people interact with systems. It’s critically important to understand the physical and mental environment in which someone is using your system—what they’re thinking and doing at the time.
For example, designing a data system for a factory foreman on the floor who needs to know why a production line is down is very different than presenting the same data set to an operations manager running reports in an office.
The foreman is under immediate time pressure, probably using a phone or tablet and having limited internet connectivity. If your mobile app is used in this context, you might not want to pop up a guided walkthrough highlighting the cool new features you just rolled out.
Configuration and Defaults
Aside from systems-centered thinking, the other most common engineering design mistake is excessive configuration.
Engineers are tinkerers by nature. They love spending time configuring and customizing things. Unfortunately, most people do not share this love of infinite possibilities. They just want to accomplish their task as quickly as possible and get out of the system.
The next time you think about creating an onboarding wizard to gather preferences, ask yourself if some smart defaults would be an easier way for users to get started. From our own experience, we know that it’s much easier to update code that’s already working than build a new application from scratch. The same holds true for UX.
Instead of requiring users to customize their environment, ask if the environment can customize itself implicitly based on the user’s usage patterns. For example, instead of having the driver configure a favorites list in the car, have the system create it dynamically based on the most frequently dialed contacts.
Putting It to Use
Whether you’re creating a phone system for a car or a back office reporting system, UX is always going to be important. And while you might not always have the luxury of a UX professional at your side, you can still be a champion for your users by asking three simple questions.
- Who’s the user
- Why are they using the system?
- In what context are they using the system?
Do this and you’ll be miles ahead of the competition. Just think of it as another engineering problem you can solve using the same logical process that made you a good engineer in the first place.