One of my earliest and most valuable lessons in design consulting was the importance of embracing ambiguity. During college, in thousands of blog posts and in countless conference talks, design is often framed as an elegant solution that perfectly satisfies a set of constraints.
But in real life—especially when it comes to work with clients or different teams within a company—these constraints are rarely packaged and tied with a bow. Boundaries are rarely clear, and, especially when it comes to consulting, design often stretches into new territory.
As individuals, we sometimes find it difficult to differentiate what we need from what we want (as we’ve all learned in Rolling Stones 101), and an outside perspective is helpful in clarifying the situation. Many of the organizations I’ve worked with are no different.
“Embrace ambiguity.”
I’ve seen clients who know they want to grow their customer base, but think they need to do this by releasing a competitive new product, which isn’t always the case. As consultants, my colleagues and I help clients realize they’re better off achieving their goals by making changes to their existing offerings, instead of putting resources against that big product creation. But getting those gears to switch isn’t always an easy thing to do. This goes to show that working through a certain amount of ambiguity at the outset of a project is par for the course in consulting.
Related: Dear client—we need to talk
Is there such thing as too much ambiguity? Of course. As with all good things, moderation is key, especially when dealing with ambiguity on projects. While there tends to exist a forever fuzzy line between corporate strategies and UX problems, designers endeavor to make those lines a little less blurry. It’s why we’re in high demand.
2 types of ambiguity
There’s a certain type of ambiguity and uncertainty around framing a design problem. Let’s call this tactical or “translucent ambiguity.” It lives smack at the center of product design and strategy. It’s fairly common and good designers deal with this type of ambiguity pretty well.
But there’s another type of ambiguity—it’s the uncertainty around basic infrastructure. Within organizations it’s things like business strategies, or clear processes for decision-making. Let’s call this organizational or “opaque ambiguity.” It lives in the areas that orbit and support product design and strategy.
In “opaquely ambiguous” situations, the necessary conditions for a design project’s success may not always exist up front. A lot of the work I do tends to have shades of opaque ambiguity, which is important to acknowledge so you can work through it and help to alleviate it. These types of problems tend to be baked into an organization’s structure, which, again, is why they’re important to work through on any design challenge.
While good UX design can’t always make up for a decision-making void, each project is an opportunity to help fill in the gaps and solve those other, larger issues.
Unfortunately, it’s not always easy to see whether you’re dealing with “translucent ambiguity” or “opaque ambiguity.”
In past projects, I’ve encountered isolated, low-level pain points like design reviews running too long because of a lot of feedback. These subtle problems are usually alleviated through tactical fixes like better timekeeping. However, in other cases, I’ve seen that these lower-level pain points are actually symptomatic of high-level deficiencies. Design reviews might actually be running too long because stakeholders have decision-making trouble because there’s no strategy or larger goal to inform decisions. You’ll need more than just better timekeeping in meetings to fix these types of problems.
“Good UX design can’t always make up for a decision-making void.”
It can be hard to know if you’re dealing with “translucent” or “opaque ambiguity” until you’re deep into a client engagement. However, by catching the red flags and creating a plan to address them, you’ll walk away having solved both a design problem, while also making an impact on organizational issues.
Ambiguity about ambiguity. It’s a cruel world.
Fortunately, there are ways to be better prepared and avoid or address unhealthy ambiguous situations. I’ve put together a list of questions for success based on my—and my colleagues’—past experiences. Use these as a discussion tool in project kickoffs as a way to level-set consultant and designer expectations. Ideally, these will help you from getting too far into an engagement before realizing you’re trying to use design to address non-design problems, and that you’ll need another set of tactics to address this set of problems.
Questions for success
No matter if you’re an in-house product designer, freelancer, or consultant, every design engagement is unique. The following questions for success are a guide. Don’t worry—if every condition isn’t in place, it doesn’t automatically make a project ultra ambiguous or poised for failure. But if the majority of these raise red flags, it may be worth putting extra effort into helping to coach clients and stakeholders. Help them set and reinforce organizational structures and be ready to shift or adapt your mindset to think of the work as an organizational design project rather than a UX design project.
Are stakeholders on the same page regarding business strategy?
Why this is important:
When different stakeholder groups align on overarching business strategy, it’s easier for each group to make lower-level design decisions. A lack of strategic alignment can result in a lot of time spent talking about what to design, rather than actually pushing design forward.
What to work on:
- Help clients and stakeholders create a project plan and mechanisms for sticking to it, or adapting when necessary
- Help to make sure user needs and business needs are all reflected in strategic goals
Do defined requirements exist and do they reflect the business strategy?
Why this is important:
Defined requirements are an expression of a clear business strategy that all stakeholders can and should agree upon. It helps consultants prioritize design goals and iterate more efficiently.
What to work on:
- Help clients and stakeholders to create detailed requirements for a project’s success
that you can then design against
Do stakeholders know their specific roles and project responsibilities?
Why this is important:
Democratization of feedback can be great, but if there isn’t a clear decision-making hierarchy in place, feedback turns into a sea of equally-weighted opinions—regardless of whether they come from a key decision maker.
What to work on:
- Put a working RACI (Responsible, Accountable, Consulted Informed) model into place so everyone knows what role they play
Are there underlying tech systems in place?
Why this is important:
A clear understanding of the available tech infrastructure is crucial for establishing what’s in and out of scope in terms of product functionality.
What to work on:
- Help clients and stakeholders get content management systems and databases established and working
Have adequate tech resources been allocated for a project’s implementation?
Why this is important:
With tech resources in place—or developers who can assess how feasible designs are—design can move into development quicker from an implementation perspective.
What to work on:
- Help clients and stakeholders identify their point-person on the dev/tech side
- Help create a plan for regular updates and maintenance to the digital product
What’s the active management of product’s roadmap look like?
Why this is important:
Consultants, by definition, are on the outside of an organization—therefore it’s important to have someone on the client-side to act as a liaison between stakeholder groups, consolidating feedback and managing decision-making.
What to work on:
- Identify and help empower a product owner on the client side who can act as a go-to figure for consultants
by Pratima Mani
Pratima Mani is a UX designer at Moment who likes information design, systems design, and complexity.
