Notes on being the first design hire

I’ve been the first design hire four times now. Every time I’ve wanted to start by fixing the interface, and every time the useful work was somewhere else first.

Weeks 1–3: earn the right to have opinions

Ship something small and visible in the first week — a real fix in the real product, merged. It tells the team that “design” here means someone who finishes things, not someone who arrives with a 40-slide critique.

Resist the redesign. You don’t understand the constraints yet, and a big speculative redesign is the fastest way to be filed under “nice to have.”

Weeks 3–8: build the smallest system that holds

You cannot design every screen. You can design the decisions every screen reuses: a type scale, a spacing ramp, a color system, six to ten components. Keep it small enough that the engineers can hold it in their heads, because they’re the ones who’ll maintain it after you move to the next fire.

Wire it into code the same week you design it. A system that lives only in Figma is a document, not infrastructure.

Weeks 8–12: pick one flow and go deep

Prove the system on the flow that matters most to the business — usually onboarding or the core loop. One flow, fully considered, motion included, shipped and measured. That’s your evidence for everything you argue for next.

The through-line

Every one of these is about compounding. The small ship compounds into trust. The system compounds into consistency you don’t have to enforce by hand. The one deep flow compounds into a mandate. Ninety days isn’t enough time to fix a product, but it’s enough to make sure the next ninety are yours to spend well.