AI Design Pipeline

How it actually went

From what worked best down to where it broke, then what I changed.

The wins

Speed, above all upstream

The research, strategy, and architecture phases that normally take weeks were done in days. End to end the project took about three weeks; without the pipeline I estimate five to six, and almost the entire difference is upstream. These are honest estimates, not stopwatch data.

Research was the strongest phase

A benchmark spanning not just direct competitors but adjacent apps that solve connected problems, a domain immersion on medication adherence, drug databases. Genuinely useful, and more thorough than I would have done on my own. This was the real win.

A reusable trail, and a reusable machine

Everything the pipeline produced is a client ready artifact: brief, benchmark, domain study, problem statement, jobs to be done, flows, sitemap, feature list, and a running design decision log. That kind of traceability is rare for a solo designer and adds real value for a client.

And the pipeline itself is reusable: I keep it and refine it, so the next project starts with the machine already built instead of from scratch.

A thinking partner

Capturing and challenging decisions worked well: the AI was a tireless colleague to think out loud with, which often got me to a solution faster than working alone, and it kept reminding me of iOS conventions. One honest caveat: it tends to agree with me, even when I am ultimately wrong. It does not push back enough.

Consistent example data

A single fixture holds the sample data (patients, medications, schedules, statuses) in one place. I set it up early, so every screen pulls the same names and values and nothing drifts from one screen to the next.

A fast start on screens

On the screens themselves, the value was kickstarting each one quickly. The development and finishing were mine (see below), but a populated starting point beats a blank canvas.

It was also a real asset for diagrams and data visualizations: charts built straight from the fixture data, so the figures shown on screen stayed coherent with the rest of the project.

The honest failures

None of that means it ran smoothly. The pipeline broke in real, instructive ways, and the worst of it was concentrated in one place: turning flows into actual screens. Here is what went wrong, and what it cost.

The wireframe trap

The biggest failure was the P5 agent (UX/UI), and it started with how I had designed the pipeline itself. The initial model had P5 produce low fidelity wireframes from a generic kit, then a later agent (P6) rebuild everything in high fidelity with the iOS design system.

Three things were wrong with that. The generic kit was only vaguely iOS-like, so instead of guiding the agent it confused it. Building every screen twice, once in lo-fi then again in hi-fi, burned tokens and time the lo-fi pass never earned back. And more fundamentally, generating wireframes through an agent defeats their whole purpose: a wireframe is meant to be a fast, throwaway sketch, but here every screen meant prompting, waiting for the model to reason, watching it drive the Figma MCP, and only then getting a result, slowly and at a real token cost. The spontaneity that makes wireframing useful was gone.

No guardrails

The deeper problem was that the P5 agent had no guardrails. It had not read Apple’s Human Interface Guidelines or the iOS 26 design system, so it had no real grasp of the native UI patterns needed to keep the flows coherent, and its translation of the wireframes into the iOS design system was a mess. It invented patterns that did not follow iOS conventions. Components and dimensions drifted from screen to screen, and it hardcoded inconsistent colors instead of using design tokens, forcing hours of manual re standardization. It repeatedly covered only the happy path and forgot whole sections. It got stuck in loops, like blindly guessing icon codepoints.

And lessons written into the agent’s skills kept getting repeated anyway: knowing a rule is not the same as following it. My honest admission: I leaned too hard on the AI in this phase, which cost time and tokens. The screens always needed heavy editing from me, which is why I now use this agent to kickstart, not to finish.

The fix followed from all of this: skip the low fidelity pass entirely and have a single P5 agent design straight in real, native iOS 26 components. I had the AI rewrite the two agents, and the P6 visual agent was cut down to optional recoloring. But changing the pipeline was not enough on its own; the agent still needed hard constraints, which is exactly what the guardrails below are. A lot of work was thrown away to get there.

None of this is locked, and that is the point. If I want to wireframe a flow by hand first, P5 can still take my own sketches in as Source and build from them, so I keep the option without paying for the agent to draw them. I have not settled exactly where P5 sits in the process yet, and I do not have to: any agent can change role, or be split, without breaking the pipeline, because they only ever talk through the shared repository. The failure that cost me the most also showed me the system was built to absorb that kind of change.

Token cost on trivial tasks

Some genuinely simple tasks, like finding an icon and placing it into a component, burned a disproportionate number of tokens relative to how simple they were. In practice I often had to interrupt the agent mid screen and make the change myself, because the back and forth cost more, in tokens and time, than the change was worth.

The learning I outsourced

Early on I leaned on the AI for the upstream work, the research most of all, more than I should have. There is a hidden cost to that. The research phase is normally where a designer goes digging, reading and scanning, and that effort is exactly what makes the domain stick: you slowly become a kind of micro-expert in the field you are designing for, and the knowledge compounds as the project moves on.

By letting the AI gather and synthesize for me, I reached the screen phase knowing the domain less deeply than if I had done that digging myself. The research output was genuinely strong, but my own grasp of it was thinner. It is a subtle, real danger of pushing AI too far upstream: you keep the deliverables and quietly lose the learning.

The guardrails

The failures pushed me to wrap structure around the AI. The pieces that actually worked:

A design system contract

I asked Claude to extract a single source of truth from the iOS 26 kit and the official Apple’s Human Interface Guidelines, the exact color tokens, the components and their keys, the spacing conventions, the canonical dimensions, written and referenced before building any screen, instead of letting the AI improvise each value; this contract is what actually cut the errors.

It is also the reference for verification: before closing a screen the P5 agent diffs the real values on the canvas (spacings, colors bound to a token versus hardcoded, real kit components versus custom look alikes, dimensions) against the contract, because a screenshot hides drift but the numbers do not.

Learn the platform first

The agent now reads the iOS 26 design system and Apple’s Human Interface Guidelines before it designs, instead of guessing the conventions.

A reference screen before scaling

One screen was validated as the standard, then every other screen was built from it, so the conventions were locked before mass production rather than discovered midway.

A complete scope gate

Before building a screen, the agent must derive every state, role, and section from the flows and the example data, instead of designing only the happy path. This came straight from it forgetting whole sections.

Lessons as enforced gates

I asked Claude to rewrite the screen agent so the recurring failures became blocking gates rather than passive advice, kept a reusable contract template for future projects and an honest running retrospective of the collaboration, saving the most stubborn lessons as memories the agent loads every session.

The clearest finding of the whole project: the only reliable guardrails are structure plus the human eye. Writing a lesson down in the agent’s skills does not stop the AI from repeating it; a gate does.

Results

The screens

The screens shown here are a complete, coherent set of native iOS 26 designs, finished to a pixel perfect standard, covering the whole product: adding a medication (dose, schedule, intake instructions, criticality), creating a patient and inviting them, adding a care circle contact, the caregiver cockpit (today, medications, alerts, refills, settings), and the patient side dose cards across their states (reminder, due, taken, all done).

But to be clear about who did what: the AI did not design all of this. It kickstarted each section by designing the first screen, a populated starting point. From there the work was mine. I designed the essential of the flows, and I reworked and refined the screens heavily to reach this level. The pipeline gave me a head start, not a finished product.

Because every screen draws from the same components, tokens, and spacing, the Medsbuddy app reads as one consistent product rather than a pile of mockups.

The documentation

Beyond the screens, the pipeline leaves the client a complete, traceable trail of documents, the kind a consultancy bills as discovery and strategy. Each one reads on its own:

Research (Discover)

• The consolidated brief: the client’s scattered input reorganized into one structured, hierarchized brief, with the explicit separated from the implicit and the open questions to resolve.
• The benchmark: direct competitors, adjacent apps, and cross domain analogues, with real screenshots and the interaction patterns worth reusing or avoiding.
• The domain study: the medication adherence field in plain terms, its vocabulary, standards, accessibility constraints, and state of the art.
• The research synthesis: a short executive summary of the key insights, the patterns to keep, and the tensions to resolve.

Strategy (Define and Ideate)

• The problem statement: the reframed problem (who, what job, the real problem versus the stated one), with the evidence behind the reframe.
• The jobs to be done: who we design for, and what they are actually trying to accomplish.
• The current journeys: how people cope today without the product, and where it hurts.
• The concept directions: the distinct approaches that were explored, and the chosen one with the reasoning for picking it over the others.

Architecture (Architect)

• The user flows: every key task step by step, including branches, errors, and edge states.
• The sitemap: the information architecture, where everything lives and how it is navigated, with one view per type of user.
• The feature list (MoSCoW): what makes the v1 and what is deferred, and why.

Design (UX/UI)

• The design system contract: the tokens, components, spacing, and dimensions the screens are built on, ready for a developer handoff.
• The design decision log: a running log of every screen decision and the reasoning behind it.

Taken together, these explain not just what the app is, but why every choice was made, which is exactly what tends to get lost in a handoff.