October 17, 2018
I'm big on semantics. What does a particular word mean to me? What does that same word mean to you? Are we even talking about the same thing? Semantics play a big role in software design - all team members need to speak the same language. The term "UX" has recently received a lot of attention. "What is UX design?", "Do we really need UX?", "We need at least 3 UXs" (j/k), and so on. There seems to be a lot of confusion and assumptions around this topic, and it all starts with semantics. Does my definition of UX match yours? If not, then expect disagreement and misunderstanding. We first need to establish that common definition before we can design a captivating user experience.
The origin of UX is "User eXperience". I think of UX as exactly that: the experience a person has using a piece of software. UX by itself doesn't indicate something is good or something is bad, it is simply AN experience. We may evaluate that experience as good or bad, but UX exists with each interaction, independent of the quality. All software with a human interface inherently contains a user experience, or "UX".
This means that the wonderful, elegant, intuitive software that Apple provides has "UX".
This means that the clunky, challenging, cryptic software of early computers had "UX".
This even means that a piece of software hacked together without ever considering the person that will actually be using it - also has "UX".
A human will experience something every time that individual interacts with software. Every human. Every interaction. Every time. This is non-negotiable: all software has "UX".
UI stands for user interface. It is made up of the pictures, words, buttons and feedback messages that form the software, and it contains the controls you can interact with.
Too often the terms UX and UI are used interchangeably, and this is unfortunate, because they are very different. The UI is a very big part of the UX, but the UI by itself has no user experience.
Think of a car. The "UI" of a car consists of the steering wheel, gas and brake pedals, speedometer, and so on. These are physical items that allow the driver to interact with the car - both inputs (controlling the speed and direction) and outputs (viewing the current speed). A car's UI is very important. The UI could be described with words like "beautiful", "elegant" and "bold" for a new car, or perhaps "worn", "outdated" and "broken" for an old car. These words describe the car's appearance.
Does a car have "UX"? Absolutely. Each person that sits behind the wheel, starts the vehicle, and accelerates down the road has an experience. The driver may describe the experience as "intuitive", "fun" and "exhilarating" for a new car, or perhaps "jarring", "frustrating" and "horrible" for an old car. These words describe how the person feels about their experience with the car.
The parts that together make up the car (the UI) are different than the decision, movements, and interactions required to produce a desired result (the UX). A simple differentiation between UI and UX: UI is what something is, UX is how someone feels about an interaction with it.
Our car analogy applies directly to software, and this is where the semantics I mentioned earlier become important. The first step to a better user experience is everyone agreeing that "UX" is something intangible but is something absolutely real. The deeper understanding happens when everyone agrees what this implies. This means that we are not just building "UIs", but we are building an "experience" We are crafting something that will elicit a feeling from a human. If someone enjoys the user experience, a human might describe it as "intuitive", "fun", or “exhilarating”￼. A negative human example could be "jarring", "frustrating" and "horrible". We get to decide how we want our customers to feel, and this is the most powerful part of building software. This is what drives both "good software" and "bad software".
Attempting to understand where UX exists is a tricky endeavor. A much easier question to answer is "Where is the UI?" Whomever is showing the product can just answer "I have images of the user interface, I'll show them to you." The user interface is something visually tangible.
But human experience is more than just visual. It can’t be described with just a set of still images or even a video. No one can be produced to fully convey a user's experience.
Wire frames and user flows are a step in the right direction, but these don't have a "where" component regarding the location of the experience. The location of the person having the experience may be known, but the experience itself does not have a location.
Therefore "Where is the UX?" is a trick question that does not have an answer. There is no place one can point to and say "there it is, that is where the UX is". A human experience of any kind does not exist "somewhere" - the experience is as virtual as a person's feelings and emotions, which makes sense because that is what an experience is - the resulting feelings and emotions of a person having done something.
An experience is a transient thing: it exists while it is happening and then exists only as a memory after it is over. Exploring the "when" of any experience provides a wealth of information. Many people get this part wrong, believing that the UX exists only while the end user is viewing and interacting with the pages, screens, and data that comprise software. They view it like this:
What a user experiences during the period of time they are using the software is indeed a big part of "when" the UX exists. The way the user flows through the software to accomplish goals is absolutely part of the experience.
But when a person interacts with software, that person is always doing something immediately before the interaction begins. Without question, the person does something that leads to the person using the software. It could be something very obvious ("my colleague told me to check my email, so I opened my email software"), something required ("the process at my job is to create a new ticket in our software for each new phone call"), something habitual ("I check my social media feeds every morning"), or any one of a thousand different triggers, but there is always something important leading up to the software interaction.
Similarly, a person does something immediately after the interaction ends that is related to the software. This may be taking an action, using an output, or saving something for later.
The before and after activities are ignored all too often, even though what the person is doing during these times is pivotal. Software UX extends beyond the software like this:
The real user experience, any real human experience, always includes the before and after activities. Sometimes directly and sometimes indirectly, but what the person is doing before reaching the software influences all kinds of things that the software should take into account.
Understanding and anticipating a person's needs are what differentiates "bad", "good", and "great" user experiences.
I went zip-lining while on vacation in Costa Rica. I took a bus from the city to a part of the jungle where the outfitter was located. I received several minutes of instruction and information on what to expect, and then after putting on the harness I was attached securely to the zip line. I glided gently off the platform and the zip lines took me high above the trees where I was able to see out to the ocean, went over several large valleys, and, somehow, sailed past a flock of birds. Finally, it dove back under the canopy, past a giant waterfall, and then reached the end of the line. At the bottom someone helped me out of the harness, I was provided a snack and something to drink, and then a bus ride back to town.
It was an awesome experience.
So where did my zip-lining "UX" start and end? Let's pretend that the physical zip-line represents the software we've been discussing. It starts at a specific point and ends at a specific point, and I only interact with the actual line for a discrete period of time. How did my activities before and after this time influence or change what I experienced during the time I was actually in the harness on the line?
I had planned this activity a few months before my trip, with a goal to have an awesome experience doing something I had not done before. I received a confirmation email the week before my vacation, reassuring me that things were all on track. On the day of the event the bus ride up the hill was cool, comfortable and fairly short. The instructions they provided were clear and contained plenty of detail. When I was actually attached to the line and starting to move off the platform I felt excited, informed, and ready to enjoy the ride. I knew my goal, what to expect, and how to correct any minor issues along the way.
Consider the alternative: What if there was no confirmation email? What if the bus ride was hot, bumpy and slow? What if no instructions were provided? With these "before" activities would my experience on the line have felt the same? As an even more extreme example, what if the worker didn't attach me securely, and instead of gliding off the platform I plummeted into the forest? After the zip line ride, what would have been different for my experience if they did not provide the bus ride back to town and I was nervous because I did not know how to get back?
The before and after activities weren't just ancillary, they were an integral part of my overall zip line experience.
All software has a user experience (UX) that is encompassed by what a person experiences before, during, and after using the software. Understanding, defining, and communicating this experience can be challenging, but is absolutely necessary when designing software.
Great UX is achieved, first and foremost, by considering the human using the software. Software is only a small portion of a person's everyday activities, so it is of the utmost importance to know with certainty how it fits into the person's actual life.