Most design teams I've worked with have the same problem, and almost none of them talk about it directly. Their designers produce polished screens in Figma. Their engineers build working products. And between those two steps, something breaks.
I call this the Designer-Implementation Gap. It's the distance between what a designer intends and what actually ships. Every designer knows the feeling: opening a staging link and realising the thing you designed doesn't quite work the way you imagined. Spacing is off. States you never accounted for are showing up. The responsive behaviour makes no sense. The engineer did their best with what they had, but you handed them a picture of a house and expected them to know where the plumbing goes.
This gap has always existed. But AI is about to blow it wide open.
The Gap Isn't New. The Framework Is.
Design's handoff problem has been written about before. Brad Frost described a "hot potato" process where design and development pass work back and forth rather than throwing it over a wall. The Atomic Design methodology gave teams a shared vocabulary of atoms, molecules, and organisms. Dan Mall and others pushed for design engineers and collaborative workflows.
These contributions matter. But they focus on process: how teams should hand work between disciplines. What's missing is a competency model for the individual designer. The question isn't just "how should teams collaborate?" but "what does a designer need to know and do at each stage of their career to close this gap on their own terms?"
That's what the Design Competency Ladder addresses. It maps the progression from screen-level output to implementation-level ownership, and it does so specifically in the context of AI tools that are compressing the value of the earlier stages. Frost tells you the handoff process is broken. This framework tells you what to learn next so you depend on it less.
Why AI Makes This Worse Before It Makes It Better
Tools like Galileo, Relume, and even Figma's own AI features can now generate layouts and component suggestions in seconds. An average-looking interface is trivially easy to produce. That sounds like progress, and in some ways it is. But it creates a problem: when anyone can produce a decent-looking screen, the screen itself stops being the valuable part of the work.
The value moves downstream. It moves toward understanding how things actually get built, what constraints exist in code, how components behave across breakpoints and states, and how a system holds together when ten different people are building features inside it simultaneously.
If you're a designer whose work stops at the Figma handoff, this shift will quietly make your role harder to justify. Not because you lack talent, but because the bottleneck has moved.
The Design Competency Ladder
Over the past four years of working across fintech, e-commerce, and SaaS products, I've noticed that the designers who stay effective through this transition tend to follow a predictable progression. I've mapped it into four stages. It's not a hierarchy of talent; it's a ladder of operational capability that determines how much of the product outcome you actually own.
Stage 1: Screen Production
You receive a brief or user story. You produce screens. Your output is measured in pages, flows, and visual fidelity. Your tools are Figma, maybe Sketch. You hand off annotated files and move on.
This is where most junior designers start, and it's a legitimate starting point. The problem is that many designers stay here for five, eight, ten years. And the longer you stay, the more exposed you are, because AI can already do a passable version of this work in minutes.
Stage 2: Component Thinking
You stop designing pages and start designing pieces. You build a button once, define its variants, and reuse it everywhere. You think about naming conventions, spacing tokens, colour systems. Your Figma file has a components page that other designers reference.
This is a real jump from Stage 1 because it requires you to think about consistency and reuse rather than individual aesthetics. But it still lives entirely inside the design tool.
Stage 3: Systems Design
You define the rules that produce the components. You think about the relationships between elements, not just the elements themselves. You ask: what happens when this card needs to hold 200 characters instead of 40? What happens when this layout runs on a 320px screen? What does the error state look like, and who wrote the microcopy for it?
At this stage, you're no longer designing outputs. You're designing the logic that generates outputs. The distinction matters because it changes the questions you ask in sprint planning, the way you review pull requests, and the way you structure your files.
Stage 4: Implementation Ownership
You understand the medium you're designing for. You can read (and sometimes write) CSS. You know what a flexbox does and why your designer's assumption about "equal columns" doesn't work the way they imagined. You prototype in code, or use tools like Webflow to build working interfaces. Your design decisions account for browser rendering, responsive behaviour, and performance.
At this stage, design and implementation aren't two separate steps. They're one continuous loop. You ship, not just hand off.
Stage Diagnostic: Where Are You Right Now?
Before the ladder is useful, you need to locate yourself on it honestly. I've put together a diagnostic you can run against your own practice. Five questions. Answer them and the pattern will tell you where you sit.
1. What do you deliver at the end of a sprint?
If your answer is "screens" or "flows in Figma," that's Stage 1. If it's "components with defined variants and tokens," Stage 2. If it's "a spec that covers edge cases, error states, and responsive logic," Stage 3. If it's "a working prototype or production-ready code," Stage 4.
2. When engineering finds a problem during build, what's the most common type?
"It doesn't look right" = Stage 1 problem (visual fidelity lost in translation). "This component already exists but they built a new one" = Stage 2 problem (no system awareness). "This breaks on mobile / with long content / in the error state" = Stage 3 problem (unconsidered constraints). If engineering rarely finds problems because you already caught them, you're operating at Stage 4.
3. Can you open a CSS file and understand what it does?
If the answer is no, you're at Stage 1 or 2. If you can read it but not write it, you're at Stage 3. If you can read, write, and debug it, you're at Stage 4.
4. When was the last time you tested your design with real data?
If you've never done this, Stage 1. If you test with a few edge cases in Figma, Stage 2. If you systematically stress-test with extreme data (longest strings, empty states, 320px viewports), Stage 3. If you test in code against actual API responses, Stage 4.
5. How do you handle a responsive layout?
If you design desktop-first and let engineering figure out mobile, Stage 1. If you create separate mobile mocks, Stage 2. If you define breakpoint behaviours and fluid spacing rules, Stage 3. If you build the responsive logic yourself in CSS or Webflow, Stage 4.
Most designers will find they're at different stages for different questions. That's normal. The diagnostic isn't a judgement; it's a map. Look at where you cluster and you'll see where to invest next.
How the Ladder Plays Out Across Industries
The reason I frame this as a ladder and not a personality trait is that different industries demand different stages, and knowing which stage you're operating at helps you diagnose mismatches between your skills and your environment.
Fintech punishes designers who stay at Stage 1 or 2. Financial products carry regulatory constraints that directly affect UI. A payment confirmation screen isn't just a layout problem; it needs to account for PSD2 requirements, transaction state management, failed payment recovery flows, and microcopy that satisfies compliance. If you're designing these screens without understanding how the API handles state transitions, you will produce something that looks correct but breaks in production.
I saw this play out on a cross-border payments product. The original design showed a clean, single-step confirmation screen. In production, the backend required a holding state while the partner bank confirmed the exchange rate. The first designer on the project had no awareness that this state existed. Nobody told them, and they didn't ask, because at Stage 1 you don't know which questions to ask. We redesigned the flow to account for the holding state, added a polling indicator with a progress ring, and wrote microcopy that set expectations without creating anxiety. That redesign only happened because someone on the team was working at Stage 3 and knew to ask: "what are the possible states between 'submitted' and 'confirmed'?"
E-commerce creates a different pressure. The challenge isn't regulation; it's scale. You might have 40,000 SKUs, each with different image ratios, description lengths, and attribute sets. A product card designed in Figma with a perfect 4:3 image and a two-line title will collapse the moment you feed it real catalogue data.
Systems-level designers solve this by defining constraints: maximum title length before truncation, image aspect ratio fallbacks, responsive grid behaviours at each breakpoint. They design the container, not the content. And they test it with ugly data, not just their carefully curated Figma samples.
SaaS products demand Stage 4 more than almost any other sector. Enterprise software has dense information architecture, complex table interactions, keyboard navigation requirements, and accessibility obligations that are impossible to validate in a static design tool. If you're designing a data table with 15 columns, inline editing, sortable headers, and row-level actions, you won't know if it works until you build it. Figma can show you what it looks like. Only code can show you what it feels like.
Where "Taste" Actually Lives in This Framework
There's a word that comes up often in design discourse: taste. People use it to describe an instinct for what looks right, what feels polished, what separates good from great. I think the word is useful, but it gets misapplied.
Taste isn't a Stage 1 skill. Or rather, it's not only a Stage 1 skill. The most valuable form of taste operates at Stage 3 and 4, where you're making decisions about constraint systems and component behaviour that will ripple across hundreds of screens.
Suppose an AI tool generates a modal component with sensible defaults: centred, shadowed background, close button top-right, action buttons bottom-right. It looks fine. But taste at Stage 3 asks different questions: should this be a modal at all, or would a slide-over panel preserve context better? If it's a modal, what happens to keyboard focus? What's the maximum width before the content feels sparse? What's the animation timing, and does it match the rest of the system's motion language?
AI can produce the artifact. It can't make the judgment call about whether the artifact is the right solution for the context. That judgment comes from working with real users, understanding the product's existing patterns, and making a call that accounts for consistency, usability, and the specific moment in the user's workflow.
That's where taste lives. Not in making things look beautiful, but in making the right structural decision when there are fifteen reasonable options and no obvious winner.
A Practical Method for Moving Up the Ladder
If you recognise yourself at Stage 1 or 2 and want to move toward 3 and 4, here's what's worked for me and for designers I've mentored.
From Stage 1 to Stage 2: Audit your last five projects. How many components did you create from scratch that already existed somewhere else in the product? Start a personal component library and enforce your own naming convention. The discipline of naming forces you to think about reuse.
From Stage 2 to Stage 3: Pick one feature you recently designed and stress-test it. Feed it extreme data: the longest possible username, an empty state, a slow network connection, a screen width of 320px. Find the places where your design fails and document what you'd change. Do this for every feature going forward.
From Stage 3 to Stage 4: Learn enough CSS to read a stylesheet and understand what it's doing. You don't need to become a frontend engineer. But you need to understand flexbox, grid, media queries, and how browsers calculate layout. Build one small thing in Webflow or raw HTML/CSS. Rebuild a component you designed in Figma and see what breaks in translation.
The jump from each stage to the next takes roughly six to twelve months of deliberate practice. It's not about raw talent. It's about changing what you pay attention to.
What This Means for Design Teams
If you lead a design team, the ladder gives you a diagnostic tool. Map your designers against it. If most of your team operates at Stage 1 and 2, you'll see predictable symptoms: high revision rates after engineering picks up the work, frequent "that's not what I designed" conversations, and a constant backlog of design debt.
If your team operates at Stage 3 and 4, you'll see fewer handoff surprises, more productive conversations with engineering, and faster iteration cycles, because the design already accounts for the constraints that would otherwise surface as bugs.
This isn't about replacing designers with engineers or asking designers to code full-time. It's about closing the gap between intent and outcome. The closer a designer operates to the build layer, the less information gets lost in translation.
The Role Isn't Disappearing. It's Forking.
If the ladder describes how designers grow, it also predicts how the role itself will split. And that split is already happening; we just haven't named it clearly enough.
Stages 3 and 4 demand fundamentally different skill sets depending on which direction you lean. Some designers at Stage 3 become obsessed with the system itself: the tokens, the responsive logic, the component API surface, the handshake between Figma variables and CSS custom properties. Others at Stage 3 become obsessed with the decisions the system serves: which features to build, how information should be structured, what research says about user behaviour, and how to keep a product coherent as it scales across teams and geographies.
These are both Stage 3+ skills. But they pull in opposite directions, and trying to do both well at once is how you burn out.
The first path is what I'd call the Design Systems Architect. This person defines the rules, components, and constraints that produce consistent interfaces at scale. They think in tokens, relationships, and responsive logic. They work closely with engineering and often prototype in code. Their measure of success is adoption rate: how many teams use the system, how few one-off components get created, and how rarely engineering has to override a design decision. They're hired for their technical depth and their ability to design for the system's users (other designers and developers), not just the end user.
The second path is the Product Design Strategist. This person focuses on user research, information architecture, and product direction. They make decisions about what to build and why. Their measure of success is product outcomes: retention, task completion, revenue per user, NPS. They're hired for their judgment, their ability to synthesise research into product bets, and their skill at keeping a growing product from fragmenting into a mess of disconnected features.
Both paths need Stage 3 as a foundation. Both are made more valuable, not less, by AI handling screen production. But they demand different career investment. A Design Systems Architect should spend their next six months learning CSS architecture, design tokens, and versioning strategy. A Product Design Strategist should spend that time deepening their research practice, learning to run experiments, and building fluency in product analytics.
Neither path looks much like the "UI/UX Designer" job description that most of us started with. And that's the point. The old title bundled together skills that are now diverging. The designers who recognise this early get to choose their path deliberately. The rest will find it chosen for them by whatever their current employer happens to need.
This framework is my attempt to make that choice visible before it becomes urgent.
Top comments (0)