bytes for thought by François Fortin

The UX-illiterate programmer: An introduction to UX from a programmer’s perspective.

As a programmer, I’ve recently been dragged into the UX (User eXperience) world, and what an eye-opener it has been. In the past, while I’ve always tried to produce the best experience for my users, I hadn’t realized how easy it is to be distracted from that path, especially when you need to answer to various budget and time constraints, or the business doesn’t value good UX. Beyond business constraints, however, I still unconsciously questioned myself: what makes a piece of software more “user-friendly” than another? If an application is “user-friendly” to you, will it be the case for me as well? I could tell when software was poorly designed, but I couldn’t express it properly.

Users tend to have a visceral relationship with technology and are very passionate about it. I am no exception to this; poorly designed software frustrates me. Before reading up on UX, when user interaction in a software wasn’t up to par, all I could resort to was: “Wow, this isn’t user-friendly, this software is terrible, I hate using it!” This is what I call the UX-illiteracy reasoning loop.

Then I thought, if I can’t explain to someone else why an app is or isn’t user-friendly to me, then how, as a programmer, am I competent to know what will or will not be user-friendly to someone else?

This article will focus on the three questions programmers should always seek the answers to before starting a project: “Who?“, “Why?“, and “What?“, in addition to the traditional “How?” and “When?“.

Who?

As a programmer, you work for many different actors, including but not limited to: the project manager, the customer, the end users, the designer, other programmers, etc. All of them have different requirements and priorities. The project manager will insist primarily on the “When?” part – delivery date, and budget. Usability may or may not be on the manager’s radar at all. Then comes the customer who may not be the end user, in which case they may not even pay attention to usability either. The designer, if you’re lucky enough to have one, wants you to follow his design where applicable, but you’re the one doing the hard work, and time constraints might force you to cut corners. Other programmers are also important in the “Who?” landscape, as they’re the ones who will likely maintain the product, and take it further if needed. That’s a lot of people to think about, and to keep satisfied with your work. Did we forget someone?

The user. Often the least vocal (at least during the development process), but by far the most important and easily overlooked actor. Before anything else, programmers should have their future users in mind when working on a project. Understand their current workflow, how they interact not only with the computer, but with their surroundings. Do they use the phone a lot? Post-it notes? Do they rely on paperwork? What part of their process is the most painful to them right now? That’s usually a good place to start. If you can’t ask them directly, try to visualize it.

Why?

When I’m asked what UX is by non-programmers, I give them the following example:

A project manager receives a request from an external customer. They want a panic button added to every screen of their application, that would cancel any print job currently taking place. The manager briefs the lead programmer in, asking him for the estimated cost of adding the feature throughout the app. After a couple hours research, the lead programmer determines it will cost around $5,000. The project gets approved by the customer, development begins. The UX designer hears about it. Having not been consulted, he chooses to contact the customer directly and ask more questions about the situation, only to learn that their problem could be solved simply by replacing their broken $50 printer with a new one.

While the example is a little extreme, it’s always good, as a programmer, to have a view of the big picture and understand why you are developing a feature. It allows for a better overall solution and lets you think outside the box. Users, although very passionate, are often very bad at truly expressing their needs. To quote Alan Cooper in About Face 3: when you visit the doctor, you can express your symptoms, but you can’t offer a diagnosis. As the programmer, you often become your users’ tech surgeon; you have to make the difference between their symptoms, and their phony diagnosis.

“Why?” also means you don’t have to solve problems that don’t exist. For a long time, I’ve been trying to get my family to use Google Chrome instead of Internet Explorer. I’d tell them how faster it is, how smoother everything would be on Chrome. Once I’d set it up on their PC, and they sat and started using it, they were confused and flustered. While Chrome increased my overall UX, it turned out to decrease theirs. I failed to apply the simplest of concepts; “if it ain’t broke, don’t fix it”. Progress for the sake of progress is not necessarily what your user wants, or needs.

What?

“What?” is the composite result of “Who?” and “Why?”. Once you have a deep understanding of who you work for and why you’re adding or modifying a feature, you can start working on what you are going to do. This step is generally the result of the UX designer’s work, but there will still be details left for the implementation to determine. Things like Hotkeys and Shortcuts can be overlooked, and you can only address these if you have knowledge on your user. What shortcut template are you going to use? Same as Microsoft Office? Do you need shortcuts to begin with? Will you write error messages targeted at a tech-educated crowd, or beginner users? Is the error message really helpful to your user? If not, why display it at all?

How? and When?

These are the two questions you, as a programmer, are already used to finding the answers to, so I won’t elaborate; it’s literally implementation within a set of time and budget constraints.

Conclusion

I only scraped the surface in this article. I’m not even covering the tip of the tip of the iceberg. So where to go from here? If you’re looking to learn more about UX, UXMastery.com put up a neat list of recommended books. I highly recommend About Face 3 by Alan Cooper if you’re curious to learn more about interaction design. Usability Engineering by Rosson/Carroll on scenario-based design was very enlightening as well, although a little too academic. If you work for a startup, or a relatively small company, Lean UX by Jeff Gothelf is a good read.