“Okay, so how long to UX it?”
This question is asked of me in just about every estimating meeting we have.
Sure it’s a joke, and I laugh. But I also cry just a little each time because, like any good joke, it has an element of truth to it.
UX has become ubiquitous. A search for “UX” on LinkedIn returns almost 200,000 results. But even with UX being everywhere you turn, it seems that many people, especially those not “in the industry” (i.e. clients), don’t have a solid grasp of what UX actually means. Even those of us in the industry don’t have a clear definition of what a UX designer is or does.
Look at any handful of UX Designer job descriptions out there and you’ll come up with dozens of different descriptions and requirements: from wireframing/prototyping, to information architecture, to user research, to being able to create, “stunning [visual] designs,” and on and on.
If we can’t agree on how to define UX how can we expect our clients to understand? In order for us to avoid the headaches that can result from misaligned expectations and misunderstood roles and responsibilities we must, at the very least, be able to explain to our clients the importance of our craft.
They must understand that “UXing it” isn’t just about churning out a few wireframes and making something look nice. It is about putting the user at the center of the design process and what that really entails. We also need to be able to explain why all of it is important to them.
All clients want to create a great experience for their users. If you were to ask, most of them would say they care about their users’ needs. In fact, many of them will even tell you exactly what their users want. As we all know, however, that generally equates to “we know exactly what we think our users should want.” This is where it falls on us as UX professionals to educate our clients and coworkers.
Our team was recently working with a client on an iPad application for members of their sales team. They explained the idea to us and it sounded like a very cool application. It was an interactive product configurator of sorts that, on the surface, made a lot of sense and would have been a lot of fun to build. The problem was, we knew that they hadn’t really talked to their user base.
We explained to them the importance of gaining insight from actual users and convinced them that we should go out and meet with some reps and distributors to talk about their processes and the ideas for the application. After two days of talking with users it became very clear that the application that was being proposed was not at all what their users needed.
If we would have jumped straight into “UXing it” by creating wireframes, for example, we would have wasted countless hours and dollars building a product that no one actually wanted or needed. By taking a step back and viewing UX as a holistic process rather than a single action or deliverable, we were able to more clearly identify the problem and therefore come up with an appropriate solution.
Unfortunately, these situations are all too common. They can, however, serve as excellent illustrations that the UX process—loosely defined here as user-centric design—will not only result in a better experience, but it will improve the bottom line.
There are various formal UX processes out there that you can implement or borrow from. The Cooper Goal Directed Design Process is a great one. It can be a bit heavy from a time and deliverable standpoint, however, so it might not fit every budget. If you’re interested in learning more, I’d highly recommend getting a copy of About Face 3: The Essentials of Interaction Design.
Lean UX is another great approach to consider. Inspired by the Lean Startup methodology, Lean UX focuses less on deliverables and more on moving quickly from concept to something tangible that you can use to test your hypotheses. In his book Lean UX: Applying Lean Principles to Improve User Experience, author Jeff Gothelf lays out the Lean UX process and offers several examples of how it’s been successfully used.
One particularly interesting story he shares involves a project he worked on with a team from PayPal. Armed with a prototype they had created in Axure, the product team broke up into smaller groups and hit the local malls testing the prototype with various people. When they got back together at the office that afternoon they were able to quickly identify which ideas had merit, and which ones did not. The very next day, they were able to begin refining the features they identified as important and start working them into the prototype for further testing. This example shows yet again the value of viewing UX as a process with the user at the center.
Too often, UX is narrowly defined as one of the many disciplines that make up UX as a whole (e.g., wireframing, information architecture, etc …). On your next project, if you’re asked to “UX it,” stand up for yourself and kindly explain that UX is a holistic process. It’s not a box you can tick off a to-do list. Use the examples and processes noted above to explain and defend your position.
Hopefully, little by little, we can chip away at the idea that UX is a verb and move toward a shared understanding of what it really means to “UX it.”
Image of bullet through apple courtesy Shutterstock
