Flux Full Circle
•
4 min
Building an AI agent to orchestrate a UX project from onboarding to wireframes. Named Rassie.
Building an AI agent that runs a UX project end to end. And naming it after the world’s best coach, Rassie.
2x rugby world champion springbok coach, Rassie Erasmus
2x rugby world champion springbok coach, Rassie Erasmus
CHALLENGE
As the sole UX designer across roughly 40 clients, every project ran through the same manual cycle: five templates worked by hand, a pattern library cross-referenced page by page, no memory carried from one client to the next.
As the sole UX designer across roughly 40 clients, every project ran through the same manual cycle: five templates worked by hand, a pattern library cross-referenced page by page, no memory carried from one client to the next.
STRATEGY
I built Rassie, an orchestrator agent that runs onboarding through wireframes across five phases, then rebuilt it around three hard gates after watching it move faster than my judgement could follow.
I built Rassie, an orchestrator agent that runs onboarding through wireframes across five phases, then rebuilt it around three hard gates after watching it move faster than my judgement could follow.
RESULTS
A working pipeline validated first on a test client, since run on further live projects, paired with a dedicated review skill that checks its own output against the brief before I do.
A working pipeline validated first on a test client, since run on further live projects, paired with a dedicated review skill that checks its own output against the brief before I do.
CHALLENGE
A manual process held together by templates and memory
Before Rassie, a UX project meant working through a stack of templates by hand: a UX Brief Template, a Persona Template, a Research Plan Template, a Synthesis Framework, a Design Direction Template. Alongside them sat a standalone Component Pattern Library and four Product Type docs, referenced page by page rather than pulled in automatically.
None of this was broken. It was just entirely manual and dependent on memory. At roughly 40 clients, that didn't scale. A pattern I'd settled on for one lodge brief wouldn't necessarily resurface for the next one, not because the thinking was wrong, but because nothing carried it forward.
Before Rassie, a UX project meant working through a stack of templates by hand: a UX Brief Template, a Persona Template, a Research Plan Template, a Synthesis Framework, a Design Direction Template. Alongside them sat a standalone Component Pattern Library and four Product Type docs, referenced page by page rather than pulled in automatically.
None of this was broken. It was just entirely manual, and entirely dependent on me remembering what I’d decided on a similar project three months earlier. At roughly 40 clients, that memory doesn’t scale. A pattern I’d settled on for one lodge brief wouldn’t necessarily resurface for the next one, not because the thinking was wrong, but because nothing carried it forward.
The manual scaffold: five templates, one pattern library, worked by hand per client with nothing carried forward automatically.
The manual scaffold: five templates, one pattern library, worked by hand per client with nothing carried forward automatically.
STRATEGY
Designing the process through iteration
Designing the process through iteration
The first version had one approval gate. It failed in practice.
Early planning notes for Rassie show a much simpler shape: brief approved, straight into the Figma builder. One review point, at the very end. On paper it looked efficient. In practice, Rassie could move through multiple judgement calls without me seeing or approving them.
Early planning notes for Rassie show a much simpler shape: brief approved, straight into the Figma builder. One review point, at the very end. On paper it looked efficient. In practice, it meant Rassie could move through every judgement call between “brief approved” and “wireframes done” without me seeing a single one of them.
Sanbona was the test case, and it found the gap immediately
I ran the first real build on Sanbona deliberately, not Rassie's toughest possible test, but its fairest one. It was a smaller-scale project, a redesign rather than a from-scratch build, which meant there was existing site structure and content to work from rather than a blank page. If Rassie was going to fail, I wanted it to fail somewhere I could diagnose quickly.
It did fail, in the specific way I'd worried about. Rassie was moving faster than my judgement could follow. It was making decisions I hadn't signed off on before I had a chance to intervene. The output wasn't unusable, but it had already committed to choices I hadn't actually signed off on by the time I saw them.
I ran the first real build on Sanbona deliberately, not Rassie’s toughest possible test, but its fairest one. It was a smaller-scale project, a redesign rather than a from-scratch build, which meant there was existing site structure and content to work from rather than a blank page. If Rassie was going to fail, I wanted it to fail somewhere I could diagnose quickly.
It did fail, in the specific way I’d worried about. Rassie moved through the process quickly and made assumptions about decisions that were mine to make, without pausing anywhere for me to catch it. The output wasn’t unusable, but it had already committed to choices I hadn’t actually signed off on by the time I saw them.
One gate to three: the early plan ran straight through from approved brief to finished wireframes.
One gate to three: the early plan ran straight through from approved brief to finished wireframes.
That single failure is what produced the shipped structure: three hard gates, not one. The failure led to three hard gates: a Knowledge Gaps gate before work begins, a Brief Approval gate, and a separate Design Direction Approval gate. Sanbona showed me that approving the brief and approving the resulting direction were two different decisions.
That single failure is what produced the shipped structure: three hard gates, not one. A Knowledge Gaps gate in Phase 1, so Rassie surfaces what it doesn’t know before it starts guessing. A Brief Approval gate in Phase 4. A Design Direction Approval gate in Phase 4.5, added after Sanbona specifically because “brief approved” and “I agree with the direction you’ve taken it in” turned out to be two different sign-offs, not one.
The resulting review model: review after every template, not after every phase
The bigger shift wasn't just adding gates, it was where the review happens. After every template Rassie produces, I review and tweak before it moves to the next one. That template-by-template checkpoint, rather than a single end-of-phase review, is what actually gives me the ability to correct course before an early misread compounds into a wireframe I then have to unpick.
The bigger shift wasn’t just adding gates, it was where the review happens. After every template Rassie produces, I review and tweak before it moves to the next one. That template-by-template checkpoint, rather than a single end-of-phase review, is what actually gives me the ability to correct course before an early misread compounds into a wireframe I then have to unpick.
Consistency became a memory problem, not just a process problem
The other change worth naming: when a pattern proves out across a build. When a pattern proves out on a build, that decision is documented so it can be surfaced on the next relevant project. The goal wasn't just to make the existing process faster. It was to make useful decisions reusable across projects.
The other change worth naming: when a pattern proves out across a build, that decision now gets noted so it can resurface on the next relevant project, rather than living only in that one client’s file. That’s the difference between Rassie as a faster version of the old manual process, and Rassie as something that actually gets more consistent the more it’s used.
Five phases, three gates, and a feedback loop: patterns validated on one build feed forward into the next.
Five phases, three gates, and a feedback loop: patterns validated on one build feed forward into the next.
A QA loop for Rassie's output
Rassie's wireframes don't go straight from Figma to me without a second pass. The figma-wireframe-reviewer skill exists specifically to check a Figma wireframe file produced by Rassie against project-context.md and UX Brief.md, flagging gaps, inconsistencies, and missed opportunities before I do my own review. It isn't a theoretical safety net, it's been run against real Rassie builds, and I've separately used it to audit whether Rassie's own process documentation still matches what the skill actually does. The reviewer adds a second layer of QA before I assess the output myself.
Rassie’s wireframes don’t go straight from Figma to me without a second pass. The figma-wireframe-reviewer skill exists specifically to check a Figma wireframe file produced by Rassie against project-context.md and UX Brief.md, flagging gaps, inconsistencies, and missed opportunities before I do my own review. It isn’t a theoretical safety net, it’s been run against real Rassie builds, and I’ve separately used it to audit whether Rassie’s own process documentation still matches what the skill actually does. That’s the loop closing on itself: a tool that checks the checker.
RESULTS
A pipeline with a track record, not a one-off proof of concept
The test client surfaced the exact failure mode that shaped the rest of the build, and the process has since run on further live projects, with the review skill catching drift on real output, not hypothetical output.
The test client surfaced the exact failure mode that shaped the rest of the build, and the process has since run on further live projects, with the review skill catching drift on real output, not hypothetical output.
3 hard review gates, up from a single end-of-process check, 5 phases from onboarding to finished wireframes, 8 live projects with a documented review-skill pass on top of Rassie's own output
Current level of execution
Current level of execution
REVIEW GATES
3
PHASES
5
BUILDING MEMORY ON
12 live projects
Takeaway Note
