Forem: Tolulope Abolarin

Closing the Designer-Implementation Gap: A Framework for Building Design Competency in the Age of AI

Tolulope Abolarin — Mon, 13 Apr 2026 09:50:08 +0000

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.

Optimizing Web Performance: How Lazy-Loading Spline Assets Took Our Build From 30 to 90 in Lighthouse

Tolulope Abolarin — Tue, 18 Nov 2025 12:50:09 +0000

When Performance Breaks Before Launch.

We faced a common problem while developing a client site at our design agency recently. Everything looked great, but the site was really slow.

We tested it and found that the initial load time was more than 6 seconds. The Time To Interactive was more than 5 seconds, while the page scored 30/100 when we ran it through Lighthouse. Unfortunately, Lighthouse didn’t tell us what was actually causing it, so it was left to us to figure it out.
We finally found the cause of the problem after digging into DevTools performance traces. The site was loading Spline assets before the user needed them and they were blocking the main thread.

Lazy-loading those assets changed everything and this is what we got:

| Metric | Before | After |
| ----- | ----- | ----- |
| Initial Load Time | 6.5s | 1.2s |
| Time to Interactive | 5.3s | 0.8s |
| Largest Contentful Paint | 5.7s | 0.6s |
| Lighthouse Score | 30 → 90 |  |

The load time went down to 1.2s, TTI down to 0.8s and the Lighthouse score shot up to 90. All these without changing the design or doing any compression hacks.

Context: The Build was Visually-Heavy

The project relied on multiple 3D spline embeds to create an immersive interface. Spline is great for this because it renders scalable 3D vector scenes. It’s also lighter than video or traditional 3D assets and allows live interaction. But it comes at the cost of having the runtime and model file load immediately unless you do something about it.

That means:

The Spline script executes before the page is interactive
The model downloads before the user scrolls to it
The browser treats it like a high-priority resource
Main thread execution stalls

Which is exactly what we saw in DevTools.

The Problem: Lighthouse Didn’t Flag the Bottleneck

Lighthouse gave us red flags about “render-blocking resources” and “heavy JavaScript execution”, but no mention of Spline directly.

It was difficult to spot because the asset didn’t show as an image or a large file. It came up as JavaScript execution time buried under other events. Only a DevTools Performance trace made it easier to see the problem:

Spline script was loaded in <head>
Execution started before anything else rendered
The main thread was blocked for hundreds of milliseconds
All meaningful content waited behind it

The page wasn’t slow because the assets were too large. It was slow because they loaded too early.

The Fix: Lazy-Loading the Spline Elements

We already lazy-load images, so we applied the same logic to Spline. Basically, don’t load it until the user is close to seeing it.

Spline Lazy Loading Pattern

function lazyLoadSpline(container) {`  
  `const observer = new IntersectionObserver(entries => {`  
    `entries.forEach(entry => {`  
      `if (entry.isIntersecting) {`  
        `entry.target.loadSplineAsset();`  
        `observer.unobserve(entry.target);`  
      `}`  
    `});`  
  `});`

  `observer.observe(container);`  
`}

Placeholder Strategy

We used static thumbnail placeholders to stop the layout from shifting. We also used a reserved container height and applied an optional loading state. All these stopped the layout from jumping when the embed initialized.

Why Spline Flies Under the Radar in Audits

Spline assets don’t behave like images, video or fonts, which means they don’t show up under “Large Media” or “Unused JS”. They also don’t trigger obvious Lighthouse warnings. Instead, they work like a hybrid of script execution, asset streaming and GPU rendering.

This means you can only catch the issue by looking at:

DevTools Network waterfall
Main thread flamegraph
CPU/JS execution timeline

Results: Before vs After

| Metric | Before | After |
| ----- | ----- | ----- |
| First Paint | 3.4s | 0.7s |
| LCP | 5.7s | 0.6s |
| TTI | 5.3s | 0.8s |
| Lighthouse | 30 | 90 |

In the end, we didn’t have to modify the Spline assets themselves or reduce resolution. We solved what seemed like a serious problem just by delaying when the Spline assets loaded.

Lessons Learned

What We Learned	Why It Matters
Performance issues are often timing-based	Not just about file size
Lighthouse is not a full diagnostic tool	Always investigate manually
Lightweight assets can still block the main thread	Rendering work matters
Heavy visuals should never load before above-the-fold content	Prioritization > compression
Lazy loading is a performance technique, not just a UX feature	It frees CPU + bandwidth

Practical Checklist for Future Builds

Based on the lessons learnt from the problem, we’ve created a checklist for future builds.

Audit runtime-based assets, not just file sizes
Treat 3D embeds like video: load only when needed
Use IntersectionObserver for scroll-based activation
Always test on mid-range real devices, not just desktop throttling
Use placeholders to prevent layout shift (CLS)
Record a DevTools performance trace before launch
Don’t assume Lighthouse tells the whole story

Final Thoughts

Having smaller files isn’t the only thing to aim for if you want a faster website. You also have to make sure the right things load at the right time. Spline is a reliable tool for interactive web experiences, but you need to integrate it with performance in mind. All the site needed to become faster was moving from “load immediately” to “load when needed”. And we didn’t have to sacrifice visuals.

If Lighthouse isn’t showing you the real performance issue, it doesn’t mean there isn’t one. Sometimes you need to open DevTools and follow the execution timeline to find the fix.