Top

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

Enterprise UX

Designing experiences for people at work

A column by Jonathan Walter
December 17, 2018

In Part 1 in this two-part series, Chris Braunsdorf and I explained that, in an environment where UX maturity is low, onboarding User Experience with an enterprise product team poses unique challenges. However, you can overcome these challenges by

  • conducting early user research
  • requesting the feedback of individual team members
  • receiving teammates’ input openly and patiently
  • redirecting teammates’ feedback to align with your user-centered approach
  • recruiting team members as active participants in your UX research and design activities

However, once you’ve onboarded User Experience in your organization, you must demonstrate certain skills to ensure that it becomes an essential component for your enterprise product teams going forward. These skills extend beyond your UX design capabilities.

“Having impeccable design skills and some technical knowledge around user-interface technologies and capabilities are just table stakes for a successful UX designer.”—Baruch Sachs, in “The Role of Soft Skills in Conveying Strategy to Executives,” a UXmatters column by Janet Six.

Enterprise product teams assume that you have these hard skills—especially teams comprising engineering-minded people. Now, in Part 2, I’ll cover six additional Rs that enable UX professionals to further demonstrate the value of User Experience to enterprise product teams:

  • Reveal
  • Review
  • Respond, calmly
  • Report
  • Ramp up
  • Repeat

Reveal

You may have well-articulated thoughts on how to design a compelling solution, but product teams experience neither your thoughts nor your intentions. Teams experience what you communicate. UX professionals must clearly reveal the rationales behind their design decisions, or they won’t get the input they need to make improvements or pivot directions if necessary.

Often, as Tom Greever points out in his book Articulating Design, the viewpoint of the most articulate person wins. While the goal shouldn’t be to win, but to foster alignment, Greever’s argument holds true. Articulate people are more successful than their peers in revealing why a design solution makes sense. It is difficult enough to persuade people to forge new experiential ground when designing pricey enterprise software products, so being a good communicator is critical.

While the following communication tips are applicable beyond enterprise software—and even User Experience in general—they merit a prominent place in this column. Here are some tips for honing your communication skills:

  • Read—a bonus R! Make the time to read frequently and broadly. The material you read doesn’t necessarily have to relate to User Experience or your domain of focus. In fact, I recommend that you explore topics outside your areas of expertise to foster lateral thinking, which is an important ingredient of being relatable and empathetic. Plus, frequent reading makes you a better writer.
  • Write well. Take a class if necessary. But, in my experience, writing with diligence—and being as clear and concise as possible—will get you most of the way there. It is important to ask someone who is either knowledgeable in the product domain or is a skilled writer—ideally both—to review and provide feedback on your work, if not edit it directly. Finally, rewrite, rewrite—and when it finally seems good enough—rewrite some more. Good writing is rewriting. Apply this advice even to routine communications such as email.
  • Speak publicly. Don’t shy away from speaking opportunities. While you might not be comfortable presenting to large groups of people—I can relate—you won’t achieve growth by remaining in your comfort zone. Speaking to a large audience or being interviewed in a video or podcast accomplishes several things:
    • Speaking builds confidence. If you can speak publicly, it becomes easier to reveal your thoughts to product teams within less visible, less nerve-racking contexts. Having public speaking experience under your belt gives you more self-assurance as you engage with teams or others across your organization.
    • Speaking builds credibility. External audiences aren’t the only ones who benefit from watching or hearing you speak—your teammates do, too. By publicly sharing your expertise on a topic, you cast yourself in a new light to team members and grow in their esteem. They know public speaking is hard, and your willingness and conviction to continue speaking says a lot about you.
    • Speaking clarifies your thinking. Have you ever had a problem or an idea in your head that didn’t gain clarity until you spoke about it to someone else? Conveying your intention or an abstract concept to another person also furthers your own knowledge. The same is true for speaking publicly on a topic for which you have a passion, because it forces you to think deeply about your true intent, which in turn hones your thinking and accelerates the expansion of your expertise.
  • Observe. Read the room. A great deal of communication is nonverbal. Be aware of how the words you use affect others. This is key to emotional intelligence. Did someone wince in response to something you said? Are people crossing their arms—a sign of being closed off—or smiling and nodding? Is someone absently tapping away on his smartphone screen, apparently having checked out? Good communicators adjust, and adaptability is critical if you work with a variety of teams across different organizations or even cultures and time zones. You won’t get far working with teams if you come across as lacking self-awareness. Furthermore, not all teams communicate in the same manner, so being aware of what works and what doesn’t helps you demonstrate your value.
  • Lead by example. Obviously, you must do what you say you’re going to do and follow through. But go further. Arm your teams with what they need by taking the time and care to produce clearly articulated, well-designed UX specifications. Annotate your mockups and deliverables to give your rationale for your design solution. Team members care about the why behind your decisions, so reveal the quality of your thinking to them. You were paid to provide it. Doing so helps facilitate better cross-disciplinary communication, and you’ll more likely get what you need from them.
Friend Advertisement
Continue Reading…

Review

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.

Report

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.

Repeat

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.

Conclusion

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. 

User Experience Architect at Rockwell Automation

Cleveland, Ohio, USA

Jonathan WalterJon has a degree in Visual Design from the University of Dayton, as well as experience in Web development, interaction design, user interface design, user research, and copywriting. He spent eight years at Progressive Insurance, where his design and development skills helped shape the #1 insurance Web site in the country, progressive.com. Jon’s passion for user experience fueled his desire to make it his full-time profession. In 2013, Jon joined Rockwell Automation, where he designs software products for some of the most challenging environments in the world. He is UX lead for a revolutionary analytics appliance for users on the factory floor. In addition to his Fortune-500 experience, Jon has contributed his skills to a real-estate startup. Jon rounds out his time by writing and reading anything he can get his hands on.  Read More

Other Columns by Jonathan Walter

Other Articles on Value of User Experience

New on UXmatters