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

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.