Driving smooth and automated handovers at Dashlane

About Dashlane

Dashlane is a Password Manager. In case you have never used one, we do 4 main things: generate, capture, autofill and monitor passwords for you — so you don't have to worry about that tedious aspect of browsing the internet. Today, we serve a bit more than 20k companies and over 18M individuals have an account with us. You can find our apps on every major platform, web, Android and Apple products. Dashlane has more than 300 employees based in France, Portugal and the US.

Can you describe your role at Dashlane?

Hugo Leloup (Designer)

I'm a Senior Product & System Designer. I've been working at Dashlane for over 4 years, and in January 2022 I joined the newly created Design System team. Amongst the many challenges of a design systems team, we have spent a lot of time - and still are - improving the way we distribute tokens across our entire product.

"The intermediary layer Specify creates means responsibilities are now crystal clear for every person involved in maintaining design tokens. Designers stop when they've uploaded their content to Specify, and engineers only start when it's uploaded there."

Hugo Leloup, Senior Product & System Designer, Dashlane

Which challenges did you face as a team before using Specify?

Our Design System team is a year and a half old — it is composed of seven people. Besides dealing with a lot of design and tech debt, we were mandated to focus on three major goals:

1. tightening up the product's UI consistency

2. promoting good accessibility practices

3. increasing the company's global output capacity

In regards to design tokens, I can say that we started off pretty naive and challenges quickly popped up. Here's an overview of how we first handled our design tokens and the hand over processes we had with our engineering team:

• We originally had a simple color palette. We published a Figma library, sent the file to engineers to replicate in code, and called it a day. We didn't feel the need for any automation at this point because a palette is not the sort of data you update frequently.

• Later on however, it turned out the palette was not enough. Designers were creating custom colors wherever they felt the existing ones weren't working well enough, and mobile teams were painfully maintaining a clunky dark theme through color pairs they regularly had to override. These two main pain points got us working on proper color theming. We started off with a light one, and then obviously went off to build the dark one as well. Along the way, we realized we could easily provide a color debugging theme, as well as one for the website. So we did!

• All of these themes were saved in Figma as libraries and handed off to engineering so they could build their equivalents

• Then the next question arose: what about typography? How are we not aligned on it yet? Regardless of your product's approach to cross platform styling, you need your type in Figma to be consistent with what engineers use in production. So we went to work and provided styles for all the platforms.

• We had properly handed off each of these style sets when they were completed, but as a few months went by, our teams were in need of some updates here and there. So we made the changes, let the engineers know and thought it was all good.

• The thing we realized at this point was that the engineers' implementation was structurally different from how we handled things in our design tool. The updates we were asking for were breaking their structure and updating everything manually created a painful bottleneck. Figuring out how to address it took time, with a lot of back and forth. We got overwhelmed, each person involved had other projects needing their attention for a minute, and before we realized it, everyone was back to working with different specs all over again.

The conclusion? Achieving product cohesion is hard when there are so many manual steps — and therefore opportunities for errors.

How does your team benefit from Specify?

When building a product, you're only as strong as the weakest link in the chain. Every company hires the best designers and engineers they can, but that's rarely where the weakness lies.

The loss of information often happens during "handoff", aka the crossing of the bridge between design and engineering. It's a controversial step in almost every company, because it's not personified. It's not a single person, no one can be fully responsible for that part of the work. Designers don't know where their responsibility stops, and engineers don't know where their responsibility starts.

Tokens are a major piece of the equation because they can be found at both ends of that bridge. They are usually created in the design tool and have to make it all the way to production without loss or confusion. Specify provides a clear and flexible setup for our design token handover, removing the weakest link of our process and enabling us to refocus on the quality and consistency of our products.

"Manual handover and maintenance were our main pain points when our design system team kicked off. We were looking for a solution to safely streamline our token handoff from design to engineering."

Hugo Leloup, Senior Product & System Designer, Dashlane

How would you describe the impact Specify had on your team?

We now have confidence that if something is available to designers, its exact counterpart also is available to engineers. Our philosophy is that everything is informed by design, and Specify provides a stable, independent source of truth, outside of the usual design and engineering tools. Designers can still be messy, Specify provides a barrier that we update only when we are sure that we are ready to go. It gives engineers peace of mind knowing that, when something is updated in Specify, it's intentional.

When you start building a DS, Specify saves a lot of time with predefined definitions for what tokens are and how they are formatted. Designers are autonomous in creating new repos, engineers only have to pull the changes periodically. Example case: changing our brand color — it would require a lot of design/engineering back and forth to set up a sandbox to test a new brand color. With Specify, a designer can handle the process 80% of the way, and the engineer only has to swap sources to test in real-life conditions.

The intermediary layer it creates also means the responsibilities are now crystal clear for every person involved in maintaining design tokens. Designers stop when they've uploaded their content to Specify, and engineers only start when it's uploaded there.

How do you use Specify?

Today we use Specify for colors, typography, icons, and timings. Regarding colors, we have one universal color set we distribute across all our supported platforms. Typography is a bit different, with platform-specific styles. We have 3 sets, but they're all structured exactly the same way, in an effort to maintain product-wide consistency. We apply this approach everywhere, even to our components, and this has multiple benefits:

• Learn once, use everywhere: the rules are the same across all platforms

• You can't go "wrong": even if a designer picks a different platform style, an engineer will still be able to implement the correct version

• It's easy to "convert" screens between 2 platforms and maintain a consistent hierarchy, while obtaining a "native" feel

• All Dashlaners work on different product areas, but they share the same set of keywords, definitions and guidelines. This means we develop a product-wide language that everyone is familiar with.

We let Specify handle all the automations and the confidence this is bringing to the team is great.

Some tips and tricks that I would like to share:

• Converting icon filenames with the preferred convention (snakecase, camelcase, etc.)

• We maintain a log page for each token/component describing what happened at each update

• Icons: we filter platform-specific icons via emojis suffixes

• We filter tokens when they're unnecessary: for example, hover color tokens on are not imported on mobile

What made you choose Specify over other solutions?

Manual handover and maintenance were our main pain points when our design system team kicked off. We were looking for a solution to safely streamline our token handoff from design to engineering.

When we came across Specify, we questioned how useful it would be for us. Among the many questions:

• Is it just a repository storing json files?

• If so, why wouldn't we build it ourselves?

• Is our toolkit already growing too big?

• Are we locking ourselves in?

We ultimately made a decision looking at the following aspects:

• Specify was saving us time: as a young DS team, we had lots of things to figure out at the same time

• Specify non-committing: it doesn't lock us in, and we can move away with our data anytime

• Specify brings a sense of safety by being an intermediary layer: we can visualize tokens at any time outside of each others' working space (GitLab or Figma)

• Specify gave clear ownership for each stakeholder: anything before Specify is design, anything after Specify is engineering. This simple fact brought clarity and autonomy to everyone

Last but not least, Specify is bringing us all of these benefits with a great user experience and ease of use.