High AI-Q in Design: Measuring What AI Changes in Practice

Design teams everywhere are adopting AI to move faster. But we haven't seen the exact metrics on how much time is saved, on which parts of the work, and what it costs in terms of quality.

At QBurst, AI-assisted design is an established practice. Our UXD Framework maps specific AI tools to each stage of the UX process, from research and synthesis through definition, design, and evaluation, and speed is one of the things it is known for.

What does that actually look like in execution, and where exactly does the time go? This article breaks down how the framework works in practice and where the gains come from.
 

What's in this article:

• Where a traditional design process actually loses time
• How we applied our AI-driven UXD Framework to a complex, multi-role enterprise app
• The process we used to generate a complete design with consistent screens
• The measured savings, and what the numbers do not show
   

The Question We Couldn't Answer: Exactly How Much Faster?

Ask a designer where a project's time goes, and you will rarely hear “drawing screens." The time goes into the work around the screens.

Research synthesis is the clearest example. Interviews produce hours of recordings that someone has to transcribe, read, tag, and cluster before a single insight is usable. Definition work compounds it: personas and journey maps are mostly an exercise in holding a large amount of scattered research in your head at once and staying consistent as you document it. Information architecture then has to reconcile every feature against every user goal. By the time high-fidelity design starts, most of the calendar is already spent, and the visual work gets compressed.

Our AI-integrated UXD Framework was built specifically to solve this. We knew the tools worked, but we couldn't answer the most important question: exactly how much time do these tools save?

"Faster" is not a metric; clients need hard data on which stages compress by roughly how much and which still take the same time they always did.

So we set out to answer it at stage-level granularity. Before starting, we built a feature list, reviewed it with stakeholders, and estimated the project the way we would estimate client work (eight hours to a manday). That estimate became the reference point. 

Meet ParQ: The Project We Put the Framework Through

ParQ is a corporate parking sharing application. Employees with a dedicated parking spot list it on the days they work from home, and colleagues without a spot book it for the day. Security verifies the vehicle at the gate.

We chose this scenario deliberately. A multi-role product with inherent user conflict is exactly where AI-generated design usually produces shallow results. ParQ gave us the perfect environment to record how the framework holds up under competing demands:

• The Renter: Needs a guaranteed spot rather than leaving it to chance.
• The Owner: Wants to share their space without losing control over it.
• Security: Needs an unambiguous yes/no at the gate during a 200-vehicle morning rush.

The core problem the app had to solve was predictability. Renters were guessing whether a spot would exist. Owners were worried their spot would be occupied on the day they needed it. Security could not verify who was authorized to be where.

Research & Synthesis: Finding the Blind Spots

Our research base consisted of four interviews, seven survey responses, and three synthetic users.

Synthetic users often invite pushback, so they warrant an explanation. Before we spoke to anyone, we prompted the model to role-play a renter, an owner, and a security officer, then interviewed those personas. We used them to identify blind spots in our discussion guide.

For example, the simulated security officer raised questions about after-hours access and identifying cars in the lot during a fire. Neither topic was in our original plan, and incorporating both made the real interviews sharper.

The guardrail: Synthetic users generate hypotheses; they never replace research. Everything we shipped as a finding traces back to a real person.

For the real interviews, we ran live sessions on Google Meet and collected voice notes, letting people speak in the language they were most comfortable in. Gemini handled transcription and multilingual audio well. Claude did the synthesis, and this is where tool selection earns its keep. Analyzing several transcripts at once means holding all of them in context without flattening the differences between them. Claude retains that context across long threads better.

In the Define stage, Claude turned transcripts and pain points into personas and current-state journey maps, and FigJam gave us the information architecture: three role-based sitemaps for renter, owner, and security, mapped end to end.

The Define phase produced our largest single saving for a structural reason: personas and journey maps transform existing research. The critical thinking happened during the Explore phase. Define is largely the labor of writing it out consistently, which is exactly the kind of work AI compresses best.

For instance, when Claude initially generated three generic personas to represent the user groups, a manual review of the interview transcripts revealed a crucial nuance AI missed. We discovered that we actually needed to account for two distinct categories of space owners: 

1. Owners motivated by offsetting the cost of a paid spot
2. Owners with a complimentary spot who simply wanted to help colleagues and donate their earnings

Building the Foundation: A Design System in One Click

Most AI design work starts by generating a screen. We start by generating the system underneath the screens, and on this project, this approach was our highest-leverage step.

We executed this in four distinct steps:

1. Define the tokens: We used Claude to establish foundational elements (colors, typography, and spacing) as real design tokens rather than vague descriptions.
2. Lock the source of truth: We finalized these tokens to prevent downstream drift.
3. Generate the code: We prompted Claude to write a custom Figma plugin designed to build this exact system.
4. Import natively: With one click, the plugin imported the entire architecture directly into Figma.
    

The prompt was specific about the output format, which is what made this work:

"Create a Figma plugin (code.js + manifest.json) that generates a complete design system inside Figma. Output: Color Primitives and Semantic Tokens as Figma Variables with aliasing, Typography Styles, Spacing and Border Radius tokens, Shadow Effect Styles. Use the Figma Variables API rather than Local Styles, and support mode switching for future dark mode."

Asking for Variables rather than Local Styles, and planning for mode switching upfront, is the difference between generating a set of swatches and building a system you can theme later.

We ended up with a full red and grey ramp, semantic colours (for error, success, warning, and info), a ten-step type scale, and spacing and radius tokens, all native to Figma before a single screen existed.

The payoff came downstream. Every screen generated afterward had a system to conform to, which means the consistency problem was largely solved before it started.

Three Tools, One Screen, and Two Ways to Prompt

We generated screens with three tools and compared them on the same prompts. The tools excel at different things, and knowing which to use is where true skill lies.

We chose Figma Make because on a project with a locked design system, adherence beats aesthetics. Stitch produced the prettiest individual screens and the least coherent set. (One useful detail inside Make: the model choice changes the result, and in our runs the Claude model produced better functional structure while Gemini produced better-looking output) .

The prompting lesson is the one we now carry into other projects. We wrote the same screen two ways.

• The Precision Prompt: Spells out every element, spacing value, and color. Paired with a tool that adheres closely, what you specify is close to what you get. This is designing with words, giving you ultimate control.
• The Intent-Led Prompt: Sets the goal and leaves specifics open. It sounds like the weaker option, but it isn't. A clear intent-led prompt regularly beats a detailed prompt that is overly prescriptive about the wrong things.

The rule of thumb is that detail rewards skill. If you can design with words, prompt precisely and keep control. If you are still building that habit, lead with intent, let the model bring its craft, then refine. Both are legitimate. Choosing the wrong one for your current skill level is what produces weak output.

One more practical point: each screen prompt has to be self-contained. AI design tools do not carry context between prompts the way a chat thread does. Every prompt of ours repeated the relevant IA, persona, and design system detail. That is how twenty-one screens stayed coherent. 

One Stage Cut, Two Habits Added

We did not wireframe this project, and the reasoning is narrower than the headline suggests.

Wireframes earn their place two ways: they are cheaper to produce than visual design, and they are cheaper to change. On this project, AI reduced the cost advantage of wireframing. Creating a designed screen required nearly the same effort and credits as creating a simpler wireframe, so adding a separate wireframing stage did not pay for itself. Iteration was a prompt away, so the back-and-forth that normally happens on wireframes happened on the real design instead.

That is a use-case call, not a verdict. We would still wireframe for complex flows where stakeholders need to align before visuals exist, on engagements with sign-off gates that expect low fidelity first, and with teams still building prompt habits. Dropping a stage because it stopped earning its keep on this project is different from dropping it because AI feels fast.

What needed active management was consistency. Stitch's drift between screens was the clearest case: individually strong screens that did not belong to the same product meant manual alignment afterward, eating into the time the tool had saved. UX Pilot's habit of adding unrequested content was subtler and more consequential, because plausible-looking additions survive a quick review. Both reinforce the same discipline: generate within a locked system, and review every screen against that system rather than against your impression of it.

Prompt construction taught us the rest. Long, elaborate prompts that tried to control everything at once produced worse results than shorter prompts aimed at one clear outcome. Most of the gain over the project came not from better tools but from better matching, knowing which tool to reach for and how much to specify.

How Much Faster: The Numbers

Measured against the traditional manday estimate we agreed upon before starting, these were the time savings:

Across the project, a job estimated at roughly 40  mandays was completed about 28% faster.

Two caveats make the numbers usable rather than decorative:

1. The baseline is a stakeholder-reviewed estimate, not a parallel manual run, so it is a considered projection rather than a controlled experiment.
2. We adjusted the scope as we went, so these figures should be read as indicative rather than exact.

What the table does not show is where the human effort moved. Reviewing, correcting, and deciding did not shrink. In some stages, they grew, because the volume of output to judge went up. The savings are concentrated in production, not in judgment. That distinction matters for anyone planning a project around these figures.

So, Gimmick or Real Leverage?

It’s both. Your methodology decides which one you get.

It is a gimmick when AI is treated as a vending machine. One tool for everything, loose prompts, first output accepted as truth. That path is fast, feels productive, and produces work that is generic.

It provides leverage when you apply strict conditions. Treat output as a fast first draft rather than an answer. Match each tool to what it is actually good at instead of standardizing on one. Build the system before the screens. Review and refine the output at every stage.

Every tool named in this article is available to any team. The difference is the method wrapped around it, and the fact that taste, and the responsibility for it, stays with the designer.