Reframing UX

Recently I’ve heard some talk questioning or knocking the value of UX (User Experience) and design for startups.

This bullshit is derived, as usual, from how is UX typically defined.

Most people think of UX in the wrong way. They associate it with an expensive, time-consuming Process and fuzzy deliverables that don’t actually add a ton of real value to a product. As well, when it’s associated with a job function, I think many people picture an expensive consultant or specialist that runs this time-consuming Process and produces these fuzzy deliverables that don’t actually add much real value to the product.

So, based on that definition of UX, startups definitely wouldn’t have a use for it. I’ll take it a step further. Hardly anyone needs that. Big, small, startup, established…it doesn’t matter.

Instead of saying startups don’t need UX, let’s change the way we look at UX. #

I think UX needs to be defined closer to the context to the actual words used: the overall experience a user has with a product. Based on that definition, we’re talking about an experience that incorporates many things that fall across many different job functions.

In essence, if you’re building a product for use, everyone involved is a UX person.

What these companies need is a way to discover, define and refine their products from a customer/user perspective. They need leadership that understands—and people who practice—user-centered design and who aren’t afraid to get themselves and their product in front of customers. They need people who can work directly on the product. This is key for early stage startups, for a number of reasons (design debt is as big a problem as technical debt, for instance), but I think this carries on to larger, established companies as well. If your UX people aren’t involved directly with the product in some way, you should ask yourself, “Why not?”

I do think it’s good to have someone who “owns” UX, and as you grow, someone who’s focused on bringing it all together. What you don’t want is a “specialist” that defines their work by the deliverables they produce. It’s not about deliverables or process, it’s about thinking about your products in a way that helps you define value from a user’s perspective and taking that thinking directly into improving the product.


Now read this

Transitioning Projects

Wouldn’t it be cool to work on one project, or task, finish it completely, take a break and then move to another? Well, yeah, but it’s not very realistic. Even if you’re focused on one larger project you’ve probably got numerous tasks... Continue →