New projects are on the brain. The new-car smell you get at the start of a new web development project. Everything is possible. Expectations are high. Dreams and aspirations of clean, beautiful code. It’s the moment the specs are all specced, the statements of work are all statement-ed. The designs are approved and the deposits are paid. Development is ready to begin.

On the latest viewSource podcast episode, Aurooba and I talk all about project kickoffs, whether you’re responsible for design or just development. But for the purposes of this post, I’m focused on the design-to-dev handoff. I had a really great design-to-dev handoff last week for a new website build. What made it so great? Three things:

1. The designs had a style guide

The days of handing over a PDF mockup of 5 distinct landing pages are over. Just because a design is “bespoke”, it doesn’t mean you need to have every button or heading look unique. Systems and standards are good for design, for development, and for user experience. And a good design handoff has this in mind.

I love a well-thought-out style guide. I love knowing that all my buttons are going to to follow a specific pattern. I love seeing consistent border-radiuses and drop shadows. I love having specific typography choices spelled out and then adhered to across the design.

Most of all, I love consistency in spacing, both in terms of margins and padding AND in terms of the overall layout. I’m still thinking through how to incorporate the width and alignment options in the block editor, but whether you use max-width blocks or a 12-column grid, sticking with consistency and adhering to the style guide is key.

2. The designs had a component-first mindset

In classic web development, we would think in terms of templates. WordPress page templates, archive templates, post templates, and so on. And there are definitely a lot of templates still floating around in a website. But more and more, we’re seeing a shift towards components. You might call them blocks, or maybe block patterns. You could also call it atomic design.

A call-to-action is a component. A hero. An FAQ accordion. A query of posts. These are all components- whether they’re a single well-designed element or a collection of elements. They’re the building blocks of a website and it makes sense that an end-client might want to use Component A on Page Z.

The client buying the design still wants to see everything in terms “landing pages,” because that makes sense. But as the developer, I appreciated that the designs I reviewed actually pulled all of the components out separately so we could review them one-by-one.

As we see new tools like the block editor’s Style Book component come into play, we’ll be bringing these components to life without building a million Lorem Ipsum-stuffed pages.

3. I’m a better developer than I used to be

To be clear- I’m not saying I’m a great or even good developer. Just better than I was the last time I started a project, which is a statement that I hope every developer can make.

In a design-to-dev handoff, the pressure isn’t all on the designer. It’s the developer’s job to think critically about each piece they’re shown, to ask questions, to push back. If something looks like it could cause an accessibility issue, or struggle to function on mobile, or use some other anti-pattern, it’s the developer’s job to say something.

It’s also the developer’s job to think in terms of “success”: What would a successful use of this component look like? You must quickly consider how you’ll successfully achieve each aspect of the design: Can I do this with native blocks? How much custom code can the client afford on their budget?

Being able to skillfully navigate a design-to-dev handoff takes a lot of practice, a lot of experience. You typically recognize pitfalls because you’ve fallen into them before. You see warning signs because you didn’t see them last time. And you can appreciate thoughtful design even that much more, because you’ve had to think through a number of designs. I can think back to the past where I’ve sat through these calls wondering why we were spending so much time on them. Now I understand.

Now I’m on to the next step: strategy. How will each of these components come to life? How many options or settings will I give the client? How flexible will these components be? How rigid? The development work starts before you write code, before you set up your local environment. It starts in that handoff, where your experiences shape your decisions just as much as the designs themselves do.