Building a Product Design Team from Scratch

---

What I walked into

GoFreight was about to launch its first customer when I joined. The previous designer was leaving, and I was taking over. The role I inherited wasn’t quite what I expected.

Because the team had always run lean and the engineering culture was full-stack, designers were expected to cut HTML and CSS — layout in code, handoff to backend engineers. “Design” and “web production” were essentially the same job.

Early on, I leaned into it. I knew HTML and CSS well enough to prototype directly in the browser, and for a B2B SaaS product where layout patterns repeat, it was often faster than Figma. But I started to notice something: the team’s thinking was shaped by what was easy to build, not by what users needed.

---

The first shift: getting design out of the build pipeline

The engineering lead — the CTO at the time — felt strongly that CSS cutting wasn’t “real code” and belonged with design. Other engineering leads were more neutral.

I didn’t fight this head-on. I brought it up in regular 1-on-1s with the CEO and COO — not as a complaint, but as a question: what kind of design team is GoFreight trying to build?

The shift happened — partly through those conversations, partly through timing. A small round of layoffs included the engineer most opposed to the change. With that resistance gone, the team reorganized. I won’t pretend I drove this cleanly — timing and circumstance played a real role. But I’d kept the conversation alive long enough that when the moment came, there was already alignment around what to do. Organizational change rarely moves on your schedule. The job is to keep the right conversation alive until the window opens.

---

Building the team: what I actually hired for

As GoFreight grew — first to 4 people, then to 8 through the A-round push — I developed a clearer sense of what I was actually selecting for.

The harder lesson was cultural fit. A designer whose communication style clashed with the team’s didn’t cost extra skill — they cost extra energy. In a small team moving fast, that cost is real. I also learned not to stall on hiring: the instinct to keep interviewing, hoping the next candidate might be slightly better, made searches longer and sometimes cost us good hires who weren’t willing to wait. If someone is clearly good enough and the culture fit is there, the right call is usually to move — “what if there’s someone better?” is a question without a bottom.

---

The harder challenge: building user empathy

Having more designers didn’t automatically create a user-centered culture. Even after the HTML handoff was resolved, the team’s default starting point was often “is this feasible?” rather than “what does the user need?”

The change that actually shifted this was simple: I made user interviews a requirement for everyone on the design team.

It wasn’t a formal program — closer to a standing expectation. If you’re working on something, you talk to users. What happened as a result was less about the specific insights collected, and more about what it did to how designers held themselves in product conversations.

Before, designers had to accept the PM’s read on users. They didn’t have their own data. After, they did. Discussions between designers and PMs became more substantive — not because designers were being defensive, but because they had something to stand on.

---

What I built to make it stick

Design critique. With multiple designers working across a large system, the same UI pattern kept getting solved two different ways. Not because anyone was wrong — just because decisions were made in isolation. Critique gave us a shared forum to surface inconsistencies before they shipped.

Component library. We didn’t build the design system from scratch. GoFreight’s product already existed and had its own patterns — some consistent, some not. Instead of starting with color tokens and building up, we extracted what already existed in the product and turned it into reusable components. The goal wasn’t a perfect system. It was a fast one — something designers could actually reach for.

---

The outcome I remember most

I could point to the products we shipped or the surface area the team covered. But the thing I remember most is smaller than that.

Designers started telling me things they wouldn’t have said early on. Not just work blockers — a build that wasn’t coming out the way they’d intended, a moment of burnout before it showed up in their work, a relationship problem, a life challenge they were worried might affect their focus.

That was the thing I cared most about building, even when I couldn’t measure it.

---

What I’d do differently

Move faster on cultural mismatches. My instinct was to try to work through friction — to assume coaching or time would shift a problematic dynamic. In most cases, the core issue was how someone engaged with people. That’s not impossible to change, but it costs the team energy they don’t always have to spare.

Structure user interviews earlier. The informal expectation worked, but the depth varied a lot by person. A clearer cadence — even a lightweight one — would have made the culture shift more durable.

Both of these are the same mistake in different forms: knowing what the right move was, and waiting too long to make it.