What does it take to create an excellent user experience?
A designer’s work revolves around this question, and the answer differs from project to project.
I want to share my recent experience with answering this question for a particular project.
The Project Details:
I work on development and design for an enterprise client in the cargo transportation space. We are rewriting the app that their staff use to track and manage the cargo. The enterprise has different divisions that handle different kinds of cargo. Each division has its own requirements for what the app must do and its own requests for what the app might look like.
Last week, we began working on a new activity in the app that one of the divisions will use to reroute cargo when necessary. We had almost no information about this activity or the details of how it worked, so we started from scratch to design a flow that would make sense for the app’s users. During that process, here’s what turned out to be important/not important:
Not Important: Fancy Tools
Many designers create the images to demonstrate their designs in a wireframing or prototyping software like Keynote (for iOS apps), balsamiq (for web apps), or inVision (for either mobile or web apps). These are very pretty. They are especially helpful while establishing the look of a brand new app. For this assignment, though, I was working on a new activity in an app that already had a standard look, standard fonts, standard colors.
Also, the new activity stories were coming up very quickly in our project backlog: we would begin coding this new activity the next day, or maybe the day after at the latest. I needed a fast way to pen a flow that my fellow developers, our product owner, and the division stakeholders could look at. So I used a pen and a piece of graph paper. I came up with something like this:
The product owner—a veteran staff member of the cargo company and a user of the original version of the app we are rewriting—could tell from this flow exactly how he would go about completing the activity. He had the information he needed to decide if he would like to use this app to reroute cargo.
The cargo rerouting division experts were also able to use the hand-drawn screen flow to identify capabilities that were missing—and to help us write stories in our backlog that would add those capabilities in the app.
Most importantly, the image conveyed enough information that the other developers on my team could tell how to execute on the UI.
I think it is worthwhile here to point something out. Whether it is a drawing in our un-animated project or an inVision simulation of a complicated animation, the tools’ primary function is communication between the designer and other stakeholders. Design, and the literature and lore that surrounds it, paints a picture of a discipline that centers on creativity and vision, on fresh ideas and artistic genius. My experience has felt very different from this. The challenge of idea generation is dwarfed by the challenge of idea communication. As in most professions, communication skills separate the most successful feats of design from the could-have-beens. That brings me to the next point.
Very Important: Communication—with all three users of the design product
Who are the users of an app design deliverable? One might be tempted to answer that they are the end users of the app we are creating. I would argue, though, that in this case I had three sets of users.
The first set comprises exactly who you would expect: the staff members who use the app on the ground. I needed to understand their feedback about the app to build what they wanted. This is where our product owner stepped in.
The second set comprises the domain experts from the client company. They used the preliminary designs to understand my understanding of what the reroute function needed to do. Because those people had a visual aid that allowed them to envision the new functionality, they got excited about being involved. That excitement made it easier to get those experts to come into our office for a conversation. I asked them questions to learn more about what the app needed to do. As it turned out, my understanding of the activity had missed a few important details. I got to ask how staff members used the current app. I got to ask how those staff members make decisions based on the information that the app gives them. I got to ask which pieces of information were the most important and which ones the users ignored—so I could remove the ignored pieces to make more room for larger text and larger buttons on the screen. I could find out why certain features existed in the original version of the app and determine how and when to do them. For example, feature A with obvious business value should go into the backlog immediately. But Feature B from the old app required precious screen space, and it only existed because 1 out of 180 stations demanded it. This should be a much lower priority, and maybe not get done at all.
The third set comprises the developers themselves. I understood what I wanted the activity to look like, but I needed to communicate that to my fellow developers. Developers were able to eyeball this drawing, ask me clarifying questions, and execute. This is an important one. As a developer, I understand the pain of being handed a stack of pretty drawings that fail to express all the information that I need to understand. I’ll have a folder full of gorgeous screens and no indication of which one comes after which, or what I have to click on in the first one to get to the second one. Tools like inVision help to ameliorate this problem. That said, a few circles and arrows can also ameliorate this problem. Circle = click. Arrow = this screen goes to that one. It also helped that I was sitting right there, and staffed on the same project, if another developer had a question about the screens.*
*I’d like to step back and add this sidenote: I work on an agile software team. Many agile shops separately staff designers, developers, and product managers (not a problem), and they rarely encourage consultants in one of these disciplines to perform any of the tasks of either of the other disciplines (definitely a problem). I found it extremely helpful for our execution of the agile software philosophy when I started to learn to switch between design and development tasks on a project. More than before, the team has the ability to handle the full spectrum of new requirements because we can execute on rapidly shifting project priorities without necessarily switching team members.
The next point has to do specifically with the priorities of this particular project:
Not Important: Animations
Modern mobile devices allow for some dazzling animations. Our app doesn’t use any. I suspect that this relates to the absence of pain around using a pen and paper instead of fancy prototyping software. It’s more difficult to draw a unique and complicated animation than a plain old screen transition, so apps that use animations may have a greater need for prototyping software in the design process.
Very Important: Accessibility
The cargo workers must use our app outdoors in the dark of a windowless cargo room. They also must use it outdoors in bright sunlight and in the rain. They must use it with sweaty fingers during the summer and heavily-gloved hands during the winter. Many of them are between the ages of 40 and 70, and they often have corrected or imperfect vision and hearing. Even if they could hear perfectly, they work around very loud cargo vehicles, often with earbuds in.
This means that the app must have large text and high-contrast colors. When staff members use the built-in barcode scanner, the app must beep very loudly to indicate a successful scan. The touchscreen presents the largest challenge: the buttons can be hard to tap for large or gloved fingers. So we make the buttons huge and far apart, and we streamline the activities to minimize the number of buttons that users have to tap.
This project has presented an extreme version of a lesson that any design-minded software maker can take to heart: not every user is a twenty-something standing in a well-lit, climate-controlled room. Some apps cater to a clientele very different from the app’s makers. In these cases, the stakes are especially high for software makers to listen well and to practice empathizing with their users.
Communication and empathy drove the design process. I had to understand the requirements of the system and the users. This sounds obvious when stated in general terms, but it can require a designer to do uncomfortable things. It is not always comfortable to dig deep and ask questions about why people invested time in seemingly unnecessary features. It is not always comfortable to walk into a room and collaborate with stakeholders who played seminal roles in building the app that you are now…replacing. But these tasks have their rewards when the field testers get ahold of the new feature and report that they love using it. Perhaps the definition of an excellent user experience is subjective, but feedback like that gives you a clue that you just might have managed it.