"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


It has always annoyed me when people say "we're gonna do a usability". Usability is not a thing you do. It is an attribute of something else. Usability can be measured in a usability test that is something you do. It can be created by doing user-centered design.

Neither was PhotoShop a verb until more and more people started using it. Now you hear all the time, "this image was photoshopped." I don't think it's a bad thing, as long as the people who get paid to UX stuff know what UX really is (See, I just used it as a verb and a noun in the same sentence). I think the verb form is best used as office slang to describe what a UX Designer does.

I actually like UXing as a verb.

I use it on my cv as the most concise way to get across that I've done what I've done for a client, i.e. "UXed a site for XXXX."

I just happen to define UXing as everything, including research - not just the wireframing. I think your exclusion of research from UXing is a bit arbitrary - why do you think this is the case?

Your article then becomes about the necessity of user research, which, of course, I completely agree with. A more usable title might be "The necessity getting your stakeholders to understand that user research is essential in the UX process", but that sounds a bit boring, a bit obvious, and would probably attract fewer clicks.

I just used your article as a reading suggestion for the developer team in my company (IT).

I often find hard to make this cultural shift from the paradigm of the 90's: "The Web designer will take care of the interface" to the real inclusion of a design process. I believe it's not something that can't happen overnight.

Now my question is; isn't that all about teaching and selling the benefit of a good usability? If yes, what's your methodology to introduce UX within in a team that doesn't know that?

Usability is certainly part of the equation, but it's not the only concern. I've found that taking a collaborative approach to the design process can help in getting everyone to see the importance of UX in the overall process. For example, conduct a design studio session with the entire project team. This gets everyone in the room together working on the solution which helps create ownership and enthusiasm.