Choosing Your Battles, Part 2

Partner with Product Teams

Whether you are fully or partially embedded on a product team—the latter being likely if your company has a low designer-to-developer ratio—seek out opportunities to join product teams in their meetings and calls that involve executives. If you’re working on a well-funded project, chances are that it has executives’ eyes and ears. Your product team must keep executives apprised of the project’s progress.

Such meetings could be your opportunity to shine alongside other members of your product team. Offer to present the rationale behind the product’s design and show how it satisfies core user needs. Tailor your message to fit the product’s unique selling proposition (USP), which contextualizes your design work in a way that is meaningful to someone writing the checks. Just be sure that you don’t get bogged down in UX jargon, which might result in blank stares. Instead, use common words to describe your work deliverables. Plus, your presentation should be visual because busy executives better comprehend communication that helps them form a clear mental picture of a problem and its potential solutions.

Communicate Your Vision

Speaking of visuals, executives are not the only ones who benefit from seeing artifacts that help them understand the problem space and its opportunities. Anyone with whom you work—whether product owners, developers, testers, or even fellow UX designers—can derive value from a tangible vision—even if a vision is overly aspirational or flawed in some way.

What do I mean by vision and why is it important? Your vision depends on what story you’re trying to tell and why you feel compelled to tell it. Perhaps a funded project lacks direction and stakeholder discussions in which you’ve participated have become increasingly tedious journeys into the abstract. Maybe people are using different words to describe the same things, and no frame of reference exists to promote consensus. Whatever the reason, as a UX professional, you could be in a position to help bring order to the chaos.

Projecting a compelling vision for a future product for could create a groundswell of interest, arming the product owner with an artifact that can guide discussions in the board room. While you might not receive an invitation to attend those executive meetings, you’ll still be there in spirit through work products that represent the quality of your thinking.

Find Your Champions

Admittedly, it is unlikely that a knight in shining armor would ride into your office to bring you to the executive team and extol your virtues. But you should always be on the lookout for champions of your work. Often, they won’t occupy the roles you might have expected. While a champion could very well be a stakeholder to whom you’ve presented your vision, he could also be a senior architect or developer who happens to have the ear of the vice president. Your champion could be the sales representative—that worthy ally who can get you much-needed face time with customers and, eventually, users.

Don’t dismiss people’s potential ability to be champions because of their title, seniority, or perceived decision-making authority. Senior leaders often have a diverse ring of confidants in all areas of a business. Someone who has earned their trust might be sitting right next to you. Ask to meet with such people, making sure you first offer to help them achieve their goals. As a UX designer, you can give your colleagues your unique perspective on what drives user motivations and behaviors. Wield your user-centered mindset to your advantage in such scenarios. Doing so encourages potential champions to reciprocate by getting you an audience with top decision makers.

Doing UX Design Earlier

As I described in Part 1, product teams who have adopted Lean or agile product-development methods—and are executing well using those methods—can create opportunity for the UX designers on a project. How so? On Lean and agile projects, UX designers can more easily test the value of their design hypotheses with early users, and they have the C-suite’s implicit permission to course-correct. However, the same might not be true for teams who depend on development methodologies that result in monolithic product releases. Teams that use waterfall, iterative, or scaled-agile models, with the intent of driving development efficiency for large programs and teams, often lack permission to fail forward quickly by frequently testing and iterating.

What often happens with such bloated product-delivery models is this: A product owner visits some customers, writes up product requirements that he has concluded would meet the needs of those customers—who, in an enterprise context, are not actually the target users—then dumps those requirements on the UX designer. The product owner expects the UX designer to create spit-polished deliverables and pass them to waiting developers, never revisiting them. The pressure that mounts within such narrow slots of project engagement is often overwhelming for UX designers. Once development implements their designs and releases them to production, it’s anyone’s guess whether or when another opportunity might arise for revisiting and improving them. As a UX designer, how can you combat the get-it-right-now reality in which you might find yourself when working on such a monolithic product release? You employ the shift-left principle as much as possible.

The shift-left principle isn’t new, but generally applies to software integration testing. Employing this principle means moving testing activities to earlier phases of the product-development cycle to enable a product team to better sustain its velocity. You can apply this same principle to your research and design work if your product team demands an overly constrained, time-bound UX-design process.

As soon as your UX manager assigns you to a large product release, try to get invited to customer visits and get involved in planning meetings and requirements-gathering activities as soon as possible—especially if you’re unfamiliar with the product or its domain. If you can, accomplish this with the help of a champion. However, you should not wait for the team or project sponsor to engage your services. They won’t involve you until it is too late. Take your services to them. Once you earn a seat at the table or get a visitor’s ID badge for the customer’s workplace, be an active listener and copious notetaker, absorbing all you can to level-up your knowledge and add greater value.

Once you have a decent handle on the problem space, envision a solution for it. Do not try to make it perfect. Endeavoring for perfection can come at the expense of efficiency. As I stated earlier, people respond best to visuals. Plus, they’re often better critics than creators. Expressing your early vision is a good first step to becoming an indispensable resource on the product team. Moreover, because weightier development processes emphasize getting things right from the beginning, you’ll give yourself a better chance of being able to iterate your designs if you get involved earlier.

Adhering to Core User-Centered Design Principles

As I described in Part 1, UX designers must be ruthless about killing their darlings—an axiom that is in common use in the literary world and encourages writers to remove any self-indulgent passage or prose. What are the immutable truths about designing for humans that you should strive to champion even at the risk of ruffling some feathers?

Here are some heuristics I find helpful whenever I’m questioning where and when to spend my hard-earned UX designer’s capital.

• feedback—Having the opportunity to get user feedback is non-negotiable. Feedback really matters. It lets you alleviate users’ anxiety and prevent them from making further mistakes. For example, there are few things more frustrating to users than painstakingly completing a lengthy form, then clicking Save only to have a blank screen appear or be unexpectedly navigated to whatever place in the user interface (UI) they first initiated their task.
• accessibility—Your product should meet the goals of all people, regardless of their cognitive or physical abilities. Ensure compliance with common accessibility guidelines such as the Web Content Accessibility Guidelines (WCAG). Support screen readers and assistive technologies. Make sure the colors you use don’t ignore the needs of people with color-deficient vision. Size and arrange UI components appropriately so users with motor disabilities can use your Web site or application just as effectively as people who do not suffer from disabilities.
• localization—As I described in my column “Supporting Localization,” there are several tactics you can use to support the needs of users whose languages, cultures, or locations are different from your own. Among these are stacking labels above their respective values or fields to accommodate unpredictable character-string lengths, using redundant coding for icons and other affordances that must command users’ attention, taking the cultural connotations of color into account, and ensuring that the language in your user interface is straightforward and free of slang and jargon.
• clarity—A user experience has clarity when users immediately understand its purpose, before they take any action. Here are some practical ways of facilitating clarity in your user interfaces:
  
  • Reduce visual clutter. Linear elements, borders, and containers can be useful for indicating groupings, but take care not to overuse them. Consider other gestalt principles—such as proximity or similarity—that might be more suitable for indicating relationship. Do not make a user interface overly decorative at the expense of designing the most efficient, effective, and satisfying experience possible.
  • Focus on information, not data. Users are no longer tolerant of incomprehensible tables of data that they must decipher on their own. Provide curated, contextual information in the user’s own language.
  • Make hierarchy apparent. Use the inverted pyramid method when laying out the elements of a user interface, giving emphasis to the most important content that is at the heart of the user’s goals. De-emphasize other content in accordance with its importance. Convey emphasis by consistently varying the size and weight of similarly important visual elements. Unrelated components of similar size and weight only confuse users.
  • Clearly indicate problem states. Do not allow error messages to get lost in the mix. Ensure that you use color and contrast judiciously throughout a user interface so important elements grab the user’s attention immediately.
• efficiency—Give users ways to make their work more efficient. Don’t make them repeat the same actions unnecessarily. For example, support access keys and shortcuts to allow advanced users to become masters of their keyboard.
• forgiveness—Provide a secure experience that prevents users from inadvertently performing destructive actions. Give users obvious ways of backing out of accidental clicks, or better, avoid this problem altogether by placing potentially destructive actions at a distance—at least two clicks away or behind an authentication workflow.
• consistency—Favor commonality over novelty. Users shouldn’t have to guess whether different words, visualizations, or interactions share the same meaning. Moreover, users don’t use your Web site or application in a vacuum. As I described in Part 1, introducing a foreign pattern into the user’s software lexicon risks confusion or frustration because the user won’t be able to draw upon existing knowledge to achieve goals efficiently.

Are there other truths that you rely on in your design work and find non-negotiable—that is, worthy of your adopting a firm stance against those who might dismiss their value? If so, please describe them in the comments.

Navigating Ambiguity

Not all decisions fall neatly into preassigned buckets—black or white, right or wrong, yes or no. What about handling scenarios in which the next logical course of action is still unclear? If you’re unsure what to do, first ask yourself how important a problem is. Think deeply about a problem’s severity, its risk to the organization, and its complexity. If a problem is systemic and hinders the organization’s ability to meet users’ needs effectively, that is a much greater problem than your annoyance over a product team’s choice of one internal software tool over another or another pet peeve. Lois Kelly, co-author of Rebels at Work: A Handbook for Leading Change from Within, recommends rating the importance of a problem on a scale of one to ten. If its rating is six or below, you should drop it and move on.

Be honest in assessing whether your perception of a problem is exaggerated or your desire to make a change is self-indulgent. Teammates and stakeholders quickly become wary of designers who dig in their heels over every little issue, and this could impact your ability to escalate a change that is truly necessary.

Perhaps a situation might be too complex to rate it on a numeric scale. If so, present the situation to others before choosing your course of action. This accomplishes a few things:

• Assigning words and actions to your thoughts clarifies your own thinking. As I explained in “Demonstrating the Value of User Experience to Product Teams, Part 2,” having to make your intention clear when communicating a concept to someone else forces you to hone your message. A situation may seem different to you once you’ve taken the time and effort to communicate it. Perhaps a problem is not as severe as you previously thought. Then again, it might be even more severe.
• If you think you have a solution to a problem, test the solution’s viability with a respected colleague before deciding whether you should escalate it.
• Presenting your solution for a problem to others lets you build early support for your design hypothesis, enabling others to amplify your perspective.

Conclusion

Taking a firm stance can be uncomfortable. Most people avoid confrontation out of fear that they’ll ruin an important relationship or do irreparable damage to their career. However, such fears are often exaggerated. As long as you demonstrate empathy toward others, you can avoid doing serious damage.

Remember, most people care deeply about a product they’re sponsoring, designing, or building. Their criticisms are not usually personal. But there is a limit to how acquiescent you should be when you experience resistance—especially if what you’re conceding would negatively impact how people would use the product you’re designing.

Remove any guesswork about your users by getting access to them early and often, and involve others in user research to help grow your team’s UX maturity. Do all that you can to gain access to leadership because remaining buried beneath layers of middle management stunts your professional growth, as well as your organization’s UX maturity. Strive to shift left when working on monolithic product releases. Being trapped within a preordained project-engagement slot would likely result in insufficient time for iterating on your designs and prevent your creating the best solution possible. Keep a checklist of those immutable truths that you hold dear, and revisit them often. It can be difficult to know where and when to spend your hard-earned UX designer’s capital.

Finally, rate the importance of a problem if you find yourself in a situation where the best course of action is unclear. Go further if you need to, soliciting the opinions of others who you trust. Verbalizing your concerns is a simple way of achieving clarity and building advocacy.