To create that perfect app, website, or digital product, we need that unique blend of making the product pleasurable, usable, reliable, and functional. And to create a product that meets that blend of needs, we need designers and developers to work extremely closely.
Most of us start a project with this in mind. But as it goes on and we spend more time working on features, we tend to forget about that blend and the required close collaboration. The result is a handoff between designers and developers that becomes a dreaded point in time rather than a constantly evolving and dynamic part of the process.
We spend far too much time getting features ready for handoff. Countless hours are spent snagging the work that has been completed with comments like “move that two pixels to the left” or “you’re using the wrong hex color here.” All of which is both time consuming and, let's face it, not what we signed up for.
Designers want to create beautiful experiences, and developers want to do the same thing. To be challenged is what we’re crying out for. And more than often, we’re bored to tears spending far too much time with the mundane parts of this process.
And you know what? It doesn’t have to be that way.
There is a better way to structure your work so that it becomes easier to share specs and speak a common language when talking about them. That’s what I want to share with you today.
But First: Why Should You Invest Time Into the Process?
A lot of you may be reading this and wondering, “Why should we invest time into improving our team’s handoff process?” And you know what? It is a valid question. At the end of the day, you’re busy with projects, deadlines, pressure from stakeholders, and you just want to get the work done.
So let me outline a few of the benefits you’ll receive by improving your handoff process.
First up, you’ll help free up your time and save hours if not days of the manual — and highly dull — work that designers and developers have to do. While I’m not saying you won’t still be creating specs and docs to accompany your work, it will be a lot leaner.
Secondly, improving this process will help improve the quality of your final product since you have more time to work on the important stuff. This might be adding that animation that you always wanted or tidying up a piece of poorly written code — or just having the time to learn new things that you can try out.
Thirdly, it will help you to improve the skills of everyone on the team. Designers and developers will become better at doing what they’re supposed to do, which is creating things, and not just mastering the art of reading and understanding a design spec.
And lastly, projects get completed quicker, and the outputs are better.
OK, So How Can We Improve Our Process?
First off, designers and developers should work together to solve problems. I know we’re talking about the handoff process, which sounds like it is all one-way traffic — design hands off to development — but it should be a back-and-forth process with ideas flowing both ways.
If designers and developers work closer than ever, by sharing their work at different stages, it opens up the door for more feedback and areas for improvement before getting to the end.
Creating a design system — which is a collection of reusable components and parts that help to speed up creating digital products — would also improve the handoff process, but these can be expensive since they can take months to design and develop — not to mention the time it takes to maintain a design system — and often, teams don’t know where to start when creating them.
But there is one part of a design system that you can quickly implement in your designs and development process to significantly speed up handoffs. They’re called tokens.
Introduction to Tokens
In a design system, tokens are a way to store values needed to specify the design system’s different parts. Tokens can be used to define colors, typography, spacing, border radii, shadows, and even text or copy.
They’re generally stored in a JSON file and instead of hard-coding values, developers can use tokens to easily update the look and feel of the user interface (UI). Tokens can also quickly be checked against the designs, which is great for ensuring consistency between what was designed and what was developed.
The thing about tokens is that they’re straightforward to implement, too, since most design tools (like Adobe XD, Figma, or Sketch) allow designers to define styles (colors, typography, shadows, grids, and so on) that can easily be shared with developers who can quickly create a version of these in CSS or JSON — if you’re really fancy.
Using tokens, you’ll start to define the values of elements upfront. Imagine you’ve got an app and want to use a shade of red (#D0021B) as the color of buttons and other parts of the UI. Instead of hard-coding #D0021b wherever you want to use this color, you’d define the red as token --color-red: #D0021B and refer to the token whenever you want to use red as a color. So your button would look something like:
.button {
background-color: var(--color-red);
}
On the surface, tokens may seem like a small change. Instead of hard coding values, you’re defining them upfront. OK, so what is the benefit of doing this? Well, there are a few benefits to this, one it will make things nice and consistent. Since values are no longer hardcoded, it reduces the chance of rogue styles or values (an old color, for instance) showing up — most often, this happens because people forget where a value was used.
It also makes it easy for the whole team to talk about the elements that make up the UI in a language that they all understand. Hex codes, RGB values and so on are not easy for everyone to understand or remember. So rather than tell someone the shade of red they should use has the value of #D0021B, you could simply say to use “color-red.” Being able to talk about colors in a simple language empowers everyone to understand.
Another benefit is token files can be easily updated, so if you want to change that shade of red to a shade of blue, you only need to edit one single line of code. And the token files which store the values can just be copied to new apps or projects.
And finally, the beauty about using tokens is that if you ever decide — and get the buy-in from stakeholders — to create a design system, you’re already got work completed to help you on your way. The components you have in your UI are already defined using tokens which is the first step of creating a design system.
How Get Started With Tokens
As I mentioned, most design tools will allow you to define styles, so the first thing a designer should do on a project is to create styles for all the colors, typography, shadows, grids, and spacing they plan on using. For example, in my designs, I use a style called “neutrals-black” with a value of #222c2f, which defines the color black. I apply this style to text colors, or anywhere I want to use that color.
Next, the developer (or designer) will create a coded version of these values to be used in the development process. Taking our color example, we’d have a coded version of the black color that would look like --neutrals-black: #222c2f if it was created as a CSS variable. You could also create it in JSON if you wanted to scale to other platforms, that way the same token could be used for a website and mobile apps.
Once done, it is over to the designer to use these styles when designing the UI and for developers to refer to the tokens when they are building out the UI. And a developer can use the neutrals-black token across instead of hard-coded values.
It is important to remember to use the styles in your design files and use the corresponding tokens in your development project. If you don’t, then you’re wasting your time.
Depending on your needs, you might just create them using CSS variables, or you might even use something like Style Dictionary by Amazon to help you define styles once and use them across various platforms.
Or you could be even more of a wizard and use the Figma API to generate a coded version of the tokens. Either way, the choice is yours. It just depends on how much time you want to spend on it.
I’d recommend you start small and go from there.
Now you know that you can quickly and easily improve the dreaded design-development handoff process with a few small behavior changes by introducing tokens to your designs and development. This is not only going to make your design-development process better, but you’ll create better products and free up your time to work on the great stuff.
