Selected work / Rocketvan (internal practice)
Rocketvan Design Technology Practice
How I built the design team at Rocketvan, and set the way a twelve-person studio frames, prototypes and reviews its product work.
Built the design team from one person to three, and put AI into the delivery workflow without handing it the product judgement.
- 1 → 3 Design team built, including two senior designers
- Up to 70% Reduction in MVP time-to-market
- About 30% Improvement in delivery efficiency
At a glance
- Client
- Rocketvan (internal practice)
- Sector
- Design technology · Product operations · AI-assisted delivery
- Period
- 2022–present
- Product
- Design system and prototyping workflow
- Role
- Co-founder · Head of Design & Innovation
- Team
- Three-person design/UX team within a 12-person multidisciplinary practice
- Platforms
- Figma · Working web prototypes · Git repositories · Generative media pipelines
Confidentiality Internal practice shown without client data or confidential code.
What it was
Rocketvan is a 12-person multidisciplinary product practice working across London and Barcelona. I lead the dedicated design/UX team of three, and work closely with senior developers and AI specialists across several products at a time.
The challenge was familiar: a design can look convincing before anyone has tested its behaviour, feasibility or awkward edge cases. Finding those problems late makes the work slower and puts unnecessary pressure on design and engineering.
The hard part
The aim was not to add AI because it was fashionable. We needed to shorten the distance between a product question and something the team could properly test, without letting generated output become an unreviewed design decision.
That meant connecting several pieces that are often treated separately: product framing, the Figma system, a functional prototype, engineering review and what eventually reaches production.
What I did
I introduced a risk-driven workflow that uses Figma, Google Stitch and coding agents including Codex, Claude Code, Antigravity and OpenCode to turn selected questions into working prototypes earlier. I defined where the tools help and where human review remains essential, then used the same approach with designers and senior developers across live project work.
I still work directly with HTML, CSS and JavaScript, review repositories and map API behaviour with engineering. The point is not that one person replaces the team. It is that design and engineering can look at the same functioning thing before a larger commitment is made.
How the team works
The design team is three people, including two senior designers I hired, inside a twelve-person practice I helped grow from three. We usually have several products running at once, so a good part of my week is deciding who works on what, and making sure the bar holds in the files I am not in.
As a co-founder I carry the decisions that come with that. I am the deciding voice on design and marketing hires and share technical ones with our CTO. I have also let senior people go, more than once, where someone could not hold the responsibility the role needed. That is the least enjoyable part of the job and the one I would not hand to anyone else, because a team that runs on integration and transparency cannot carry a senior person who is not really in it.
I scope and price work too, against margin targets between 15 and 25% on budgets from four to six figures. It keeps the design conversation honest: I am arguing for the time something needs while knowing exactly what that time costs.
The craft standard lives in review rather than in a document. We look at work early and judge it against the system rather than against taste, with engineering in the same review, so the question is whether a thing can be built and maintained and not only whether it looks right.
Dual-shore means London and Barcelona, so most of this has to survive being asynchronous. The design system and the prototypes are what carry the intent when people are not in the same room.
A few decisions worth calling out
Start with the risky question. We do not build every screen. We prototype the part most likely to change the product or expose a technical problem: a role and permission model, an AI interaction, a multi-step workflow or a responsive component with difficult states.
The design system comes before the prompt. Reusable components, tokens, content rules and expected states give the prototype a structure the team can inspect. Generated layout is not treated as a substitute for that system.
Review behaviour, not just appearance. Designers and developers inspect the prototype together: what happens with incomplete data, a failed request, a small screen or a user who should not have access. The prototype is useful because it makes those questions visible.
Which model goes in is a design decision. For client work with generative media in it — stills and short-form motion produced inside the product rather than dropped in afterwards, and on one campaign platform that means NanoBanana for the images and Veo for the motion — we compare candidate models per feature on three things: how fast it comes back, whether the output is good enough for the job, and what it costs per use. Those three rarely point the same way. The fastest model is often the one you would not put in front of a client’s audience, and the best one can be expensive enough to change what the feature is allowed to do. Deciding that is design work, not procurement, because the answer sets the waiting, the retry behaviour and how generous the product can be when someone wants another go. We don’t keep the comparisons as published figures, so I don’t quote any.
Assume the model will fail. Provider fallback chains are built into the generation workflows, so a feature degrades to another model rather than returning nothing. A product that is only correct when its model is available is not finished.
Keep judgement with the team. In healthcare and professional decision products, AI has clear boundaries. Generated work is reviewed and corrected; specialist users retain control where a model could be uncertain or wrong.
Where it landed
Across suitable MVP work, the combined change reduced time-to-market by up to 70% and improved delivery efficiency by about 30%. More importantly, product, design and engineering could disagree around something concrete much earlier, when changing direction was still inexpensive.
What I took from it
The useful part of AI is not the first answer. It is the shorter learning loop. The quality still comes from choosing the right question, giving the work a coherent system and having experienced people review what the tools produced.
