Demonstrating the Value of User Experience to Enterprise Product Teams, Part 2 :: UXmatters


Consistently conducting design reviews reduces risk, improves efficiency, and disambiguates false assumptions. Enterprise solutions come laden with their own unique terms and phrases, so conversations can become tedious journeys into the abstract if no visual artifacts exist to help frame discussions.

Once you have a design artifact—even if it’s rough—schedule a review session and invite all team members to attend. According to Dr. Nancy Burnham, a senior project engineer at Rockwell Automation, UX professionals demonstrate value when they bring others into the design process early. “Be willing to share your ideas before you think they’ve been documented perfectly,” advises Burnham.

Too often, UX professionals wait until they think their work is perfect before sharing it with product-team members. This is a mistake. Deputize your teammates as fellow designers because much of their work is design related, just with a different focus. Not only can they experience the quality of your thinking, you’ll be exposed to their depth of expertise, which in turn, grows your product knowledge and informs better design decisions going forward—a win-win.

So how can you do this? It can be difficult to encourage technical-minded folks to think in a more user-centered way. One method I’ve found useful is to print out a concise usage scenario that is no more than a paragraph in length and supports the deliverable you’re showing. Provide this scenario to your teammates prior to a design review.

A tangible scenario provides a convenient way of ensuring that reviewers don’t simply slip into feasibility concerns or technical solutions when they see your in-progress design. As discussions ensue, you can continually refer to the scenario as a means of recentering the team’s feedback. Plus, as Chris and I explained under Redirect in Part 1, this hand-out provides a useful reference point when you ask, “How does that help the user accomplish the goal in this scenario?”

Respond, Calmly

Your teammates don’t just review your in-progress design deliverables, they observe you. How do you respond when someone criticizes your work harshly? Do you become defensive and closed off? Do you defend, blame, and take it personally? Or are you open to criticism?

There are few more sure-fire ways to undermine your credibility than to react defensively. Remember, your teammates may not share your mindset. Plus, there’s a good chance they’re new to user-centered design reviews if your organization lacks UX maturity. Be open to your teammates’ unique perspectives, and they’ll be more accepting of your mindset.

As Andrew Follet explains in his Smashing Magazine article, “How to Respond Effectively to Design Criticism,” you should remain calm and check your first reaction. Follet recommends that you thank your harshest critics because doing so demonstrates that you can accept all levels of feedback.

“Expressing gratitude will also make you feel better about the experience and help you alleviate any innate avoidance of feedback and criticism you may have.” —Andrew Follet.

If someone isn’t as constructive as you’d like, don’t take it personally. Not all input is equal, so you’re ultimately free to disregard less-useful comments when making design decisions. However, teammates will appreciate your willingness to accept even caustic feedback publicly. Seeing your composure encourages quieter teammates to give you feedback without fear of embarrassment or retaliation—even if they do so outside the context of a group setting—because they’ve seen you can handle harsh feedback with maturity and calmness. Know who else might notice? Your boss and business leaders.

As with anything in life, cool heads prevail in hot situations. If a teammate seems out of line, take a calming breath. Remember the techniques we described under Redirect in Part 1. Politely ask how their feedback relates to the scenario at hand or would help users attain their goals. Design can be highly subjective, so it is important to relax and remain as objective as possible. After all, it is best always to assume good intent on the part of your teammates—that the intent of their feedback is to make your designs better. Learn and grow by openly considering everyone’s feedback. That said, if you receive negative feedback that is personal in nature, you are well within your right to defend yourself.


While you should endeavor to include your product-team members in design reviews, usability studies, and other UX activities, it is just as important to formalize the findings and metrics that result from those activities. Typically, senior leaders want to see numbers to understand how User Experience helps improve the bottom line, but your teammates also want to see metrics because the product’s performance reflects their individual contributions, too. User Experience doesn’t exist as an island. The destinies of the members of cross-functional teams are often intertwined. Your success is their success and vice versa.

If you’re fortunate enough to have access to product telemetry—which can be elusive in the world of enterprise software—report on it early and often to provide transparency. Even if your design solutions do not initially demonstrate their value tangibly, you can still show value by giving the team insights into the product’s performance. Remember to reveal your design decisions in a contextual way. Telemetry reports are no exception. While tools such as Google Analytics and Mixpanel offer their own reporting workflows, one thing always holds true: information is not the same thing as data.

Information is data that someone has curated for a target recipient. Do not simply regurgitate what the tools give you—even if the output looks nice. Take the data, study it, and look for any additional patterns that are not obvious. Are there obscure points of failure in the user’s journey? Why are users navigating the user interface in a way you weren’t expecting? Is there low engagement with a feature the business considered highly desirable? What other inferences can you draw that the accompanying information confidently backs up? Deeply consider these reports. Ask a trusted peer to cross-check them. Curate data, creating actionable information that demonstrates value.

Adopt the same mindset regarding usability studies. If you’re using some whiz-bang tool that spits out video recordings that show study participants using your software, don’t just send the video files to teammates and expect them to watch them. They won’t. Instead, review the videos and notes, relive the study sessions, and polish a curated message for your teammates. Remember, presenting information to your team in a meaningful way promotes clearer thinking. As you rehearse your tailored message—even if it’s in written form—you’ll better understand the underlying problems. This allows you to give your teammates the right level of designed information that they can comprehend, which they’ll be more willing and able to act on.

Ramp Up

As you progress in your journey to demonstrate the value of User Experience to your product teams, help them onboard UX knowledge along the way. As we discussed in Part 1, being too quick to use jargon with your team only leads to alienation. However, that doesn’t mean you can’t progressively grow your teammates’ UX knowledge, vocabulary, and skills as you go.

Prior to conducting a usability study, explain the process to those you’ve recruited to observe the sessions so they understand why you’re asking participants to think aloud and why you won’t immediately help them to perform the correct actions to achieve the desired result. If you’re fortunate enough to visit a customer site to perform a contextual inquiry, go ahead and coach any non-UX observers on proper observation techniques and how to ask probing questions that do not lead the user or create biased results. Help grow your teammates’ skills organically and contextually. Most people learn best by doing.


Make a habit of incorporating all of the Rs that I’ve described in this column in your work with product teams, as well as the Rs we described in Part 1. Consistency and stability are at a high premium in the modern world of hyper-fast software delivery and increased user expectations. Trying to achieve them can overwhelm development teams—including those who build enterprise software.

As a UX professional, you are in a position to help bring order to the chaos of software development through the repetition of desirable behaviors and by iterating your deliverables. Predictability favors process, which fosters efficiency, and eventually leads to faster product delivery. As you begin to establish User Experience as a core component of your product team’s development efforts, ensure that you consistently leverage what you’ve learned and what has worked. Then repeat.


Your challenges do not stop once you’ve onboarded User Experience to your enterprise product teams. As you progress in your journey to establish User Experience as an essential component of your team’s success, openly reveal the thought behind your design decisions with clarity and intention. Your teammates cannot directly experience your thoughts. They experience what you communicate. Ask teammates to review your in-progress deliverables early and often to cultivate shared responsibility.

If you receive harsh criticism of your design deliverables, respond calmly. Reacting defensively undermines your credibility and stunts the growth of UX maturity. Regularly report any insights you gather on the product’s performance to your team—over the course of iterative releases—and attempt to translate the data into actionable information to further demonstrate the value of User Experience. Ramp-up your teammates’ knowledge of User Experience along the way to help grow UX-maturity in your organization. Finally, codify what has worked and repeat successful approaches. You have an opportunity to make User Experience a key ingredient of your enterprise’s software-development process. 

Source link