Using keyless and remote access technology, We Deliver by Volkswagen enables service providers to deliver services and goods in their customers’ cars. The idea: Giving the many cars standing around on our streets a purpose and helping partners achieve better delivery rates.
The service went live in November 2019 and is currently available as Open Beta in Germany.
When I joined the team in January 2020, We Deliver had been developed for several years and was facing typical challenges of a grown product: Maintainability, scalability and speed.
The part of our product that was struggling the most was our frontend:
No reusable components
When We Deliver was built, VW’s design system was still being developed by another team. Many aspects were not defined yet, so we partly took the pre-built react components from the style guide and partly built designs on our own. This led to a large variety of components and design elements in our frontend, all of them being slightly different and therefore hard to maintain.
No easy updates and changes
We Deliver started as a VW-only product, but soon other brands of the Volkswagen group raised interest in offering the service for their vehicles. When we had to adapt our frontend to Škoda, we realised that styling the pre-built react components from VW’s design system wasn’t straightforward. We applied some hacky implementation techniques to meet the deadline, making our code more complex. Plus, whenever VW’s linked react components were updated, our frontend broke, causing developers to spend one day or more fixing it.
No source of truth
The fact that design and development collaboration was disconnected back then didn’t help. Team members changed frequently and soon there was no clarity about a potentially underlying system behind design decisions. Having neither consistency in design and code, nor things properly documented slowed the whole team down, especially when new team members had to be onboarded.
We need a design system!
Although I wasn’t brought in to tackle these challenges, realising how much they slowed us down made me decide to address them before we develop new features. Because every new feature creates more debt.
Having worked with design systems in my previous jobs (mainly at Kleiderkreisel), I knew their benefits very well:
By creating a system of reusable components and constraints, design systems do not only bring consistency to the look and feel of a product, but enable the team to make faster decisions and collaborate better.
Even though we were using VW’s design system, it didn’t meet our needs and caused additional challenges for being a multi brand product. What we needed was our own design system on top of VW’s.
I led the initiative of tackling our consistency problems through our own design system. After my team and I had settled on an approach, I designed components in Sketch, wrote the documentation, defined style differences per brand and educated my team about design systems along the way.
1. Involving the team
I scheduled a meeting and prepared a few slides to get my team on board. First, I had to create awareness around the problem, its impact and severity. When I introduced design systems as the solution, I made sure I speak the language of my teammates, pointing out the benefits we all care about, such as development speed and product performance.
The best part was: Once my direct co-workers believed in it, the news got spread so that we also got the support from our manager and product owner.
After my team and I agreed on a rough approach, it was time to get to work.
2. Choose a methodology
I decided early on to build the design system following Brad Frost’s Atomic Design methodology, which is by far the most adapted approach to design systems.
3. Audit the status quo
I scanned the current state of We Deliver and listed all components and patterns we’re currently using, looking for opportunities to merge and unify them. I also had to get more familiar with the current state of VW’s design system since it laid the foundation for our own design system.
4. Design components
Once all components needed were listed, I designed them in Sketch and provided detailed specs and documentation for each one of them. The main challenge here was to decide when to use the symbols of VW’s design system and when it was necessary to create our own Sketch symbols.
5. Map styles for different brands
All components were built for the VW brand, but we also needed to define how they translate to Škoda. Designing all components for Škoda would have taken another month, so I started a spreadsheet that shows styles for each brand (e.g. hex codes, typefaces). This list will directly inform each brand’s CSS and can be extended by new brands in the future.
6. Document on the fly
Thoroughly documenting styles in the moment I added them saved me a lot of time compared to documenting the final design system. What started with note taking just for myself later evolved into a documentation for the team using Zeplin’s style guide and components features. Also giving components in Sketch thoughtful names right away made it much faster to create symbols out of them.
7. Share and adopt
This step often comes at the very end of the design system process, but is worth doing from the start if the users of the system are new to the general concept. Even though design systems have been around for several years, they are still new to many developers or not understood as the link between design and development.
Instead of showing the final result in form of a presentation, I created a Slack channel where I gradually showed my progress, tied decisions back to our goals and asked for feedback.
Posting daily on Slack didn’t only help with awareness and adoption of the new design system, but also with staying connected during the corona pandemic. Sometimes I just shared insights or reading material in order to spread inspiration and excitement about design systems as a topic.
Note: Due to the corona crisis, product development got stopped end of May 2020, so that we were not able to execute all steps we planned. For the sake of completeness, I’d like to point them out below.
8. Prototype one screen
As agreed upfront, the developers and I wanted to implement one screen (our homepage) to validate if the design system including the multi brand approach works the way we envisioned it. To not mess around with our existing code, we decided to develop the screen outside of our main codebase using Storybook.
9. Roll out
Once our approach got validated, we wanted to incrementally roll out the design system by replacing and updating existing components. The idea was to start with major components like the primary button while keeping the atomic design methodology by implementing single components rather than whole pages.
Before it was decided that We Deliver will not be continued for VW, the plan was to hand product development over to a new team. The goal of the design system shifted from solving our own problems to giving the new team a solid design and code foundation they are happy to take over:
- We pointed out a clear direction of how the product should be developed further.
- We tidied up our design and code using state-of-the-art methodologies.
- We provided a source of truth so that the new team can work when we’re out of reach.
Personally, my biggest achievement was to do what felt right and make my team trust me. Even though our design system didn’t make it into coded reality, it helped non-designers understand design a bit better. Because still too often design is misunderstood as decorating screens rather than laying the foundation for building maintainable products.