My Design Thinking Process

Design Thinking Isn’t a Process. It’s How You Decide What Matters.

Design thinking gets a bad rap.

So often we see it presented as a nice neat diagram with arrows, sticky notes, and a clear beginning and end. But in the real world, it’s often none of those things.

Design thinking isn’t a workshop. It’s not a deliverable. And it definitely isn’t linear. It’s a mindset that shows up in the decisions you make when things are unclear, constrained, or messy, which is most of the time.

Start With the Design Directive (Not the Canvas)

I start with whatever exists — a PRD, brief, Jira ticket, or sometimes a loosely defined idea. Before opening Figma, my goal is to understand intent.

What problem are we trying to solve?

Who is this for?

What does success actually look like?

I’ll often use ChatGPT here to restate the directive in plain language, surface assumptions, or call out gaps. From there, I follow up with stakeholders to confirm alignment. This step is about framing the problem correctly — not jumping ahead to solutions.

Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible.

Clarify Through Questions (Before Pixels)

Before designing anything, I focus on removing ambiguity. This is where design thinking really earns its keep.

I ask questions like:

• Who is the primary user vs. secondary?
• What constraints are already in play?
• What’s explicitly out of scope?

This is also where some designers start sketching. I’m more intentional.

Early sketches can be helpful — but only if they’re treated as thinking tools, not design direction. If I sketch at this stage, it’s rough and internal — used to explore logic or flow, not layout or UI. Once visuals enter the conversation, they tend to steer it, often too early. I try to protect the problem space a bit longer.

Fidelity should match certainty.

Define User Needs and Flows

Once the problem is clear, I move into user needs and flows.

I map how users move through the experience, focusing on goals, decision points, and moments of friction. This helps surface complexity early — because if something feels confusing at the flow level, it will only get worse in UI.

Tools here might include:

• Low-fidelity user flows
• Light journey mapping
• FigJam or whiteboarding in Figma

This keeps the work grounded in intent, not screens.

Design and Iterate Intentionally

With a solid foundation, I move into design exploration.

I start with structure before polish and explore multiple approaches when the problem is still open. As clarity increases, options narrow. Iteration here isn’t churn — it’s learning.

I use Figma for core design work, and tools like Figma Make or First Draft to quickly explore variations or unblock early thinking. I’ll also use ChatGPT to pressure-test flows or think through edge cases.

Throughout this phase, I stay closely aligned with product and engineering to validate feasibility and keep momentum.

Communicate Progress, Not Just Screens

Design doesn’t move forward in isolation.

I share work early and often, framing designs around:

• The problem being solved
• The decision being made
• The tradeoffs involved

This keeps feedback focused and helps stakeholders engage with intent rather than personal preference.

Prepare for Dev Handoff

As designs solidify, I shift toward clarity and execution.

I make sure flows, states, and interactions are well defined, components align with the design system, and edge cases are accounted for. The goal isn’t perfection — it’s reducing guesswork and rework.

Handoff is a transition of ownership, not the end of design.

Stay Involved Through Build

After handoff, I stay engaged to answer questions, adjust for constraints, and help ensure the final implementation stays true to the original intent.

Design thinking doesn’t stop when development starts — it adapts.