Navigating Ambiguity

Enlisting the Help of Key Stakeholders

When you must solve a vaguely defined problem, do not suffer alone. Schedule time to meet with the stakeholders who are responsible for the product or feature you’re working on—whether the product manager or other subject-matter experts (SMEs). Ask them to share your burden. Their spending time with you to give you clarity is in their best interest.

Asking the Right Questions

It can be difficult—even overwhelming—to decide what questions to ask stakeholders to best achieve clarity on a vague problem. In addition to asking some obvious questions about a project’s timing and roadmap, I like to ask the following W questions to reduce ambiguity and approach a problem from a higher-level perspective:

• What problems does this product or capability solve?
• Who will use it?
• Why will they use it?
• When or in which context will they use it?

Finding answers to these simple questions can be difficult, so don’t be surprised if your stakeholders don’t readily know the answers. The people leading a product’s development and delivery are often equally in the dark as UX designers. They might need their own ramp-up period. Depending on where they are in their process, they may not be able to provide satisfactory information. However, at the very least, asking high-level questions helps you communicate your user-centered approach to stakeholders, which is especially beneficial if they are not familiar with User Experience.

Once you understand this high-level information, you can ask progressively more specific questions. In my experience, asking the following additional questions helps me tease out insights I might not otherwise discover:

• What are some similar capabilities?
• Do solutions for these problems already exist—even if a competitor has developed them?
• Can you recommend any customers I can interview or with whom I can conduct user research?

Also, ask stakeholders about any inklings they might have about how an experience should look and work. While these thoughts should not have undue influence on the experience you ultimately design and you shouldn’t leap into the solution space too soon, asking stakeholders about their assumptions can bring to light any biases they might have, which is useful knowledge to have as you develop your working relationships.

Are stakeholders using words and phrases that are unfamiliar to you? If so, be sure to ask about their meaning. If necessary, rephrase or restate their words and phrases in terms that are meaningful to you. While it is great to foster a shared vocabulary with stakeholders and team members, this doesn’t necessarily mean you should mandate the use of the same vocabulary. If certain words or phrases make sense only to you, don’t impose your preferred lexicon on others. Nor should you blindly adopt any unwieldy words and phrases they might impose on you. Everyone’s brain is wired differently. Having mental talismans that you can call upon to clarify your own understanding is perfectly acceptable—even if you keep them to yourself!

Encouraging Visual Communication

Sometimes words are not enough. The terms and phrases that stakeholders use to describe vague features, capabilities, or product requirements might be ineffective in helping you to visualize the problem space or opportunity. In such situations, hand your stakeholders a marker and ask them to sketch a rough workflow of their ideal experience on a whiteboard. The act of visualizing something often clarifies someone’s thinking—including that of your stakeholders. There is also a good chance that doing this might reveal their pre-existing assumptions or biases. Make sketching a collaborative exercise. Not everyone is comfortable with drawing. You can either create your own drawings or augment those of stakeholders to build consensus and clarify your thinking. Before you know it, you’ll not only have disambiguated the problem, you’ll also have built rapport with your stakeholders.

Some people in the design community disagree with letting people who don’t have a UX-design background participate in the design of a product. However, in my experience, giving your stakeholders the opportunity to participate in shaping an experience not only reduces ambiguity, it also gives the UX designer the opportunity to help shape the requirements. Early collaborative engagement in creating sketches and low-fidelity wireframes often results in alterations to the existing requirements or the addition or elimination of requirements. Before you know it, your product team won’t make decisions without your involvement.

An effective UX designer enables those with whom he or she works. As Jared Spool stated on Twitter, sometimes designers’ value “comes from the designs they enable from others around them.” Achieving through others is an important skill in any profession, and UX design is no different.

Soliciting Multiple Opinions and Perspectives

You’ve made a great start if you’ve already met with key stakeholders who are responsible for releasing a product or feature. But don’t stop there. Get a second opinion—or a tenth. Do not get all of your information from one person—who could potentially suffer from acute bias or a rigid perspective. In addition to seeking information from a product manager, also solicit the opinions of architects, senior engineers, or others who are knowledgeable about the problem space and can help you further flesh out your perspective—even if they’re involved with the project only tangentially. Has anyone performed a similar task or followed a similar workflow using a competitor’s software? Does anyone have prior work experience that maps to the problem you’re attempting to solve?

The realm of enterprise software often has complexities that exceed those of consumer-facing software applications, making it necessary to cultivate as many ideas as possible about how to approach a problem. This eventually leads to better solutions. As Art Markman states in his Fast Company article “A Guide to Uncertainty for People Who Hate Not Knowing,” “People who have the best ideas are often ones who have the most ideas. Quantity, generally speaking, leads to quality.”

Gaining Access to Customers and Users

Usually, your best sources of information do not reside within the walls of your company. These are your customers and users. Granted, it can be very difficult to gain access to these people in the realm of business-to-business (B2B) software—as opposed to business-to-consumer (B2C) software. Plus, doing so might not even be productive if you haven’t yet identified the main problems you’re attempting to solve. Nevertheless, in talking with stakeholders and SMEs, ask them to try to identify people who match the appropriate user personas for the proposed solution. As I suggested earlier, ask, “Who will use this capability?” Once you have their answers and a rough sketch of who these people are, work with internal resources to gain access to them—even if you must do so over the phone. It is well worth your effort to understand your users early in the design process.

Talking with users removes layers of abstraction. Plus, it helps you to see the problem or opportunity more concretely through the eyes of people who would use the eventual solution. As UX designers, our need to take a user-centered approach only increases when requirements and solution hypotheses are vague. If you are fortunate enough to gain access to your target users, I recommend asking them the following questions:

• What are your goals and what do you currently do to achieve those goals for [insert existing workflow or capability]?
• What are your biggest painpoints with [insert existing workflow or capability]?
• What is your typical process when attempting to [insert existing workflow or capability]?
• What other software applications do you use, if any, when attempting to [insert existing workflow or capability]?
• Who do you work with when attempting to [insert existing workflow or capability]?

If you cannot get direct access to users, locate close proxies within your company. Be a detective and seek out their opinions and perspectives. At the very least, doing so can help broaden your perspective, increasing the quantity of ideas you’ll have for addressing the opportunity, which of course fosters the higher quality of your ideas.

Reducing the Problem Space

Trying to solve ambiguous problems can feel overwhelming because they might seem to exceed the bounds of what your brain can comfortably hold. In your imagination, a problem might feel like a tentacled mass that squirms and writhes and reaches. You might feel that you cannot truly grasp it—which is especially true if you’re unable to get adequate help from others, whether inside or outside your company. However, there are some ways of reducing ambiguous problems into a form you can grasp. The following are some techniques I’ve found useful for reducing the problem space to a more manageable scope.

Using Inverse Thinking

Instead of thinking about all the things a solution or capability could do, try focusing on those things it should not do. While this sort of inverse thinking is not new, you’ll be amazed at how quickly you can reduce a problem to a form you can more easily manage. Brainstorm a list of features or capabilities using the knowledge you have—even if incomplete—then cross any items that seem far-fetched or inappropriate off the list. Better yet, encourage stakeholders to participate in this brainstorming activity with you. Before you know it, you’ll have defined what requirements are out of scope—at least for the first release.

Imposing Arbitrary Constraints

Ask yourself what you would do if a senior executive came to your desk and demanded a solution to this problem tomorrow. Sounds crazy, right? However, introducing such fake, highly aggressive time constraints can force your mind to focus on a task for a short, manageable period of time. Granted, you might not be someone who works well under this type of pressure—even if that pressure is imaginary—but reducing your runway for solving a problem, also reduces your ability to seek perfection. UX designers often second guess themselves, becoming paralyzed by all of those things they could do. If you had to come up with something tomorrow, it would be flawed, right? But that would be better than having nothing, and you can always improve on it later. As many in the writing community like to say, “You cannot edit a blank page.”

Finding Similar Patterns and Parallels

People often possess more knowledge and valuable insights than they realize. This includes you. Your knowledge as a UX designer who is working on multiple products is an asset from which many teams can derive value. Wield your broad perspective to your advantage. You might be aware of products, features, or services that do similar things. Even though you might not have deep knowledge in any single area, your breadth of knowledge lets you step back and see patterns and parallels where others cannot. Often, one product team invents a feature that is already in use elsewhere—just under a different name or in a different context. Sometimes there are good reasons for this duplication of effort. More often there are not—and these are simple oversights.

When you’re trying to get up to speed on a vague problem, don’t just pay attention to the words that people use, notice the implicit application behind those words. People might be describing something that is similar to something you’ve already encountered, without being aware of it. Having broad awareness can help give you a top-down perspective on product requirements, which ultimately enables you to reduce the problem space into something more manageable and well known.

Projecting a Vision

As I described in my column “Choosing Your Battles, Part 2,” producing an artifact on which stakeholders can focus their attention and provide feedback can help bring clarity to ambiguous requirements, reduce the problem space, and build consensus faster. Plus, doing so can help foster an environment in which stakeholders can experience the quality of your thinking. A win-win.

Furthermore, your vision—even if it is overly aspirational or flawed—provides a North Star that product-team members can keep in sight as they develop a product. It can also serve as a useful artifact for identifying which features are in scope for early releases and which you should defer to later releases.

Just take care to avoid leading stakeholders to believe that the vision is final. Such a misconception can quickly spiral out of control and even result in a development team’s implementing a solution that has not yet benefited from sufficient design rigor, user research, or usability testing.

Conclusion

Ambiguity isn’t going away despite all we try to do to reduce it. There is no magic way of revealing hidden answers to the difficult questions we face in the world of complex enterprise software. However, once you become comfortable with not knowing everything, you’ll resist the urge to pretend that you know more than you actually do, which would ultimately set you up for failure. Train yourself to ask simpler questions, giving you the opportunity to approach problems from fresh new perspectives.

Begin your partnerships with key stakeholders by asking them some simple W questions that let you approach a problem from a top-down perspective. Then go progressively deeper by asking more specific questions and even encouraging stakeholders and SMEs to disambiguate the problem by sketching their own assumptions. Visual artifacts are often more effective than words alone. This process can also reveal hidden biases.

Try to get multiple opinions—especially those of the users themselves—to provide fodder for thought and generate a greater diversity of ideas about how to approach an ambiguous problem. A larger quantity of ideas helps seed the greater quality of ideas. Limit the problem space by using inverse thinking, imposing arbitrary constraints, and identifying similar patterns and parallels.

You might know more than you think you do—especially if you’re working on multiple products and features. Looking at the problem from other perspectives could provide clarity. Finally, do not be afraid to project a vision—even if it’s flawed—because you’ll build consensus sooner and help clarify the team’s thinking, including your own.