Figma
Visual referenceUnderstand the existing language.
Inspect client screens, interaction patterns and visual conventions. Product screens were not authored in Figma.
Enterprise energy · Product design & design engineering
Grid inspection.
Human intelligence,
AI assisted.
The brief: turn aerial imagery into trustworthy grid-inspection decisions for large energy enterprises. I established the team’s AI-driven design process and designed a B2B platform across four operational roles and executive oversight.
2 Main Deliverables
Deliverable 01 / Process
A way of working the team could repeat.
Role-based discovery, workshops, rapid experiments and an explicit handoff. A shared path from an open question to an approved screen.
Deliverable 02 / Product
A platform the team could use.
Connected workflows for imagery intake, asset association, AI review, assessment and oversight. Built as a high-fidelity, interactive frontend.
Actual product prototype · Client identity anonymizedOpen any screen for a closer look ↗
The context / Enterprise energy · B2B
Real infrastructure.
Real responsibility.
An inspection platform for large energy companies, connecting aerial imagery of power lines and poles with asset data, AI detections and expert assessment.
A missed defect is more than a row in a table. Inspection decisions inform work that protects people, keeps electricity flowing and reduces the risk of equipment failure and fires. The reviewer brings professional judgment and accountability to that decision.
Who uses it
Specialists working as one team.
Administrators set up access and assets. Uploaders bring in imagery; associators connect it to the grid. Reviewers assess the evidence, while CEOs and project leaders monitor the wider picture.
The scale of the work
Tens of thousands of images.
A single upload can contain tens of thousands of images. This data-heavy workflow needs clear processing states, focused queues and a traceable path from each image to a decision.
Human in the loop
AI proposes. The human decides.
AI helps surface potential defects. A qualified reviewer accepts, rejects or records an assessment. Human judgment remains authoritative; a later AI run must not overwrite it.
The mandate / What I owned
One designer.
A cross-functional product team.
I owned the translation from a complex energy domain into an experience the client could try and engineers could build. I also designed how that translation happened.
- Role
- Sole product designer and design engineer—from role discovery and information architecture to a working frontend.
- Scope
- Domain and state models, role journeys, interactive modules, AI-assisted prototyping, design-system integration and handover.
- Team
- Client domain experts, business analyst, architect, project manager, frontend team and backend team.
- Input
- Recorded workshops, requirements, process spreadsheets, client Figma references and the supplied Storybook design system.
Part 01 / Process
Process
How I turned an open brief into a shared way of working — and made feedback arrive before the expensive build.
01.1 / Shared understanding
The first design material
was a conversation.
The brief described an ambitious platform, but the roles, exceptions and boundaries still needed agreement. I ran role-focused discovery with the team and client to turn overlapping requirements into a shared picture.
Collect the evidence
ConversationsWorkshops · recordings · transcripts
DocumentsPDFs · requirements · process sheets
Existing referencesFigma files · prior product patterns
Co-create understandingRole-focused
workshop
workshop
Ask → model → challenge → clarify
Client + designer + teamMake the model visible
Roles & accessWho does what, with which permissions.
Journeys & task flowsHow the work moves between people.
States & dataWhat changes, what persists, what can fail.
Agreed scope + visible open questionsOne discovery pass for each role
Client & domain experts
Explain inspection practice, challenge assumptions and validate the proposed behavior.
Design & business analysis
Structure the inputs, model each role’s work and turn unknowns into workshop questions.
Architect & engineering
Frontend and backend teams check interaction constraints, data availability and implementation feasibility.
Project management
Connect priorities, scope boundaries, review sessions and delivery planning.
What I brought back to the team
A common language for the product, before committing to its interface.
01.2 / Decisions & evolution
The process changed
when the evidence did.
Seeing a working idea often changed what the client wanted. I needed a process that could absorb that learning before it turned into expensive rework.
An AI-driven design approachFigma informed the work.
Figma informed the work.
AI made the product tangible.
The client’s Figma files showed patterns, visual language and earlier iterations from related products. I used them as references; I designed the product through AI-assisted exploration and code.
Storybook
Visual source of truthUse the maintained design system.
Ground the final prototype in the client’s components, tokens, states and patterns.
ChatGPT + Claude Code
MakingMove from understanding to behavior.
Structure inputs, explore alternatives, produce specifications and build a clickable frontend.
Client references + shared design systemAI-assisted experiments → validated specifications → coded prototype
Three approaches / The same problem, a different sequence
I moved feedback closer to the beginning.
Mar–AprSuperseded
01Requirements-driven
- Documents
- Structured requirements
- Finished prototype
- Client review
Feedback arrived after the build.
- Starting material
- Requirement documents
- First review artifact
- Finished prototype
- When the spec stabilizes
- Before shared agreement
- A change of direction
- Rebuild the solution
What failed
The system executed the plan faithfully, but the next client conversation invalidated assumptions already built into the solution.
What I learnedMore complete instructions could not replace agreement on the workflow.
Inside this approach +
- Input
Requirement sets for each role, scope documents and workflow spreadsheets.
- Structure
ChatGPT turns documents into structured requirements.
- Build
My Claude Code skills generate screens and audit design-system use.
- Output
A finished prototype goes to review and engineering.
May–JunSuperseded
02Spec-driven
- Documents + feedback
- Detailed specifications
- Rebuilt prototype
- Client review
Better instructions. The same late learning.
- Starting material
- Documents + workshop feedback
- First review artifact
- Finished prototype
- When the spec stabilizes
- Before shared agreement
- A change of direction
- Revise specs and screens
What failed
The specification still came before shared understanding. Workshops reopened it, and exploration landed inside the most expensive artifact.
What I learnedA rigorous specification is valuable once the team knows what it is specifying.
Inside this approach +
- Input
Original requirements + meeting transcripts + workshop outcomes.
- Reconcile
ChatGPT and Claude help expose contradictions and update requirements.
- Specify
New screen specs define states, rules, edge cases and acceptance criteria.
- Build
The final prototype is rebuilt to match the updated specification.
Jul–AugAdopted
03Experiment-first
- Inputs + open questions
- Experiment ↔ reviewCheap to change ↺
- Validated specification
- Final prototype
Feedback shapes the direction before the build.
- Starting material
- Documents + workshop feedback
- First review artifact
- Disposable HTML experiment
- When the spec stabilizes
- After client validation
- A change of direction
- Revise a cheap sketch
Why it worked
A change landed on a cheap experiment. I could test the direction with the team and client before committing to the final implementation.
What I keptThe specification and quality reviews stayed; they moved after validation.
Inside this approach +
- Input
The same documents, transcripts and workshops, with open questions visible.
- Experiment ↔ review
Quick HTML options; internal review, client reaction, keep or replace.
- Agree & specify
Capture the accepted behavior, states and acceptance criteria.
- Build & hand off
Implement on the client’s design system and approve the screen.
01.3 / The design process I established
A shared process,
built around learning.
Six stages connect discovery to delivery. I gave each stage visible responsibilities and outputs, and made room for client feedback before the final specification.
Understand the problem01 Capture → 02 Make senseExplore & agree03 Validate ↔ 04 ExperimentCommit to the solution05 Specify → 06 Build
My adaptation of the Double DiamondExplore the problem.
Explore the problem.
Converge on the solution.
Then commit to delivery.
The first two spaces create room for learning. Delivery turns the agreed direction into a specification, a working prototype and a concrete handoff.
Problem spaceDiverge → converge01 Capture · 02 Make sense
Solution spaceExplore → decide03 Validate ↔ 04 Experiment
DeliverySpecify → build → hand off05 Requirements · 06 Prototype
The repeatable path from question to product
Six stages. One connected process.
Follow the work from raw input to developer handoff. Each column shows the activities, people, tools and outputs that move the next stage forward.
Capture
Raw materialClient input- Record and transcribe the client conversation.
- Collect documents, screenshots and loose ideas.
- Capture the raw material before structuring or challenging it.
- The aim is a complete input set; clarity comes next.
Who
Client SMEsUXBAArchitect
Tools
ChatGPT
Outputs
- Meeting recordings
- Transcripts
- Client documents & PDFs
- Screenshots of legacy tools
- Raw notes & unfiltered ideas
Make sense
Shared modelInternal sense-making- Turn raw input into artifacts on a shared board.
- Move from notes to clusters to structure.
- Model roles, personas, processes, journeys and task flows.
- Make unknowns explicit as questions.
Who
UXBAPMArchitectFrontend
Tools
LucidChatGPTClaude Code
Outputs
- Personas & role model
- As-is / to-be process maps
- Customer journey map
- User & task flows
- Information architecture
- Domain glossary
- Open questions & idea parking lot
Validate
Confirmed scopeValidate & clean- Walk the board with the client.
- Confirm the model, correct it and remove unsupported assumptions.
- Seeing the rough whole prompts new functionality and a rethink of the flow.
- Ideas can expand before they narrow.
- Close questions and agree scope boundaries and priorities.
Who
ClientUXBAArchitect
Tools
LucidChatGPTClaude
Outputs
- Validated board: one shared picture
- New client feature requests
- Corrected roles & processes
- Answered questions log
- Agreed scope boundaries
- Prioritized functionality
Experiment
Agreed directionRapid experiments- Create fast, disposable sketches and wireframes.
- Keep them cheap: no production build or design-system implementation.
- Sketch → internal review → show → adjust.
- Answer design questions through something the team can try.
Who
UXClient reviewersBAArchitect
Tools
Claude CodeClaude Cowork
Outputs
- Throwaway HTML experiments
- Draft requirements per experiment
- Decision log: kept / rejected
- Agreed interaction model
- Shared functional understanding
Specify
Build-ready rulesFinal requirements- Write the specification after the direction is understood.
- Define states, rules, edge cases and the minimum UX behavior for each screen.
- Review and approve the specification before the final build.
Who
BAUXArchitectClient sign-off
Tools
Claude CodeChatGPT
Outputs
- Confirmed specification per screen
- Build plan per screen
- Reuse manifest: what already exists
- Acceptance criteria
- Client sign-off
Build
Clickable productFinal prototype- Build a high-fidelity, clickable prototype on the shared design system.
- Use consistent patterns and reusable components.
- Implement the agreed specification; resolve exploration in the earlier loop.
Who
UX / DesignDevsClient demo
Tools
Claude CodeGitLab
Outputs
- Clickable, DS-compliant prototype
- Screen inventory & status
- Shared component library
- Specifications as the build contract
- Developer handoff checklist
03 ↔ 04 is the learning loop.05 → 06 turns the agreed direction into the delivery contract.
The collaboration contract
Who does what.
I made leadership, contribution and review explicit. Discovery is shared work: UX and business analysis jointly drive sense-making, while the client validates the interpretation.
Leads / facilitatesContributesReviews / signs offReceives the output
| Role | 01 Input | 02 Sense-making | 03 Validate | 04 Experiments | 05 Requirements | 06 Prototype |
|---|---|---|---|---|---|---|
| Client / SMEsDomain owners | 01 InputDrives | 02 Sense-making— | 03 ValidateValidates | 04 ExperimentsReviews | 05 RequirementsSigns off | 06 PrototypeReviews |
| UX / DesignMy role · facilitator & maker | 01 InputListens | 02 Sense-makingDrives | 03 ValidateFacilitates | 04 ExperimentsDrives | 05 RequirementsContributes | 06 PrototypeDrives |
| Business analystRequirements | 01 InputCaptures | 02 Sense-makingDrives | 03 ValidateFacilitates | 04 ExperimentsContributes | 05 RequirementsDrives | 06 PrototypeReviews |
| ArchitectData access & feasibility | 01 InputListens | 02 Sense-makingContributes | 03 ValidateContributes | 04 ExperimentsContributes | 05 RequirementsContributes | 06 PrototypeConsumes |
| Project managerScope & cadence | 01 InputContributes | 02 Sense-makingContributes | 03 ValidateContributes | 04 Experiments— | 05 RequirementsReviews | 06 PrototypeReviews |
| Frontend / DevsBuild & integration | 01 Input— | 02 Sense-makingFeasibility | 03 Validate— | 04 ExperimentsSanity-check | 05 RequirementsReviews | 06 PrototypeConsumes |
“Consumes” means using the approved output for implementation or integration. It does not mean owning the design stage. A dash means no standing responsibility is shown.
Where the design decisions happen
The experiment loop.
Two nested cycles keep learning cheap: internal iterations measured in hours, and client reviews measured in days. Both happen before committing to the final build.
Internal loop · hoursKeep the useful direction. Discard the rest.
SketchExplore an option
Internal
reviewTeam feedback
reviewTeam feedback
Show to
clientMake it tangible
clientMake it tangible
FeedbackSurface ambiguity
DecideKeep / reject
Client loop · days
Refine the interpretation.
Return with a better experiment.
Exit criterionEveryone describes the core functionality the same way.
Cheap to be wrong
Experiments are disposable wireframes and HTML sketches. They carry no production-code commitment; rejecting one costs hours rather than a build cycle.
The internal loop absorbs the noise
The team tests weak variants before the client review. I bring forward the options that are useful to react to.
Feedback on something tangible
The client can react to a screen and its behavior. Ambiguity surfaces during exploration, while a change is still inexpensive.
Understanding is the exit criterion
The loop ends when the team and client can describe the core functionality consistently. The specification records that agreement.
Screen walkthrough · 05 views
Early workspaces made the questions tangible.
These early workspaces show how the review model became tangible: queue, association context, findings and image evidence in progressively clearer arrangements.
AI acceleration, human directionWhich tool does which job,
Which tool does which job,
and where I stay.
The stage guide shows which tools are involved. Here is the boundary between what they accelerate and what I remain accountable for.
ChatGPT
Tools accelerateDigest workshop recordings and documents.
I ownWhat needs clarification; what deserves investigation.
LucidChatGPTClaude Code
Tools accelerateStructure role models, journeys, flows and a domain glossary.
I ownThe problem framing, relationships and unresolved questions.
LucidChatGPTClaude
Tools acceleratePrepare workshop material and consolidate corrections.
I ownThe conversation with the client, priorities and scope.
Claude CodeClaude Cowork
Tools accelerateGenerate and revise disposable HTML alternatives.
I ownWhich option is useful, what gets shown and what gets rejected.
Claude CodeChatGPTReview agents
Tools accelerateDraft specifications and check fidelity, reuse, design-system rules and UX states.
I ownResolve ambiguity and approve the behavior with the team.
Claude CodeStorybookGitLab
Tools accelerateImplement with shared components and publish the reviewable frontend.
I ownInteraction quality, approval status and the handoff decision.
Agents check the rules. I choose the direction, defend the tradeoffs and stay accountable for what reaches the client.
01.4 / What the process changed
The process
Collaboration made repeatable.
I established a shared rhythm for discovery, workshops, experiments, specifications and handoff. What began with this team became a working standard for multiple teams: a shared environment, clear responsibilities and a repeatable path from discovery to delivery.
My estimate of the design cycle after moving to AI-assisted experiments.
My reported spend reduction after changing the AI setup and moving to a subscription.
Feedback arrived before the expensive build.
Cheap experiments resolved the direction. The final spec and coded prototype followed.
A shared way of working was the first deliverable. Here is the product it made possible.
Part 02 / Product
Product
An interactive inspection platform: four operational roles, connected workflows and a configurable overview for leadership.
March–August 2026
How the product took shape.
Milestones across discovery, role delivery and the evolution of the team’s workflow.
- MarDiscover the domain
Client input, role discovery and the first requirement models.
- AprEstablish the foundation
Entry flows, admin and GIS setup; early coded screens.
- MayConnect imagery to assets
Associator specification set delivered on 29 May.
- JunExplore the reviewer
AI review and inspection experiments; interaction models evolve.
- JulValidate the direction
Inspection direction demoed and accepted in early July; then specified.
- AugConsolidate & share
Executive overview, feasibility review and a wider process proposal.
Designed & prototyped
Select a module to explore its workflowA connected suite of modules.
One connected productGrid
Inspection7 modules · 4 operational roles
Inspection7 modules · 4 operational roles
Access
Operations
Oversight
Expert review
Module coverage spans early and refined prototypes. Assessment and AI review are two work modes of the reviewer role; schema configuration remained partial and some admin settings were stubs.
02.2 / Product workflows
From aerial imagery
to accountable decisions.
Power-line inspection connects data, physical infrastructure and expert judgment. I designed the handovers between those jobs as carefully as the screens themselves.
01 / Establish the environment
Enables every role belowAdministrator
Access & roles · GIS assets · Assessment schemas
02 / Operational role
Uploader
Bring aerial imagery into a traceable session.
Processed imagery
03 / Operational role
Associator
Connect each image to the physical asset it represents.
Asset-linked evidence
04 / Operational role
Reviewer
Validate AI findings and record a human assessment.
Reviewed assessment
AI proposes detections.The reviewer accepts, rejects or records an assessment.
A clear route into the right workspace.
I designed the entry and access flows around enterprise onboarding: invitations, login, multi-factor authentication, password recovery and role selection.
Shared access foundationIdentity first.
The right context next.
The right context next.
Access flows connect the account to the operational workspace.
Accept access
Invitation or an existing account.
Verify identity
Login and the applicable verification step.
Resolve the role
Open the workspace associated with the user’s role.
Ready to workRole-specific workspace
The appropriate tools, tasks and asset context.
Screen walkthrough · 06 views
From invitation to the right workspace.
Account setup, sign-in, verification and role selection form one connected entry flow.
Support the people behind the work.
The administration experience connects upload-session oversight, GIS configuration, users and assessment schemas. It gives the operational roles a consistent foundation.
The workflow I designedFrom role discovery to interaction design
- 01Set up accessConfigure users and their operational roles.
- 02Prepare GIS dataMaintain the asset context used throughout the platform.
- 03Version the schemaDefine the structure of an assessment and its findings.
- 04Oversee sessionsMonitor incoming data and operational activity.
Administration is the foundation for the other roles, rather than the last step in the inspection chain.
Screen walkthrough · 02 views
The configuration behind the workflows.
Administration connects people, permissions and the assessment schemas used by the operational teams.
01
Manage access
User and role configuration supports different responsibilities.
02
Maintain the asset base
GIS setup anchors imagery to the grid model.
03
Define assessments
Versioned schemas keep structured findings consistent.
Make every file accountable.
Aerial imagery is only useful when the team can trust what arrived. I designed upload sessions around individual file states, recoverable errors and a clear processing summary.
The workflow I designedFrom role discovery to interaction design
- 01Create a sessionDefine its name, data type and project.
- 02Upload the batchTrack each file; retry or resume failures.
- 03Process the dataShow progress through the processing phases.
- 04Hand overSend usable imagery into association.
A failed file stays visible. Completion should never hide missing or invalid data.
Screen walkthrough · 08 views
A complete upload journey.
From session setup to recoverable failures and a traceable processing summary.
01
Batch intake
One session keeps images and processing results together.
02
Recoverable errors
Per-file feedback makes failures visible and actionable.
03
Clear handover
Processed imagery moves into the association queue.
Watch the working prototype 21 sec · Upload and association
Recorded from the interactive frontend prototype with demonstration data. Silent walkthrough; the interaction is described above.
Give every image a place.
The image and the physical asset must agree before an inspection can be trusted. I brought the queue, map and image context into one association workspace.
The workflow I designedFrom role discovery to interaction design
- 01Take the sessionOne associator owns the active session.
- 02Inspect the queueReview areas, loose images and discrepancies.
- 03Resolve the matchLink an asset, place a virtual asset or flag a mismatch.
- 04Complete reviewed workBulk-complete high-confidence items and pass to AI review.
One active owner prevents two conflicting versions of the same image-to-asset relationship.
Screen walkthrough · 12 views
From an image queue to linked assets.
Match imagery to infrastructure, handle ambiguous groups and loose images, then complete the session.
01
Spatial context
Keep the physical asset visible while checking its imagery.
02
Exception handling
Resolve missing matches and flag discrepancies.
03
Queue ownership
Make responsibility and progress explicit.
AI finds. The reviewer decides.
I designed two complementary modes: a grid for scanning and bulk actions, and a focused view for judging one detection. The reviewer can confirm or reject the model’s proposal.
The workflow I designedFrom role discovery to interaction design
- 01Open & filterWork within a session; filter component, condition and status.
- 02Choose review depthScan the grid or use one-image focus mode.
- 03Confirm or rejectJudge the detection, individually or in a selected group.
- 04Check completionSurface unmarked items before closing the review.
A later inference run must not overwrite a human-reviewed decision. The AI review result stays advisory.
Screen walkthrough · 09 views
AI suggestions, reviewed by a person.
A connected review flow covers scanning, focus, individual decisions, bulk actions and completion.
01
Control the workload
Filter by component, condition and review status.
02
Move with intent
Switch from scanning to focus; use keyboard decisions.
03
Finish responsibly
A completion gate surfaces unmarked detections.
Watch the working prototype 21 sec · Filters, focus and completion gate
Recorded from the interactive frontend prototype with demonstration data. Silent walkthrough; the interaction is described above.
Turn observations into a record.
In assessment mode, the reviewer works across an asset queue, map, aerial imagery and component findings. I designed the final states so an uncertain assessment stays visible instead of looking complete.
The workflow I designedFrom role discovery to interaction design
- 01Scope the taskSelect grid assets in the map and create an inspection.
- 02Inspect the evidenceMove through assets, images and component annotations.
- 03Record the judgmentClear · with findings · cannot assess.
- 04Complete the recordEvery asset reaches a final state; save a new assessment.
The same queue, map, imagery and findings context stays available while the reviewer moves from asset to asset.
Screen walkthrough · 17 views
An inspection workspace that adapts to the task.
Define the scope, inspect assets in different layouts, record findings and complete the review.
01
One working context
Read the image alongside the asset and its components.
02
Structured findings
Capture the affected component and severity.
03
Accountable history
Completion creates a new assessment record in the intended workflow.
Watch the working prototype 15 sec · Asset context and findings
Recorded from the interactive frontend prototype with demonstration data. Silent walkthrough; the interaction is described above.
Leadership workspace / CEO & project leaders
Explorer Mode Dashboard.
I designed a highly configurable, dynamic dashboard for CEOs and leaders who need a view across the whole project. It brings inspection progress, processing status and project data together, so the overview can adapt to the questions leadership needs to answer.
Configurable viewsProject-wide visibilityLeadership decisions
Grounded in the available data.
I audited proposed metrics against the schema, removed unsupported financial targets and rebuilt the dashboard around feasible information.
5Supported KPIs shown
8Candidates deferred or excluded
How the data review changed the design +
I initially excluded “structures reviewed vs. remaining.” When the supporting tables became available, I brought it back as the headline. The decision followed the evidence as the backend evolved.
Screen walkthrough · 03 views
Explorer Mode Dashboard
A configurable executive view that turns review progress, processing health and discrepancies into inspectable decisions.
The leadership workflowFrom project data to a useful overview
- 01Set the perspectiveStart with the project-level question a leader needs to answer.
- 02Configure the viewTailor the dynamic dashboard to the information that matters.
- 03Read project healthInspect progress, processing and the wider project picture.
- 04Direct attentionUse the overview to identify what needs follow-up.
Designed for CEOs and leaders. The prototype uses demonstration data; chart readiness was checked against the available schema.
02.3 / What I delivered
A substantial first version.
A foundation for what comes next.
This phase delivered a large proof of concept (POC): an interactive first version of the product, together with the environment, process and way of working needed to carry it forward.
A connected inspection platform.
Seven modules across four operational roles and executive oversight. High-fidelity workflows connect access, imagery intake, association, AI review, human assessment and a configurable dashboard.
A working delivery setup.
An AI-assisted prototyping environment, the shared design system, a reviewable frontend and a repository-based handoff with screen specifications and acceptance criteria.
A standard beyond one team.
I established the discovery, workshop, experiment and delivery process. Its responsibilities, review gates and execution model became a standard for multiple teams.
Next phase / Real-data validation
Moving into live testing with real data.
The product now moves into testing with real inspection data to validate the workflows and assumptions developed during the POC.
The delivered POC uses demonstration data; production integration remains with engineering. Real-data testing is the next phase. Reported time and tooling-cost improvements describe my design workflow; operational and safety outcomes have not yet been measured.
02.4 / Developer handover
A running reference,
inside the team’s repository.
I organized handover around the version engineers could trust: an approved route, its specification and the same component library the team maintained.
- 01My local prototypeReact + Vite, demonstration data and no backend calls.
- 02Shared design branchA long-lived branch in the developers’ repository.
- 03Published review buildCI exposes a static, clickable version for the client and team.
- 04Engineering integrationDevelopers take approved screens and connect data and services.
GitHub was used earlier; GitLab became the delivery environment. Production integration and release remained with engineering.
Approval is the handover boundary.Route + page status + agreed spec
A screen they can run
The interaction, including empty, loading and error states, is available to inspect in the working frontend.
A contract they can check
Acceptance criteria, source references and a build plan explain the intended rules behind the screen.
Components they already own
The shared design system is consumed as a dependency. Product-specific extensions and local overrides are kept explicit.
The practical handoff
A ticket comment points to the approved route and its specification. That gives engineering a concrete starting point for implementation and review.
03 / Bonus · An earlier engineering experiment
Figma into code,
with an AI migration team.
Alongside the product work, I built an agent-driven pipeline to translate an existing Figma design system into a typed component library. This was a separate migration exercise, not the tool I used to author product screens.
Figma library
Audit & canonical specs
Specialist build agents
QA ↔ repair
Typed component library
The experimentOne source library.
One source library.
Coordinated specialists.
A gated code output.
I organized the work into bounded roles and sequential quality gates, with a human review between stages. The build produced tokens, foundations, primitives, components, patterns and documentation.
Why it was superseded
The client supplied its own coded design system.
I switched the final product prototype to that maintained library. Keeping a parallel library would have created another ownership and maintenance burden for the team.
Built quickly with AI · Retired when the better source arrivedInside the migration: agents, stages and quality gates Read the technical story +
Figma auditor + designer review
Capture the library, normalize its component definitions and record evidence before implementation.
Token normalizer · foundations architect · primitive architect · component builder · pattern architect
Specialized builders work against the agreed specifications and their dependency order.
Documentation agent · QA validator · repair agent
Document the output, run checks and feed specific failures into a repair loop.
One orchestrator coordinates nine specialist roles. Human approval sits between stages; Figma access stays with the source-reading roles.
Readiness
Confirm access, scope and the migration contract.
Audit → canonical specs
Inventory the source and establish one agreed definition per component.
Tokens → foundations → primitives
Build the dependency base before higher-level components.
Components → patterns → docs
Implement in waves, compose the patterns and document use.
QA → repair → QA
Use findings to drive targeted fixes until the release checks pass.
5 packages13 primitives32 components8 patterns
A readiness gate plus ten migration stages. These figures describe the separate migration output, not production adoption or customer impact.
Good enterprise design makes the product clearer—and helps the people building it move together.
Start a conversation