RightShip runs a maritime risk and compliance platform: more than a dozen products for the shipping industry. When I joined in 2025, design was down to one person, with a committed roadmap to deliver.
Rebuilding the team was the first job. The larger one turned out to be rebuilding how design work gets made, just as AI began to change who can build a product.
The product process we inherited ran in the classic three walled-off steps: discovery, design, then front end. Inside them sat a chain of hand-offs: research, wireframes, review, high fidelity, review, handover. In a traditional process like this every step is a translation, and every translation loses something. What gets built rarely matches what was designed. And every step takes time away from discovery, the part that decides whether teams build the right thing at all.
In B2B, products are new capabilities inside one platform, and customers move between them. Designers can be happy with their work in isolation, until it comes together and doesn't feel like one platform. A new product that looks different is not automatically better. It can feel bolted on, cost more to build, and break patterns customers have already learned. Such a new product comes with high onboarding and support expense. RightShip wasn't too far off this way of working when I joined.
By mid-2025, AI prototyping tools such as v0 and Lovable made it clear that the process would change, whether design led it or not. Product managers would ultimately build prototypes. Engineers would pull straight from Figma. For designers at the time it looked like losing purpose and control, and for customers it might mean lower-quality products. The question at the time was as simple as it was scary to the team: is design going away?
We decided to lead the change rather than wait for it. The argument that turned the team round was about control. Designers had always lost control at the handover. If design could reach code directly, what customers get would finally match what was designed.
And the time saved on drawing screens had to go somewhere useful, and there is no better place for it than discovery. The effect is two-fold. Spending more time in discovery means that designers can build a deeper understanding of what needs to be built. And shaping the coded components with front end means that anyone using prototypes gets to build something that increasingly looks and works like our product.
Wireframes, redlines, rebuilds and review loops are disappearing.
A deeper understanding of what needs to be built.
Together with front end, so every prototype looks and works more like the product.
You don't rebuild how seven live squads work on a hunch, mid-roadmap, with customers waiting. So we spent most of a year reading what others were exploring, testing tools, trying and discarding.
The start was deliberately small: one designer and one front-end developer. They matched our Figma components to the coded ones, down to the names of tokens and variables, made sure the most important components existed in code, and gave that set to an AI model as the system to prototype with. The first attempt was clumsy. But it was remarkably fast, and it showed what a design system that AI can read could do.
The first thing a designer makes now is a working prototype, built from our real components. It is not a final deliverable. It holds everything the squad learns in discovery, and it changes with every customer conversation.
Looking back, low-fidelity design only existed because high fidelity was slow and therefore expensive. Handovers only existed because designers could not deliver to code. With AI prototyping at one end and Figma Code Connect at the other, both reasons are disappearing.
Swipe sideways to see the whole chart →
Three walled-off steps
From internal design check to the centre of discovery
Design in every step
But while proofs of concept are cheap, scaling this to production across several squads is another story. This is where the process is still maturing. A prototype goes into Figma, where a designer corrects and completes it. An engineer then uses Code Connect to let AI build it in code from the same components. What takes time to mature is the fact that components without clear usage rules can still get used in ways that do not match how the product should look and work. Each round fixes some of that, so every pass through the loop makes the next one faster.
AI builds a prototype from the real coded components.
A designer corrects and completes it in Figma.
An engineer uses Code Connect to let AI build it in code from the same components.
The usage rules for the components get sharper.
Critics of early prototypes warn that they pick a winner before the team has explored enough. For a standalone product breaking new ground, that risk is real. Inside a platform, the constraints are different.
So we split discovery in two. Opportunity discovery works out the need. Once the squad is confident it understands the need, solution discovery tests what an answer could look like within the platform. The line is not fixed. And because a prototype now costs so little, both can run at once: a solution conversation with one customer while opportunity conversations continue with others.
When discovery is done is still a judgement call. It weighs whether more discovery would change what we build against the time available and the cost of getting it wrong. No framework or tool makes that call, and it is why skilled designers are still needed.
Customers now understand what we plan to build before we build it. A wireframe asks them to imagine. A prototype lets them use it. For B2B products this has a very important side effect: it turns key accounts into collaborators. Feedback comes early and is specific — less philosophy, more “this doesn't work” — while there is still time to fix it. Sometimes a prototype clarifies the customer's own problem. Sometimes the pushback shows we had not understood the problem yet, and we go back.
Wireframing is gone as a phase. The redlines, rebuilds and review loops that used to fill calendars are disappearing.
What we see now is what we set out to do in 2025 — designers spending more time solving problems and much less time building screens. And prototyping in discovery is part of everyday work for both designers and product managers. The route to production code is being built step by step, at the pace engineering capacity allows.
Making fundamental process changes is a matter for a whole team and everyone around it. None of this would work without them and the system underneath it.
I was hired to rebuild design from one remaining designer. I covered four squads myself until the team was back to full strength two months later, and no roadmap commitment was missed.
The team has since grown to eight senior designers across seven squads.
We built the new modular design system Voyage from nothing to full use in every squad. It is now AI-readable and what the prototypes are built from.
I also made the case that moved front-end engineering from Aurelia to Angular.
Changing processes must always follow a clear need. In this case it was more than one - increase quality, standardise solutions and put the power of visualising ideas into everyone's hands as early as possible.
We achieved all.