What I Mean When I Say UX

I don’t mean stakeholder interviews.

I don’t mean personas or user archetypes or scenarios.

I don’t mean user flows or user stories or jobs to be done or OOUX maps.

I don’t mean wireframes or mockups or prototypes or user testing.

I don’t even necessarily mean talking to users or listening to them or thinking about their experience at all.

I mean building features people actually need.

I mean solving the biggest, gnarliest problems your users are facing.

I mean seeing the trends to help you architect your system with enough extensibility and conceptual coherence to avoid a total rewrite next year.

I mean having an engaged user base who become your best advocates and most fertile ground for product roadmapping.

I mean getting unsolicited inquiries from other departments or market segments, because they’ve heard from friends how much your system has helped.

Ultimately, I mean saving time and money while having better resilience and user buy-in. When I’m talking to an executive, that’s what I mean when I say UX.

Outcomes Over Outputs

At Simple Thread, our process for building software always starts with UX research, and we occasionally get pushback from clients on whether this discovery phase is really necessary. It can be a little frustrating, but I don’t begrudge non-technical executives when they’re skeptical of spending time on this fancy UX stuff. Enough talking, let’s get building!

As an industry, we do a bad job communicating the value of User Experience. There’s an irony here, something about the cobbler’s kids.

We practitioners of UX love to talk about the process – navel gazing over, say, the finer points of a wireframe versus a low-fi mockup. And while it’s important to bring everyone along on the journey with clear expectations and a shared vocabulary, many stakeholders are just too busy to care about any of that. They are never going to read the interview summaries or look at a process flow map.

Most executives simply do not care about the outputs of your process. But they absolutely care about the outcomes!

Slow Down to Speed Up

The next time you have stakeholders who are reluctant to engage in UX, make sure you are setting enough context for why any of it matters. You won’t always convince them, but you can’t judge them if you’re not clearly communicating how the UX activities will improve the outcomes.

A friend of mine joked that her product org never seems to have time to do it right but always has time to do it twice.

And sometimes people just need to experience getting burned first. No matter how persuasively you describe the hazard of fire, they need to reach out and touch it to understand. After they build the system nobody wanted, they might be more open to a better way. If you treated them with respect and empathy, they might even come back to you to try out all this UX hokum.

Our job is not to make people feel ignorant or cheap for wanting to move fast. Our job is to help them understand that UX is how you move fast.