Let's be honest, most of the conversation about designers and AI still focuses on generating code from designs. We talk about moving faster from Figma to a working prototype or shortening the distance between Design and Engineering. 

Sure, that still matters, but it’s only part of the opportunity. 

Inside organisations, designers can now create the systems around their work. The small utilities, plugins, platforms and workflows that would previously have required an engineering team, a lengthy business case or another software contract. 

I’m a Senior Product Designer working in Design Systems at Stepstone. My role still includes the components, patterns and guidance you would expect. 

Increasingly though, it also includes tooling and enablement. I’m now helping designers use our system more effectively and informing the change in processes surrounding the work itself. 

That shift didn’t begin with a strategy to turn designers into engineers though, it began with a simple question: could I make this better myself?

“Instead of comparing two platforms… I built a third."

When a prototype could remember

My first experiments with Figma Make were interesting, but they still felt like familiar prototypes. Just simple polished screens with attractive transitions and a convincing impression of how something might work. 

Then Figma did the best thing imaginable... Databases became available. 

The moment an AI-built experience could store real information, retrieve it and respond to what a person had done, the scope creep became real!... This was no longer only a way to make believable interactions. It could become a real, data-driven tool. 

The first POC was highly unglamorous. Our Experience Checklist is a living record that designers complete throughout a project. It helps teams check that design language and product expectations remain aligned during design reviews and conversations with product owners so that it's a perfect experience at launch. 

Previously, however, it lived in a spreadsheet full of formulas. The information was useful, but the experience of contributing to it was not. People had to leave their design, find the right URL, interpret the sheet and connect it back to the work in front of them. 

I took this personally... So, I rebuilt it as a database-backed experience that sits inside a Figma plugin using Figma Make. Designers now answer clear questions and update the checklist beside the design itself.  

It was my first attempt at building a tool with AI. I would approach it vastly differently today, but seven months later it’s still used by our designers during their work. A comparatively small experiment removed repeated friction from an established process. 

“The moment a prototype could remember, it stopped being theatre and started becoming a system."

Build the system, not just the screen

The largest expression of that idea became the Design Playbook. 

Our design-system documentation didn’t have a clear home. Some guidance existed in Storybook, while Brand documentation lived elsewhere. Exploring dedicated platforms such as Frontify and zeroheight had been on the backlog for some time. So, the natural and expected next step was to compare their capabilities, understand their costs and select the closest fit. 

Instead, before completing that comparison, I built another option. 

I worked through the requirements with my chosen LLM, including the capabilities we genuinely valued in the established products and used that work to create a detailed prompt for Figma Make. Only a few hours later, the proof of concept already had the foundations of a content-management system: people could create pages, write and organise content, navigate the site and administer it through different profiles (admins, editors, teams etc). 

That represented perhaps 75–80% of the core concept - not 80% of the responsibility involved in operating software, but enough to prove the idea was viable. 

Building the alternative also became a way to discover the requirements we had. Instead of comparing products against an abstract list, we could compare them with something tangible. When we found a capability we genuinely needed, we could add it. When a feature didn’t serve our workflow, we just didn’t build it into our system. 

Turning that first version into the public Design Playbook took approximately three months alongside my usual responsibilities.  

The Playbook now supports design-system, Foundations and Brand guidance. Avoiding additional platform commitments and enabling Brand to move away from its previous platform has avoided plenty of annual costs.

And when Brand asked to publish selected asset folders publicly while keeping individual files hidden, the capability existed the next day, showing that we aren’t bound by the time constraints of a 3rd part tool. 

The saving matters, but it’s not the most important result. The Playbook proved that design could initiate working organisational infrastructure and demonstrate its value to the point where it’s now a public resource of the business.  

“The prototype didn’t just represent the software... It was the first version of the software."

Building happens at every scale 

Not every designer will build a documentation platform and they definitely shouldn’t need to. The more useful way to understand this change is as a range of possibilities, each appropriate to a different level of problem to solve. 

• A personal automation can remove a repetitive task from one person’s day. 

• A plugin can apply shared knowledge directly inside the design environment. 

• A functional prototype can make an ambitious product all of a sudden become tangible. 

• An internal platform can become infrastructure that other teams rely on. 

  
  

During a 2 day hackathon, a five-person team from Design created a translations plugin for Figma. It stored English and German variants of design content in a database, updated the design straight in Figma when someone changed language and could help generate the content itself. The project won the hackathon and is still used by some designers. 

Its influence went beyond the plugin. It showed the organisation that design no longer had to wait for someone else to make a useful piece of software. We could build enough of the idea ourselves to entirely change the conversation. 

Another project showed what functional prototyping could do for product strategy. We wanted to demonstrate what an AI-first job platform might feel like and in approximately one week, we built an experience that accepted a CV, analysed it using our model, matched it with real Stepstone job data, explained strengths and areas for improvement, and connected the entire canvas to an interactive AI assistant. 

Sure... a set of Figma screens could have described the journey. But it couldn’t have demonstrated the actual proposition. To show what an AI experience feels like, the AI must be present and responding. That working prototype helped establish backing for a product direction that after substantial iteration, is now live on our platform. 

And yes, we even covered the most common conversation... Our designers can build Figma designs with code! 

Our latest plugin creation works even closer with production.  

It scans a Figma design for hard-coded values, missing tokens and elements that don’t use our design system library. Designers can review each issue and decide when to correct it. The plugin can then restructure whole Figma designs so they relate to our coded components and prepares the design for Claude Code. 

The result after a designer has built this now prepped design using Claude, is that the front end is ready for an engineer to connect to the underlying product and refine where necessary. Across several tests, engineers involved estimated that this reduced their development time by more than half. 

It also moves design QA earlier, because the front end build is done by the designer! Technically, there’s no QA... 

All of these projects are very different in scale and consequence, though the common theme is that the designer no longer has to stop at describing what should exist. 

The learning curve is not code

I was an engineer before I became a designer, and that experience helped me understand the code being produced and recognise problems as the systems developed. But writing code isn’t the prerequisite it once was. 

The more important learning curve is changing how you think. 

Designers are used to creating journeys page by page, a structured user flow. Working software demands a more holistic understanding of relationships. Example: If a job card appears in search results and again under ‘more jobs like this’ on a listing page, it should be one reusable component with consistent behaviour, not two similar drawings on separate pages. If you don’t explicitly tell Claude this, it will build the same thing two different ways. 

This way of thinking is challenging at first because it asks designers to describe not only what someone sees, but what the product knows, remembers and changes. Saying that, it’s not a massive departure from product design, if anything it’s a deeper form of it. 

The strongest evidence is what happens when the capability moves beyond 1 person.  

A researcher came to me with an idea for an AI-supported interview platform and one question: how do I start? 

I helped them frame the first prompt and showed them examples of what was possible. They went on to build a working system with roles for researchers, moderators, interviewers and participants; live transcription; question support; and analysis. They are now working with engineering on the audio and video elements needed to take the proof further. 

I didn’t build that platform for them. I helped remove the fear surrounding the first step. 

That fear is real.  

A terminal window, an unfamiliar editor or the process of connecting internal tools can make people feel that they’ve wandered into someone else’s job by mistake. Telling people to ‘go and experiment’ isn’t enough, because not everyone learns by being dropped into an empty project. 

At the beginning of the year, I ran an AI enablement session for approximately 96 colleagues across Product, including designers, product owners and some tech. I mainly demonstrated in Figma Make. Explaining from prompting to databases and how to move from ‘this is the flow I want’ to a series of workable iterations. 

The informal support continued afterwards. People messaged me with the same difficult first questions, so I transcribed those support conversations and used Claude to turn the recurring advice into self-service onboarding documentation. AI helped document the process of helping people use AI. 

We also have the Design AI Lab in Slack: a place where we post shortcuts and examples of what we’ve done with AI. But more importantly, a safe space for designers can ask questions. Our entire design org is now actively using Claude and functional prototypes are regularly appearing in reviews as real, interactive experiences rather than routes someone must be taught how to click through. 
What’s worth noting though, is that although I use AI constantly, AI still isn’t an accomplished designer. Left alone, it produces vague interfaces and repeats familiar patterns. It definitely doesn’t understand the user, let alone the brand or the organisational context. We still require our own judgment to make the correct decisions. 

Example: Recently, I created a new design-system component by talking to Figma’s AI agent rather than drawing it with frames/shapes etc... the standard tools.  

The agent produced the initial component. But then I adjusted its properties, fixed its structure and adjusted its behaviour to make it belong in Genesis. I undoubtedly did way less manual drawing, but the design judgement didn’t disappear, if anything, It became more visible. 

What makes designers valuable isn’t our ability to place rectangles faster than a machine. It’s our ability to understand people, recognise the right problem, make deliberate choices and know when a plausible answer isn’t yet a good one. 

“Designers don’t need to become programmers. But we do need to start thinking beyond screens."

Make room for better tools 

Designers spend most of their time improving products and experiences for other people. We can become so focused on delivery that we accept friction in our own systems as unavoidable. There’s always another deadline or feature that appears more important than improving how the work gets done. 

The difficult sentence for a designer to say is: ‘I spent half a day experimenting with a better way to do this.’ The instinctive response can be that they should have spent that time completing the immediate task. 

But if one day of exploration changes an hour-long task into a five-minute one across the next 50 projects, the experiment wasn’t a distraction from delivery. It was an investment in every delivery that followed. 

Design leaders have an important role here. People need encouragement to push past the intimidating first screen, permission to invest in their own working environment and visible recognition when an experiment creates reusable value. That doesn’t require every idea to become a formal programme. It requires enough space for someone to produce evidence. 

The opportunity also extends far beyond prototypes. AI skills can draft design-system documentation from a Figma component, capture the necessary variants and screenshots, and upload the result to the Playbook for human review. Connected to our internal tools, an assistant can update routine Jira tickets or locate organisational information that would previously have meant navigating several systems and asking several people. 

Sometimes the useful thing is smaller still. I wanted to know when the next trains would leave my local station, without repeatedly searching for the journey, so I built a phone widget that shows the next three. A colleague who makes pizzas built a booking system for his neighbours. Neither needed a roadmap. Both solved a real problem for a real person. 

This is the mindset I want designers to take away: building is no longer reserved for the largest product opportunity or the people with ‘engineer’ in their title. You can begin with the irritating task you repeat every week. 

Whoever invented the paint roller was not trying to end the craft of painting. They had found a faster way to perform one part of the task, leaving more time and energy for the work requiring greater care. 

AI-assisted tooling offers designers the same opportunity. It doesn’t reduce the value of human design. It gives us more ways to apply our judgement and less reason to spend that judgement on repetitive tasks. 

The most meaningful AI work won’t always be the most visible. Sometimes it’s a plugin, a translation utility, a checklist or a documentation system. Sometimes it’s five minutes spent removing a problem that would otherwise follow the team for years. 

And sometimes the most important thing an organisation can build is the capability to build for itself.