Top

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

Enterprise UX

Designing experiences for people at work

November 5, 2018

The general public is often unaware of enterprise software products. For the UX professionals who create these products, designing for highly specialized users poses unique challenges. The learning curve for a particular domain can be steep because UX designers don’t necessarily have any applicable knowledge about similar domains or products. When UX professionals are working with product teams who know their unique domain much better than they do, it can be particularly difficult to demonstrate the value of User Experience.

What often happens is something like this: Business leaders for an enterprise product bring on UX professionals who have some available bandwidth, but no familiarity with the problem space. They then drop these UX professionals into teams with product managers, developers, testers, and program managers who already know the domain. Such teams often perceive these UX professionals as not adding much value on strategy, up-front research, task analysis, or interaction design because they don’t have the deep product expertise that comes with training and time in the domain. In such cases, the role of User Experience is often limited to making the product somewhat more usable or look better.

In such a situation, UX professionals often experience what are seemingly contradictory feelings: being both out of their depth and underutilized. This is especially true for UX professionals who are working at a company with a low level of UX maturity. In this column—the first in a series of two parts—we’ll cover five Rs for UX professionals that facilitate their onboarding and enable them to demonstrate the value of User Experience to enterprise product teams:

  • research
  • request
  • receive
  • redirect
  • recruit

Research

Of course, user-centered design always requires an awareness that you are not the user. A UX professional who is designing a product for physicians might know some of their lingo, but has likely never gone to medical school or treated patients. In a case like this, it becomes especially important to conduct up-front research—perhaps a contextual inquiry using a master / apprentice model—that helps you to develop a deeper understanding of the specialized user and that user’s objectives.

Some folks on the business side might wonder why you can’t just read existing product documentation to come up to speed. But, while documentation is certainly helpful when you’re just starting your onboarding process to work in a new product domain, we’ve found that it tends to be highly prescriptive and solution focused, especially if the author has a more technical background.

Product Management may also tell you that they already know what the customer wants. Unfortunately, many product managers think in terms of features that customers—or salespeople—have requested rather than focusing on the needs of users or how they do their work. As we discussed in our first column,“Defining Enterprise UX,” the customers and actual users of enterprise software are not usually the same people.

Get to know your product’s users. If no information exists that describes a particular user’s role, mindset, goals, and tasks—the kinds of details you need to create a persona—it’s up to you to do the necessary research and define that persona. Look for early opportunities to meet with specialized workers. You’ll need to understand their needs, expectations, and painpoints before you can begin designing solutions for them. There is much more we can say about conducting effective enterprise UX research, and we’ll be delving deeper into this topic in an upcoming column.

Request

When working on an enterprise software product, you are likely surrounded by experts. For example, Rockwell Automation, where we work, is an engineering-driven company. While these engineers are not themselves the users—or at least might not have done the day-to-day work of the people who will use your product for many years—they have a wealth of knowledge about the domain. Don’t be afraid to tap into their expertise. Perhaps you’ll be able to pick the brain of an esteemed principal engineering fellow who has dozens of patents to his name. In discussions with internal experts, we play the “I’m a newbie / not an expert” card a lot in our quest to understand the problems we need to design our products to solve.

Here are some practical tips that have worked for us when requesting information from our teammates:

  • Introduce yourself to each team member individually. Simple, right? Maybe not, especially if you’re part of a large team that is distributed across multiple time zones. Still, we strongly encourage you to make the effort to establish a one-on-one relationship with each team member. Don’t overlook those who are quieter or don’t speak your language well. Let them know how much their knowledge can help you improve the design of the product. If they are several time zones away, you may need to make yourself available for a Skype call late in the evening, but it is well worth the effort. While you can guide the conversation to ensure you get your questions answered, be sure to give your teammates plenty of space to talk, too.
  • As UX professionals, we like to be seen as experts in our field. But pride shouldn’t get in the way of admitting that you lack expertise in a teammate’s specialized area. At Rockwell, we’ve been fortunate to work with engineers and developers who love to solve problems. As long as we are respectful and appreciative of their time, they eagerly accept the challenge of educating us. Plus, being transparent with our teammates about what we don’t know and what we’re trying to do for users creates the foundation for a productive, long-term relationship.
  • Be specific about what you need. Do you want a teammate to demo a product or feature so you can learn about it? Can your teammates share any additional documentation with you? What can they tell you about the issues users have in completing certain tasks with the existing application or a competitor’s product? Always remember that the onus is on you to be proactive in seeking out your teammates’ help. If you don’t ask for help, they’ll assume you have what you need.

Receive

Once you’ve established rapport with your teammates, it is critical that you practice active-listening skills when seeking the information you need to design effective solutions. A ready ear communicates your interest and empathy. You’ll come away with the most valuable insights if you listen to your colleagues just as you would listen to users.

Remember, most experts genuinely like talking about what they do and sharing their expertise by teaching others. We’ve found it’s very helpful to repeat back what we’ve heard. (“So, let me make sure I understand what you’ve said so far….”) Experts may gloss over some details that they assume you already know, so don’t be afraid to ask for clarification.

Being an active listener builds trust and demonstrates your investment in your teammates’ thoughts and ideas. This trust pays off when it’s time to obtain their buy-in for your design solutions.

“Everyone opens up when someone listens to them attentively and shows avid interest in what they’re saying.”—Pabini Gabriel-Petit

Redirect

Receiving the information you need is one thing. Processing and understanding it is quite another—especially when you’re dealing with complex, enterprise software. If a subject-matter expert (SME) goes on a tangent, explaining technicalities that aren’t really relevant to your current design challenge, you can attempt to redirect the conversation. (Remember, your job is to become expert enough, not to actually become an engineer, doctor, or detective, for example.) One way of doing this is to ask open-ended questions that focus on what the user needs to do. Here are some questions that we have found useful:

  • Who is the user in this scenario and what is her role?
  • Can you walk me through what the user is trying to accomplish with that feature?
  • What is the user’s goal at this point in the workflow?
  • How does that help the user accomplish his task?

As UX professionals, we need to understand the user’s goals, needs, context, and expectations before we start designing. However, experts often leap right into solving problems. So, during your discussions, they may propose features and design solutions. Listen and take notes on their ideas, but don’t commit to any particular solution at this point.

Remember, you don’t want to force your SMEs to redirect your conversation just to clarify your UX jargon. If you want others to simplify the words they use, return the favor. Terms such as cognitive walkthrough, contextual inquiry, and heuristic evaluation are not in common use outside the UX community. Don’t overwhelm your teammates with jargon. However, that doesn’t mean you can’t gradually increase your teammates’ vocabulary along the way. We’ll discuss more about how we can educate our colleagues in Part 2.

Recruit

To leverage your colleagues’ expertise effectively, involve your teammates early in the design process. Invite them to preliminary brainstorming sessions and design reviews that focus on low-fidelity deliverables—which we’ll cover more in Part 2. You can use these sessions as a low-key way of educating your teammates about user-centered design—just by exposing them to your process and letting them see the effort that goes into iterating design solutions. Plus, their insights will help them better understand how they can help you in your ongoing journey to understand the product’s unique problem space.

Continue to keep your teammates involved throughout the design process. Invite the development team and other SMEs to sit in on usability studies. Don’t just share research findings, encourage your colleagues to observe the studies themselves. It never ceases to amaze either of us how much benefit developers, engineers, and product owners can derive from watching study participants struggle with solutions that may have seemed like slam-dunks to the product team.

A cross-functional team that shares the experience of observing the successes and failures of their product through the eyes of the user can generate a spirit of collective ownership of that product. The team develops shared knowledge, camaraderie, and trust.

Conclusion

Designing enterprise software poses unique challenges, but you can overcome them by conducting early user research and requesting the feedback of individual team members. Receive their input openly and patiently, redirecting their comments as appropriate to align with your user-centered approach. Finally, recruit and encourage teammates to be active participants in your UX research and design activities because sharing such experiences draws teams closer and leads to improved efficiency and productivity.

In Part 2 of this series, we’ll provide more tips to ensure that User Experience becomes an essential component of your enterprise product team. 

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

Lead User Experience Researcher at Rockwell Automation

Cleveland/Akron, Ohio, USA

Chris BraunsdorfOver the last two decades—as a researcher, interaction designer, and information architect—Chris has helped shape products for a wide variety of companies and industries. He has worked at startups, consulting firms, and Fortune 500 companies, in domains that include mortgage finance, insurance, ecommerce, and industrial automation. At Rockwell, his work impacts the design of software that powers factories producing automobiles, food and beverages, pharmaceuticals, oil and gas, diapers, and just about anything else imaginable. As a researcher, Chris employs a wide variety of methods to discover user needs and expectations and drive product strategy. Curiosity, critical thinking, and storytelling guide him on every project. Outside of work, Chris is a music / pop-culture nerd and a voracious reader who uses his store of useless knowledge to compete in an online trivia league. His happy place is right next to the stage in a small club, watching live music.  Read More

Other Columns by Jonathan Walter

Other Articles on Value of User Experience

New on UXmatters