How I cut my design time in half with better workflow systems

Speed for its own sake produces sloppy design. But when you build the right systems around your practice (the kind that eliminate friction, reduce decision fatigue, and front-load the thinking that makes everything downstream easier), you stop losing hours to problems that should have been solved before you opened Figma.

Here’s exactly what changed for me.

The biggest unlock: learning how to learn a product fast

Before I talk about Figma shortcuts or component architecture, I need to talk about OOUX. Because nothing I’ve done at the tooling level has saved me as much time as learning how to rapidly understand a product at a structural level before I start designing it.

OOUX (Object-Oriented UX) gives you a framework called ORCA: Objects, Relationships, Calls to Action, and Attributes. The short version is this: before you think about screens, you map the nouns of the product. What are the core things a user interacts with? How do those things relate to each other? What can a user do with each one? What information lives on each one?

It sounds like extra work. It is extra work — at the beginning. But here’s what I’ve found: every hour I spend on ORCA saves me three hours of redesign later.

Without it, I’d get deep into a flow and realize the information architecture didn’t support what I was trying to do. I’d build a component and discover it needed to behave completely differently in a context I hadn’t accounted for. I’d hand something off and get questions from developers that revealed I hadn’t resolved something fundamental about how the product worked.

With it, I walk into Figma knowing what I’m building. The objects are the core structures of my strong foundation to build from. The attributes tell me what content my UI needs to display. The relationships define my navigation. The calls to action tell me what interactive elements I need and where. The design practically scaffolds itself.

Naming conventions: the system nobody talks about enough

I lost an embarrassing amount of time early in my career to bad naming. Layers called “Rectangle 47.” Components called “Button — new version FINAL use this one.” Files called “Homepage v3 — revised — client feedback — FINAL2.”

I don’t do that anymore.

Everything in my workflow follows a consistent naming convention — files, layers, components, tokens, CSS classes. It’s based on BEM for code and a parallel logic in Figma: block, element, modifier. A button isn’t called “button.” It’s button--primary, button--secondary, button--disabled. A card isn’t called “card.” It’s card--project, card--blog, card--feature.

The payoff isn’t just organization. It’s the cognitive overhead you stop burning every time you need to find something, hand something off, or return to a file you haven’t touched in three weeks. A well-named file is a file you can navigate without thinking. And thinking is expensive — save it for the design problems.

A design system that actually works for you

I’ve built design systems that were technically correct and practically useless. Beautiful token architecture, comprehensive component libraries, documentation nobody read — because the system was built to impress rather than to work.

The system I use now is built around how I actually design, not how I think I should design. That means:

Primitives first. Every color, spacing value, and type style lives as a token before it lives anywhere else. I don’t apply hex values directly — ever. If a brand color changes, I update one token and it cascades everywhere.

Semantic layer second. My primitives feed into semantic tokens that describe purpose, not appearance. Not --blue--500 applied to a button, but instead, --color--action--primary that references --blue--500. The distinction sounds pedantic until you’re six months into a project and need to update your brand color in forty components simultaneously.

Components last. And only after the token foundation is solid. A component built on a shaky token structure is a liability. A component built on a clean one is an asset that compounds over time.

The result is that when I sit down to design a new screen, I’m not making visual decisions from scratch. I’m applying a system. The decisions have already been made. I’m just solving the layout problem.

Shortcuts and muscle memory

This one is unglamorous but real: I have spent time deliberately learning keyboard shortcuts, and it has paid back every minute.

In Figma specifically — auto layout, component creation, frame sizing, style application — the difference between reaching for the mouse and knowing the shortcut is small on any individual action and enormous across a full workday. Multiply a two-second fumble by a few hundred interactions and you’ve lost meaningful time to friction that didn’t need to exist.

I also use text expanders for things I type constantly — common CSS snippets, boilerplate PHP, repeated annotation language in handoff files. Small things. Real savings.

AI as a workflow accelerator

I use AI tools in my workflow, and I want to be specific about where they actually help versus where they don’t.

Where they genuinely save me time: talking through a problem I’m stuck on, generating boilerplate code I’d otherwise write from scratch, pressure-testing copy and microcopy, handling the first draft of documentation I’d otherwise stare at for twenty minutes before starting.

Where they don’t help: visual design decisions, design system coherence, anything requiring taste or judgment. I’ve learned not to outsource those. AI doesn’t know when something is slightly off in a way that matters. I do. That’s the job.

The honest version of “AI cut my design time in half” is: AI handles scaffolding so I can spend more time on the parts that actually require a designer. More thoughts on AI in design can be found in this article: AI vs human designers: where each wins.

The compounding effect

Here’s what I’ve come to understand about workflow systems: they compound.

A good naming convention makes your component library easier to build. A good component library makes your token system easier to apply. A good token system makes your handoff cleaner. A clean handoff means fewer developer questions. Fewer developer questions means more time designing. More time designing, with less friction, means better work.

None of these things are dramatic individually. Together they change how a workday feels — and what you’re able to produce in one.

But all of it starts with understanding what you’re building before you start building it. Get your ORCA right. Know your objects. The rest of the system has something solid to stand on.