How product designers move responsibly through uncertainty without waiting for perfect clarity.
Before sunrise in Labuan Bajo, Ameera joined a small boat heading toward an island she had only seen in photographs.
The sea was calm when they left the harbor. Thirty minutes later, a pale fog settled over the water. The coastline disappeared. The other boats became faint shadows, then vanished.
Ameera looked toward the captain. He did not pretend to see the full route. He checked the compass, reduced speed, listened to the engine, watched the current, and compared the position with familiar landmarks that appeared for a few seconds at a time.
He was neither frozen nor reckless.
“Can you still find the island?” Ameera asked.
“I can find the next safe direction,” he replied.
Design work often begins in that kind of visibility. The brief is incomplete. Stakeholders disagree. User behavior is changing. Technology creates possibilities nobody fully understands. The team wants certainty before moving, but certainty will only come from movement.
The Stanford d.school calls the ability to work productively in this condition Navigate Ambiguity.
🌫️ The Brief With One Clear Sentence and Twenty Hidden Questions
Ameera’s product team received a request to “build an AI assistant for customer support.”
The sentence sounded decisive. Underneath it were many unanswered questions.
Whose problem was the assistant solving? Customers waiting for answers, agents handling repetitive tasks, or managers trying to reduce cost? What kinds of requests were safe to automate? Which languages and tones should it understand? What would happen when it was uncertain? How would people know whether they were speaking with a person or a system? What information could the assistant access?
The leadership team wanted a roadmap. Engineering wanted requirements. Legal wanted defined data use. Customer support wanted relief but feared losing judgment in sensitive cases.
Ameera could not produce an honest, complete plan because the team did not yet know enough.
She could, however, help them make the ambiguity visible.
🗺️ Name What Is Known, Unknown, and Contested
Ambiguity becomes more frightening when every uncertainty is mixed together.
Ameera created three areas on a wall.
Known: Support volume was growing. Delivery-status questions formed a large repeated category. Agents copied information across several tools. Customers disliked waiting for simple updates.
Unknown: How accurately an assistant could interpret mixed Bahasa Indonesia and regional expressions. Which requests customers would trust it to handle. How much time agents would actually save.
Contested: Whether the main goal was cost reduction, faster resolution, or better agent support. Whether the assistant should speak directly to customers or begin as an internal tool.
Naming these categories did not solve them. It stopped the team from treating every statement as equally factual.
Some unknowns required research. Some required experiments. Some contested areas required a leadership decision. Some constraints required expert input.
Ambiguity had become navigable because it had structure.
🧭 Choose a Direction Without Pretending It Is the Destination
The captain in Labuan Bajo adjusted course using the best available signals. He did not draw a false straight line through the fog.
Ameera helped the team choose a bounded starting direction: an internal assistant that helped agents retrieve delivery information and draft responses, while keeping the agent responsible for sending them.
This direction reduced several risks. The team could learn from real support cases, observe where the system was uncertain, and preserve human judgment. It also left open the possibility of customer-facing automation later.
The decision was not a permanent product vision. It was a responsible next position.
Navigating ambiguity means making provisional commitments that create learning without locking the team into an unsupported future.
🔦 Build Small Beacons of Clarity
When the whole landscape is unclear, teams benefit from small things they can trust.
Ameera’s team created a shared problem statement, a list of prohibited use cases, a weekly review of failed responses, and a simple principle: when confidence was low or consequences were high, the system should make uncertainty visible and involve a person.
They also collected real language from support conversations. One customer might write, “Paketku nyangkut di mana?” Another might ask whether a parcel was “muter-muter.” The system needed more than formal shipping vocabulary.
Each research session and prototype added a small beacon. The team learned which questions were repetitive, which needed emotional judgment, which data sources were reliable, and how agents wanted suggestions to appear.
Clarity accumulated through action.
⚓ Hold the Tension Instead of Solving It Too Early
Ambiguous projects contain tensions that cannot always be optimized into one simple answer.
Automation could increase speed and reduce personal care. More data access could improve answers and increase privacy risk. A confident response could feel useful and hide uncertainty. Human review could protect quality and reduce the promised efficiency.
Ameera resisted slogans such as “AI first” or “human first” because they ended the conversation before the team understood it. She framed the work around situations and consequences.
For a simple delivery estimate based on reliable data, automated assistance could be appropriate. For a lost package containing medicine, the system should help a human act quickly and carefully. The distinction depended on risk, context, confidence, and user need.
Navigating ambiguity often means holding two valid concerns long enough to create a better relationship between them.
🌊 Ambiguity Is Not an Excuse for Endless Discovery
There is a comfortable version of uncertainty where teams continue researching because deciding feels risky.
Ameera set decision points. After two weeks, the team would choose the first use cases. After a limited internal pilot, they would decide whether the assistant reduced handling time without increasing correction work. After reviewing sensitive cases, they would decide which boundaries must remain.
Each decision used the evidence available at that moment. Each included a condition for revisiting it.
Navigating ambiguity is active. It requires sensing, framing, making, testing, deciding, and adjusting. Waiting for the fog to disappear is also a choice, and often an expensive one.
The aim is not to eliminate uncertainty. It is to move without allowing uncertainty to become either paralysis or careless confidence.
🧑✈️ Make the Route Legible to the Crew
A captain may hold experience that others cannot see, but the crew still needs to understand what is happening.
Ameera communicated why the team had chosen the internal assistant, what evidence supported it, what remained unknown, and which signals could change the direction. Legal understood when their input was needed. Support agents understood that the pilot was not a hidden plan to remove them. Engineering understood which capabilities were exploratory and which boundaries were firm.
The route was provisional, but it was not mysterious.
This matters because ambiguity can concentrate power in whoever claims to have intuition. Making assumptions and decision rules visible allows a team to navigate together.
🌅 When the Island Appeared
On the boat, the fog began to thin. A dark hillside appeared slightly to the left of where Ameera had expected it. The captain adjusted course once more.
He had not predicted every meter of the journey. He had combined experience, instruments, observation, and small corrections to keep moving safely.
Months later, Ameera’s team had not created the grand AI assistant from the original brief. They had built something more grounded: an agent tool for selected requests, clear escalation boundaries, and a body of learning that made the next decision wiser.
The route emerged through the journey.
Designers do not become valuable by pretending the fog is absent. We become valuable by helping people see what is known, choose a responsible direction, create evidence, and adjust without losing the larger purpose.
You do not always need the full map.
You need enough shared orientation to find the next safe direction.
🧺 Takeaways to Bring Into Your Next Project
- Ambiguity is a normal condition of design work, not a sign that the team has failed.
- Separate what is known, unknown, assumed, and contested.
- Make provisional commitments that create learning without pretending to be final answers.
- Build small beacons of clarity through principles, evidence, boundaries, and decision points.
- Hold important tensions long enough to design more responsible relationships between them.
- Avoid both paralysis and careless certainty.
- Make the route, assumptions, and reasons legible so the team can navigate together.
P.S. Next up:
“Reflection: Like a Warung After Closing, Turning a Busy Day into Better Judgment” 👀
🔗 About This Series
This is article 8 of Designerly Thinking: Eight Core Design Abilities, followed by a reflection epilogue. The abilities come from the Stanford d.school and are not intended as a rigid sequence.
- Design Your Design Work: Like Setting Up Your Kitchen Before You Cook
- Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood
- Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research
- Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu
- Move Between Concrete and Abstract: Like a Doctor Connecting Symptoms to the Larger System
- Build and Craft Intentionally: Like a Watchmaker Engineering Every Gear
- Communicate Deliberately: Like a Diplomat Aligning Allies in a High-Stakes Room
- Navigate Ambiguity: Like a Captain Forging the Route Through the Fog
- Reflection: Like a Warung After Closing, Turning a Busy Day into Better Judgment
