Why UX Matters Regardless Of How Tech-Savvy You Are

Introduction

When I was in High School back in the mid-2000s, I remember getting into an argument with a friend of mine over Mac vs. Windows. My friend argued that Macs were too expensive and did the exact same things that a Windows Machine could. I, on the other hand, argued that Macs were much easier to understand and more intuitive, so you could simply focus on the tasks without worrying about trying to understand how the system works or dealing with errors. My friend then stated that Mac users were stupid and that it takes more intelligence to understand how Windows works. In short, it was not the fault of Windows, but rather the fault of the user.

The notion that the user was to blame for being unable to interact with a system properly kept ruminating in my mind for a long time. From teachers to my own family members, I can’t tell you how many times I have seen them groan at their computer screens trying to accomplish their tasks, whether it be trying to make an online purchase, set up an appointment, or managing spreadsheets. What was even sadder was that when they needed assistance in figuring out how a website or software application worked, they felt like an idiot afterwards. A common sentiment I kept hearing was, “I am a computer moron,” or more colloquially a “noob with computers.” Those sentiments saddened me and made me wonder, “are some people just born tech-savvy, while others aren’t?” In the back of my mind, I just kept pondering about it.

Story From Field Research

Stakeholder Interviews

It wasn’t until I finished work on a generative design research project with a software client in the oil and gas space earlier this year that I realized just how essential the user experience was, regardless of how tech-savvy the users were. Our client summoned the startup design agency I was working in earlier this year to help them refresh their brand. To put this into perspective, our client has been around for over three decades but was very esoteric. The purpose of this project was to help them refresh their brand so that they could attract more customers to their products.

To accomplish this, we needed to understand the company’s products and their target users. The first step was to conduct stakeholder interviews with some of the team members from the company to understand the purposes and functionalities of their products. As the stakeholders were demonstrating their products, it became very apparent just how feature-rich their products were. Everything from the support of different programming languages to the ability to analyze 3D, well-log data, it was just amazing how powerful the software was.

The impression that we had as we were interviewing with our stakeholders was that their target users must be very intelligent to be able to use such advanced, feature-heavy software tools. However, when we asked the client, whether they tested any of these features with their users, they stated that they only tested their products internally with their own colleagues and never outside. This raised some interesting questions about their users: are their users using all of the product’s features? Also, how did our client know these features were absolutely necessary for their users if they haven’t gone out and tested it with their users? These were the big research questions we kept in mind as we were getting ready for our next step: conducting the user interviews.

Interviews With The Users

When we were interviewing 15 of their target users (primarily software developers and geophysical analysts), two common themes became very apparent during the interviews: a steep learning curve and an extreme version of the 80–20% rule. A common pain point between the software developers and geophysical analysts were that it took a really long time to understand how their software works. They noted that the software documentation was very obscure and it didn’t help that there weren’t many visual examples to help guide them in learning how to use the software libraries. After many days of trying to understand how the software libraries and features worked, many of the users ended up resorting to contacting customer support just to learn how to use the software. After the constant back and forth between our client and their respective users via email and phone, they were able to understand how the software works, however, it came at the cost of delaying their Agile cycle and release schedule altogether. 

On top of the steep learning curve, a common sentiment that the users felt was that they felt that there was a lot more to the software that they were utilizing. In other words, the users were only using a fraction of the full feature set our client’s software provided. The stress of meeting deadlines along with the steep learning curve made it challenging to really understand the full feature set of the software. 

In the end, it made the developers and geophysical analysts feel really overwhelmed and stupid for not understanding the system from the start as they would’ve wanted to. Based on what we had discovered during the field research, we made proposals to our client such as having better software documentation and examples to better guide their users to how their software works as well as having webinars to keep their users engaged and learn about new features within their software in a safe, convenient environment.

Reflections From Field Research

The experience of observing and interviewing with the target users’ made me realize that the user experience matters not just to the common person who uses technology for casual things like email, but also to people who possess domain-specific knowledge too. Our target users’ were really super sharp people with many years of experience developing software in object-oriented programming languages in Java and C++, yet they felt lost and confused trying to figure out our client’s software. In Don Norman’s The Design Of Everyday Things, Norman states that when systems don’t work as intended, the user has a natural inclination to blame themselves for not being able to operate the system properly. Likewise, our target users felt that they weren’t competent enough on their jobs simply because our client’s software didn’t make sense to them and as a result served as a major roadblock on their work schedules. User Experience is more than just making systems look beautiful, it is about making sure systems make sense to people so that they can do their jobs well with full confidence.