When stakeholders use AI to prototype their own designs

How do designers integrate this value into the design process while protecting its integrity and without being a blocker to innovation?

Halfway through a UX project to improve an internal platform, something happened that I wasn’t prepared for and didn’t have a ready response to.

The Moment

A stakeholder who worked with the platform daily used Figma Make to build his own prototype and shared it with the team to communicate his needs.

He was keen to visualise his ideas, and AI gave him the tools to do it quickly. It was detailed, considered, and came from someone with genuine expertise in the problem space.

But, to be honest, my first reaction was quietly personal: Is this what’s coming for my job?!

While still processing that, I refocused on the project, realising I needed to figure out how to respond to a stakeholder who had effectively started designing too.

He had built something from direct experience with the platform—and that was valuable. But it presented a challenge I hadn’t experienced or even thought about:

How do designers embrace this potential new way of working without being a blocker while also protecting the integrity of the design process that protects the things that matter: usability, accessibility, consistency, sustainable ux, and evicence-based design decisions?

This isn’t a case study with a clean resolution, however — it’s an honest account of navigating an unfamiliar situation in real time, the potential risks I could see, and some early thinking on how designers might start to build a process around something that’s only going to become more common.

My first response

My instinct was to engage with the stakeholder’s artefact as constructively as possible. Letting him know it was a helpful start, we set a meeting for him to take me through it in detail.

As I reviewed it in the meantime, however, concerns distracted me — there were usability and accessibility issues, it was inconsistent with the existing design, many ideas contradicted learnings from previous testing of the existing design, and it went way out of scope — the natural result of giving someone with deep domain knowledge a tool that lets them design freely.

And then I realised I was overcomplicating things.

The stakeholder’s prototype was not a formal design proposal to be handed over to dev — it was just a tool to communicate his ideas to merge into the main design version.

Where I landed

The practical path I landed on was to help the stakeholder distil his ideas — from both the prototype and a separate spreadsheet he’d been maintaining — into a simple list of proposed changes to the existing design, each with a clear rationale and a focus on MVP needs only, and capturing out-of-scope ideas for a backlog.

This ensured the stakeholder’s input was captured while maintaining one design source of truth, with his thinking folded in rather than competing with the main design.

It was a reasonable solution, and the stakeholder hadn’t rejected it. But in the following meetings with others, he brought out his prototype anyway to continue championing his needs.

There were no established ways of working around how stakeholder-created designs should be handled in the project, so there was nothing to suggest he shouldn’t. And there’s something worth acknowledging here that will likely become more common: when someone designs and builds something — without or without an AI tool–they become invested in it. The ability to visualise and interact with your own ideas is exciting, and stakeholders who experience that for the first time develop a strong attachment to what they’ve made. That enthusiasm is great, but without a clear process for how those artefacts fit into the wider design process, meetings and goals can get derailed.

That’s when broader risks became clearer:

• A polished AI prototype looks finished to anyone who isn’t a designer, and once a wider team has seen it, expectations may form quickly and quietly around it. The stakeholder’s intentions were good, but his prototype was now circulating independently, and I had no control over the context in which people were seeing it or the assumptions they were forming.
• There was also a real risk that the stakeholder — keen to see his ideas realised — might go directly to the developer with his prototype, or that the developer, keen to move fast, might treat it as a brief rather than a communication tool. Either way, the design review process could get cut out of the loop entirely.

Two designs were then in the wild, and I had no clear process for bringing them back together before they influenced decisions that could be hard to walk back.

I’m still not sure the best way to handle this, or if there’s one right answer.

So, for now, I’ve attempted to articulate all the concerns that surfaced, and some suggested solutions.

Risks to consider

When a stakeholder builds their own design with AI, the risks may not be obvious straight away. Some surface immediately, others creep in quietly. Below are the ones that surfaced for me during the experience and after reflecting. Every designer should think these through before they happen on their projects, so they can:

• Manage the moment professionally
• Get the value from the shared work
• Not hinder this new way of working
• While also protecting the integrity of the design process

I’m thinking those are the goals to aim for, but maybe there are also others to consider.

Risk 1: Confusion over the source of truth

If a stakeholder prototype and the main design are both in circulation, developers — and stakeholders — might start to treat them as two separate sources of truth, creating confusion and potentially creating a rework risk.

Risk 2: A polished prototype creates expectations

AI-generated designs look polished, so when a wider team sees one, they tend to assume it’s more validated than it is. Managing that expectation after the fact is much harder than setting it up front.

Risk 3: Out-of-scope ideas become time-consuming conversations

When a stakeholder has the freedom to design freely, ideas beyond the project’s scope will naturally find their way into the prototype. But once those ideas are visible and interactive, they’re harder to set aside, taking time and energy away from the work that actually needs to move forward.

Risk 4: The designer becomes the explainer

The more stakeholders use AI to design, the more designers could find themselves explaining, guiding, and coaching — not just designing — and it’s worth preparing for rather than arriving at that in a meeting and being unprepared.

Risk 5: A prototype can bypass the designer entirely

A stakeholder prototype built to communicate ideas doesn’t always stay contained to that purpose. Once it exists, it circulates. Once it circulates, it can create expectations, and it can be shared in ways that cut the designer out of the conversation altogether. Even with the best intentions, that quietly undermines the process that protects usability, accessibility, consistency, and validation.

Risk 6: Non-designers can lose time in these tools

AI prototyping tools are genuinely engaging — and easy to get lost in. There’s a real risk that stakeholders invest significant time designing when that time could be spent on their core responsibilities. It’s worth thinking about how to acknowledge and contain that, without discouraging the contribution.

Risk 7: Personal accounts carry business risk

AI design tools are easy to access on a personal account. But a file built on a personal account — potentially containing sensitive business or user information — sits outside the organisation’s visibility and control. Who owns it? Who else can access it? What happens to it when the project ends?

Questions worth exploring

Articulating the above risks generated the following questions that I think designers need to start exploring, because this situation is going to become more common, and having no position on it is its own kind of risk.

1. Do we ask stakeholders to share with the design team first — or does that just create a bottleneck?

There’s a case for making design team review a default step before any stakeholder prototype circulates more widely.

Some might make a case that this slows things down and signals distrust.

The answer probably depends on the team, the project, and the stakeholder — but leaving it unaddressed means the decision gets made for you, in a meeting, when it’s too late to shape it.

2. Do we need to set expectations about what a prototype is and isn’t?

A polished AI prototype looks finished to anyone who isn’t a designer. Without a clear, shared understanding of what it represents — a thinking tool, not a design decision — expectations can form quickly and quietly. Getting ahead of that conversation is easier than walking it back.

It also raises another question worth exploring: should stakeholders be encouraged to keep their ideas at the wireframe level — rough, low-fidelity, intentionally unfinished — to avoid the expectation problem altogether? Or is there value in letting them explore UI ideas too, even if it creates more to manage?

3. Should stakeholders create their own designs, or contribute to the designer’s?

A separate prototype can surface ideas that annotating an existing design wouldn’t, but it also creates a parallel artefact that needs managing.

Should stakeholders use their AI-generated designs just to help them articulate their feedback on the main design?

4. What happens when a stakeholder’s prototype reaches a developer before the designer has reviewed it?

Even informally, even with everyone understanding the context, this creates a moment where the design process is effectively bypassed. That might be fine — or it might not be. Either way, it’s worth having a position on it before it happens.

5. How do designers stay guides without blocking innovation?

I think this is the core tension:

Designers who respond to stakeholder-led design by tightening control will slow things down and damage trust. Designers who step back too much risk losing influence, quality, and consistency. The position that seems most useful and most sustainable is somewhere in between.

A starting point for the current state

The following suggestions assume the current state remains where the designer owns the design process and is accountable for its integrity. That may evolve, and following this section, I speculate on what that shift could look like.

For now, most designers are working within organisations where they hold the responsibility for quality, consistency, and process. They need to explicitly define quality for each use case—and that’s the context these suggestions are written for.

Every team, project, and stakeholder will have different variables, but having no process is riskier than having an imperfect one.

Treat this as a starting point to challenge and build on.

Before stakeholders start designing

If stakeholders are already showing signs of designing, consider having a conversation early — not to discourage it, but to set a shared understanding of how it fits into the project. Some things worth establishing upfront:

• Is there a clearly defined scope they’re working within, so ideas stay focused on what’s needed?
• Do they understand the design team will need to review anything before it goes further, and why that matters?
• Set a time when these ideas can come in, before designs have been tested, so the stakeholders' ideas can be tested too, not added in untested
• Ask them to keep their ideas at the wireframe level, to avoid polished designs becoming loose in the wild, and to help non-designers reduce time spent on creating designs and prototypes
• Are they using a managed business account, not a personal one — and does the organisation have visibility over what’s being built and where it’s stored?

When they share a prototype

This is the moment that needs the most care. A few questions worth asking:

• Who has already seen it? If it’s circulated widely before the design team has reviewed it, expectations may already be forming.
• Has anyone set the context — that this is a communication tool, not a final design?
• Are there usability, accessibility, or consistency issues that need to be named early, before they get treated as design decisions?
• Is there anything obviously out of scope that needs addressing now rather than later?

How to work with what they’ve built

Rather than treating a stakeholder prototype as a problem to manage, consider treating it as a brief in a different format. Some options worth exploring:

• Help the stakeholder distil their ideas into a clear list of proposed changes to the existing design, each with a rationale and a focus on MVP needs — preserving their thinking without creating a competing artefact.
• Find a way to fold the genuinely useful ideas into the main design explicitly, so their contribution is visible and valued.
• Where possible, find a way to keep the visual and interactive quality of what they’ve built — a written list is easier to manage, but loses communicative power.

Before anything gets shared too widely

Regardless of how a stakeholder’s ideas enters the process, one principle feels worth holding firm on:

• There should be one source of truth. Whatever a stakeholder may build and share, it needs to be consolidated into the main design before developers see it as a brief.
• Every proposed change should have a clear rationale and should have been reviewed against the scope and MVP needs.
• The design team should be the ones to make that final call on what goes in — not as blockers, but as the people accountable for quality and consistency.

Exploring a future state where the status quo changes

With AI tools enabling anyone to describe what they want and generate high-fidelity designs instantly, it means that what my stakeholder did was inevitable, not exceptional.

The suggestions above assume designers own the process. But that assumption is worth questioning because the tools that allowed a stakeholder to build a prototype mid-project are only going to get more capable and more accessible.

It’s not hard to imagine a future where AI design tools don’t just help non-designers express ideas, but actively guide them — flagging accessibility and sustainability issues in real time, suggesting consistent components, prompting users to stay in scope, checking designs against usability principles before anything is shared.

In that world, some of what designers currently do as process gatekeepers gets absorbed into the tool itself.

But right now, what these tools can’t do is navigate organisational politics, read the subtext in a stakeholder relationship, or understand why a user research transcript means something different in this context than it did in the last project. And AI-assisted guidance still needs a designer’s eye — the tool’s checks are only as good as what it’s been trained to look for, and that’s never the full picture. There’s a real risk that stakeholders who receive automated feedback develop a false confidence — that because the design passed the checks, it’s ready, and the designer’s review becomes a formality rather than a necessity.

So, for now at least, the designer’s role doesn’t quietly shrink — it might get actively harder to justify, but the need for designer direction actually increases.

What would that mean for the designer’s role?

If AI absorbs more of the process guardrails over time, the designer’s value shifts further toward strategy, facilitation, and judgment — the things AI can support but not replace. Designers might spend less time owning the end-to-end process and more time setting the conditions for others to design well within it. Less maker, more guide. Less executor, more standard-setter.

That’s a fundamentally different role. And the designers who navigate it best will be the ones who start thinking about it now, before the shift happens around them.

Shape your role before someone else does

AI tools are already in stakeholders’ hands, and they’ve started designing. Design teams that wait until it happens on their project will find themselves managing risks that are already in motion — and that’s a much harder position to design from.

React too slowly, and you’re scrambling. React too rigidly, and you become the blocker.

The opportunity is to get ahead of it: embrace the value stakeholders bring when they can express their ideas visually, while building just enough process to protect quality, consistency, and trust.

But this is bigger than process because boundaries are blurring and the Designer role is being rewritten. The designers and leads who articulate what shifts when AI enters their workflow — and what doesn’t — are the ones who shape that rewrite.

Being candid about what’s changing, exploratory about what might come next, and comfortable sitting with unresolved questions is, right now, a form of leadership.

The alternative is letting someone else define the future Designer role and then reacting to it once it’s already done.

More from Damien

**Follow Damien on Medium, **and explore his design innovations:

• Life-centred Design Lab — Expanding human-centred design to include nature and invisible communities to do less planetary harm and more good.
• Future Scouting — Designing life-centred, values-driven future tech products with speculative design.
• Damienlutz.com.au