(My) Ideal Design-to-Code process

Design-to-code has intrigued me throughout my entire time in product development. Design and Frontend are the same worlds, in different languages. I've asked myself over and over "Why do we insist on drawing, and then re-drawing products?".

We need a way to iterate and validate ideas fast, and often times, drawing up something in Figma first is faster than building directly in an IDE. Getting ideas out there fast, and if that is through Figma, is a fair method — but in my experience, the ideal approach needs to include the agility of testing these ideas as well.

The concept of merging design and developer tools sounds great, but infusing the workflows can’t be slapped on. Regardless of how innovative or cool your product is, existing human behaviors and adoption will be the biggest competitor to your product’s success.

— David Hoang, IDDE: The infusion of design and dev tools

I used to think the answer to combining speed and agility might be a tool such as Modulz (acquired by WorkOS), Vizzly (acquired by Figma), or Framer classic/X. And they did have a massive impact in getting devs and designers asking if one should learn the other's skills. But I've come to agree with David from the quote above. To effectively solve this problem, we need to hold our existing tools and workflows to a higher standard, rather than creating a new tool.

"Should designers code?" A talk I submitted to the inaugural Figma config in early 2020 answered with a resounding YES - but not necessarily in IDE's. Rather designers need to understand the way the DOM works on a rudimentary level, and design tools need to more readily represent how their designs will be implemented.

The ideal design to code process requires design systems and/or component libraries to "speak the same language". In my opinion, things like shadcn , Chakra UI and the up and coming Catalyst are all appropriate options if you're not ready to invest into a bespoke design system.

I'm not going to claim to have the one and only process - but this is the current ideal solution in my opinion for small software teams that care about efficiency, and speaking the same language.

My current, working process

This process describes the workflow from 0 to shipped, and has historically been owned by multiple roles. But with a design engineer role it can be streamlined and even assigned to one contributor.

Step #1 Prioritized problem/need from the customer

Ideally the team member assigned to the issue would hear direct from the customer's mouth what they're looking for. I.e. you're on the call, watching a call recording, or seeing a written request from them directly. Could be from the business team, but thats diluted.

Helpful tools here:

• Customer request tools like Monterey AI or Productlane make it easy to double click on a user's problem even after-the-fact
• Ask your product and customer teams to use Grain or another call recording software. Hearing directly from customers rather than a recap from a team member will give a better chance at truly understanding the problem that needs solved
• June AI for digging into data to support the need and give context to the problem
• Dogfooding will get you very far here. Deeply understand working in your product.

Step #2 High level design

Work with the context of customers and the business team. I've approached it by doing research of existing solutions, writing out requirements to solve the problem, analyzing the existing data model, and looking for existing components that could come in handy. Then the standard next step: user flows, and wireframes. This could be sketched out or using something like tldraw/FigJam but should focus on user flows, not high-fidelity.

Tools here:

• FigJam makes it super easy to share quick sketches, pull in more high-fidelity pieces if necessary to convey ideas (Tip! copy-and-paste from a normal file into FigJam works!), is an already open tool and has great mobile compatibility if you're a hand-sketching kinda person
• tldraw is a fantastic no bullshit, low-fi canvas with sharing capabilities
• iPad notes app, honestly if you're trying to break through the tool fatigue and just want to sketch in an easily sharable way this is great. I've been known to use the lasso tool and copy an iPad notes sketch into a Linear ticket or doc directly

Step #3 Prototype the idea out in Code

After socializing and iterating on a basic solution, we need to validate with actual fidelity. It's reasonable to ask coworkers that deeply understand the product to use their imagination, but true validation of a solution from a customer needs full-fledged-fidelity.

I think there are two main ways to do this.

Either your team:

1. Should have slightly more imagination and stay in low-fidelity/sketches for longer - then code out a super stripped back prototype
2. Or you'll need to invest deeper into a design system and a custom Figma dev mode exporter for a Designer to do this in a high-fi Figma design.

If it's the latter - i.e. being done by someone with out coding skills and inside of Figma - for crying out loud make sure that you have a custom Figma dev mode exporter. There are several general plugins out there that can get you 85% of the way there if you don't have the time to write one. Frontender by Webbie for example does allow you to import your TailwindCSS theme, however you'll need to put in the work as a team to convert to your design system components directly.

Tip! — If you'd like to make life easier, prefix your design system component names in Figma with an emoji i.e. for frosted-ui, a design system component would be 🧊 Button whereas a non-design system Figma component would be Preview frame. This makes both manual and AI parsing for appropriate components easier. Otherwise, your chances of the converter spitting out gibberish code that needs to be refactored, rises. The more Figma nodes you have selected at one time, the more this rings true.

Helpful tools:

• Figma Dev Mode, specifically Dev Mode plugins
• Framer or the Framer to Figma plugin if working on a website - zero reason to redraw in Framer with how easy that interface is
• v0 or Magic patterns (more css output options) for direct idea to code iteration
• Specify for syncing ionic/token values

Step #4 Get a validatable resource in front of a customer ASAP

Granted, not every org can ship to production to validate an idea. Figure out what version of shipping fast means to your team — is it an Request For Comments posted to a discussion board, a preview URL used in a customer interview, or maybe feature flagged to a set of bought in beta testers?

The product strategy side of me though has to warn you - make sure you're not just shipping and hoping it sticks. Get comfy with product analytics or at the very least be thoughtful about the data you're collecting to appropriately validate this idea.

Helpful tools:

• Vercel Preview Deploys to send production feeling code and encourage inline feedback with comments
• PostHog has both feature flags and product analytics that work together