The agency's Discovery process was established and already producing valuable client work and revenue. It was designed around a sensible constraint: incomplete information and late changes were expensive, so the team invested time in preparation before design began.
AI changed the cost of collecting, structuring and revising that information. It did not reduce the value of Discovery or the need for design judgement. My hypothesis was that the workflow could respond by moving repeatable preparation into a controlled pipeline, then returning the time it released to the decisions that make each project specific.
To turn that change in cost into a practical design opportunity, I began by mapping the work before assigning technology to it. The map included phases, responsibilities, repeated activities, client wait states and the deliverables that allowed one part of the project to move into the next. This exposed approximately ten hours of Discovery preparation per project, much of it spent gathering, organising and formatting information. That work was necessary, but not all of it required a designer's judgement.
That separation defined the boundary. AI could reduce the cost of preparing and revisiting the problem; it could not decide what the problem meant or how the design should respond. Client judgement, strategic direction and creative decisions remained human. The system would standardise repeatable preparation and evidence handling while leaving the design direction responsive to each project's context.
Manual mechanisms becoming system functions
I translated the map into a first set of Claude Skills connected through a linear sequence. Each Skill received a defined input, completed one job and passed a named file to the next. The blueprint made the movement of information visible and reflected the promise surrounding early agentic workflows: if the responsibilities were divided clearly enough, the work appeared capable of moving through a clean chain.
The mapped Discovery loop had three decision stages: Pre-Discovery prepared the evidence and exercises, the workshop validated the team's assumptions with the client, and the signed-off Discovery Playback Deck became the source of truth for design. My system hypothesis was to carry the same project context through that full cycle, then use its confirmed decisions to prepare the initial Figma foundation.
That was an idealised version of both AI and Discovery. Working with real inputs confronted the proposal with a supply chain that was inherently variable. Some projects began with a detailed brief; others had a proposal, a website and partial call notes. Client responses could arrive after research had started, and certain activities needed to run in parallel while others depended on a decision.
I kept the standard, but changed where it lived. Instead of prescribing one sequence, each Skill declared its inputs, outputs, source rules and conditions for stopping. The system could activate the capabilities a project needed without changing the standard each capability had to meet. It became responsive to volatile project conditions while remaining a controlled workflow rather than a collection of independent prompts.
Early maturity snapshot, optional
The first operational Skills structured the material already available in the Claude Project: proposals, briefs, website content, call notes and partial questionnaires. The problem was not extracting more information. It was preserving the status of that information as it moved into research documents and workshop preparation. Inputs could contain confirmed client facts, unresolved intentions, contradictions and genuine gaps. If the system treated them all as equivalent, an absent answer could quietly become an invented one.
I encoded those differences into the outputs. Black identified original client material, pink identified analysis or assumptions produced by the pipeline, and navy captured new information raised during the workshop. Assumptions later had to be marked as confirmed or discarded rather than blending permanently into the source material. This created traceability between the source evidence, the working hypothesis and the decision made with the client.
The mechanism was simple, but it changed the role of AI in the workflow. Its job was not to produce the most complete-looking document. Its job was to make the available evidence more useful without manufacturing certainty on behalf of the client or the team.
Rather than applying AI broadly, the map made it possible to identify the phases where AI could provide natural value.
Early maturity snapshot, optional
The Skills were not off-the-shelf agents added to an existing process. I authored them specifically for the agency's Discovery workflow. Each one combined a defined role, accepted inputs, source hierarchy, reasoning criteria, output contract, QA checks and conditions for escalation. This allowed Claude to perform a bounded piece of work while remaining accountable to the methodology around it.
The analytical Skills were designed to be critical and reflective rather than agreeable by default. They had to identify contradictions, challenge unsupported claims and explain the design implication of a finding. Established UX frameworks, recognised heuristics and sector-specific research informed their core instructions, but recommendations still had to be grounded in the confirmed brief, project evidence and operational constraints.
This was not model training. It was closer to onboarding a junior practitioner with an explicit playbook: what evidence to trust, which questions to ask, how to recognise a weak conclusion and when to escalate instead of improvising. Storing that knowledge in reusable Skills meant the method could be tested and revised without relying on a designer to rewrite the same prompt for every project.
Early maturity snapshot, optional
With the source layer established, I built separate Claude Skills for Competitor Analysis, User Needs and Information Architecture. Each Skill read the same structured project context, but used its own evidence threshold and reasoning contract. They were separated because they did not answer the same design question. Combining them into one general research instruction produced broad observations without making the consequence of those observations clear.
Competitor analysis was redesigned around applicability. A North Star had to be a real reference rather than an abstract ambition; depth had to reflect the project budget; and every finding needed to explain what should be retained, challenged or deliberately avoided. User Needs rejected decorative personas and unsupported demographics. It focused instead on posture, context of use, barriers and the conditions under which a person succeeds.
The IA Skill required a different standard again. Before proposing a future-state architecture, it had to reconstruct the client's current-state navigation faithfully. If that baseline was incomplete, every recommendation after it would be built on gaps or errors. Its agents distinguished navigation from a complete content inventory and separated the utility bar, primary navigation and footer before proposing changes.
The same contextual model supported every analytical Skill: confirmed needs, business model, budget tier, stakeholder expectations and the conventions of the client's sector. Each Skill interpreted that shared context through its own UX lens. For Information Architecture, the future-state recommendation combined those constraints with recognised IA patterns, and every non-obvious change needed a design rationale. This made the IA Skill closer to a specialist collaborator than a sitemap generator, without repeating the broader critical framework already encoded across the system.
Early maturity snapshot, optional
By this stage, the system could no longer assume that every project should activate every capability. I introduced Small, Mid and Full tiers to vary the depth of work without changing its standard. A smaller scope could use a focused analysis; a larger engagement could support more extensive research. Neither was allowed to replace missing evidence with a generic answer.
To manage those variations, I added an Orchestrator as the entry Skill for the Claude workflow. It read the available project files, checked the internal budget tier and identified which specialist Skills had the evidence required to run. It could work with partial material, pause for a focused question or withhold a capability until its inputs were available. Activities could run independently or as part of the wider workflow, and client wait states were treated as part of the operation rather than as exceptions to it.
Human control sat at the transitions. A designer supplied or confirmed the source material, reviewed analytical outputs before they moved into workshop preparation and decided whether unresolved items should pause the flow. The individual Skills could ask for missing evidence, but they could not approve their own assumptions or decide that material was ready for a client. Review was the control that allowed repeatable work to move faster while project context, client priorities and design judgement remained accountable to people.
Early maturity snapshot, optional
I tested the IA Skill against live websites because the current-state reconstruction was the foundation of every future-state recommendation. The test gave Claude a project context and website URL, then checked whether its agents could identify the site's actual navigation zones, capture their hierarchy and produce an evidence-based baseline before suggesting any change. This exposed a risk that polished outputs could conceal.
A source might return a 403 response, expose only part of its navigation or fail before the Skill had collected enough evidence. Continuing from that point could still produce a plausible result, but it would be a result based on information the system had never seen.
I introduced explicit stop conditions. If a site could not be accessed, the workflow requested screenshots or another source before continuing. Information architecture required evidence from the site's actual structure rather than relying on visible labels alone. The system also distinguished a missing input or setup problem from a failure in its own method, so the corrective action was clear.
These behaviours applied UX principles to the automation itself. A useful failure state did more than report an error. It prevented false progress, explained what was needed next and protected the team from inheriting confident but unreliable work.
Early maturity snapshot, optional
The available tools could not yet complete that route end to end. The Skills therefore produced structured Markdown as a persistent project reference, while a dedicated workshop Skill organised a separate content pack frame by frame. A designer could review the wording, see which evidence supported each exercise and copy the approved content into Miro manually. The documents became the operational bridge between Claude's analysis and the workshop board.
Information Architecture exposed the same limitation visually. The first sitemaps were generated as HTML, exported as images and then placed into Figma or Miro. Direct construction had always been part of the hypothesis; the early formats were a practical response to the available integrations. When Claude proved capable of creating editable nodes in Figma, it showed that the pipeline could eventually produce working artefacts rather than stopping at documents and static exports.
That test also established a higher QA threshold. Direct construction only saved design time if the artefact could sustain the next action. If its hierarchy, Auto Layout or annotations failed when a designer edited it, the automation had only transferred the effort into clean-up.
Early maturity snapshot, optional
Miro was the agency's established workshop environment, and direct board construction had been part of the system hypothesis from the beginning. The technical question was whether Claude could move the prepared material there without the manual handoff.
The official Miro connection could read board content but did not provide the reliable write operations needed to construct the workshop. I tested a dual route: using the connector to read the template, then a Miro developer token and REST API to create content, with Python handling the sequencing. Each route worked partially, but together they could not construct a complete workshop presentation that met the minimum requirements for a live client session. Image handling, layout behaviour and permissions remained too inconsistent for the board to be complete, editable and predictable in front of a client.
After reviewing the constraint with company leadership, the direction was to use the reliable tools already available rather than continue investing in the custom Python bridge. I tested that direction by asking Claude to build a client presentation directly in Figma using presentation-sized frames and the project information already processed by the Skills.
The first deck was visibly AI-produced, but it was complete, editable and structurally successful. That result opened a new path for the system: the final destination no longer had to be limited by Miro's integration. Figma could become the environment where the pipeline assembled its outputs into a tangible starting point for the designer, turning a technical blockage into the next architectural opportunity.
Early maturity snapshot, optional
The result was not an automated version of the agency's existing process. It was a different allocation of effort within it. Repeatable preparation could be structured, research could be revisited more quickly and incomplete information remained visible. The designer remained the operator of the AI-assisted workflow: choosing the evidence, directing the Skills, reviewing their outputs and deciding how that material should influence the design.
The first operational system also made its own limitations easier to see. Real project variation changed the architecture; failed sources changed its safeguards; and an unusable diagram changed the standard for its outputs. The value of the work was not that AI completed more of the process. It was that the process created more space for designers to do the parts that still depended on them.