Process over deliverables: how senior designers work with founders

Every six months a designer at a startup messages me asking the same thing: "How do you actually work with founders day-to-day? What's your process?"

The honest answer is that the process matters less than I'd like to admit. What matters is what I'm optimizing for at each stage. Most designers — and I include past versions of myself here — optimize for deliverables. Pretty Figma files. Polished prototypes. The artifacts of design.

That's exactly what stops careers from compounding past mid-level.

The deliverable trap

When you optimize for deliverables, you become very good at producing them. Your screens get tight. Your prototypes ship on time. Your handoff docs are readable. These are real skills, and they got you to your current role.

But here's the trap: at most early-stage companies, the bottleneck has never been the quality of the screens. The bottleneck is the quality of the decisions the screens encode.

A founder who hires a senior designer doesn't need beautiful onboarding flows. They need someone who can say "we shouldn't ship this onboarding flow at all — the activation problem isn't onboarding, it's the third session." That sentence is worth more than four weeks of polished mockups.

If your job description in your own head still reads "design the screens," you're stuck in the deliverable trap.

What a decision-first process looks like

The shift is subtle but reorients everything. Instead of asking "what should I build?", you ask "what should the team decide?". Then your design work serves the decision, not the other way around.

Here's what that looks like across the four phases I run with founders.

Phase 1: Reframe before designing

Almost every brief from a founder comes pre-cooked with a solution buried inside. "Redesign the onboarding to fix our activation rate." That's a brief with a solution masquerading as a problem.

The first week is reframing. Look at the actual data. Talk to ten users. Map the funnel. Then come back to the founder with the actual problem, which is rarely what was in the brief. Often the conversation goes: "So you said the issue was onboarding, but the dropoff is actually session 2 to session 3. The onboarding is fine. We need to redesign the second-session experience."

That conversation is the most valuable thing you'll do all month. It's not in any portfolio. It saves the company six weeks.

Phase 2: Decide before producing

Once the problem is clear, the next move is to write down the three or four key decisions the team needs to make. Not screens. Decisions.

For a typical engagement, decisions look like:

• Which user persona are we explicitly not serving in this release?
• What's the smallest version we can ship to test the hypothesis?
• Are we building this in the existing flow, or carving out a new entry point?
• What metric will tell us this worked, and what threshold counts as "worked"?

These decisions get made over async conversations with the founder before any pixel moves. The screens that follow are downstream of these decisions — and they're 5x easier to produce because the design space is now constrained.

Phase 3: Design as evidence, not output

Once the decisions are made, the design work becomes evidence. Each screen is asking a question and proposing an answer. The hi-fi mocks aren't the deliverable — they're the artifact of the team agreeing on what to build.

This sounds abstract, but it changes how you present work. Instead of presenting "the new dashboard," you present "the four hypotheses we tested in the dashboard work, and the one that survived." The founder sees the thinking. The engineer sees the constraints. Everyone shares context.

I covered the decision frame in more depth in another piece — the short version is: a senior designer's main output is not screens, it's clarity.

Phase 4: Stay involved through the build

The final phase is the one most designers skip — staying involved during build. Not as a quality gate. As a partner.

Engineers will hit edge cases the design didn't account for. The PM will renegotiate scope mid-sprint. The CEO will see the partial build and want to change one thing. If you've handed off and walked away, every one of these decisions gets made without you, and the work that ships is some lossy compression of what you designed.

A senior designer treats the build phase as ongoing decision-making, not as someone else's problem. You don't have to be in standups daily. But you should be a slack message away when the eng lead needs a 2-minute call to unblock something.

The mindset shift

If you take one thing from this: stop counting deliverables in your career. Count decisions you influenced.

A great month isn't 14 high-fidelity screens. It's two hard product decisions where your input changed what the company shipped. The screens are downstream of that.

This is the shift that took me from senior to staff-track. It's also what most founders are looking for when they hire someone "senior" — even when they can't articulate it that way themselves.

What this means for your portfolio

Your case studies should reflect the decision-first orientation. I wrote a separate piece on the seven portfolio mistakes that signal you're still in deliverable mode — most of them stem from the same root: showing the screens instead of the thinking.

The fix is the same here as there: lead with the problem, name the decisions, show the evidence. The screens take care of themselves.

If you're trying to make this transition and want a second pair of eyes on the process side of your work, drop me a note — I sometimes do 1:1s on this when my schedule permits.