As the first designer at a pre-launch AI dev-tools startup, I built the design practice — moving it from a late execution step toward a partner in product planning.
I joined the company before launch. The MVP had been built by the engineering team without a designer involved, and there was no research or QA process in place. Before starting on screens, I ran a diagnosis — where the design practice stood, who influenced the product, and where design could enter the process earlier.
Tasks arrived at the last minute, engineers changed the design on the fly, and design steps were skipped whenever speed was the priority. Design was brought in to execute at the end — rarely to help decide what got built.
No formal way to brief design, no mid-term planning, and design routinely dropped from the schedule to hit a deadline.
No researchers, no QA process, and no reliable way to recruit respondents — so design decisions couldn't be validated before they shipped.
shadcn was applied unevenly — the same components looked different across the product, so the product looked unfinished.
Design wasn't seen as a driver of quality or value, and decisions defaulted to engineering over UX.
I treated the design function like a product with a maturity problem. Before changing how the team worked, I scored where the practice stood, audited the resources, mapped who influenced the product, and made an explicit plan for building trust.
The company had money; what it lacked was people and time. So the plan couldn't rely on hiring alone — it had to use the existing time better.
Influence and interest didn't line up: the people with the most influence over design weren't always the most interested in it. I plotted each decision-maker on a 2×2 and set an engagement tactic and cadence for each quadrant. Two groups mattered most — the key partners (PM and CTO) to involve from the start, and the high influence but low interest (engineers), who could hold up delivery if not kept in sync.
Mapping the business's priorities over time showed where to place design bets. The two rows that flip → are the shift I planned around: the company was moving from polish now toward speed and building a design team.
With low credibility at the start, every move either added to or drew down design's credit — so I made both sides explicit to guide the team's early choices.
High value and low effort first — to build trust — before moving to the deeper changes.
I audited the whole app and logged every problem, then ran a 2×2 prioritisation with the product team and turned the top items into sprint tickets — so the backlog was shared, not imposed.
Engineering agreed to a design review before every release, and to spend 15% of each sprint on design-debt tickets. That agreement gave design a regular place in the release process.
With no research budget, I monitored post-launch support requests to surface the most frequent problems — a cheap signal that pointed the roadmap at what users actually hit.
To build trust with the team, I ran short decision-maker workshops: brief, Q&A, then everyone drafts a concept solo in Miro (group discussion tends to create noise). I synthesised the concepts into one report the team debriefed — widening the range of solutions while involving stakeholders in the design.
Instead of design working on its own — the people with influence but low interest became participants rather than blockers.
Sprint work lived in Notion — issues, planning, everything. It had grown disorganised: no shared way to write tasks, stale state no one kept current, and the tool lagged under the volume of content. I proposed and ran the move to Linear end to end.
The team kept issues up to date — so current load became visible and sprints got easier to plan.
A deliberate tag system (Customer · Scope · Bug) made the backlog easier to navigate.
The Slack integration made it easy to turn incoming support into tasks, and made task changes visible to everyone.
To make quality something we could track rather than argue about, I scored each core flow with the PURE method (Pragmatic Usability Rating by Experts). Higher means more friction — which turned the two heaviest flows, Create new Index and Parse file via API, into the first fix targets.
Back to the baseline I opened with. The one-year goal was to lock in the operational floor and push the practice into tactical — design in product planning, not bolted on at the end. Re-scoring the same three tiers a year on:
Design had a regular place in the release cycle — a review before every ship, plus a 15% sprint allocation to work down design debt.
The team ran on one planning system with current state, a workable backlog, and support flowing into tickets via Slack.
Decisions started earlier: a shared audit, a stakeholder plan, and co-design workshops made design a partner in planning, not a service at the end.
Quality became measurable — a PURE usability baseline across the seven core flows, and a maturity target to move the practice toward tactical.
Everyone — designer, engineer, QA, PM, marketer — watches the quality of the experience and can propose an improvement. Design stops being one person's bottleneck.
Visible process builds trust. Show intermediate work, tie wins to insights, and make it clear what design is doing and why.
Notice what users struggle with in every interaction, write it down, and bring it back to the team — even when there's no formal research budget.
The stronger an organization's culture for design, the greater its commitment to using design as a resource. Businesses need to develop their own design culture by applying design leadership and applying effective design-management practice … Only then will the idea of design as a business resource achieve its true power as a means of reaching business objectives.