Designing in Ambiguous, Systemic Problem Spaces

How to bring structure and clarity to complex product work

👋 Hey designers, it’s Rebekah, a Product Designer at Meta.

You’re starting a new project.

The brief sounds something like, “Explore how AI could help businesses create better ads.”

Stakeholders have different opinions. You know it will impact multiple tools and teams. The scope is large, and the direction feels unclear.

You open a blank Figma file and realize you don’t know where to begin.

In ambiguous spaces like this, the goal isn’t to jump to solutions faster. It’s to frame the problem and define the scope well enough that you can start designing with confidence.

Here’s how I approach it.

1. Draw a Box Around Where You’re Playing

When everything feels open-ended, the first step isn’t designing solutions. It’s defining the boundary.

If you’re designing for ads on social media, you could improve targeting, creative, reporting, onboarding or all of it. Trying to solve the entire ecosystem at once will be frustrating.

So I draw a box. Not a permanent one, just a working boundary.

For example: “We’re focusing on helping small businesses generate better first drafts of ad content inside the creation flow.”

That box can expand later. It can shrink. It can shift entirely. But you need somewhere to stand before you can move.

Ambiguity becomes manageable once you define where you’re playing.

2. Map the Flow Before You Design the Screens

When there are many unknowns, I don’t start with UI. I start with a flow.

I open FigJam and map how the current experience works at a high level. Where does the user enter? What inputs already exist? What parts of the system connect? Where might this new idea fit?

The diagram is usually messy with boxes, arrows, notes, open questions.

The goal isn’t polish. It’s visibility.

A simple system map helps the team see how everything connects before debating interface details. It’s easier to share, easier to critique, and much faster to adjust.

You’re building shared understanding before building UI.

3. Clarify the Jobs to Be Done

In ambiguous projects, the stated goal is often too broad.

“Help businesses create better ads” sounds clear, but it hides complexity.

A job to be done is the outcome a user is trying to achieve in a specific situation, not just the task they complete.

The job might be helping a small business owner improve ad performance without requiring deep expertise.

I frame it like this:

“This system helps [user] achieve [outcome] within [constraints].”

For example:

“This system helps small business owners create effective ads quickly without needing advanced marketing knowledge.”

If I can’t write that clearly, the thinking probably isn’t clear yet.

That sentence becomes an anchor. It aligns the team and filters out ideas that don’t serve the core outcome.

4. When the Direction Changes, Say It Clearly

In ambiguous projects, direction will shift. That’s normal.

You’ll learn something new. The scope may change.

When that happens, document it.

Restate the updated boundary. Rewrite the jobs to be done. Share the revised flow and explain what changed and why.

If you don’t make the new direction explicit, teams begin operating on different assumptions. That’s when design reviews turn into circular debates and momentum slows.

Ambiguity becomes chaotic when changes feel abrupt or unspoken.

It becomes manageable when direction is clearly named and intentionally shared.

5. Design Mocks

Once the direction feels grounded, the job is clear, and the system flow makes sense, then I move into low-fidelity mocks.

Not polished UI. Not final visuals.

Low-fidelity explorations test logic. They expose gaps. They pressure-test decisions without triggering debates about color or spacing.

Fidelity should increase only when clarity increases.

By the time you reach high fidelity, it isn’t guesswork. It’s the expression of thinking that has already been aligned and refined by the team.

My One-Page Design Brief

Before I start designing, I align with my team on a simple one-page brief. If we can’t answer these clearly, we’re not ready.

1. The User

Who are we designing for specifically?

2. The Outcome

What meaningful change are we trying to create?

3. The Jobs to Be Done

“This system helps [user] achieve [outcome] within [constraints].”

4. The Constraints

What technical or business limits are real and non-negotiable?

5. The Tradeoffs

What are we prioritizing? What are we consciously not solving right now?

Just enough shared understanding to move forward intentionally.

Closing

Ambiguity doesn’t disappear as you grow in your career. If anything, it increases.

The difference is that you stop waiting for clarity and start framing it.

Strong designers don’t just ship designs. They create direction.

And in systemic problem spaces, that might be the most valuable design contribution.

---

Thanks so much for reading! The next time you’re handed a vague brief, remember your first job isn’t to design the interface. It’s to frame clarity.

— Rebekah 💛