Context
Design as an afterthought - and what it costs
When I took on a design lead role at Converj in 2023, design had been reactive for too long. I was the only designer supporting a product and engineering team of twenty. There was no component library, no design review process, and no shared source of truth in Figma. Features shipped with inconsistent UI patterns, onboarding drop-off was high, and engineering lost real time resolving design questions mid-sprint.
The company had just raised funding and was accelerating hiring. Leadership wanted to scale the product fast, which meant design either became a bottleneck, or we built the systems and team to scale with it.
The challenge
Infrastructure first, headcount second
My first instinct was to hire immediately - I was one designer and there was too much work. Instead I spent the first six weeks mapping the actual workflow: where design was getting blocked, where the most expensive errors happened, and where engineering was losing time waiting on design decisions. The answer pointed at infrastructure, not headcount.
Without a component library, every new designer would recreate the same work. Without a review process, quality would stay inconsistent no matter how many people I hired. Without documented standards, a new hire would take months to produce work that fit the product. So I built the infrastructure first, then hired into it - so each new person could be productive from week one instead of month three.
The plan had four parts: a component library, a documented design review process, a simple hiring process, and then scaling the team against that foundation.
My role
Owning the function, not just the deliverables
I was given the mandate to build the design function - as design lead, a player-coach role where I kept shipping design work myself while building the team and systems underneath it.
I set the scope myself: component library, review process, hiring, and mentoring, run as one connected roadmap rather than four separate initiatives.
Leadership
The four pillars of the design function
Component library
Built a shared Figma component library from scratch, starting with an audit of existing UI patterns across the product. Unified inconsistent components (we had six button variants that should have been two), defined a token system for colour, typography, and spacing, and documented every component with usage guidelines and do/don't examples. Library shipped to Storybook so engineering had a living, browsable reference that stayed in sync with Figma.
Design review process
Introduced a lightweight, structured review process with clear stages: concept review (rough direction, early in a sprint), design review (high fidelity, before engineering kickoff), and eng handoff review (spec check before build). Each stage had a defined checklist - not to create bureaucracy, but to make it easy for designers to self-review before asking for feedback. Average review cycle dropped from 3.2 days to 1.4 days over six months.
Hiring and onboarding
Wrote the design job descriptions, defined the hiring rubric, and ran the portfolio review and design exercise stages. Hired two mid-level product designers and one researcher over 18 months. Built an onboarding guide covering the product's design language, review process, Figma conventions, and engineering workflow - reducing time-to-productive from what had been months (for previous contractors) to under three weeks.
Mentoring and career development
Ran weekly 1:1s with each team member focused on craft feedback, career trajectory, and removing blockers. Moved from instinct-based feedback to structured critique: leading with what the design is trying to accomplish before commenting on execution. Created monthly "design reflection" sessions - not retrospectives, but focused reviews of shipped work asking what we'd do differently. Two designers were promoted over the two-year period.
What shipped
The systems, not just the screens
Two of the four pillars are easiest to show directly: the component library, and the review process it made possible.
Component library - core patterns
Six months after the review process launched, the numbers moved together:
How I led
Delegating decisions, not just work
The biggest shift in how I led: good design leadership reduces how often the team needs your own decisions. I introduced a practice called "design reasoning" - for any significant decision, a designer had to state the user need, the alternative they'd rejected, and the engineering constraint they worked within. A year in, the team was making calls I wouldn't have made alone, because they understood the reasoning behind our standards.
I kept process light - clear review stages, a shared component library, weekly syncs on blockers, not status - and gave the team autonomy inside those guardrails. As AI tools matured, I used them where they had the most leverage: draft documentation, research synthesis, and first-pass specs, so designer judgment went where it mattered most.
Outcome
What the team looked like two years later
The team grew from one to four - two mid-level product designers and one researcher - with an onboarding process that got new hires productive in under three weeks. The component library shipped 84 production-ready components over 18 months, cutting the inconsistency that used to be a constant source of design debt and engineering rework.
Design QA pass rate - the share of shipped features that passed review without needing revision - went from 64% to 91% over six months. Average review cycle time dropped from 3.2 days to 1.4 days, not from rushing reviews but from giving designers better tools to self-review before asking for feedback. Two team members were promoted during this period.
Reflection
What I'd do differently
I'd have started the component library even earlier, before the first hire - building it forced the design decisions that clarified our visual language. I also underestimated how much of the job is managing up, not managing the team: building trust with product and engineering leadership, and making the case for design ops work that doesn't produce visible output right away.
The lesson that stuck: a design team's output ceiling is set by its infrastructure, not its talent. Talented designers without shared systems produce inconsistent work; average designers with good systems produce consistently good work. Invest in the infrastructure first.