Many people who work in user experience face the same problem: UX is not taken seriously by their organizations. Specifically, it’s hard to get executives to prioritize great user experience (though they might understand, in a vague sense, that it’s important). It’s difficult to get product managers to collaborate on design because product management exclusively owns solving business problems. And it can be really hard to get engineers to work in a way that supports great user experience in a product because engineers sometimes think of user experience-derived work as costly and overly exacting to implement.

Product management and engineering seem to have nailed how to convey the value of what they do to the people they work with. Why are UX designers so often stymied, and how can UX leadership learn from these disciplines?

When Design Is Blocked

UX designers often start a new job only to hit a wall once we’ve settled in. We are hired explicitly to make a product beautiful and usable, but then find that our new organization is actively (and usually unwittingly) blocking our efforts.

What does being blocked look like?

• The organization might see “design” as a noun, not a verb. In this situation, designers mostly implement everyone else’s requirements. Internal stakeholders give direction and designers make the pixels. There is no sense of “design” as a process that uncovers insights and strategic course corrections; if anything, that process is driven by everyone but the designers.
• The organization makes a lot of noise about valuing great UX, but great UI is somehow never implemented. UI enhancements are deprioritized by product management or engineering unless a high-value customer asks for them, or unless UI updates are associated directly with specific feature work. “UI only work” is seen as frivolous by the rest of the organization. This leads to design debt (an inconsistent, unusable experience) in the product and very frustrated designers.
• Design expertise is seen as just an opinion, not based on anything concrete or observable. Recommendations from designers are routinely challenged or worse, voted down by product or engineering teams. UX expertise is not trusted, and designers are not permitted to own UI decisions, even though designers may still be accountable for bad UI. Every design discussion turns into a pitched battle.

This is all terribly frustrating and demoralizing for UX professionals. Design is not a noun, it’s very much a verb, and the design process—when applied properly—does in fact yield strategically important insights that move a business forward. Designers are worth listening to; when companies don’t listen, it becomes very hard for customers to access the promised value of a feature. And why hire designers without enabling them to do their jobs?

So how do designers break the stalemate?

Where We Want to Be

Getting to a great user experience requires more than just bolting a UX capability onto an organization. Organizations must adapt to and work with the UX team for great UX to happen because UX cannot be effective in a vacuum.

Getting There: “UXing Harder” Doesn’t Work

Designers can apply all the UX process they want, but if the rest of the organization doesn’t recognize the need for change it doesn’t matter what UX does. It’s all performance art unless product management and engineering (and the executives) understand how the stuff that the UX team does can help them. Nobody wants yet another process after all, especially if it only seems to benefit the team yelling about the process in question.

In fact, “UXing harder” when an organization isn’t motivated to listen is a great way to burn your team’s credibility. Designers must instead demonstrate that the UX process they’re pushing benefits everyone, not just UX. And designers must be very specific as to how.

Observe and Leverage Common Processes: Agile/Lean/Design Thinking

Agile, Lean Startup, and Design Thinking are separate methodologies that converge on the same outcome: They’re all about investing in—meaning, spending time and money to design and build—only what is valuable for the market and the business. And each resonates with a different part of the business and can be leveraged accordingly.

For example, Agile is an engineering philosophy (Scrum is the process), that enables engineers to prioritize work according to its value in small, easy-to-estimate-and-complete chunks. Value is defined as “what’s valuable right now to customers,” at the time that the work is plucked out of the backlog. Because any work that makes it out of the backlog is, by definition, high-value, time won’t be wasted on stuff that won’t further the aims of the business.

Lean Startup is about figuring out what’s valuable to a market and iterating on that in quick cycles. In Lean Startup, an idea is expressed in a low-cost way (as a sketch, for example) and validated with users, then reconsidered, and expressed in progressively higher resolution, in repeating cycles until an idea evolves into a product with market fit. The company won’t invest heavily in an idea (meaning, the company won’t turn it into a full product) until the idea is proven to have value for the target market. This process is typically led by either a founder or a product manager (and perhaps guided by a designer).

Design Thinking is a process led by designers, that brings all the various roles (including product, UX, and engineering) together within an organization to ideate, prioritize ideas, and then validate those ideas with users, in repeating cycles, until these ideas evolve into a product or a feature. The value of an idea is determined by its utility to and acceptance by users. In terms of outcome, there is very little difference between Design Thinking and Lean Startup, other than the point of view applied (designer versus product manager).

These three methodologies are not quite the same, but can be boiled down to the following steps:

1. Understand the market.
2. Come up with ideas that we think the market wants.
3. Validate with users, iterate, repeat.
4. Gradually move validated ideas into full-on development.
5. Always build the most valuable thing first, as defined by 1-3.
6. Repeat.

Anyone who works in a software company should be able to agree that these are all good things to do in this order (even if people aren’t doing all these things now, it’s not hard to get them to agree that they probably should be). Maybe engineers are interested in numbers 4 and 5, and product managers find that their focus is usually on items 1-3. But UX process can integrate with all of them.

If we review this list again, but from a UX point of view, standard UX processes seem to map gracefully:

• Understand the market is closely allied with user research.
• Come up with ideas that we think the market wants is ideation—a designer’s specialty.
• Validate with the market, iterate, repeat? That’s a different flavor of user research, plus design, applied in cycles.
• When UX designers work to validate ideas before ideas become code, designers help development avoid wasting time (and money) on work that won’t advance the business.

So, if you’re having trouble getting engineering and product management to accept that UX process is necessary and good, try talking about:

• How the UX team can support the Lean Startup process by running user research and idea validation with the product management team in low-cost ways to explore a problem space and come up with market-validated solutions that will achieve market fit.
• How the organization can better align with the Agile principle of “working software over comprehensive documentation” by involving engineers in research, inviting them to participate in customer interviews and findings presentations to enable them to adopt a customer mindset and help them make better decisions in how they prioritize and build chunks of work.
• How executives can understand the value of the design process by seeing how UX is helping product management and engineering reduce risk by building the right product for the market (aka, not building the wrong thing).

To Fix UX, Step Outside UX

The best way to improve the chances of great UX happening in an organization is to solve organizational issues. The best way to solve organizational issues is to step outside of UX. Designers don’t run the product roadmap, and we aren’t full-stack engineers, either. But if we’re going to have the influence we want, the first step is to apply some designer empathy to the people we work with. We can study other disciplines to figure out how best to communicate the value of what we’re good at in the language of those disciplines.

This is what good senior managers do, by the way: explore how to make an organization better by understanding each group’s way of thinking and helping people work together. If you want to be a UX leader in your organization, working this way is a step in the right direction.

Topics: 条件 , コラボレーション, コミュニケーション
Published in: April, 2018 in アジャイル手法

Comments are closed.