Things don’t settle. The system just keeps growing, and the gap between what’s in your head and what’s written down keeps widening.

That’s where documentation actually matters. When I started using AI (Claude chat) to help write the docs, 2 things happened.

1. Documentation stops being a separate job.
   Bringing Claude in at decision time, iterating on a token name, rationalising a spacing rule, capturing a component decision as it happens - means you're documenting as you build, not after. The overwhelm disappears because you start treating it as a continuous output of the thinking you’re already doing.

2. The documents you’re producing aren’t just for design system documentation. They become the “context layer” that keeps your system coherent.
   Every canonical doc, every micro-decision logged, every motion call captured, is fed back into Claude continuously as the system is being built. By the time you’re building components in code, the AI isn’t starting cold. It knows the token vocabulary because it helped build it. It knows why the disabled state fails contrast. The system doesn’t drift because the reasoning behind it is always in context.

Building context first wasn’t new to me - I’d been doing it with prototypes for a while. When I started design system work (with AI), the instinct carried over naturally. TJ Pitre at Southleft gave this a proper name - Context-Based Design Systems. I've watched a lot of his work and it's quietly shaped how I think about building design systems with AI.

AI should know how you think about your design system

The first thing I do when starting a design system is set up a Claude Project (in Claude chat). I feed it two things before anything else: instructions to act as my Design System (DS) co-pilot, and a set of skills .md files that tell it how to handle design system work and DS documentation specifically.

Most of what I do with the Design Systems Project is brainstorming and iterating decisions with Claude, for example - why is this token named this way, why does this semantic category exist, what’s the exception and why. By the time I start building components, Claude knows the vocabulary because it helped shape it.

One thing that accelerated this for me was, I had already written extensively about foundations and token architecture in my Design System Chronicles series. I handed those articles directly to Claude. They gave Claude a deep understanding of how and why I’d architected things the way I had, without me having to re-explain from scratch.

If you have something similar, use it. If you don’t, you can do the same thing with reference material from design systems you admire. Study how they’ve structured their token architecture, adapt it to your organisation and your system, and feed that thinking into Claude as your foundation. The goal is the same - Claude needs to understand not just what your system looks like, but how you think about it.

Subscribe now

Foundations first - canonical docs

The three core foundations of any design system are colour, typography, and numbers. Each one runs on the same underlying logic - a two-layer token model → primitives that define the raw values, semantics that map those values to meaning and intent.

Now, for every foundation, I produce two types of files and the distinction matters.

1. The first is the canonical docs (all docs are .md files). This covers the

   1. token architecture - how the primitives and semantic tokens are structured, how they map to each other and

   2. the system model - which is where the reasoning lives. The rules, the whys, the exceptions, the decisions that weren’t obvious. These aren’t notes. They’re authored, structured, source-of-truth documentation written with Claude during the creation of tokens and decision making, not after. The doc is the output of the thinking behind it.

2. The second is the JSON export - all variables out of Figma, exported via a Figma plugin and fed straight into the Claude Project. This is the data layer.

The canonical docs give Claude the logic. The JSON gives it the values. Both matter, and both live in the Project from the moment a foundation is done.

The reason to be disciplined about this isn’t just organisational tidiness or that it serves as my documentation in Figma. It’s that every one of these files is context for Claude as you’re building in Figma, and later for Cursor when you’re building in code. It’s what stops Cursor (later) from violating the intent behind tokens and any other type of drift.

Elevation

Elevation doesn't get this treatment upfront. Elevation values make sense against real component surfaces. You can't reason your way to the right shadow in the abstract. So I defer it entirely. Build a few components first, place them in real layouts, evaluate elevation visually against them. A doc after this is enough.

Motion

Motion gets the same deferred treatment - for the same reason. You can't evaluate a transition in the abstract.

What I do → vibe code a simple motion prototype app with controls - duration, easing, a replay button and vibe code my components into it (components need not be perfect, they are just artifacts to test motion). I then use these controls to test if a motion feels right for each component (that may need motion).

The output is a motion table - which components need motion, which values, which don't require them - and from that, a motion.md that captures the tokens and the reasoning behind each call. That goes into the Claude Project.

What we’ve got

At the end the Project has canonical docs for foundations

• colour.md (Note - you could either combine all your docs into one, or have them as separate docs - for example, colour-token-architecture.md and colour-system-model.md and so on. This applies to all your foundations.)

• typography.md

• numbers.md

• elevation.md

• motion.md

and their JSON files. Every foundation is accounted for, and all of it is context for AI.

Building components and logging decisions as you go

While building components in Figma, maintain a decisions record, you could call it component-decisions.md.

Now, this is different from the canonical foundation docs. Canonical docs are authored and structured and they're meant to be read. The decisions record is freeform and continuous. It's a running log of every non-obvious call made during the component build (in Figma), captured as the thinking happens.

Think of things like:

Button scale - Small 32px, Large 40px. 48px deferred, no confirmed use case yet.

Chip - Uses spacing/150 (12px) padding on both ends. When the dismiss icon button (24px hit target) is present, the invisible 4px padding within the icon button frame creates a visual discrepancy at the trailing end in Figma. This should not exist in code.

Three things it does:

1. It keeps you honest about decisions you've already made so you don't accidentally override them later.

2. It helps you remember the why behind calls.

3. And it becomes part of the context stack that everything downstream draws from, including component documentation.

These are exactly what produces reasoned outputs later.

Now, before documenting a single component, do one more piece of work with Claude: research and brainstorm a component documentation template. What sections should every component doc have? What's always present, what's conditional? That way your documentation output stay consistent.

You could point to several real design systems, use them as a reference and build a template that fits your system. A good template could include the following: Overview, Anatomy, Props, States & Variants, Behaviour & Interactions, Usage, Accessibility, and Token Callouts.

The template goes into the Claude Project. When it's time to document, Claude has the template.

Now you have

• Foundations canonical docs

• component-decisions.md

• component-template.md

For component documentation, I connect Figma to Claude or Cursor (if Cursor has all context) via the Figma Console MCP. I pass the component node and the component documentation template. At that point two things are in context simultaneously:

1. the Figma node - full component tree, bound variables, variant structure, exact measurements and

2. everything accumulated in the foundation docs, and the decisions record.

The output reflects that. “Token Callouts” don’t just list which token is used but explain why that token and not another. The reasoning behind a deliberate accessibility exception isn’t missing or vague, it’s there because it was logged when the decision was made.

The Figma Console MCP gives Claude ground truth from the file. The accumulated context gives it the system thinking. Together they produce documentation that a designer, an engineer, and Cursor can all read and actually use.

Quite honestly, you'll still need to review and correct and that's not going away. But where you get at with the final component documentation is really good.

In fact this output becomes a {component-name}.md that can serve as a component spec and supplement the Figma Console MCP when you code (and do Storybook) the component. With so much context established, there is minimal drift.

What you've actually built

This is what building context-first actually means. A continuous accumulation of decisions and reasoning that runs parallel to the design work, so that when AI enters the loop at any point, it isn't starting cold.

Every canonical doc, every JSON export, every component .md file - this entire context stack gets fed to Cursor when it's time to build in code. Cursor isn't guessing at your token vocabulary or second-guessing your spacing rules.

/
├── colour.md
├── typography.md
├── number.md
├── elevation.md
├── motion.md
├── component-decisions.md
├── component-template.md
├── Components/
    └── component-doc-1.md
    └── component-doc-2.md
    └── ...
    └── component-doc-n.md
├── json-foundations/
    └── colour-primitive.json
    └── colour-semantic.json
    └── ...(the rest of it)
└── projects/
    └── your-ds

The system doesn’t drift because the reasoning behind it is always in context - in Claude, and then in Cursor. A design system built this way stays coherent, because the thinking behind it was never lost.

💡Note:

You are also doing yourself a favour by making it easy for AI tools like Cursor. When the context is already there, you dont need premium models to do the work for you. Even Auto mode or Composer-2 handle it very well - which saves you real money!

I’ve written a lot about fast prototypes that I’ve done with tools like Figma Make, Google AI Studio and v0 (you could catch up with a bunch of them here - AI & Product design, if you haven’t).

That workflow is covered, but this piece isn’t that. I’m also not talking about enterprise design-to-code pipelines where designers commit directly to production.

This is specifically about solo side projects. Things you’re building for yourself - tools, experiments, workflow explorations. The kind of project where it’s just you, an idea, and Cursor open.

I’m doing this with two projects right now. Tenet UI - my design system, which I want to build in code, with a component playground where anyone can copy-paste code snippets - something like what shadcn does. I know its ambitious and honestly it is overwhelming.

And “Loading” is a craft project, a web experience built around beautifully designed loading screens. Think DOS terminals, VHS tapes, Film countdowns and Cassette rewinds. Both are works in progress - and honestly, I still have a long way to go. But importantly both taught me what the setup needs to look like.

Before I open Cursor

The starting point is usually Claude (I’ve replaced ChatGPT with Claude, its way better). I use it as a UX co-pilot before anything else. Brainstorming the idea, thinking through what I actually want to build, sometimes quickly visualising a direction in Google AI Studio.

From that conversation, I put together a lightweight PRD - just enough structure to give me a clear direction I can carry into Cursor. Alongside that, I sort out a basic style guide, base colour palette, typography. Small decisions, but they feed into the design.md I'll create later with Cursor.

Skills before anything else

The first thing I do when I open a new Cursor project is set up skills. In Cursor, skills are SKILL.md files that package domain-specific knowledge and instructions the agent can pull in when relevant. Think of them as a capability layer you're giving the agent before it touches anything.

These are separate from rules, which are always-on, skills are dynamic - the agent decides when to apply them based on what it's doing.

I use a frontend-design, interface-design, and ui-ux-pro-max skill all pulled from ui-skills.com a curated resource built specifically for this. You can also create your own skills inside Cursor itself. Ask the agent to interview you about how you work and what you care about, and have it write the SKILL.md from that conversation.

The point is, before the agent touches anything in your project, it knows how to behave. What quality bar it's working toward, how it should handle UI decisions, what it should never do.

Subscribe now

The “prompts” folder

This one I learned entirely from Tal Raviv. Full props to him! He wrote about how he uses Cursor as a product thinking partner, and maintains a public GitHub repo called from-thinking-to-coding - a set of prompt files that instruct the agent on how to write specs, plans, opportunity assessments, and more.

I clone that folder and drop it in my project root at the start of every project.

What this does is give the agent reference material for every document it's going to help me create. For example, when I ask Cursor to write a spec, it reads from the prompts folder to understand what a good spec looks like.

The output is more disciplined and consistent than anything I'd get from a cold prompt. It also means I'm not rewriting these from scratch every time. Tal has generously done that thinking. I point Cursor to it and move on.

Either download it from Github and drop it in your root folder manually, or you can tell Cursor or Claude Code to clone the repo directly - give it the GitHub URL and ask it to download the files locally. Once they're there, the agent can read them as documents in your project.

Brainstorming inside Cursor

Here's where it gets interesting, and where I think most people leave a lot on the table.

Once skills and the prompts folder are in place, I don't start building. I brainstorm. Inside Cursor, using the agent as an interviewer. The prompt I use is adapted from Tal's repo, and it goes something like this:

Before we start doing anything, I want you to converse with me and ask me questions to understand the project. I am winging it with you, so things may keep changing, but I'll try to tell you what I want. Think about what's missing, interview me, and pull insights and ideas out of me, and brainstorm with me. Let's converse just enough to make a great lightweight doc from our collaboration. Wait on writing the doc until our conversation is done. Keep it succinct and readable — no filler — but capture all the gold. Use our original conversation words for the vivid, evocative stuff. Let this doc be an ever-evolving one.

What follows is genuinely good. Cursor asks questions I hadn't thought to ask myself. As Tal puts it in his repo’s readme:

I love having my AI coding agent guide me conversationally, pulling the context out of me.

That's exactly it.

The brainstorm looks different depending on the project, and that's worth saying explicitly.

With Tenet UI, I was new to a lot of the dev concepts involved. There were a lot of unknown unknowns for me. So the brainstorm was Cursor acting as the technical expert, surfacing the right questions:

• Are Tenet UI components in the same codebase as Tenet Studio, or a separate package/repo?

• How do you actually measure the success metrics in Phase 1? Do you have analytics/tracking in place, or is this more of a qualitative observation metric?

• For “installation overview”— is this step-by-step instructions with code blocks, or just conceptual guidance pointing to component pages?

I was learning through the conversation. The agent was filling in the gaps I couldn’t even see yet.

With Loading, it was completely different. I had an idea, but it was vague and evocative rather than clear. I knew the feeling I wanted - cinematic, tactile, unconventional, but I couldn’t fully articulate it. The brainstorm felt like walking around in a dark room with a torch. I’d take a step in one direction, Cursor would light up what was there, and I’d decide whether to keep going. I didn’t know what was in front of me until I started moving toward it.

Some examples:

• On sound — are you thinking ambient soundscape per world (the hum of a CRT, tape hiss, projector flicker), sound on interaction (the physical act of flipping a card, a DOS beep on hover), or both?

• When you flip a card and enter that world — DOS, VHS, film — what happens in there? Is it a single static(ish) screen, slowly animating? Or is there more to explore, more to read, more depth?

Sometimes the conversation gets messy. I'd hit a question I couldn't answer. I’d go back to Claude to think it through, then return to Cursor with a better answer. The flow is chaotic. But it's productively chaotic. I end up knowing things about my own project that I wouldn't have figured out any other way.

The document stack

By the end of the brainstorm, Cursor produces a brief.md - a proper PRD built from the initial context I fed in (including the PRD I wrote with Claude) and everything that came out of our conversation. What the product is, who it's for, rough features, a visual direction. This becomes the foundation for everything that follows.

From here, I build out the rest of the document stack before any code is written, in this order.

agent-behaviour.mdc - cursor rules. How the agent behaves throughout the entire project like conventions, preferences and non-negotiables. They keep behaviour consistent across sessions so I'm not re-explaining myself every time I open Cursor.

design.md - a living design system file. Colour palette, typography, spacing decisions. Not exhaustive, but enough for the agent to make consistent visual calls. This gets updated as the project evolves.

spec.md - the architecture. File and folder structure, tech stack, scope, non-goals. This is where the shape of the project becomes concrete. What we’re building, and just as importantly, what we’re not.

plan.md - the build plan. Phases, tasks within each phase, what “done” looks like for each one. Macro order first, then detail per phase.

agents.md - a living roadmap the agent can read at any point. Current state of the project, key decisions made, what’s done, what’s next, gotchas. Lighter than a traditional roadmap but it becomes the single source of truth for build progress. I build this using the agent-instructions file from the prompts folder.

At this point, before writing a single line of feature code, I have:

• skills,

• a project brief,

• cursor rules,

• a living design system,

• a spec,

• a build plan, and

• a roadmap.

That's a lot of documents. But this is the setup that means the actual building doesn't fall apart.

Git before you build

One last thing before the first phase starts.

All of the document (brief, spec, plan etc) writing happens on main. I push that once the full document stack is ready - local main and remote main, both with full context, and no code yet .

Before starting any phase from the plan (plan.md),

• I create a new branch.

• All the vibe coding for that phase happens in that branch.

• When it’s working and I’m happy with it, I commit, merge to main (local), push online (main).

• Then start the next phase on a new branch.

Closing notes

In the end success with AI tools is about context and collaboration. These initial documents are a shared understanding that makes this possible. Quite honestly, setting all of this up before building can feel like a lot, but remember you needn’t nail it.

In fact, I don’t want to be too prescriptive, and that’s also why I treat them as “living” documents. The brief evolves as the project gets clearer, the design system grows as you build and the roadmap updates as decisions get made. The initial drag of setting everything up is real, but once it’s taken care of, “building” becomes genuinely fun. A lot of the second guessing and correcting the AI is reduced and you start “moving” with the AI tool.

I'm building a small website called "Loading..." - (work in progress - making with Cursor)
Shout out: This was inspired by Josh Puckett's - Interface Craft. His (amazing) work feels very soulful and personal.

Its built around a simple idea: what if a loading screen could mean something?

The experience opens in a warm dark room, with a small stack of cards laid out in front of you. Each card holds two things at once: a theme and an emotion. One might feel like a VHS tape on a Sunday evening. Another like a DOS terminal. Another like a film countdown for the version of yourself you promised you’d become.
When you pick a card, it doesn’t just open. It transports you. The whole world shifts into that card’s aesthetic, sound, pace, and feeling. Every card is its own little universe, built to delight first, then quietly leave something emotional behind. The interaction always belongs to the world itself, so a VHS card rewinds, a cassette clicks, a terminal waits for exit and so on.

At its heart, Loading... is about the space between cold systems and warm human feeling. It takes the language of progress bars, old machines, and nostalgic interfaces, and uses it to talk about real things: time, regret, friendship, work, memory, longing, becoming. Each card is a tiny authored moment.

I want it to feel cinematic, tactile, a little funny, a little melancholic and human.

Have a lot of cards (and worlds) to go, but here are 2 cards I completed.

PS: The sounds here of course, were added during editing. But the sounds in the website closely mimic it. Part of the website's experience are the sounds!

More to come 🙌

In the past, alignment was a slow climb. We would do the artifacts, static flows, then rough wireframes, then a high fidelity pass that finally made the thing feel real enough for stakeholders to react to.

That middle layer is collapsing now. We are skipping wireframes more often. We are jumping straight into near high fidelity prototypes that actually run. You can click through flows, hit edge cases, see empty states, watch errors happen, and test whether the experience holds together.

You are iterating on functionality, features, and behavior while everyone is looking at the same working thing. If you can build prototypes that are real enough to think with, you get alignment earlier, you make better calls, and you waste less time arguing in the abstract. Prototypes are becoming table stakes.

The prototype is the unit of alignment

Just think, a good prototype collapses weeks of alignment into a single link. It lets the team feel what the product actually does. The faster you can create that shared reality, the faster everything downstream moves.

But the catch is, as prototypes get more real, they also get more fragile. The first version is easy. At version five things start to snap. One small change and things start to break.

A very important part of design today, is not just to prototype fast but to also do it in a way that stays stable under iteration. That stability is not magic though. It’s a set of habits, constraints, and small decisions you put in early so the prototype can survive complexity without collapsing.

A prototype becomes the spec when it survives iteration

Speed is increasingly cheap. What’s not cheap is making a prototype people can trust. You want your team to treat it as a serious alignment artifact. So, the real bar is that it stays coherent after multiple rounds of change.

Quick note on what I mean by “prototype” in this post:

• End to end prototypes with real flows and edge cases, and not just one screen demos.

• Prototypes you can keep iterating on without rebuilding everything each time.

• Not production ready code, but high fidelity, functional alignment artifacts.

The rest of this piece is the set of dependencies I now treat as baseline, so my prototypes don’t drift, break, or quietly lose intent as they get more complex.

1) Using GPT as a co-pilot

To build a prototype that’s worth aligning on, you need more than a screen idea. You need clarity on the problem, the domain you’re operating in, who the users are, what they’re trying to achieve, and what constraints you can’t violate. I build them through design artifacts (user archetypes, JTBD, user flows, IA), because they force clarity.

This is where GPT becomes my co-pilot. It’s my thinking partner to create these design artifacts that shape the prototype. Those artifacts feed my PRD and specs, and more importantly, they discipline how the prototype behaves.

In practice, GPT becomes my working memory for the prototype. A place where the artifacts and decisions stay current, so every new iteration starts from the same source of truth.

I highly recommend reading this incredible piece → Build your personal AI copilot by Tal Raviv written in Lenny’s newsletter.

💡PS:
Aman Khan and Eric Xiao, in their article - Cursor for Product Managers prefer doing everything inside Cursor, especially if you want your docs and codebase in the same place.

It’s an interesting take, and while I agree, it’s just that, I still prefer ChatGPT Projects for long, iterative conversations because it fits my workflow and budget better. Mostly, this is UX preference. The principle stays the same: your artifacts need a stable home.

2) Instructions to GPT

If GPT is going to be my working memory and thinking partner, I can’t treat it like a blank chat window. I need to set the role it’s playing, the boundaries it should respect, and how it should behave when reality is unclear.

This matters because the artifacts I generate are not throwaway. They become the logic that drives the prototype.

My instruction set usually includes:

• the role (senior product designer x Product analyst x UX solution architect)

• my workflow (artifacts → prototype)

• UX and design principles

• non-negotiables

• how to handle ambiguity

• how to think (First principles → system behavior → UX implications)

• pushback and challenge

• tone and style

Subscribe now

3) Hitting context limits in GPT

Even with Projects and “intrinsic memory,” GPT can still feel unreliable especially when a conversation becomes too long, and you have to continue this in another. Because you will always hit context limit, and the thread becomes too long and heavy.

When that happens, I use a handoff prompt like this:

“This conversation has reached its context limit. Could you with great detail enumerate all that we discussed with regards to [topic] so I could input this in another conversation?
Create a document that can serve as the initial context for a fresh blank LLM thread. Your goal is to preserve approximately 90% of the conversation’s value and context while reducing its length by ~90%.
Act as an expert handing off to another expert who will help me, and set them up for maximum success, as close as possible to having been there all along. Tell the new expert what instructions or behaviors to exhibit that I’ve implicitly or explicitly requested of you.
The idea is to create the document like you are educating me.”

💡This prompt is courtesy Tal Raviv, from his article - Build your personal AI copilot, with small tweaks (almost verbatim).

I save the output as a .md file, add it as a reference in my next conversation and start from there.

And this really matters, because the “context feeding” has to be stable. Otherwise any type of context drift becomes product drift.

PS:
When I first started off with this workflow, I used to download them (the response) as .txt files and called them “memory blocks”.

4. Why meta-prompting is a super power

I was going through this article - Cooking with constraints: A designer’s framework for better AI prompts and found the premise interesting.

What the author says:

I've been building my own prompt framework, and this TC-EBC structure—Task, Context, Elements, Behavior, Constraints—has served me well. This kind of structure doesn’t just help you get better results.

For example, let’s say you’re designing a prompt for a new Figma Make that generates recipes from pantry photos.

Please build a new app that allows home cooks to take a picture of their pantry or freezer to suggest recipes. Remember any allergies or preferences. Thanks!

That’s the equivalent of throwing all your ingredients into a pot and hoping for a meal.

Now let’s try the same prompt adapted to the TC-EBC format:

• Task: Build an AI-powered meal suggestion app using pantry/fridge photo inputs

• Context: Home cooking assistant for households with dietary restrictions

• Elements: Camera input, pantry scanner, dietary settings form, meal suggestions list, recipe cards

• Behavior: User uploads photos; app scans inventory, filters by diet prefs, suggests recipes

• Constraints: Mobile-first, iOS/Android, accessible UI, supports multiple household profiles

As you can see, the TC-EBC formatted prompt is clear, scannable, and explicit about desired behavior and UI.

For this precise reason I rarely write my own prompts inside Figma Make or Google AI Studio. That creates drift. Prompting is an art and I’d rather do the thinking in GPT, get the constraints and behavior explicit, then (create and) copy-paste the prompt that is actually anchored.

I call this my two-tool workflow. ChatGPT handles reasoning and prompt authoring and the prototyping tool handles execution.

Meta-prompting sounds like an extra step, but it buys me stability.

So this is why my GPT Project and context matters. It is the living product context. Users, JTBD, flows, IA, constraints, and anchor files. When that context is available, the prompt can be precise without being fragile. My (meta) prompts more often than not have the TC-EBC structure

• instruction and goal

• context

• what exists in the UI (structure, components, states)

• how it behaves (interactions, validation, empty and error states)

• what must not change (layout rules, constraints, system decisions)

This is an example prompt I used when creating a prototype for Tenet UI Studio (This is a shortened example. The structure of the prompt is the point).

You are working inside an EXISTING Tenet Studio prototype.

CONTEXT (source of truth)
- Task: Build the Chip documentation page for USE MODE only.
- Inputs: screenshots for props/tokens + implementation code.
- Accuracy rule: reflect inputs exactly.
- Do not invent new props, token names, or code structure.

GOAL (what “good” looks like)
- Turn the current Chip page into a polished USE MODE page.
- Real code snippets, not toy examples.
- Playground controls map to the public API only.
- UI must stay stable: nav must not break, dropdowns must read correctly.
- Light/Dark mode must be consistent.

SCOPE (what you are allowed to touch)
- Modify the Chip page only.
- Keep global shell and overall layout unchanged.

PAGE STRUCTURE (order is strict)
1) Header (breadcrumb, title, 1-line description)
2) Preview + Playground (two-column)
3) Installation / Import
4) Usage examples (multiple code blocks)
5) Props table (public API only)
6) Accessibility / behavioral notes (short)
7) Do / Don’t

LOCKED VISUAL RULES
- Neo-brutalist surfaces: thick borders, hard offset shadows, warm grid background.
- Elevation hierarchy: preview strongest, panels medium, secondary light.
- Light mode must not inherit dark panels and fills.

BEHAVIOR + API GUARDRAILS
- Playground controls only what is public: selected/disabled, etc.
- If interaction states exist for demos, keep them internal or label as demo-only.

FINAL QA CHECKLIST
- Sidebar continuity fixed.
- Dropdowns have real affordance (filled + caret).
- Props table matches source screenshots.
- Preview updates live from controls.
- No Learn Mode content, no anatomy/token map/specimen matrix.

OUTPUT
Give one execution prompt for the tool.
Apply changes to the Chip page only.

💡This is an under-rated technique. The prompts I get are robust and my prototypes seldom break or drift. I do this at work (Enterprise apps) all the time, and I’ve had good success.

Creating a PRD, Roadmap, light-weight design system

Once you start executing the creation of the prototype in the tool of your choice (Figma Make, v0, Google AI Studio, Cursor etc), that tool in the chain also needs the same reality.

They all make better decisions when they have persistent context about what you are building, what is locked, and what is still in motion.

So I started shipping a small set of artifacts alongside the prototype:

• a lightweight PRD

• a lightweight design system

• and (optionally) a roadmap that acts like a living, versioned brief

The key is that these documents are feedable. They can live inside the codebase or the project folder, and the AI tool can reference them whenever it generates UI, components, or flows.

You could also treat them as live, iterating documents. If you later changed a product decision, or updated the visual (design) system, you would ask the AI tool to modify only the relevant sections. The structure stays intact, and the document accumulates decisions instead of losing them.

Even if GPT is producing meticulous prompts, these docs act like guardrails. They reduce the number of times you need to restate the same constraints, and they lower the chance of the tool making up structure on it’s own.

💡There is a whole lot of stuff you could do with Cursor - Rules, Skills, Subagents and Commands. That is maybe for another article.

A quick note from the trenches

One last thing I’ll add. Recently, for an enterprise product I’m working on, I built a fairly complex working prototype in Figma Make. Not just a single flow. A suite of features with real behavior, edge cases, and enough fidelity to make it look close enough to the product.

I kept the functionality aligned with what we’d actually want in the working product. For context, it went through roughly 20 forks and 396 prompt-level iterations.

Because the workflow had a stable context layer (artifacts, instructions, prompt framing, and feedable docs), I could keep iterating without the prototype drifting or breaking.

I can’t share the exact prompts or screens because of NDA constraints, but the point is simple. When your prototype is built to survive iteration, it actually stops being a mere throwaway demo.

A prototype becomes powerful if it can survive change without collapsing. And getting there is less about the tool, and more about the system around it.

I do a lot of 0→1 work across unfamiliar domains - working first in a consultancy, and now as a contract consultant for an enterprise product.

Most of my projects start in a domain I don’t fully understand yet.

So my design process is built around one thing: getting to clarity fast. And this is important. Because in new domains, the biggest risk is confidently building the wrong thing.

AI fits into this workflow everywhere. I treat it like a multiplier: if my context is strong, I move faster with fewer bad iterations.

So everything I do upfront is about building context first - then using that context to create artifacts, prototypes, and finally polished UI.

Stakeholder intake

I talk to stakeholders early, but I keep it light.

In new domains, early conversations are good for constraints and vocabulary - not understanding. So I’m not trying to “solve” anything in these meetings. I’m just collecting the inputs I’ll later verify through research: what they think the problem is, what success looks like, and the terms I need to go learn properly.

That’s it. The real clarity comes after I do my own digging.

Build a context container

Right after stakeholder intake, I set up a dedicated GPT Project for that product/feature.

GPT is not just for conversation. Running long threads in ChatGPT starts to drift. It gives you bad results.

I keep separate threads for each artifact (research, JTBD, feature mapping, flows/IA, PRD/spec). It sounds like overhead, but it prevents the real slowdown: losing context and re-explaining the domain every time I switch tasks.

This is the foundation. Once context is organized, everything else moves faster.

Domain ramp-up (the real work)

After stakeholder intake, I go into heavy domain research.

I take the terms and concepts I collected, feed them to GPT and reverse engineer them until I can explain them in plain language. I’ll do a lightweight competitor scan, and I’ll mine YouTube transcripts from adjacent products, (again) feed this into GPT so it helps me understand how people in the space think and talk, extract patterns, workflows, and pain points.

This is one of my biggest speed advantages: GPT turns weeks of “slow ramp-up” into a few focused hours/days.

Recently I went to the extent of creating a separate GPT project for domain research itself, to get me up to speed with everything in that domain.

Subscribe now

Problem framing

Once I’ve ramped up on the domain, I write a problem statement.

Not a fancy one - just what’s broken, for whom, and why it matters.

User archetypes

The goal isn’t to create a “persona deck.” I want to define who the system is really for, using what I learned from domain and competitor research, product constraints / scope and the problem statement

How I use GPT here

I use GPT to draft archetypes fast, but with strict constraints:

• keep it to a) goals, b) daily responsibilities, c) pain points

• avoid long lists

• don’t invent anything

• if it’s uncertain, label it as an assumption

This helps me move quickly without turning it into fiction.

The check I run (so GPT doesn’t hallucinate)

After it drafts archetypes, I ask:

“Is this backed by our research or are we assuming it?”

“Mark what is grounded vs inferred vs unknown.”

“What evidence would confirm/deny this?”

That step is the whole point. I’m not taking GPT at face value.

JTBD + Needs (the bridge from research → features)

Once archetypes are stable, I translate them into Jobs To Be Done.

I use a strict format: “When [situation], I want to [motivation], so I can [expected outcome].”

Prompt:

Let’s create JTBD for [user type] archetype. The format of the JTBD should be:

“When [situation], I want to [motivation], So I can [expected outcome]”.

When creating each JTBD, also create a “Needs” section that would inform the type of features needed to fulfill the JTBD.

Note for every JTBD, I add a “Needs” section.

Needs are important because they naturally point toward feature categories without jumping straight into UI.

That “Needs” layer is what makes feature mapping clean later.

Why this part is fast (and still solid)

This is one of the places AI genuinely helps me move faster.

I can generate drafts quickly, but the speed doesn’t just come from “automation.”

It comes from:

• having research already in the context container

• asking GPT to stay constrained

• forcing a grounded vs assumption split

So instead of sitting for days trying to wordsmith archetypes and JTBDs, I can get to usable models quickly, then refine as I learn more.

Quick prototyping to sharpen fuzzy understanding

Sometimes as I shape features, I like to visualize for more clarity. I would take a feature from my notes, reason through it with ChatGPT, then materialize it as a rough UI. A lot of times this back-and-forth turns vague ideas into something more grounded.

Importantly it surfaces gaps in my understanding much earlier than they would have otherwise. This isn’t the “final prototyping” phase yet. This is something I do occasionally, just to visualize a feature, pressure-test an idea, and surface gaps early.

User flow and Information architecture

This is where things get interesting. I don’t have to start with a blank canvas, in fact I could get a jump start with GPT. With a lot of context already established (domain/market research, user archetypes, JTBD, feature list), I start with this prompt:

We will be creating user flows in this conversation. Please note that our user flows must be rooted in our project’s in-scope features.

I am attaching certain anchor files/images for your reference (relevant context).

I want to create user flows for [user type] for the [module]. I will give you a legend to follow:

🟦 Screen

🔷 Dialog / Modal

🟩 User Action

🟧 System Response / State

🔶 Decision

🟨 Notes

🟪 Assumptions

🟢 Open Questions

Each flow must include:

- Full step-by-step sequence (User Action → System Response → Next Action).

- States & Edge Cases (empty, loading, error, transitional).

Also, make these user flows verbose and detailed so I can easily visualize them.

Note: The anchor files could be anything that is relevant to help produce accurate user flows.

The sample response:

This is very handy.

Of course, I still go through the text and sanity-check what’s being proposed. A lot of human-in-the-loop decisions need to be made. But it’s fast and I can iterate from there.

Another advantage of this process - if something is hard to pin down or hard to visualize, I’ll paste the flow into another chat and ask GPT to generate a prompt so I can prototype the flow. I’ll paste that prompt into Figma Make and immediately visualize how the flow behaves, the happy path and the edge cases.

I usually translate these into visual artifacts in FigJam, export the flows as PDFs, and feed them into GPT to create the IA:

We will be creating the Information Architecture for [user archetype] and [user flow] in this conversation.

Please note that our IA must be rooted in our project’s in-scope features and the user flows.

I will provide necessary docs and notes. Use anchor files:
(a) from our Project folder and (b) the files I have shared here.

Legend for the IA

🟩 Screens / Visual States - All navigable screens or distinct render variants.

⬜ Groups / Tabs / Structural containers - Non-navigable sub-sections within a screen (e.g., tabs, collapsible panels).

🟧 Actions - Clickable interactions or triggers (buttons, links, CTAs).

🟪 Notes - Clarifications, constraints, or behavioral explanations (non-UI).

🟥 Open Questions - Items to confirm with stakeholders or developers.

The response ends up looking very similar to how the user flows are shaped - which gives me a jump start and helps me finish faster.

PRD, roadmap, and a lightweight design system (as guardrails)

Before I move into the main prototyping phase, I write three lightweight docs: a PRD, a roadmap, and a design system notes file.

• PRD: problem, users, scope, constraints, success criteria

• Roadmap: build order + dependencies (what gets prototyped first vs later)

• Lightweight design system notes: colours, token architecture, interaction patterns, light weight implementation notes

These .md files are fed into Figma Make/Google AI studio, so the prototype stays aligned across screens, and I spend less time correcting random UI decisions.

Prototyping

I don’t prototype by directly prompting inside Figma Make and hoping it behaves. That approach used to create drift (I most frequently use Figma Make and Google AI studio for prototyping).

I always very strictly resort to meta-prompting with the help of a two-tool workflow

a) ChatGPT handles prompt authoring (and layout logic)

I do the thinking in ChatGPT first.

That means I design the layout in text:

• spacing and hierarchy

• component rules (what exists, how it behaves, what states it has)

• interaction logic (what happens on click, validation, empty/error/loading, etc.)

Once the layout is approved in text, ChatGPT generates a deterministic Figma Make prompt.

2) Figma Make handles execution

Then I paste the prompt into Figma Make and review the output.

If something breaks, I don’t keep iterating inside Figma Make. I take a screenshot, return to ChatGPT, and ask for a rectification prompt.

That loop removes ambiguity and keeps the prototype stable across screens and iterations.

From prototype to high-fidelity UI

Once the prototype behavior is stable, high-fidelity design becomes much more deliberate.

Instead of starting from a blank canvas, I’m tracing over correct behavior and focusing purely on visual quality, coherence, and system-level consistency.

The prototype gives me a predictable map of:

• all screens I need to design

• interaction patterns (toasts, dialogs, confirmations, inline validations)

• screen variations and states (loaders, empty, filtered empty, errors, etc.)

• even small component-level behaviors that would otherwise get missed

So the high-fidelity work becomes a matter of polishing.

Important note: Production-ready UI is always done using a design system.

A note on high-fidelity (and what I’m experimenting with)

In my main client work, high-fidelity UI still happens in Figma.

After the prototype is stable, I build the design system foundations (tokens, components, patterns), and then translate the prototype screens into production-ready UI for engineering handover in Figma. That part of the workflow is still very real, especially for enterprise products where flows are complex, data is dense, and edge states are endless. Figma remains the most reliable place for me to design with intention and hand off clearly.

That said, I’m experimenting with a side project - Tenet UI Studio, where I’m skipping high-fidelity design in Figma entirely.

In that project, I’m building the design system and the high-fidelity screens directly in code using Cursor. The reason this is even possible (and worth trying) is the nature of the product: Tenet UI Studio is a documentation website for a design system I’m building. The UI is still high-quality, but the surface area is more predictable: it’s layouts, content, components, and interaction patterns - not a sprawling enterprise app full of conditional flows, heavy tables, permissions, and tangled states.

So, for me, I don’t think “code-first high fidelity” is a universal replacement for Figma, yet.

I’m still in the middle of that experiment, and I’ll write about it once I have stronger lessons (and more scars).

Related reads

• Context > Prompt: A designer’s system for an AI copilot

• Riffing With AI: My ChatGPT → v0 → Figma Workflow

• Designing behavior before code

• How I vibe-coded my 90s-game themed portfolio using ChatGPT + Google AI Studio

Subscribe now

Post #9 - Component design workflow | Post #10 - From Figma to Code | Post #11 Designing Behavior Before Code

Tenet UI Studio is the first time I’m doing this kind of work end to end, going from research to implementation without relying on high-fidelity Figma designs.

I’ve been using AI-assisted workflows at work for a while, and I also built my portfolio using a similar approach. That gave me some confidence. There seemed to be a system here that I could repeat.

But Tenet UI Studio raised the stakes for me. I’ve been designing it directly through exploration, prototypes, and code (no Figma high-fidelity mocks). That means I can’t rely on visuals to carry unclear thinking. So having a solid system in place matters before I go too far with implementation.

The rough plan has been fairly clear from early: ChatGPT as a design co-pilot, Google AI Studio for quick prototyping and iteration, and Cursor for final implementation.

What wasn’t clear was the shape of the product itself.

Was Tenet UI Studio meant to be an installable npm package, or something closer to shadcn-style copy-paste components? How should a learning layer sit alongside documentation? What does a design system actually look like when it lives in code?

I had a lot of small, foundational questions like this. I couldn’t move forward without working through them first.

Why I didn’t jump straight into Cursor

It would have been easy to jump straight into Cursor and start building. That’s tempting, especially with AI making it easy to move fast.

At this stage, too much was still undefined. I didn’t know whether Tenet UI Studio should behave like a traditional component library or more like a reference system with copy-paste patterns. I wasn’t clear on how much abstraction made sense, or how the learning layer should coexist with documentation. These weren’t details I could safely “figure out later.” They shaped the foundation.

I needed a lower-friction environment first - one where I could reason through ideas, test assumptions, mock things out, and throw them away without consequences, while the shape of the system was still forming.

Using ChatGPT as a persistent thinking space

Tools like ChatGPT or Claude are helpful for retaining and building context. ChatGPT offers a dedicated space/environment (ChatGPT Projects) to think clearly without locking myself into decisions too early. They can hold a deep, multi-layered context and effectively act as a UX co-pilot.

Before creating the project itself, I spent some time defining what I wanted ChatGPT to help me with (I talk about this in my previous articles as well - Context > Prompt and Vibe-coding my portfolio).

I started a regular conversation and gave it detailed context:

• what Tenet UI Studio was

• what I was trying to build

• what I was unsure about

• what role GPT should take

• how I wanted feedback and responses to be framed

From that conversation, I iterated on an instruction set. This wasn’t perfect on the first try. I adjusted it until it reflected how I actually wanted to think and work on the project. Once that felt right, I copied it into the Project instructions.

Feeding the project with context over time

As the project progressed, I started attaching files to the ChatGPT Project.

“Files” feature is very handy. By attaching files to a Project, I give GPT a curated, evolving source of truth it can keep referencing every time I spin up a new thread.

Files included:

• research notes

• user archetypes - (FigJam → PDF)

• JTBD - (FigJam → PDF)

• Information architecture (FigJam → PDF)

• rough plans and outlines

• PRD drafts

Whenever I created a meaningful artifact in a conversation, I fed it back into the Project as a file. Over time, this became growing knowledge base that GPT could reference consistently.

Subscribe now

Instead of reminding ChatGPT what we had already discussed, I could start new conversations assuming shared context. That made it easier to:

• explore specific questions in isolation

• sanity-check decisions against earlier thinking

• avoid contradicting myself without realizing it

In practice, I spun up separate conversations for different pieces of the work:

• separate threads for research and framing

• another for user archetypes and JTBD

• another for feature mapping

• another for IA

• later, threads focused on specific concepts, doubts, prototyping

Each conversation stayed focused, but all of them pulled from the same underlying project context.

This let me move between areas of the system without losing continuity. I could pause work on one thing, come back days later, and still pick up where I left off.

Prototyping behavior before committing to code

Once I had a rough feature map and IA, I realized that feature lists and diagrams weren’t enough.

I could describe features in text, but I didn’t yet understand how they would behave. The fastest way to surface that gap was to visualize the features as actual screens and flows. I needed to see things.

From feature lists to behavior

Feature mapping and IA helped me understand the scope of the product, but they didn’t surface interaction complexity. The fastest way to close that gap was to visualize features as actual screens and flows.

Using quick prototypes to sharpen fuzzy understanding

As I shaped features and the IA in ChatGPT, I started visualizing each feature alongside that thinking.

I would take a feature from my notes, reason through it with ChatGPT, then materialize it as a rough UI. Once I had something concrete, I’d take snapshots back into ChatGPT and iterate again.

Some features didn’t survive this loop. Others changed shape once their behavior became visible.

This back-and-forth turned vague ideas into something more grounded.

Importantly it surfaced gaps in my understanding much earlier than they would have otherwise.

Freezing intent before prototyping

By this point, my IA and feature list were reasonably stable. I condensed all of that thinking into two documents:

• a Tenet-PRD.md that forced me to articulate the product’s intent, users, mental model, feature boundaries, and non-goals

• a Styleguide.md that outlined the high-level visual direction - colour, typography, and spacing rhythm

These weren’t final documents. Rather they were context anchors. Their role was to make sure that both my own thinking and the tools I was using stayed aligned as I moved forward.

I placed these files in a docs/ folder and used them as inputs during the prototyping phase.

Along with the .md files, I also created an instruction set for Google AI Studio. Without this setup, the prototype would drift or hallucinate. With it, the outputs stayed aligned to the system I was trying to build.

Committing to a prototype

I didn’t try to prototype the library with all components. Instead, I documented just one component - the Chip component, in depth.

That was enough to understand how the core ideas behaved: the playground, the learning views, the parity checks, and how tokens showed up across layers. Alongside this, I also built a few auxiliary pages like Foundations, Get Started (installation), and About to see how the system held together beyond the component playground.

For execution, I leaned on the two-tool workflow I usually resort to.

• Design, reasoning and prompt authoring happened in ChatGPT.

• Execution and refactoring happened in Google AI Studio.

Through this process, one clarification became clear. Tenet UI Studio worked best as a reference system - something you read, inspect, and copy from, rather than an installable npm package or a traditional component library.

Pushing the prototype

After that, I went a bit further than strictly necessary.

Out of curiosity, I spent time polishing the prototype. Nothing fancy though.

I also created multiple forks along the way. Having checkpoints made it easier to experiment without fear of losing work.

By the end, I had around fifteen forks of the same prototype. Each one represented a moment where the system felt coherent enough to move forward again.

Freezing intent before moving on

Once the prototype stopped changing in fundamental ways, it felt safe to move on to implementation in Cursor.

Closing notes

This workflow has been interesting largely because it’s shifted how I think about making things. Static artifacts are good at showing structure, but not always behavior.

Working this way moved everything closer to being dynamic. Ideas stopped living as diagrams and started showing up as interactions. When something was unclear, it didn’t stay abstract for long. It surfaced visually, in behavior, or in the friction of trying to explain it to the tools I was using.

In theory, I could probably do most of this directly inside Cursor. Over time, that may even become the default as tools get better. But for this project, having a GPT co-pilot outside of the implementation environment mattered. It gave me a space to reason, question, and discard ideas without feeling like I was already committing to code.

The split workflow - thinking and throwaway prototypes on one side, implementation in Cursor on the other, simply felt more comfortable at this stage. It let me explore without consequence, then switch modes once intent had stabilized.

I don’t see this as a settled answer. It’s more an open question I’m still sitting with. This is also my first time using Cursor seriously, and there’s probably room to collapse parts of this workflow into a single tool over time. That’s something I want to experiment with.

For now, this approach helped me build enough clarity to trust the next step. From here, the work shifts to execution.

Related reads

• Crafting a semantic colour system: Fixing the colour chaos, one semantic variable at a time

• Post #3 (Design System Chronicles)- Organizing colour variables in Figma

• Post #5 (Design System Chronicles) - Semantic tokens (colour) in action

Subscribe now

Related reads

• Building for efficiency and usability: A Case Study on Component Design

• Crafting Components with Subcomponents and Nested Instances

Subscribe now

Lately, I’ve been spending my time building Tenet UI Studio.

The first nine posts in Design System Chronicles was about how I built Tenet UI - a design system in Figma.

Phase 2 is the next chapter of that journey → taking the same system and translating it into code.

The goal is simple (and slightly uncomfortable).

Tenet UI has tokens, components, variants, states, all neatly structured. Now I want to understand what that system actually looks like when it exists in code, not just on a canvas. And while doing that, I want to layer in a learning experience for designers.

I’m treating Tenet UI Studio as a learning experiment in a few directions at once.

• I’m building the foundations and components directly in code. This is not as a production framework, but as reference-quality implementations.

• Each component comes with copy-able code snippets that can be dropped into real projects.

This has been my way of slowly getting a hang of what a design system really means in code - how tokens flow, how components are composed, how states are handled, and all of that stuff.

Quite honestly, this has been tough. There are obvious knowledge gaps for me here. But that’s the point. This is my way of slowly getting a real handle on what a design system actually means in code.

A core idea I’m exploring is a split between two modes:

• Use mode - when you just want to copy a code snippet of the component and move on

• Learn mode - when you want to understand how the component works under the hood

Tooling

Tooling has played a big role in making this exploration possible.

• ChatGPT has been my design co-pilot, helping me think through structure, sanity-check decisions, and reason in systems. I don’t know how to code, so I’ve also leaned on it heavily to answer silly questions and help close knowledge gaps.

• Google AI Studio has been useful for visual direction and quick mockups.

• Cursor will be where the real implementation happens (that part is honestly a little scary). And I plan to use Figma MCP inside Cursor to build components with proper Figma ↔ code parity.

Visually, I’m keeping things light and fun for v1 - leaning into a neo-brutalist direction inspired by Gumroad.

Right now, this is intentionally a small, low-stakes project. I’m starting with a light v1, learning as I go, and seeing where it leads before deciding how far to take it.

I’m quite excited actually as I’ll be building, breaking, learning, and documenting this journey.

Cheers!

Subscribe now

We were building multiple enterprise products in parallel - different clients, timelines, and designers rotating in and out of projects. Each project had some foundations, some components, and enough structure to ship, but this approach led to fragmented systems, inconsistent outputs, and inefficient workflows.

This is a common problem especially across consultancies, agencies and freelancers simply because of how work functions. Multiple clients over time, multiple designers touching the same product, and very real delivery pressure.

And that is why, I was tasked with building and maintaining a design system in my consultancy - a shared system that could support multiple enterprise products, stay consistent as different designers used it, and still adapt to the unique needs of each client project.

Having a shared design system solves a lot of problems. Workflow becomes efficient. Also there is faster delivery, more consistency, less reinvention and all of that stuff. But there is also the hard part which is helping designers use it effectively in real projects. Which, in practice, means design system designers need to be intentional about how the system is structured, and other designers need clarity on how to work within it.

💡Let me be clear…

I’ll use the term “design system” throughout this article, even though a lot of Figma community “design systems” are closer to a UI kit - which includes foundations, design tokens/variables/design decisions, component library and documentation in Figma.

Whether an organization pairs this with partial or full code parity is not the focus here. This article is specifically about the designer workflow inside Figma.

Where things get tricky

Consultancies, agencies, freelancers and even small design teams in startups or product companies, in practice usually take one of two paths.

• Build a Figma design system over time and work toward code parity with engineers.

• Start from an existing UI kit - something like Untitled UI or the Simple Design System and layer their system/decisions on top of this.

Either ways, designers need to know how to use the design system effectively.

Design folks generally know what a design system is. There’s no shortage of content on the internet about building one from scratch. But using an existing Figma design system, navigating its constraints, understanding what to touch and what not to, and making practical decisions under real deadlines is a different problem altogether.

Subscribe now

When there are designers using the system, a familiar set of questions crop up.

• How am I supposed to add my brand colors to the UI kit for my product?

• Can I tweak this component, or should I duplicate it?

• Is it okay if I detach this?

• Does this custom component live in my project (module) file, or in the design system?

• How do I cascade changes from the Master Design system to the Project Design system?

This applies to both,

• design system designers tasked with creating a system and

• designers using the system in their day-to-day project work.

This piece is about the practical side of using a Figma design system in real work. If you’ve ever opened a design system and thought, “I know this exists. I’m just not fully sure how I’m supposed to use it”, this article is for you.

Getting started

There are differences in how a Figma design system is used across consultancy/freelancing versus in-house product teams. Since most of my experience comes from consultancy work, I’ll anchor the examples from that perspective.

Consultancy setup

In a consultancy (inclusive of freelancing/agency), a design system typically needs to support multiple client projects.

In this setup, I usually work with what I call a Master Design System (MDS). The MDS acts as the source of truth. It contains the foundations, design tokens / variables / rules, component library, and documentation.

This Master UI kit might be built internally from scratch, or it might be based on a publicly available UI kit like Untitled UI. Either way, this is the system that defines the core decisions and is often the one translated into code.

The Master Design System is intentionally flexible. It supports multi-theming, multiple component variations, and a broad set of patterns that can work across projects.

Project Design System (PDS)

Don’t directly use the MDS. For every new client or product, I would duplicate the MDS. That duplicate becomes the “Project Design System (PDS)”.

The PDS is:

• scoped to a single product,

• the source of truth for that product,

• and the place where branding, theming, and project-specific adjustments live.

This allows designers to start with a robust system immediately, without rebuilding foundations for every new project.

Once duplicated, the PDS is published as a library and used by the actual product design files (screens, flows, modules).

💡An important implication

Because the PDS is a duplicate, changes made later to the MDS do not automatically cascade. If something is improved in the Master Design System, those changes need to be reflected manually in existing PDS files.

This is intentional. Each PDS represents a stable snapshot tailored to a specific product. Automatic cascading would introduce unexpected changes into live projects.

Duplicate → Publish → Use

Once the MDS is duplicated,

• Rename the PDS clearly to match the product.

• Publish the PDS library.

• Use the PDS library, not the MDS, in your project files.

Note in the example below - Tenet UI (a personal design system I published to the Figma community) is my MDS which I duplicated. The duplicated file (PDS) - in this case “Tenet UI (duplicate)”, is the one I publish.

In my example, the PDS (Tenet-UI duplicate) is renamed “RedStack Design System”.

💡 Note

When working with a Master Design System (MDS) and multiple Project Design Systems (PDS), there’s one mistake that designers might do.

It’s tempting to simply copy-paste components or instances from the MDS directly into your project files.

Here’s what actually happens when you do this:

• The pasted components continue to inherit properties from the Master Design System (they don’t adhere to the local theme and rules of the project).

• They do not respect the local design decisions made in the Project Design System (PDS)

• Any changes you make at the project level won’t behave the way you expect

This is never what you want. Project files should only consume libraries from the PDS. The MDS should stay “upstream” and untouched by product work.

💡In-house product teams (quick note)

In in-house product teams with a single product, this MDS → PDS split is usually unnecessary.

There’s typically one design system, and that system is published and used directly.

However, for design system designers in product companies, understanding this consultancy model is still useful. It forces clarity around:

• what should be customizable,

• what should remain stable,

• and how to design systems that others can adapt without breaking.

Manipulating variables/design tokens

For the branding and visual language of a product the Project Design System (PDS) should be adapted by manipulating variables, mostly “primitives”.

I’m not going to re-explain variables here, but it helps to understand how any system has been set up before changing anything.
I have a "Design System Chronicles" series where I have written in depth about creating a design system - right from foundations to component manipulation. I recommend going through them, if need be.

The first thing I recommend doing is opening the variables panel in the PDS and understanding how the system is set up:

• which variables are primitives,

• which are semantic,

• and which ones are intended to change per project.

In Tenet UI, for example:

• color primitives define the raw palette,

• semantic color variables reference those primitives,

• typography follows a similar primitive → semantic structure,

• numbers (spacing, radius) are usually primitives and rarely change.

The biggest advantage of this setup is that, in most cases, you only need to change primitives in the Project Design System to adapt the system to a product. Components and semantic mappings usually remain untouched.

This of course, is the overarching principle. But,

1. you could change or introduce new semantic or component specific variables if the project requires it,

2. change the values of a semantic variable. In Tenet UI bg/brand/default = brand 600. Maybe your project demands it to be brand 500. This differs between projects, more specifically with the type of colour palette generated.

Hence its important you assess the needs of the project, understand how the variables in the PDS have been setup and then manipulate them as needed.

Working with components in real projects

At times, designers feel that working within a design system restricts creativity and leads to cookie-cutter or templated outcomes. In practice, this usually isn’t true.

Most of the visual character of a product comes from decisions around spacing, layout, borders, corner radii, typography, colour, and iconography. All of these are already adjustable within a well-set-up Project Design System. The system isn’t preventing customization.

Instances are not where changes should happen

You can make small adjustments at the instance level. Width and height changes are usually fine. Content changes are expected. But the moment a change needs to be repeated, relied upon, or shared across screens, it no longer belongs in an instance.

Any meaningful change should happen in the main component, inside the PDS.

Making changes the right way: component → publish → update

Once a change is made to a component in the PDS, it needs to be published.

Once published, you update the library in your local project or module file. That’s it. This loop sounds obvious when written down, but it’s one of the most commonly broken workflows I’ve seen in real projects.

Don’t create custom components unless you actually need to

Another common issue designers run into is assuming they need to create new components too early.

Take a card component as an example. In Tenet UI, the basic card ships with size variants and a set of properties that control structure and content.

At first glance, it might feel limiting. In reality, most designers haven’t spent the time to explore what those properties can already do.

For more complex components, this takes patience. You need to inspect the component, understand the props, and see what combinations already exist before deciding it doesn’t fit your use case.

Apart from cards another common example could be the header or navigation component. Maybe your project needs six menu items, but the component supports only five. Before creating something new, it’s worth understanding why that limit exists and whether the component can be extended safely.

In a consultancy catering to many different projects, you cannot have a design system that could have all possible combination of variants needed to cater to your project. On the flip side, such a design system would be flexible enough to give you a good number of variations.

Hence it becomes important to know the variations that are possible to rule out the need for creating a custom component. If the variation genuinely belongs in the system, you have two options:

• extend the existing component by introducing a new property, or

• create a new component that clearly represents a different pattern.

Once that decision is made, the workflow stays the same. Make the change in the PDS, publish it, and update your project files.

Working with atoms instead of forcing complex components

Some patterns are inherently complex. Tables, side navigation, headers, dense lists. Even when a design system provides these components, manipulating them at the instance level can feel painful.

In those cases, it’s often easier to work with the building blocks or “atoms” that were used to create them.

Let me give you an example.

At work, I have had a designer tell me he never used the table component in our system. Instead, he preferred using the table atoms directly to build what he needed. That feedback shaped how I approached tables in Tenet UI.

Rather than shipping a rigid table component, Tenet UI exposes flexible table atoms.

Data cells with strong variant support.

These atoms can be assembled as rows or columns, depending on how a designer prefers to work. The pattern stays consistent, but the construction is flexible.

The same idea applies to side navigation.

Instead of relying on a single, heavy side-nav component, you can often rebuild it quickly using flexible atoms like “list items”. When those atoms are well designed and property-rich, assembling a navigation becomes faster and easier than fighting a locked component.

This approach won’t look the same in every system. The specifics depend on how your system is built. But the idea holds. When a complex component becomes hard to manipulate, step down a level and work with its parts.

Closing thoughts

The goal of this article was to show how to use and adapt a design system sensibly in real projects, especially from a consultancy or agency perspective, since that’s where most of my experience comes from.

In a follow-up piece, I plan to go deeper into common “why can’t I do this?” questions pulled directly from Reddit and Figma community discussions, with more tactical, tutorial-level answers.

For now, if this article helps you approach your next project with a little more clarity and a little less frustration, then it’s job done!

For the longest time, my newsletter quietly doubled as my “portfolio.” All my case studies live here, my writing lives here, and it felt good enough. I never felt a strong need to build a glossy, dedicated portfolio website.

But looking at some portfolios designers have carved for themselves, I can’t help but think of it as being more than just displaying work. It’s a chance to express personality. It’s a small playground where you can show the kind of creative chops you don’t always get to use in product work.

So with the AI tools now available and the experience of having done AI assisted prototypes at work, why not try “vibe-coding” my own portfolio and see where it goes?

Except, I figured, this was going to be a very different kind of challenge. Up to now, all my AI experiments have lived in the “vibe-design” bucket - fully working mid to “highish” fidelity prototypes that help teams understand flows, UX decisions, and behaviour. Those are functional tools inside my design workflow.

A portfolio, on the other hand, needs something else entirely.

• It has to be expressive.

• It has to be high fidelity.

• It needs to feel crafted.

• Micro-interactions have to be intentional.

• And it has to exist as a real, deployable website, not just a prototype running in a sandbox.

🎥Playing around with my portfolio website

Don’t start directly in the AI tool (v0/Bolt/Lovable)

A lot of AI design tutorials begin the same way → “I want to build X. Let’s open v0/Bolt/Lovable and just prompt it.”

You describe the website or app, hit enter, and the tool spits out layouts. And you continue to iterate from there. It’s fast and it gives you something to react to, but it’s shallow. That approach works for quick UI explorations, but to build anything real with structure, you require a system.

A system helps you have a structured, repeatable method of generating artifacts without compromising thinking or quality.

Over the past year, I’ve built a lot of AI-assisted prototypes, some of them complex, with multi-role flows, behavioural logic, and sometimes high-fidelity UI. And here’s the catch - these prototypes survived because I established context first and only then executed inside the AI tool. They usually break badly when you don’t.

Tools like ChatGPT or Claude are phenomenal for this. They can hold a deep, multi-layered context and effectively act as a UX co-pilot. This becomes invaluable when you step into execution tools (v0/Lovable), because you’re no longer prompting from scratch.

I wrote about this in depth here: Context > Prompt: A designer’s system for an AI copilot.

Tools like v0, Lovable and Google AI Studio are incredible at what they do and they even allow instruction sets, which help a bit.

You can add additional context inside these tools through things like a roadmap.md or a /guidelines folder in your project (and I’ll get to that soon).

But the heavy lifting, the reasoning, the design direction, the architectural thinking is something I’ve learned to do outside the execution tool, before the code begins.

And that is the core principle behind something I call “The Two-Tool Workflow”.

(Side note: Tools like Cursor or Google Antigravity have powerful features like “Plan” mode, which can hold even richer context.)

📖 Read next: 
- Context > Prompt: A designer’s system for an AI copilot
- Riffing With AI: My ChatGPT → v0 → Figma Workflow

The Two-Tool Workflow that powered this build

The two-tool workflow on a high level is simple.

• Design, reasoning and prompt authoring happen in ChatGPT. It’s my UX co-pilot.

• Execution and refactoring happen in the AI prototyping tool (Google AI Studio in this case).

This workflow is powerful, especially when building complex apps with numerous flows. This approach has worked consistently for me at work. For a portfolio website however, the approach is the same although a lot simpler (there are lesser UX artifacts).

ChatGPT

Never have isolated conversations. If you do, you’ll constantly need to re-feed context This can become cumbersome.

ChatGPT “Projects” solve this.
Think of them as folders that remember everything:

• instructions

• files

• your design philosophy

• and every conversation inside the project

I created a Project called “Portfolio website”. Ideally I also want to feed an instruction set, so there is some type of direction for ChatGPT to follow.

To do this, I started a conversation and gave detailed context as to what my goal was and how I want the instruction set to be (additionally I attached my CV as well).

Prompt:
I want to create a fancy design portfolio with the help of AI tools and get it deployed/published. I already have a portfolio at www.fourzerothree.in. Right now fourzerothree is a newsletter side project where I have a section for my case studies. 
It works very well, but I want to get creative with this portfolio of mine. I am thinking of 3 tools to create this with: 
- Google AI studio 
- v0 by Vercel 
- Figma Make 
I actually want to get very creative. I want it to be like a 90s pixelated computer game - think “Dangerous Dave”, “Prince of Persia”, Wolfenstein 3D”. You would have to help me build it. 
I am going to start a Project for this here. But first I need a solid (super solid) instruction set so that you know what to do and how to go about doing stuff. The instruction set should be comprehensive.
Remember I am a designer and the instruction set for you should include 
- The AI’s role 
- The expected tone 
- Your design principles 
- non-negotiables 
- How to handle ambiguity 
- How to retain context 
And add some more if you deem it fit. 

The prompt is detailed, and I talk to ChatGPT as if I am telling a friend of mine what I want to do and “how I want his help”.

I get the instruction set → read it → iterate → and finalise it. I then feed this instruction set to my Project.

Subscribe now

Conversations

All my conversations relating to my portfolio lived within this Project.

Creating a plan

Ideally I would want to create a roadmap for the product.

For web apps one would ideally start with research → and then move on to UX artifacts → UI layout → build prototype. I could go on, but this is for another article.

For “websites”, it’s simpler and a bit different.

a) Foundation
I would want to define it’s foundation - stuff like business goals, target audience, value proposition, tone/voice and all that jazz. This was straight forward. This was my portfolio and I wanted it to be creative, playful and themed like a 90s PC game.

b) Structure
Based on all of this, I would want to create the structure (website pages and sitemap for the website). I knew what pages I wanted. This was a no brainer.

c) Content
Next, I would want to create the content for each page. This I had to brainstorm with ChatGPT.

d) Layout
The content decides the UI layout (brainstorm with ChatGPT).

Point (d) is important. Content decides the UI layout!

I could directly jump to deciding the content and planning the layout for the pages.

Creative UI direction

Before I jump to creating the content and UI layout for the pages, I need to establish some sort of “UI direction” I want to head in.

You could say this is something akin to wireframing but done in high fidelity with the styling, branding and the creative direction. This was primarily because I wanted it to be themed like a 90s PC game and I was starting on a blank canvas.

Added some inspiration snapshots.

At this point I was still exploring possible shells and layouts. That’s where this iteration loop kicked in.

1. Generate layouts in ChatGPT

2. Pick the most promising one

3. Convert it into a Google AI Studio prompt

4. Generate UI in AI Studio

5. Review output

6. If broken → send screenshots back to ChatGPT

7. ChatGPT refines the prompt

8. Repeat

This loop continued until I found a direction I genuinely liked.

This is an example of my prompt in GPT where I picked a promising layout and asked GPT to author a prompt to build it.

Why generate prompts in ChatGPT?

1. ChatGPT generates prompts that humans simply cannot.
   My prompts could be short, incomplete, non-specific and lacking in structure.

2. ChatGPT can enforce design-system discipline.
   All rules stay intact → Typographic scale, colours, shadows, components, shell layouts.

Google AI Studio

Instructions

Once I got a direction and narrowed down on a shell for the entire website, it was time for me to take things to the next stage.

I treated Google AI Studio the same way I treated ChatGPT. A teammate that needed orientation.

I made ChatGPT write a full instruction set that covered:

• core intent

• overall style and aesthetic direction

• interaction philosophy

• responsive (mobile and tab breakpoints) and accessible behaviour

• creativity guidelines

• tone and personality

• what to avoid

• content type to expect

• summary

so I could feed this in Google AI Studio.

💡Pro tip

When prompting ChatGPT for an instruction set, I kept my prompts intentionally loose, without being too specific. Since GPT is my design partner and with the several conversations I have already had, GPT is smart enough to give me a detailed instruction set that pretty much covers all that I/we discussed. The magic lies in being a “Human in the loop”:

read → add/remove/iterate → finalise on the instructions.

The Roadmap.md file - A persistent context layer

One of the most powerful things I did in this entire project was create a file called MVP Roadmap.md and drop it into a /docs folder.

This file became kind of the core memory of the whole build.

This document held:

• the theme strategy

• the IA structure

• what was already built

• what was locked

• what still needed work

• which decisions were temporary vs final

• the aesthetic constraints

• the scope of the MVP

• what “done” actually meant

Let me reiterate, as to why authoring your prompts in GPT can be a game changer. Once I had the file in my folder, I asked GPT:

The prompt that was authored:

You are assisting in building a professional design portfolio with a subtle 90s game-inspired interface.  
A file called “MVP Roadmap.md” exists inside the /docs folder.  
This file is the SINGLE SOURCE OF TRUTH for project status, decisions, information architecture, and build progress.

Your responsibilities:

1. Always read and reference `/docs/MVP Roadmap.md` before generating any output.
   - Treat it as persistent context.
   - Assume it contains the current vision, structure, IA, and completed work.

2. Anytime I say:
   - “We’ve locked this”
   - “This is final”
   - “Let’s update the roadmap”
   - “Consider this done”
   - “Record this”
   ...you MUST update the roadmap file accordingly.

3. When updating the roadmap:
   - Modify only the relevant sections.
   - Keep the structure clean and chronological.
   - Add a new section called “Changelog” at the bottom if needed.
   - Never remove important context unless explicitly told to.
   - Always maintain markdown formatting.

4. The roadmap must always reflect:
   - What is already built (pages/components/content).
   - What visual/styling decisions have been locked (colors, typography, themes).
   - What remains to be done.
   - Which phase we are currently working on (v1.0 shell, v1.1 visuals, etc.).

5. When generating UI, page variations, copy, or prompts:
   - Align with all details currently in the roadmap.
   - Do NOT contradict locked decisions inside the document.

6. If the roadmap becomes outdated or inconsistent:
   - Proactively notify me.
   - Suggest updates for accuracy.

7. All new instructions, locked decisions, and design choices should automatically flow back into `/docs/MVP Roadmap.md`.

In short:
- Use the roadmap as context.
- Keep it updated.
- Treat it like a living project document.
- Ensure all future outputs are consistent with it.

This is a crazy detailed prompt that did a lot to help Google Studio understand what it’s responsibilities as far as the updating and following the “roadmap” was concerned.

The exact purpose the roadmap served

It acted as a:

1. Single source of truth - IA, theme, decisions, progress.

2. Contract - If something was marked “locked,” the AI couldn’t revert or drift.

3. Guardrail - Even when I wiped a context window, the roadmap had the AI in the correct direction. I could fork different versions and still maintain context.

4. Chronicle - Doubled as a project log as I moved page by page.

Forking Projects

Every major stage became a save point:

• Initial layout working

• Breakpoints stable

• Theme switching functional

Because you’re experimenting continuously. And sometimes trying to execute an idea leads the entire project into a ditch.

Forking gave me psychological safety.

The Canvas Editor: Annotation > Prompting

The canvas editor in Google AI Studio is great!

You can literally:

• write/draw on the canvas

• draw arrows/rectangles

• add comments

• add text

and push/add them to chat.

Using Excalidraw to create annotated images

When making changes inside of Google Studio, I used excalidraw to create annotated images to inform Google better. Surprisingly, this worked really well.

Wrestling With Breakpoints

I generated breakpoint-specific prompts (with GPT) with strict constraints and pasted them into Studio. Then I verified everything manually.

It wasn’t glamorous. I did a lot of testing and iterated several times.

What this produced

By the end of this, I had:

• A 90s-style portfolio shell with draggable “windows” and a character sheet.

• A stable layout across desktop + mobile (after lots of breakpoint wrestling).

• A working deployment at portfolio.fourzerothree.in that now replaces my “newsletter as a portfolio” setup.

Closing Thoughts

By the time I had the shell, the instruction sets, the roadmap, and the workflow in place, the rest of the build honestly doesn’t need a dramatic story.

The point I want to make here is about the system I had in place to build this the scaffolding, the workflow, the thinking behind vibe-coding something real.

I think this is part of the building that nobody talks about. People assume the hard part is the prompting. It’s not. The hard part is creating the structure that keeps the prompts moving in the right direction.

So that’s where I’ll leave this piece.

RedStack is a remote execution platform where one user (Creator) defines structured procedures (workflows) and another user (Executor) carries them out on-site, step by step. The platform ensures that a workflow designed remotely can be executed safely, consistently, and with a clear audit trail even when the creator isn’t physically present.

Note: This is a redacted case study. Designs, terminology and data have been intentionally modified to respect confidentiality.

a) User archetypes

At its core, the platform supports five personas:

• Creators, who design structured workflows.

• Executors, who execute these workflows on-site.

• Three admin roles, who manage resources, billing, and system-wide governance.

b) Product evolution

The initial version focused on validating the core loop: a Creator uploads a workflow, an Executor performs it, and the system captures the results.

Once the loop proved meaningful, the platform expanded into a multi-role ecosystem. Phase 2 introduced new admin portals, extended Creator responsibilities, and added modules for materials, billing, and system governance - areas that didn’t exist in the first version.

2) Design Challenge

RedStack wasn’t a typical “one-user, one-flow” product. It was a multi-role ecosystem with many moving parts, each with its own portal, rules, responsibilities and each one influencing the others.

Main challenges:

a) A dedicated portal for each role needing needed tailored UI, navigation, workflows, and error states. Keeping these portals distinct yet coherent was a core challenge.

b) Complex, branching user flows.

c) Dense, data-heavy UI with complex components.

d) A deeply interconnected product ecosystem. decision in one portal directly shaped what another user could or couldn’t do.

e) Tight timelines.

🎥 Prototype preview

Before getting into the workflow itself, here’s a quick look at the functional prototype I built. The video demonstrates interactions in 2 screens including different states (Empty, loader, error).

This prototype became the source of truth across product, engineering, and design discussions. It grounded every conversation in real behaviour instead of abstract wireframes, and helped us reason about functionality with much more clarity.

Due to NDA constraints, this demo includes only two representative screens. All UI, data, and branding have been intentionally modified for this case study.

3) Choosing an AI-Augmented approach

Given the scale and pace of RedStack, I needed a workflow that let me move fast without losing accuracy. With the design challenges I had traditional UX workflows wouldn’t keep up.

An AI-augmented workflow became the most practical way to work through this complexity. I had already experimented with it during Phase 1, but Phase 2 is where it evolved into a foundation for the entire design process.

Using ChatGPT as a UX co-pilot

I used ChatGPT as a structured UX co-designer for research and UX. This allowed me to:

• work faster across large modules with many states

• connect dots across roles, rules, and flows

• digest dense product logic and turn it into clear UX behaviour

• maintain accuracy at scale

• turn UX decisions into working prototypes quickly

Working prototypes

For a product of this magnitude, static wireframes would fall behind. With 5 user portals (including a mobile app for the Executor), dozens of states and numerous screens, the design process needed something more dynamic.

⚠️Early workflow where things broke!

My initial approach was to generate layouts using ChatGPT and then build the full prototype inside v0. It looked promising but quickly ran into practical issues:

• v0 hallucinated layouts during regeneration.

• components broke unless prompts were extremely precise.

• stateful UI (tables, logs, conditional screens) sometimes got flattened or lost.

• small changes frequently caused flows to break or disconnect.

I made progress, but maintaining stability required multiple forks and constant patching. This wasn’t scalable.

The root issue for me, was my prompts in v0. I truly believe this makes or breaks your prototype.

✅ The Fix

I switched to Figma Make and adopted a new pattern: a two-tool workflow where each tool had one clear responsibility.

Instead of designing inside Figma Make (with me doing the prompting and iterating inside Figma Make), the prototype is created through a controlled two-step pipeline:

1. ChatGPT handles all prompt authoring

   I designed layouts in ChatGPT - spacing, structure, component rules, interaction logic. Once the layout was approved, ChatGPT generated a deterministic Figma Make prompt.

2. Figma Make handles execution

   I pasted the prompt into Figma Make and reviewed the output.
   If something broke, I returned to ChatGPT with a screenshot and asked for a rectification prompt.

   This loop removed ambiguity and kept the prototype stable.

This way I ensured Figma Make received instructions exactly the way it wanted it to. Hallucinations dropped dramatically and prototypes remained stable across screens and iterations.

4) From Prototype to High-Fidelity UI

Once the prototype behaviour was stable, moving into high-fidelity design became much more deliberate.
Instead of starting from a blank canvas, I could trace over correct behaviour and focus purely on visual quality, coherence, and system-level consistency.

How the prototype shaped the UI work

The prototype gave me a predictable map of every screen, interaction, and edge case I needed to design. It clarified the following:

So the high-fidelity work became a matter of polishing, not guessing.

Design system application

From here, I translated each prototype screen into production-ready UI using the design system:

• Applied DS tokens for colours, spacing and typography

• Created complex reusable components – tables, editable tables, multi-step modals, filters, side nav, cards

• Ensured cross-portal coherence - five personas, but one unified product feel

The scale of the UI work

Across four portals, I designed around 100 screens, including state variations and supporting dialogs.
Because the behaviour was locked in early, the UI stage was fast, predictable, and required far fewer revisions.

5) What this workflow achieved

1. Faster delivery across a massive surface area
   I designed ~100 screens across four portals (including all state variations, dialogs, loaders, filtered empties, confirmations, errors) with far fewer iterations than a traditional wireframe-first approach.

2. Clearer product conversations

   Every discussion across product, engineering, and design was grounded in real behaviour. The prototype removed ambiguity early, especially around edge cases, rules, and logic.

3. Better alignment across a multi-portal ecosystem

   Dependencies between roles (different user archetypes) became easier to map, validate, and design for.

4. A reusable internal workflow

   The “ChatGPT (UX and UI layout) → Figma Make (execution)” loop evolved into a repeatable method I can now apply to complex systems work going forward.

6)Reflection

This project fundamentally reshaped how I work.

A five-persona, rule-heavy ecosystem with tight timelines would have been extremely difficult to tackle with a traditional wireframe-first design workflow. By treating AI as a structured co-designer, I was able to move fast without sacrificing depth.

The biggest shift for me was realising that behaviour-first design unlocks clarity. Once behaviour is correct and testable inside a prototype, everything downstream - UI, components, states, edge cases become predictable.

This experience has changed how I approach large systems going forward -
anchor behaviour early, ground discussions in real interactions, and use AI tools intentionally to scale clarity, not replace craft.

Recently I cam across Tom Johnson’s tweet on X that got me excited:

For Tom, the loop is “Make → Canvas → Make.”

For me its more of a ChatGPT → v0 → ChatGPT loop to get things close to what I want, and then go to Figma to refine it to high fidelity.

The idea is the same, but my stack leans heavier on GPT for structure and v0 for riffs.

💡Here are some other more comprehensive pieces I’ve been writing on AI & Product design:

• A Context-First design process for 0→1 work (With AI)

• How to build prototypes that don’t drift

• Designing behavior before code

The “ChatGPT → v0 → ChatGPT” loop is akin to making the wireframes, albeit this is faster, you can see how your flows work right in front of you, get your edge cases and error states sorted and keep it in the mid-fidelity.

Let me elaborate:

High-Level Flow

1. User flows + IA in ChatGPT → bring them to life in FigJam

2. UI layout (text based) in ChatGPT

3. Use v0 to bring these layouts to life

4. Keep “riffing” and forking in v0

5. Debug with ChatGPT

6. Back to v0

7. Export to Figma using the “HTML to Design” (Figma) plugin

Step-by-Step walkthrough - the guts of the workflow

1. Flows & IA in GPT

Instead of starting in Figma, I start in GPT. I get it to spell out user flows, edge cases, error states, and all the awkward stuff like empty/loading states.

GPT is great at exhaustiveness. It doesn’t forget to ask: “What happens if the user cancels halfway?” or “What if the server fails?” (If it doesn’t I can ask for it). It helps me catch those details upfront.

For me, this is like having the entire “canvas” already in my head before I even start drawing.

2. Loose UI Layout in GPT

Once I know the flows, I’ll ask GPT to sketch a UI structure in plain text. Top to bottom, section by section: layout details, content blocks, patterns, components wherever necessary.

I’m not asking GPT to make it pretty. Think of it as my blueprint. It keeps me from staring at a blank page in v0 (which is half the battle) and start from scratch.

3 and 4. Bring them to life and keep forking in v0

This is where the riffing happens. I paste the layout into v0 and let it generate a first pass. Then I start forking:

• Trying different layouts.

• Shuffling components.

• Seeing variations side by side.

The magic of v0 is speed. I can throw around 3–4 versions in minutes.

Subscribe now

5. Problem-Solving (Debug) with GPT

When I get stuck (which happens a lot), I don’t fight v0. Instead, I snapshot the code or layout, paste it into GPT, and say: “Here’s the problem. Fix it.”

GPT becomes my debugging partner. It gives me solutions, tweaks the code, gives me great prompts to fix the problem in v0, and helps unblock me. Meanwhile, v0 stays my riffing playground.

6. Back and Forth (GPT ↔ v0)

This is the core loop.

• Fork in v0.

• Hit a problem.

• Debug in GPT.

• Feed it back into v0.

• Refine, fork again.

7. Export HTML → Figma

Once I have something semi-stable, I use HTML-to-Figma (or similar plugins) to bring the designs into Figma. This step is where I bridge from AI riffing → designer craft.

High-Fidelity in Figma

Finally, polish mode. Now it’s pure Figma:

• Setting up tokens.

• Fine-tuning typography, spacing, grids.

• Refining components for reuse.

At this point, v0 has done its job. It helped me avoid the blank canvas problem. Figma is where I bring the final design home.

Trade-offs and mitigation

Forks in v0

In step 4, where I keep forking in v0, I can get stuck in a vicious loop where things keep breaking, and instead of exploring ideas, I am firefighting errors.

My fix → when this happens, I don’t force v0 to handle the whole flow. I generate screens one-off, so each page works in isolation. Later, I stitch them together if needed.

v0 costs money

Riffing in v0 with prompts costs money. Every broken fork = more tokens burned. The trick is to lean on GPT as your debugging partner. Be precise with prompts, fix issues cleanly, and only loop back into v0 once you know what you’re testing.

Closing thoughts

Now, half the time it feels like duct-taping three tools together. But honestly, that’s also the point: designing is not a straight line. For me, “ChatGPT + v0 loop” and back to Figma for high fidelity is enough to keep ideas flowing, avoid the blank canvas freeze, and get to high fidelity faster than I ever could before. Until the tools catch up, this messy loop is how I ship.

That task turned into a crash course in AI-augmented design. Sure, I started by testing prompts to get decent outputs but the real challenge came when I tried to push through long conversations. The context window just couldn’t keep up. Long conversations meant hitting context window limits.

This problem was obvious when I started exploring. The challenge, I then realized was carrying over context across conversations. If I wanted GPT to act as a “copilot”, I couldn’t just prompt it once and hope for the best.

So, while prompts get all the attention, it’s actually context engineering that makes or breaks an AI-augmented workflow. Context, by far, is the only way you’d get consistent, high-quality outputs across the full design process.

💡Here are some other more comprehensive pieces I’ve been writing on AI & Product design:

• A Context-First design process for 0→1 work (With AI)

• How to build prototypes that don’t drift

• Designing behavior before code

Clever prompts are not enough

This piece isn’t about “prompts”. What I want to put forward instead, is the scaffolding around those prompts, the way you hold context so that GPT builds on itself instead of drifting off, no matter how polished (or sloppy) your actual prompt is. That’s been the real breakthrough in my work.

My process has been messy, full of dead ends and restarts. And that’s taught me how to set GPT up so it doesn’t drift, how to carry decisions across conversations, how to keep the AI acting like a teammate instead of a vending machine. For me, it’s closer to asking a friend for advice - the more context you give them, the better the advice you get.

This piece is my two cents about the scaffolding I’ve stitched together to make AI a reliable copilot in the design process.

Subscribe now

Context engineering

Mitigating long chats

Like I said, the first and very obvious challenge was getting around long chats. Long chats drift and break. The only way around this is to start a new one, but you hand over context so you can continue where you left off.

This is a lot easier with “Projects” in ChatGPT (Claude too, has Projects and Gemini has an equivalent called “Gems”) but I’ll get to this later.

💡In this piece, I’ll focus on “Projects” in ChatGPT

When I first started and was still figuring my way out in ChatGPT, I used to prompt GPT to give me a summary or context of our current conversation so I could input that into another window to carry on where I left off. Additionally I used to tell ChatGPT to store the context in global memory.

This then evolved to this prompt,

I want to start [fill this up accordingly] in another window. Give me a detailed prompt with all the context of this conversation, so I could carry it over to the next window. Also give this to me in a downloadable .txt file.

These downloadable txt files with the context served as memory blocks. I could use these blocks in any conversation to help GPT remember what we had done.

Using “Projects”

The design process is long-winded. It rarely moves in a straight line, and it almost always spans multiple artefacts: research → user archetypes → JTBDs → flows → IA → UI layouts. Each stage has its own mess of decisions, and together they form the scaffolding of a product.

That’s exactly why I lean on Projects. In my workflow, each artefact becomes its own conversation inside a Project.

Projects are basically smart workspaces. Think of them as folders that remember everything from instructions, files, and your chats.

Instructions

Set detailed instructions about who GPT should be and how it should respond. Kind of like what values and behaviours we want it to have. This is a great way to bypass the need to reiterate this in every conversation.

Instructions could get tricky, I mean, how good is an instruction? What I usually do is, open a window and give a brain dump of who I want GPT to be and the kind of instruction set I expect.

Notice its an unorganized brain dump. ChatGPT would then give me a detailed instruction set which I could feed into my Project.

Memory

By far the most useful feature is the memory that comes with Projects. Your project is always self-contained. So even if your global memory can’t hold more, the Project itself carries context through its stored files, instructions, and chats. This becomes extremely handy in preserving context of all our conversations within a Project.

Files

Talking about files - PRDs, artefacts or relevant documentation could always be fed on a Project level.

By attaching files to a Project, I give GPT a curated, evolving source of truth it can keep referencing every time I spin up a new thread.

In practice, this has been huge. After finishing a round of research, I’ll often drop the summary deck or notes file (remember memory blocks?) straight into the Project. When I move on to the next conversation, GPT already has that research context at hand without me pasting walls of text again.

Think of files as the long-term memory of a Project. Conversations may come and go, but the files stay, grounding AI in the reality of the work. And because I can update them over time, the memory evolves with the project.

The best part about this is, it can “connect the dots” across everything I’ve given it. For example, it knows the research that shaped the JTBDs, the flows that grew from those JTBDs, and the UI layouts that emerged at the end. This has proved especially useful when there are complex product specs.

Branching in GPT

What if you’ve had a very long conversation and want to revisit an idea midway? I manually copy-paste a “snapshot” of the conversation into a new chat and keep going. I still do this, but lately the “branching” feature in ChatGPT could be an antidote for this.

Also there are times I have spun up a conversation for the sake of particular artefact and randomly gone on a tangent. I run out of window bandwidth and have to unnecessarily create another conversation to continue.

I can fork a conversation at exactly the point I want to explore, and GPT carries the Project memory and files with it. This kind of feels a lot closer to how I’d actually ideate in real life.

Carrying context into AI design tools

The importance of context doesn’t end inside ChatGPT. It carries forward when you move into AI-powered design tools like v0, Magic Patterns, or Lovable.

What I’ve found useful is to carry over my memory blocks into these tools. I paste the context we’ve already built together in ChatGPT - PRD, the flows, IA, sitemap. That way, v0 or Magic Patterns aren’t guessing blind; they’re working with the same background as my copilot.

This back-and-forth loop has become a big part of my workflow:

1. Draft layouts in ChatGPT.

2. Carry the context into v0 to render the prototype.

3. Bring the output back into ChatGPT for critique and refinement.

4. Iterate until the design actually feels right.

Closing thoughts

Looking back, what started as an experiment at work has changed the way I design. Every project I take on now runs through this lens: how do I carry context from across (AI) conversations and even into the tools I prototype with?

Its a shift every designer can make. When you treat AI like a teammate and set it up with the right scaffolding, the results stop feeling like one-off wins and start becoming repeatable. That, to me, is the real unlock for designers.

Starting with simple sketch/comic-style videos, it grew into a full learning platform - complete with a structured curriculum, revision notes, and interactive question banks, used by a global community of students and educators.

From Pathology to Product

I was an Oral Pathologist and Assistant Professor at a teaching hospital (prior to pivoting to Product Design). I knew firsthand how overwhelming dental education could be: dense textbooks, expensive resources, and endless exams.

There was clearly a gap. Students needed a resource that was visual, lighthearted, and accessible anywhere. And I wanted to build it as a business.

This wasn’t a side experiment. From day one, the intent was to grow HackDentistry into a global platform for dental learning. YouTube was simply the first brick in that system.

Designing with Constraints

With no technical background, the most practical starting point was YouTube. It gave me a way to build an audience while figuring out how to eventually deliver a full learning platform.

As the YouTube channel grew, I started creating structured study material and bundling content into courses.

My first attempt to build the platform was on WordPress, but it quickly broke under scale.

I pivoted to Thinkific, a no-code tool that helps build learning platforms.

No-code meant I could:

• Build fast, without engineering support.

• Focus on structuring the learning journey, not the backend.

• Spend my time designing pedagogy and experience.

The result was a platform that gave students the ability to:

• Track their progress in a personal dashboard.

• Navigate lessons easily with a clear left nav for navigating lessons and canvas at the right to study/read/watch videos.

• Revise actively with interactive quizzes.

• Learn consistently with hand-drawn visuals and diagrams.

Constraints forced me to keep things simple. But in hindsight, that simplicity made the product work. It had a clear structure, predictable flow, and engaging content.

Wearing Every Hat

HackDentistry wasn’t a big team. It was just me and a close friend collaborating with me on curriculum design, shaping question banks, brainstorming ideas, and taking care of the heavy lifting of creating other specialty content early on.

Otherwise, I was handling:

• Product & platform → creating and managing the no-code build, structuring course bundles, and keeping the site running.

• Content creation for Oral Pathology → producing 100+ sketch/doodle-style videos, detailed notes, and transcripts.

• Marketing & community → growing a YouTube channel to 129K subscribers and a newsletter to 4,000+ readers.

• Business & Operations → running the business, handling payments, customer support, and global learners.

It was scrappy, hands-on, and often overwhelming, but it taught me how to think like a founder and a designer.

Global Reach, Real Impact

HackDentistry started out focused on undergraduates preparing for exams. it grew beyond that, reaching learners in 40+ countries, and adopted by a wider audience.

• Interns → balancing hospital rotations with postgraduate entrance prep.

• Postgraduates → using the videos to simplify advanced oral pathology concepts.

• Professors → integrating the material into classrooms to teach their own students.

What Didn’t Work

HackDentistry reached thousands of learners, but it struggled to scale as a business. The key lessons for me as a designer were:

• Friction kills trust → I faced repeated issues with payment gateways. While I fixed them each time, the interruptions eroded user trust. Payment failures showed me that reliable flows are very much a UX problem.

• Manual doesn’t scale → In the later years, I just resorted to granting access manually after payments were done (to mitigate my payment gateway woes). This created a poor user experience and led to churn.

• Burnout → Running everything solo eventually caught up with me. The constant grind left me with little energy to push HackDentistry forward and became one of the reasons I pivoted toward product design.

  

HackDentistry worked as a product. Students loved the content and structure. But as a business, it didn’t scale like I expected it to.

My First Design School

HackDentistry ran for eight years, and in hindsight, it was my first crash course in product design.

• I didn’t call it UX research, but I was uncovering student pain points.

• I didn’t call it IA, but I was structuring dashboards and navigation.

• I didn’t call it systems, but I was building consistent formats for videos, notes, and quizzes.

Design is not just pixels. Its also about systems, constraints, and outcomes. For me, HackDentistry isn’t just a business story, it was the foundation of my design career.

PS: I also explored a mobile design concept as a personal exercise. It wasn’t shipped, but helped me practice prototyping, theming, and design system integration → Designing a learning platform for busy dental students - a mobile design exploration

Act I - Setting the Stage

At our consultancy, we were building multiple enterprise products in parallel. Each project spun up its own mini design system - more like a style guide than a scalable system.

Designers often worked in silos, creating their own components and patterns, and applying colors and typography inconsistently. The result? Inconsistencies across products, duplicated work, and slower delivery cycles.

We needed a shared foundation, a system to unify, scale, and speed up every project we delivered.

Note: This case study shares my design process and key learnings from building an internal design system in my consultancy. They are not tied to any client projects, brands, or confidential company information.

Act II - The Problem

Our design process wasn’t broken, but it was slowing us down.

1. Fragmented systems - Each project had its own lightweight design system, but none of them were built to scale.

2. Inconsistent outputs - Designers working in isolation produced mismatched results in colors, spacing, and component anatomy.

3. Inefficient workflows - Without shared foundations, turnaround times stretched longer than necessary.

4. Reinventing components - Designers repeatedly rebuilt same components for different products from scratch.

5. Missed opportunities for reuse - Components that could have been shared across projects stayed siloed in individual files.

Act III - The Challenge

I was tasked with building a design system that could serve multiple enterprise products. Honestly, I had never done this before, and I wasn’t sure if I could pull it off. But it was a fun challenge.

The challenge wasn’t just about creating components. It was about creating a system that could scale, stay consistent as different designers used it, and adapt to the unique needs of each client project.

Act IV - The Foundations

If the system was going to scale, the foundations had to be solid. That meant starting with design tokens.

I focused first on colors and numbers. Colors were structured with a semantic → primitive → hex referencing model.

Semantics made tokens reusable across projects, while primitives allowed us to swap hex values depending on the brand or theme.

To keep things consistent, I set up a clear naming convention:
element/semantics-hierarchy-state

This broke down tokens into predictable, scalable parts so designers didn’t have to make ad-hoc decisions every time.

Typography variables came later, but the core idea was the same: set rules once, and let them ripple through every component.

The result? A foundation flexible enough to support multiple products, but strict enough to guarantee consistency.

Act V - Components

Once the foundations were stable, the real challenge began: components.

At least 50 components were mapped and listed, starting with the most common components we needed for projects.

I then dug into how each one should be built: balancing constrained components (for simplicity) with flexible ones (so it could be used for multiple use cases).

Every component was designed with:

• Slots and sub-components for flexibility wherever possible/needed.

• Clear anatomy so any designer could pick it up and use it.

• Code-aligned properties so developers could consume them easily.

Act VI - Feedback & Outcomes

Designers found it easy to set up workflows. Changing a primitive value in the tokens file updated colors across the entire system. Components could be reused, extended, or built upon instead of recreated from scratch.

The outcomes were clear:

• 2× faster turnaround - projects moved quicker because the heavy lifting was already done.

• Consistent outputs - Designer A and Designer B could work on different modules and end up with the same look and feel.

• Reduced duplication - common components were no longer rebuilt from scratch.

• Less miscommunication - with shared tokens and rules, there was no confusion about colors, spacing, or typography.

For the consultancy, this meant faster delivery for clients and less design debt across projects.

Act VII - Governance

The system wasn’t perfect. As it grew, new challenges appeared:

• The Figma file became heavy and harder to manage.

• Component bloat made the library feel overwhelming.

• Some components were almost too flexible, which added complexity instead of reducing it.

• Variables needed some getting used to.

• Design system organization wasn’t clear:

  • Once we publish the Design System library for a client project, do we continue to build (any new) components in library itself?

  • Building/modifying components in the main Design system file (library), publishing/updating it, then updating the main Module file to keep up with library updates was painful.

To keep the system usable, governance became just as important as design.

I ran an onboarding workshop for designers, helped them understand how it could be used effectively, helped them troubleshoot issues, and collected feedback regularly.

Over time, I shipped a leaner, more optimized version of the system:

• made variables more leaner (cut back of variables that were rarely/not used),

• variables were made more organized,

• components were updated to be leaner and less complex so it was easier to use.

This balance between power and usability was key. A design system only works if people actually use it.

Act VIII - Reflection

In a consultancy, design systems aren’t just about scaling a single product. They’re about creating a foundation that can flex across multiple clients, timelines, and teams.

The biggest wins came from structured tokens and reusable components. They gave us speed, consistency, and clarity at scale. But I also learned that too much flexibility can overwhelm, and governance is what keeps a system alive.

Designing the system is only half the job. Sustaining it is where the real impact lies.

I used to think the hard part was choosing/creating the color palette. And yes, it’s a good start. But if the goal is to build a system that scales, we can’t stop there.

So, a) creating colors is one side of the spectrum and b) tokens - those neat variables in Figma or code are the other.

What connects the two is a crucial middle process. And this is where the real DNA of a color system gets written.

It’s in this middle layer where we answer the questions that actually make colors usable:

• What’s the default background, and do we need lighter, darker, or inverse variations?

• Which shade of grey becomes body text, and how does it hold up across surfaces?

• If blue-600 is our brand primary, does it still pass accessibility on a 100-level background?

This “middle process” isn’t just a bridge to variables/tokens. It’s where accessibility, usability, and the overall logic of how color behaves in your product are established. Think of it as the set of design decisions that form the foundation of a scalable color system.

And this isn’t just a personal workflow. Mature design systems recognize it (I learnt from mature systems). Carbon talks about “layering models”. USWDS defines theme tokens that abstract color families into accessible, flexible roles. Orbit bans dark shades as backgrounds.

None of them stop at “here are our colors.” They all define the invisible choices that sit between palette and tokens.

Surfaces & Background Layers

The first thing I decide after creating a palette is how my surfaces behave. Because surfaces aren’t just “background colors” - they’re the stage where everything else plays out. Text sits on them. Components stack on them. Accessibility succeeds or fails on them. If surfaces aren’t defined, everything else in the system becomes guesswork.
So, in order to map out my background layer (surface) colours,

a) I try to understand how I would want my surfaces to behave.

b) I roughly try to predict the components I might end up using most often.

Surfaces (greys)

When I talk about surfaces, I’m mostly talking about neutrals - the deepest layers of the UI. Think of the page or screen itself, the canvas that other components sit on.

Take this screen for example.

The page is bright white, with components blending into it and using borders or elevation to separate themselves from the “base” page or screen.

Have a look at these screens.

The page is a subtle grey. The components may or may not have borders or an elevation but they pop by simply being lighter than the background.

Now this depends on the product you are working on and different products handle this differently.

📖 Read next: 
- Designing colour palettes that work for every project
- Crafting a semantic colour system: Fixing the colour chaos, one semantic variable at a time

Carbon (IBM) talks about “layering models”

Colors in the neutral gray palette are layered on top of each other to create depth and spatial associations. The layering model defines the logic of how colors stack on top of each other in a UI.

• In the light themes, layers alternate between White and Gray 10 with each added layer.

• In the dark themes, layers become one step lighter with each added layer.

So you can see where I’m coming from. Its very important to understand how layers stack one on top of each other in the UI. And so this is how I look at it.

When it comes to greys (neutrals), I usually pick 3 shades going from light to lightest. I would use this for pages or elements/components that reside on the page. The shades could be the same or slightly different for each category (pages and components).

After I have created the palette, I literally stack one on top of each other, eye ball it, tinker if necessary and pick.

Dark mode works the same way, only inverted: the deepest layer is the darkest surface, and each level up gets progressively lighter.

TLDR - first set of greys for surfaces → light, lighter, lightest (I also always choose a dark shade that acts as an inverse to the lightest shade).

Surfaces (brand and semantics)

Its a lot more harder to fathom the different shades of brand and semantic colours I might need for the project. When I started out in design, I would just map out the bare minimum variables or tokens that may be needed for a project and build as I go.

Over time however, I believe there are a bare minimum set of colours one might need. The way I went about establishing this was to actually quickly create (“wireframy”) components, fill them with colours from my palette and understand what I may need. Or even better, just pick (copy-paste) components from existing Figma UI kits and play around.

A lot of your components would just require greys but lets take a few examples.

I might require “default” buttons and tonal buttons. Tonal buttons have a much lighter shade than the default ones. Similarly I might need badges that have the same shade as the tonal buttons.

Subscribe now

I also have alerts and selected states.

These have the lightest shade of the respective semantic or brand colour. Lighter than my tonal buttons or badges.

So maybe I might need 3 shades of these colours starting from default/base to a much lighter shade and lightest.

TLDR → sets of brand and semantic colours → default, light, lightest.

Foreground (text & icon)

Foreground (greys)

For neutrals, I usually define three roles: primary, secondary, and tertiary. Unlike surfaces, these start with the darkest shade for primary text, then step lighter for secondary and tertiary.

How do I decide which shades? I start visually stacking them on my surfaces to see if the difference feels clear, then confirm with contrast checks. Accessibility is non-negotiable here. Every foreground shade has to pass WCAG contrast ratios across all surface levels. The only exception is disabled states.

I usually let this pass because WCAG 2.1 says:

User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements.

That’s why I allow a “disabled grey” that falls below contrast thresholds.

Foreground (semantics)

The same logic applies to brand and semantic colors. My “default” is usually the 500 or 600 shade, strong enough to hold its own against light surfaces. But I also define light and lightest variants. These are critical when semantic colors need to appear as text or icons on darker backgrounds, or when used in badges, alerts, and tonal components.

Default, light, and lightest - this set usually covers the practical cases without overcomplicating the system.

Theme Tokens (USWDS’s Approach)

Interestingly, I found validation in USWDS’s approach, where they formalize it into what they call theme tokens.

Each color family has seven possible lightness grades, from lightest to darkest, though not every family needs to include a color at each grade. Some grades may be set to false in your project’s theme settings. The default USWDS theme palette does not use every grade for every family. The primary and secondary families also have a vivid grade available.

- Theme color tokens

In other words, they start with a full spectrum, but intentionally don’t use every single shade. Instead, they enable only the grades that make sense for the project’s theme.

This is almost exactly how my own workflow has evolved into. Instead of trying to define and maintain every possible shade, I decide upfront which ones matter.

💡The takeaway here is important: you don’t need every possible shade in your palette to make a color system. What you need is a consistent, role-based selection that can serve as a foundation.

Interaction States

Once surfaces, text, and semantic roles are in place, the next layer of decisions is around interaction states. Hover, active, focus, and disabled are essential for usability. But they don’t need to be overcomplicated either.

In my workflow, I usually extend a simple logic.

• Hover → a lighter or darker step from the base color.

  So if the lightest (surface) needs a hover state, its one step darker than that - Grey-100 is the base shade and 200 is hover. Same logic to any shade.

• Active/Pressed → a stronger shift, often two steps.
  The pressed state is usually 2 steps away from the base or 1 step ahead of hover - Brand-600 base would have a Brand-800 as pressed (Brand-700 as hover).

• Disabled → a de-emphasized neutral that intentionally falls below accessibility thresholds.

• Focus → a clearly visible color (often brand or accent) with guaranteed contrast (usually a 600).

This makes the transitions predictable and not subjective. You don’t need a special hover color for every button or a dozen unique active states. What you need are clear, predictable rules that apply system-wide.

Decisions → Variables/Tokens

At this point, it’s worth stepping back to see how these middle-layer choices flow into tokens. To me, variables have some sort of a foundation because of the decisions we make in the middle. Otherwise they become just arbitrary names with no shared logic to back them up.

But once you’ve defined surfaces, foregrounds, semantics, interactions and the logic of why you may need certain colours in your system, variables almost write themselves.

A few examples:

Surface or background

The variables base-weak (lightest), base (lighter) and base-strong (light), reflect the colours I may use for the deepest surface, the pages.

Variables surface-primary, surface-secondary and surface-tertiary reflect the colours that are used for the components.

Brand colour examples

The variables I may need are backed by the decisions I made in the fuzzy middle layer.

The point is simple: variables/tokens aren’t the starting point - they’re the outcome. They’re the visible layer of a much deeper set of design decisions.

💡 Tenet UI is a Figma design system/UI kit that I built as a personal project, available in the Figma community. The UI kit has a robust and lean semantic colour system (design tokens/variables) established. Visualizing the variables in the UI kit could give you a better sense of how the variables have stacked up.

Closing thoughts

It’s easy to think of a color system as just palettes and variables/tokens. Pick some swatches, name some variables, and move on. I’ve done this in the past, and never knew what or how many variables I needed. I built them as I moved forward and the result was inconsistencies and a lack of a clear plan in creating variables.

The work that makes a system scalable happens in the “middle”. That middle (invisible) layer is where accessibility gets baked in, where consistency is enforced, and where a palette actually turns into a system.

And that’s the point - don’t stop at colors. Define the decisions in between. Because that’s where the DNA of a colour system really lives.

#1 - Design DNA - A playbook | #2 - The "invisible" middle layer of colour systems

Design debt is inevitable. You can delay it, ignore it, or patch over it. But sooner or later, it catches up. The only real way to keep it under control?

Think in systems. Design for scale.

And when I say “design systems,” I’m not just talking about the heavyweight, multi-layered setups you see at big companies. I mean “systems” in the truest sense - any structure that reduces debt, keeps things consistent, and lets you scale design without losing your sanity.

I want to start a new series on building design systems. I’m calling it Design DNA.

No, I’m not here to help you build the polished, enterprise-level systems you see in big companies with dedicated DS teams (I’d love to get there someday, though).

This is about practical systems you can create right in the middle of real product work. The kind that help you keep design debt in check, maintain quality, and grow without overcomplicating everything.

I want to talk about foundations that make a system work. Then I want to dig into how you can create your own Figma design system or UI kit from scratch, and maybe also how to get the most out of an existing UI kit if you don’t have the time (or budget) to build one from zero.

We’ll break down what goes into a design system, how it’s built, and why it’s worth your time even if your team is small, your deadlines are tight, and your files are already a little messy.

I want to write about all of this because they’re the kind of problems you and I are probably dealing with right now.

Why I’m writing this

Design DNA is my way of filling a gap I wish I had when I was starting out. Most design system content lives at the extremes:

• At one end, there’s high-level theory that sounds nice but leaves you wondering where to start.

• At the other, dense documentation for teams who already have DS engineers, governance models, and years of polish.

If you’re in the middle, building as you go, trying to ship product without drowning in inconsistencies, you’re mostly on your own.

I know, because I’ve been there.

That’s why I’m writing Design DNA. To share the wins, mistakes, and patterns I’ve learned along the way and to learn in public (especially around documentation and governance).

Subscribe now

What to expect

Honestly, it’s still a little abstract right now. My plan is to start with the foundations (duh, obviously) tokens, color systems, typography, all the stuff that sets the stage. From there, I’ll probably move up to components, documentation, and governance (hopefully?).

I can’t promise perfect-world advice. But I can promise practical, example-driven guidance you can plug straight into your workflow. That, I’m confident about.

Cheers and see you on the other side of Design DNA 😃

The hack, though, is getting that one “data-cell” component just right, and then using that to build your entire table. I had to figure out how to build that one “atom” so it had me covered. In essence, what we’re doing here is going outside-in.

Break the table down into either rows or columns and then break those down into individual data cells.

Creating a data-cell

This is where the real work is. Tables can hold many different types of data and each of those could demand a slightly different layout or style.

Different contexts could demand different types of data to be displayed.

So the idea is to create a data-cell component set that:

• Covers most common types of variations we may need.

• Handles different states.

• Scales to different sizes.

Subscribe now

There are 2 common ways to approach this:

1. All variations as separate components.

2. Lean component with packed properties.

All variations as separate components

Personally, I don’t prefer this (though it’s not wrong). It feels bulky. Too many components cluttering my panel. But it’s very straightforward, and a lot easier for designers to pick the variant they want from the variants dropdown.

This becomes a problem when you start stacking variations:

• States: default, hover, selected, disabled

• Styles: colored or striped

• Sizes: small, large

Your component set explodes!

Lean component with packed properties

This is my preferred approach. It’s much leaner. You can achieve a huge number of variations with a compact set of components.

The downside? You might end up with a bit of a “prop-soup” in the properties panel, potentially overwhelming you. But honestly, I feel this is a small learning curve and can be handled with a little practice.

As you can see in the image below, this setup includes both size and state variations (including the “colored” variant). This helps me create a very flexible component set with just 15 variants.

The variations are packed with the help of component properties.

Example video - Manipulating properties to get different variants

Building rows or columns

Once your data-cell is ready, you can use it to build either rows or columns. Honestly, I started off building tables as columns, but I now prefer rows. Either way, it’s just a matter of preference.

Many UI kits, design systems and designers treat the “data cell” as the atomic unit of the table. They often include pre-built column components that use data-cell instances, so you can just drag in the whole column and go.

In Tenet UI, I kept only the data-cell as the main component. Rows and columns are up to you, which made things more flexible and customizable. This was actually a piece of feedback I got from teammates (at work). They liked having that level of control.

Example table 1

Example table 2

Closing thoughts

Tables can feel overwhelming, but its about cracking the logic behind building a single, robust data-cell. So, focus on that atomic unit. Build it well, and your tables will practically build themselves.