One year ago I’ve moved from academia to business. It’s been a few months now, and I’ve witnessed a big change in culture, methods, flow, focus, success metrics. It is a challenge, a good one. It’s helped me to get out of my comfort zone, open my mind, develop new skills, communicate in a different way, think differently. In other words: to grow, both personally and professionally.
One thing, however, caught my attention: it is not always clear what a user experience designer does, or should do. A common misbelief is that s/he creates beautiful user interfaces. Which, let’s be clear, is not wrong. It’s just not the whole deal.
Let me take one step back. When I was in research, I mostly worked with other researchers in the HCI field, the head of our team was a full professor in HCI, the conferences and journals I published in had “human-computer interaction”, “human factors”, or “interaction design” in the title. I had to be taught what user experience was, and I learnt it over the years in the field. I was the one in need of explanations, and I grew in a nest where I was surrounded by top notch researchers in this field. Within my team, if I needed direction on HCI research methods and strategy, I turned to Massimo, if I had doubts on qualitative methods I could ask Chiara, if I wanted to discuss experimental designs I turned to Gianluca, for wearable devices to Eleonora, for educational robotics to Ornella. I was surrounded by experts in the field.
Now that I’ve fled to business, I’ve entered a world where HCI, UX, UCD, design thinking are largely unexplored. They’re not granted. Product and delivery time are in the foreground: user research and design are just a means to an end. And let’s be honest: they’re an optional means. Very good products have been developed and delivered for years with no need for user experience research or design. And, no need to play games here: UX costs money. Let me say it again.
UX costs money. So, why bother?
This is a perfectly reasonable question. And I feel it’s just fair to try and answer this and the other big questions that I sense around me.
Why do we need user experience design? Why do we bother to include it in a well-established process that has proved successful for so many years? And anyway, what does a user experience designer do? Can s/he help me to deliver better? How, and how better? Will s/he slow me down? Will I have to work more to include user experience design? These are all very reasonable question, and all deserve honest answers. But please, before I dig into the numbers, bear with me. We need to talk the same language.
First and foremost. What is (not) user experience?
A.K.A. “Take this product and make it pretty, please.”
Let’s set a common ground and tackle the most common misconceptions about user experience.
User experience is not… (only) user interface.
User experience is not… (only) user interface. Let’s make an example from real life. I love orchids. I have different kinds, different colours, different scents. 12 by the window, one in the kitchen, a couple outside. This is the user interface. But why did I place them that way? Why do I have so many? What do they mean to me? What do I experience when I take care of them? How do I water them? User experience is so much more than user interface. User interface is just one piece of the puzzle. Coming back to technology: user experience is not a nice dress for a digital product. It’s not about button placement, or styling.
User experience is not… something that you tackle at the last minute.
User experience is not… something that you tackle at the last minute. It’s not a step in the process, nor the last step in the process. It is the process: it starts way before deciding what a software should do, and surely way before development. It is an ongoing work that starts even before deciding what to build and goes all the way through, at least until you release the product, not an item in a list that you can check and then move to the next one. If you ask a UX designer for advice when you are about to start the development, or when you are already developing, s/he will only be able to scratch the surface of the interface. And this relates to the following two concepts: usability, and user experience without users.
User experience is not… (only) usability.
User experience is not… (only) usability. Sure, ease of use is a major component of UX, but it is not the whole deal. User experience has to do with the value people assign to a product: is it useful to them? Can it solve their problems? Does it convey the right emotions for the users? Does it meet their needs? And more: can users easily find what they are looking for? Can they understand its content? Is the information presented in a clear, concise way? Do users find the right information in the right place? Can they use it with minimum cognitive and memory load? Is the product credible? Does it convey trust? Is it accessible to everyone?
User experience is not… user experience without users.
User experience is not… user experience without users. Or, in Hoa Loranger’s words, “it’s X, which means don’t do it!” (have a look at the short videoclip below). If you don’t include users in the development process (= if you don’t do user research) you’ll base your design on assumptions and opinions, not on hard data. And this is particularly dangerous because we’re all victims of cognitive biases, one of the most problematic in this case being confirmation bias, and the assumption that if something works for you, well… it will work for your users too (wrong!). Do you need to plan and invest in user research? Of course! But user research is what makes your product competitive.
User experience is not… magic.
User experience is not… magic. It is not the result of a magical session of few hours when creative designers sketch wireframes on a whiteboard based on their prior experience and insight. Sure, experience counts, as well as a solid knowledge of interaction design best practices and cognitive and social science. But intuition and prior knowledge are not enough. There’s a process and a method to it.