# Girudo AI Conversion

By Munawar Khel / Independent Practice / Freelance UI/UX Designer / 2026 / 11 min read

Published at https://munawarkhel.com/work/independent-practice/girudo-ai-conversion/

Converted the platform's development from a manual design-then-handoff process to an AI-based workflow in which design and frontend happen simultaneously, removing the specification, the handoff, the interpretation gap, and the review-and-correction round trip entirely

- Company: Independent Practice
- My role: Freelance UI/UX Designer
- Timeline: June 2026 to August 2026
- Platform: A working method: a structured knowledge workspace and Claude skill suite, with the Next.js platform produced through it
- Category: AI Workflow / Design Process
- Status: New design, delivered
- Tools: Claude Code, Claude Skills, Next.js 16, React 19, TypeScript, Tailwind CSS 4, Vitest, Figma, FigJam, Obsidian, Vercel
- Team: Solo, working directly with product and stakeholders

## Context

Girudo is a trading card game platform I had already designed end to end as a separate engagement. Version 2.0 was the rebuild, and the interesting part of it was not the product decisions. It was that the way the work got made changed completely.

The first version was built the normal way. Design happens in Figma, reaches a state someone calls final, and is handed to developers. Developers interpret it, build something close, and send it back. The designer reviews, finds the gaps between what was drawn and what was built, and writes them up. That loop runs until someone runs out of time, and the product ships slightly worse than the design because the last round of corrections never got made.

For 2.0 I converted that process to an AI-based workflow. Design and frontend stopped being two sequential activities separated by a handoff and became one activity. There is no specification to write, no handoff meeting, no interpretation gap, and no round trip, because the person making the design decision is the same person the implementation happens in front of. This case study is about that conversion: what had to be built to make it work, what it changed, and what it cost.

## The problem

The handoff is where design work goes to die, and everyone in the industry has normalised it. A designer produces an artefact that is not the product, a developer reconstructs the product from that artefact, and the difference between the two is discovered afterwards. Every project pays this tax twice, once in the reconstruction and once in the correction rounds, and the correction rounds are always the ones cut when a deadline arrives.

Working with AI removes the reconstruction step in principle, since the same person can decide and implement in one motion. In practice it introduces a different failure that is worse, and this is the part that makes the conversion hard rather than automatic.

An assistant is only as good as the context it is working from, and design context is exactly the kind that is never written down. Why this module exists, which competitor pattern was deliberately rejected, who signed off on this scope, what a term means in this product, what is still an open question rather than a decision: on a normal project all of that lives in Figma comments, call recordings, and the designer's head. A model cannot read any of it. Ask one to build a screen without it and it will produce something plausible, confidently, with invented product logic filling every gap you did not specify. At speed, that fills a codebase with decisions nobody made.

So the real problem was not learning to build with AI. It was that going fast is only safe if the knowledge behind the work is available in a form the workflow can actually use, and on a rebuild that knowledge was scattered across two years of a previous version.

## What I did

The conversion has two halves, and the second is what makes the first work.

The first half is collapsing design and implementation into one activity. There is no Figma-to-code handoff on this project because there is nothing to hand off. A design decision is made and implemented in the same session, in the real components, in the real product, against real data and real breakpoints. Figma stays in use for exploration and for the screens worth drawing before building, but it stopped being the deliverable and became a sketchpad. The design system reference is a live route inside the running application rather than a document, so what a component actually does and what the reference says it does cannot drift apart, because they are the same thing.

The second half is the infrastructure that makes working at that speed safe. Before designing anything for 2.0, I built the workspace the project would run inside. A single command stands up the whole structure: external research covering competitors, feature comparison, pricing and market opportunities; internal product knowledge covering overview, per-module workspaces, personas, UX research, open questions, information architecture and sitemap; a rules directory; and an append-only log holding decisions, meeting notes, requirement changes and dated feedback. Every folder carries a readme explaining what belongs in it. The script is idempotent, so the same command repairs a workspace as easily as it creates one.

That structure exists so the context is retrievable at the moment of building rather than remembered. When a module gets built, its definition, its user flows, the research behind it, and the open questions against it are all in known locations, so the work starts from what the product actually is rather than from what seems reasonable.

Three phase gates keep the sequence honest even at speed: product knowledge, then research, then UX structure, each with named sign-offs and a logged transition. And one hard rule does the heaviest lifting: product detail is never inferred. Module names, features, user roles and business goals come only from what the product owner supplied, and anything unconfirmed goes to an open questions file with a named owner instead of becoming a confident sentence in a document. Going fast without that rule is just generating fiction quickly.

On top sits a suite of custom Claude skills for the work that repeats: competitor profiling split into creating and approval-gated refreshing, a UX visualization assistant for producing the right artefact for a question, feedback intake that categorises and deduplicates across a dated log and imports from design boards, a research writing partner, and a changelog generator driven by commit history.

## Outcomes

- Converted the platform's development from a manual design-then-handoff process to an AI-based workflow in which design and frontend happen simultaneously, removing the specification, the handoff, the interpretation gap, and the review-and-correction round trip entirely
- Shipped Girudo 2.0 through that workflow in Next.js 16, React 19 and strict TypeScript, roughly 283 source files and 77,000 lines with 82 test files, across four tagged releases in under two months
- Moved design judgement onto working interfaces rather than static frames, so empty states, wrapping labels and interaction feel are evaluated against real data and real breakpoints at the moment the decision is made
- Built a reusable, project-agnostic workspace that stands up in one command, generating the full research, rules and institutional-memory tree with a readme in every folder, idempotent so the same command repairs an existing workspace
- Made product knowledge retrievable at the moment of building rather than remembered, with every module carrying its definition, user flows, research and open questions in known locations
- Kept speed safe through a hard rule against inferring product detail, routing anything unconfirmed to owned open questions, plus three phase gates with named sign-offs and skills that draft for approval rather than writing directly
- Authored a suite of Claude Code skills for the repeating work, spanning competitor profile creation and approval-gated refreshing, UX visualization production, categorised and deduplicated feedback intake, research writing with citations, and changelog generation from commit history
- Eliminated design system drift by shipping the reference as a live route in the application, so the documentation and the components it describes cannot disagree
- Produced the rebuild's full knowledge base inside the system, including eleven sourced competitor profiles, personas, module definitions, information architecture, sitemap and a mapped Figma screen inventory

## Decisions

### Remove the handoff by merging the roles, not by improving the spec

What: Made design and frontend one activity performed by one person in one session, so 2.0 has no design-to-development handoff at all. Figma became a sketchpad for exploration rather than the deliverable.

Alternatives: Keeping the split and investing in better handoff, richer specifications, annotated frames, tighter design tokens, which is the conventional answer and the one the industry keeps refining.

Why: Better specifications reduce the size of the interpretation gap without removing it, and the round trip that gap creates is where the schedule actually goes. Deciding and implementing in the same motion removes the loop rather than shortening it, and it means every design judgement is made against a working interface instead of a picture of one.

### Build the knowledge workspace before designing anything

What: Spent the first week of the rebuild building a project-agnostic workspace that stands up in one command, before any 2.0 interface work started.

Alternatives: Starting on screens immediately and organising the documentation as it accumulated, which is what deadlines usually dictate.

Why: Removing the handoff makes context the binding constraint rather than production capacity. An assistant asked to build without the product knowledge will invent it, confidently, and at speed that fills a codebase with decisions nobody made. The workspace is what converts going fast from a risk into a method.

### Never infer product detail, route the unknown to owned open questions

What: Made it a hard rule that module names, features, user roles and business goals come only from what the product owner supplied, with anything unconfirmed going to an open questions file with a named owner.

Alternatives: Letting the assistant fill gaps with reasonable assumptions flagged for later verification, which produces a more complete-looking draft much faster.

Why: This is the single rule that makes the whole conversion safe. Generated product detail is indistinguishable from confirmed product detail once written down, and on a rebuild it gets inherited by everything downstream. An assumption inside a document is invisible; the same assumption as an owned open question is a task.

### The design system is a route in the app, not a document

What: Shipped the design system reference as a live page inside the running application rather than as a separate file or Figma library treated as the source of truth.

Alternatives: Maintaining the canonical system in Figma and mirroring it into code, which is standard practice and keeps designers in familiar territory.

Why: Any reference that is not the thing it describes will eventually disagree with it, and on a project with no handoff there is no review step where that divergence gets caught. Making the reference render the actual components removes the possibility rather than managing it.

### Reset the documentation rather than curate it

What: Deliberately removed the accumulated research and design documentation in August, restarted from the clean workspace definition, and preserved the prior state behind a git tag.

Alternatives: Auditing and pruning in place, which loses nothing and feels more responsible.

Why: Past a certain ratio of superseded to current material, a documentation tree costs more to read than it returns, and in this workflow that tree is what the work is built from, so its noise propagates directly into the product. Curating is slow and leaves a structure shaped by decisions nobody would repeat. A tagged reset was cheap precisely because the workspace skill rebuilds the structure in one command.

## What I learned

Removing the handoff does not remove the work it was doing. The specification, the annotated frame and the review round were compensating for a real problem, that the person implementing did not know what the designer knew. Merging the roles solves that for the human and immediately recreates it for the assistant, which knows nothing about the product beyond what it can read. That is the trade this workflow actually makes: the effort that used to go into communicating intent to a developer goes into making intent retrievable instead. It is less effort in total and it compounds, since a written decision serves every future session while a handoff conversation served one.

Speed changes which mistakes are expensive. When a screen took days, a wrong assumption surfaced in review before much was built on it. When a screen takes an hour, a wrong assumption is three modules deep before anyone notices, and it looks exactly like a decision. Every safeguard in this system exists because of that asymmetry: never infer product detail, route the unknown to an owned question, gate the phases, draft for approval. None of them slow the work down noticeably, and each one prevents a class of error the old pace would have caught for free.

The rules that survived were the ones with no judgement call attached. Everything written as a recommendation was skipped within a fortnight; the absolutes held. Not because they were better rules, but because a rule with a judgement call becomes a judgement call, and under deadline that resolves the same way every time. The routing table, which simply states where each kind of content goes, removed more friction than any single rule, because it retired a decision being made dozens of times a week.

The honest caveats are real. This workflow suits one person who can hold both roles, and I do not know how it behaves with two designers and three engineers, where the handoff is also a coordination mechanism rather than pure overhead. It puts unusual weight on typed, tested code, since the pace is only safe because the compiler and the test suite object loudly. And the August reset revealed how much of the first two months of documentation was not worth keeping, which is a tighter phase gate I should have enforced from the start rather than a discovery.

Tags: Information Architecture, Design Systems, AI Workflow, Claude Code