In a recent conversation, I was asked about pet peeves at work. As someone who’s been working in the user experience field for 25+ years, long before it was even called UX, I can give you an earful. Similar to UI design, where a single line blurted out at the project’s kick-off can ruin the whole mood (“It’s gotta pop!”), projects can get off on the wrong foot when I’m asked questions out of the blue about what’s the best approach in a particular situation. Advice without understanding the context can be worse than saying nothing at all.
Besides, the act of expressing that context is beneficial to both parties. That said, my pet peeves fall into these categories:
A UX Designer Cannot Start Designing on Day One!
Before you start, you need to:
- Define what success looks like for the organization
- Describe everyone who will use or be impacted by your product’s use
- Map out the user behaviors that will allow you to achieve your goals
Either the client has done this work up front or, more likely, they have that built into the statement for work for the UX designer. I prefer the latter because it allows me to fully grok the context in which the client operates.
The User in UX Is a P
Each individual interacting with your product arrives with their own history and experience. UX is not a one-size-fits-all proposition. That said, you cannot please all people all of the time, so you need to prioritize. The prioritization must be done by the client. As a UX designer, with my understanding of the context, I can make suggestions, but the product manager has to own the success of the product.
UX is Not I
A user’s experience the first time interacting with your product is different from the second, the tenth, the thousandth, etc., etc. The key is to implement a framework that gathers usage metrics that allow you to evaluate the current UX and adjust as necessary. If I’ve done my job right, the organization will now have:
- Access to people who fully understand the universe in which the product operates
- Know how that universe and the people who populate it might change over time
- Have the metrics to evaluate that evolution
- Understand how to express that to the development team
That is the sign of a project well executed.