User experience (UX) is about much more than fonts and colors. Application UX design includes every interaction a user has with your company, product, service, and even sales and support—which is why every little detail matters.
We recently hosted an Ask Me Anything session with UX design and product management expert Laura Klein, Principal of Users Know and author of Build Better Products. Laura fielded questions on how to approach application UX design, when to include it in your product lifecycle, and what exactly makes a great application UX.
First off, how do you define UX and why does it matter?
When I talk about UX, what I’m talking about is user experience in design. If you’ve created a product and it has what we call “bad UX,” it’s hard to use. It’s not user friendly. It’s confusing.
Now, here’s the interesting thing: A lot of brand-new products, and even some niche or big enterprise products, have what a lot of us would consider to be really bad UX. I get people coming to me and saying, “X company has a terrible user experience. They seem extremely successful.” That’s true. If your product is useful enough and solves a serious problem, you can get by for a while, maybe even for a long while.
But here’s the problem: People are expecting better and better user experiences. For the last 10 years or so, we’ve referred to this as the “iPhone effect.” People started bringing their iPhones to work and demanding that they be able to use them as their work phones instead of the corporate-issued [devices] they had before—because they got used to the better user experience.
What are the consequences of bad application UX design?
If you have a terrible user experience, you are leaving yourself open to losing business when somebody else comes along and makes something that “just works” (to quote Apple). So that’s a danger to consider. You could go out of business. I think a bad UX over the long run means more churn, more people getting frustrated and leaving and trying something else.
Is it good practice for other business teams—beyond the design team—to understand product UX design?
Yes. We should all understand what other people in our organizations do. That’s incredibly important for building team cohesion. The other reason, of course, is that if you have good UX designers, they will come and ask you for your opinions on things. If you know the kind of information they’re asking you for, you’re going to give them better feedback, right? If you know that saying “I don’t like green” isn’t particularly helpful at this stage in the process, you’re going to be able to give better feedback.
I understand time is valuable and limited. So no, [other teams] do not have to be able to do product UX design in the same way that I do not need to do database design. But they need to understand what UX designers are doing and why they’re doing it, and to respect that.
At what point in the design process does UX start?
User experience happens whether you design it intentionally or not. When you don’t design it intentionally, it sucks. Organically grown user experiences tend to be terrible.
So at what point does the UX design process start? From the second you start thinking about the product. Having a user experience designer and/or researcher helping you with that process means your user experience gets intentionally designed from the very beginning of product development—and not tacked on at the end.
I think sometimes when people ask this question, what they mean is: “At which point should I do the visual design? At which point should I sprinkle some magical fairy dust on it? At which point should I decide if something bounces or slides?” Those can come later. They’re still important and they should still be designed in because it is part of the user experience. That stuff comes after you understand what the user experience is going to actually be.
In an ideal world, how would application UX and product management work on solving a problem?
Very simple answer: Together. UX and product management, at the highest levels, are not wildly different. There are things that product managers, especially in large organizations, do that UX designers don’t and vice versa. On small, cross-functional balanced teams, we’re all working together on the product. Different people work on different parts of the product.
The worst possible solution is product management goes off and decides we’re doing X. We’re building this product and it needs to have these features, and here’s a big specification document on all the different features. UX design comes in and says, “Given all of these different features, here’s how it would fit together,” and then that gets thrown over the wall to developers who build half of it (because they run out of time and they have a deadline). That’s the “waterfall model” and we don’t do that as much anymore because it doesn’t turn out great products.
We need to work as cross-functional, balanced teams. That’s a very high-level vision of what is, in fact, incredibly complicated. There are a ton of communication methods that need to happen. There’s a ton of work that we need to do around really focusing on what we’re building and coming up with the right ideas.