UX for Engineers
A couple of months ago I finally bought a new car. As a tech geek, I was really excited about all the gadgets and accessories — bluetooth phone, nav system, drive settings, dual screens, etc. Unfortunately, when I started setting everything up, I was super disappointed.
It wasn’t that these systems didn’t work, it’s that they weren’t usable. They made even the most trivial tasks painful. For example, calling my wife required digging through four levels of navigation:
- Activate the phone on steering wheel
2. Select “Favorites” list
3. Select contact from a static list of favorites I had to set up
4. Select “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 another distraction that could get me killed.
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, but the system makes the driver choose between equally weighted “Call” and “Delete” actions. How often do you delete a contact while driving?
The next day, I complained about it to a few members of my design team. My lead product designer didn’t look surprised at all. He simply turned to me and said, “Assaf, the system was designed by engineers.”, then popped his headphones back in and went back to work.
The more I thought about it, the more obvious it was he was right. The system made no sense from a user perspective, but it made perfect sense from an engineer’s.
Systems-Centered Design
Engineers think in terms of systems. I know this because I am one. An engineering system has a specific set of features and configuration options. We engineers focus on making these systems feasible — organizing 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
Many engineers think they can’t do UX because they aren’t designers, artists, or some other creative type. Designers speak a different language, using vague terms like “shared aesthetic vocabulary.” and asking strange questions about spirit animals.
As engineers, we may not be interested in aesthetics and emotions, 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 point in the application stack.
While we might not be able to re-wire the firmware in our brains to become designers, 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.
User-Centered Design
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 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 the 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 users 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. Consider a driver’s context, and you may realize how hard it is to hit 3 consecutive touchscreen buttons while bouncing up and down and keeping an eye on the road.
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 on with their day.
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 people to get started. Just like it’s easier to extend a starter application than build one from scratch, giving users boilerplate settings and smart defaults gives them a less intimidating starting point.
Instead of requiring users to explicitly 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 3 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.
