designing in 2026

A reflective piece on my designing of two products, twelve months apart and how my process has changed with a year of new AI tools

Role
Product Design
Focus
AI tools · Efficiencies
Year
2025–2026
Two experiences, a year apart

In just one year, we've all probably experienced a dramatic shift in the way we work, and what efficiencies we now lean on. A year ago I designed Bebop RTS (Ready to Sell), leaning on the existing Bebop design system to ship a new product quickly. Today I'm working on WatchList — a product similar in shape to RTS, but the experience of designing it has been completely different. Sitting between these two projects is a year of MCP connectors, the ever-developing Claude suite, and new rapid prototyping capabilities.

Hi-spec prototyping now takes less time and produces more results. Time doesn't limit how many ideas we can explore anymore, but we're still learning how much we can shortcut while still producing the right product. What counts as a 'quality product' is being quickly redefined too — in the same way AI is shortcutting my design process, users are increasingly expecting AI and agents to take away some of that manual navigating.

01
2025
Figma
2026
Figma, Claude chat, Claude Code
02
What was called efficient back then

RTS is an app that serves up prospective sales leads, matched against buying intent signals and ideal customer personas. It started as an experimental 'garage' project — we spent a lot of time refining the in-house AI engine behind it, which left us with time pressure on the front-end design. That was okay, because I could lean on the existing Bebop design system, something I had set up cleanly and could leverage easily. Reusable components saved a lot of time. The result was a nice looking design with no major UX problems for the time frame — but a year later, I can see how much of what felt efficient at the time would now be the slow way to do it.

Three constraints shaped how I worked on RTS:

01
One direction, picked early

Exploring a wide range of visual concepts meant Figma frames we didn't have time for, so we picked a direction and built it.

02
Designed for, not with, users

There was no time to design, test, and iterate before shipping. The 'thin slice' MVP became the user testing, with the user wearing the consequences.

03
Waiting on dev

Any improvement based on what we learned had to wait until the developers had capacity to make changes. Iteration speed was capped by the queue.

Bebop
RTS
2025 design process
03
Rapid prototyping allowed for true exploration

WatchList surfaces deep information and upsell opportunities about existing accounts. We're still designing it — another garage project, with more engine power and richer datasets than we had with RTS. We started around March 2026, around the boom of the Anthropic Claude suite improvements.

Because of that, I've been able to rapidly produce clickable concepts in a fraction of the time. Previously I'd never have had the time to develop them. Now I can put a visual in front of someone who needs to see a thing before they know whether they like it — and change it on the spot. Feedback that used to take hours takes minutes.

Compared to RTS, this has given us time back. Time to explore properly, test, and refine.

This time, our first delivery won't have to be a thin slice.

Prototypes explored for WatchList
More time to focus on what matters

Other parts of the design process — the manual and time-exhaustive ones — have become rapidly more efficient with Claude skills.

Figma hasn't gone anywhere. It's just sitting within a different stage of the process now. After generating WatchList concepts in Claude, I take them into Figma to convert into clean hi-spec designs. Then, instead of designing every iteration and instance, I can convert those designs into a fully functional prototype using Claude Code.

WatchList has a stronger focus on content than UX, so we needed multiple personalised prototypes for testing. The first one took me a few hours to curate content for, and then two days of copy-pasting to actually build.

Before Claude
Two days per prototype
After Claude
Two days of Claude skills + git versioning setting me up to spend 19 minutes per prototype

That gave the team so much time back. Hours of copy-pasting collapsed into minutes, and the time went somewhere better — testing with a wider range of customers, and spending more time on the things that matter, like product lifecycle and strategy.

04
2026 design process with Claude
05
What counts as the right product now?

These changes have brought a lot of shortcuts and 'optimisation' — the new buzz word — to our processes. But we're still learning what those changes actually mean.

With RTS, we spent a lot of time validating before we started designing. Now we can produce a hi-fi prototype in a fraction of the time, but that doesn't mean the validation stage can be bypassed.

Speed has changed the process but not the standard. A faster route to a prototype isn't worth much if the prototype isn't right.

During concept exploration for WatchList, we also explored whether the output should just be a Claude MCP. Our output relies so heavily on the user being able to customise what they see from the data, and customising through a Claude conversation is exactly the kind of pattern users are starting to expect — AI doing the operating, instead of the user doing it themselves.

As I write this in May, our reasoning for deciding against it comes down to one thing — newness. There are open questions we don't have answers to yet:

01
Pricing

How does relying on Claude MCP change our price point, and what does that mean for the customer?

02
Tokens running out

What does the experience look like when the user hits a limit? Where does our product go in that moment?

03
Owning the platform

How do we feel about being reliant on a product we don't own — and how do we design for that dependency?

Evolution of technology isn't new

These new user expectations are no bad thing — it's just the evolution of digital products. I don't believe every digital product should be transformed into an MCP, but I'm willing to explore the idea when it makes sense.