Building a Design System for a multi-vertical ecosystem
The Jeff Design System
The Problem
When I arrived at the company in November 2019, Jeff was experiencing a big change in their business model. They were transforming their one-product service into a complete ecosystem of different verticals. The single Mr. Jeff laundry service was transforming into a ‘‘super app’’ with multiple services starting with beauty and fitness, plus the countless new verticals to come.
What did this mean for our Product & Engineering team?
Many different Squads working on different products at a time, simultaneously developing products that had to be aligned and work together in one app, while at the same time serving completely unique businesses.
Our Brand team was also about to launch a huge rebrand, so soon everyone started to work on adapting our product designs to fit the new look while continuing to design and develop new features with different designs depending on the vertical and the product itself.
‘‘What a mess’’, you might say… Our thoughts exactly.
It was clear that sooner or later, with the rapid growth of the company and its products, the super app would turn into a gigantic Frankenstein monster if nothing was done about it.
The Solution: A Jeff Design System
From the Product department, we landed on the idea of creating a Squad in Jeff dedicated to ensuring that all the other Squads could reuse designs and chunks of code and basically just make it as easy as possible to keep delivering a well-designed product as we continued to grow.
And that’s where I started working. We were a three-person team: one Product Designer (Paula Sempere) and two Frontend Developers (including Mario Sanz and myself).
Our main purpose was to understand the product needs and find the right solution to our main concerns:
- Product Alignment: being able to handle current and future products and verticals and let the app grow as fast and as safe as possible
- Brand Coherence: keeping all the products aligned with a visual ‘main Jeff structure’, while also letting each vertical have its own style and personality
- Development Efficiency: reusing pieces of code would make the development so much lighter and easier, would give coherence to the products and would also make the growth of the company a lot smoother
Building a Design System* was the best possible solution. We would create a library of well-documented visual styles, product components and guidelines so creating and improving our products would be much more efficient and coherent moving forward.
*A Design System is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. If you’re not familiar with the concept of Design Systems, here is a great explanation by Colm Tuite:
But building a Design System from scratch would be no easy task. Especially when taking into consideration the unique challenges and opportunities we have with the nature of our company, team and product:
- As I mentioned before, we have Squads working on different verticals within Jeff (currently Mr. Jeff (Laundry), Beauty Jeff and Fit Jeff). There are style elements that connect them under Jeff, but each one also has its own style elements as well as very unique needs in terms of functionality.
- Within each of those verticals, we have multiple Squads again working on different products. For example, the web apps that our Partners use to manage their businesses and the mobile apps their Customers use to enjoy their local services (that’s already 2 products per vertical minimum!)
- Our products are being used by business owners and customers all over the world. We have to make design decisions that are flexible, universal and translate-able.
- Jeff has been growing fast and we need to be prepared for anything. Tomorrow we could add a new vertical that has completely new needs than all of our existing products and we need to make it ‘‘fit’’ into our Design System.
So with all of that in mind… where did we start?
The Process: Building our Design System
We started by reviewing all of our products and deciding which things we had to start with and how we were going to make the Design System grow. There were some things we had to consider before starting to build anything.
- Our style guide needed both a unifying element to represent the main brand, and then representative elements for every vertical. This would give the brand coherence to everything as a whole, but also allow each vertical to have its own differentiating traits.
- Our components needed to be adaptable to suit any vertical and product. This meant that we had to build a tool able to thematize every component depending on the project it was implemented in.
- The project should let us scale the Design System gradually, starting with small reusable components but letting us build big reusable structures that would, in the future, let our new products grow super fast.
How did we manage to meet the requirements we had?
We worked with our Brand team, testing very different scenarios with different approaches of how we could use color through components and various different product screens. And we ended up choosing a conductor color, with its own variations, that had complementary colors depending on the vertical.
The conductor color and its variants would be used for all of the main recurring elements in the library, no matter what vertical. Vertical colors would only be used for specific details that had nothing to do with structure of components or user feedback, in order to avoid design discordance or give wrong feedback to users.
On the development side, we decided to build our tool with Vue.js, as it was the tool that we were currently using in most of our products anyway, so the implementation of the component library would be a lot easier.
We chose Storybook as our main development and documentation tool, as it was one of the most complete tools for Design Systems at that moment, and we had also the opportunity to integrate it with the design tool in Design System Manager, by InVision.
This DSM tool would give us the ability to manage both development and design documentation in one shared place. That way, our entire team could access the most up-to-date Design System documentation in the one spot, as well as real live components with which they could interact and see how they worked live.
In order to make the component library grow in a structured way, we opted to start building components in an Atomic Design fashion, which basically means building things from the tiniest elements that later are put together and become a series of larger components.
We started from the basics: buttons, text styles, main input fields, etc., and we analyzed current element usage in our projects so we could prioritize which components made the most sense to develop first.
Stop and Rethink: Collaboration Processes
Once we had a very small first version of our component library, we started implementing it in our projects to see how it worked and started reusing and unifying pieces of our different projects.
Very soon we realized that our small three-person team would never be able to provide every Squad with all the components they needed, and we started thinking about the idea of everyone collaborating in the creation of our Jeff Design System.
It made sense to have a Design System team defining a strategy, building the system, and directing the design and development of tools so everyone can participate in the process of creating components.
“The reason for introducing a design system in a company is not so people can work less, but so people can work better. Cristiano Rastelli”
So our main objective turned into defining those processes that would help the entire team know how to create components for the library.
We basically divided collaboration processes in three main workflows:
- An initial one in order to decide which type of contribution they had to make
- A modification of an existing component workflow
- A creation of a brand new component workflow
Here’s how it worked: first they had to create a task in our Jira Board describing their idea, and our team would review it and decide if it fit our needs. Once the task was approved, they started the whole process of creating/modifying the component including
- A needs analysis
- Description of the component, technical requirements, usage, do’s and don’ts, content requirements
- The design of the component with its Sketch symbol
- The development of the component inside Storybook
- Make sure all documentation is inside our Design System Manager
- The publication of the new version of the DS Library so everyone else could implement it in their projects as well
We’re currently using these processes and continuously improving them with the feedback from our designers and developers, but the growth of the component library has been so much faster since we started this process, and it lets us focus on continuing to define the strategy for the future of our Design System.
Next Steps
Our main focus right now is to continue testing our processes and give support to our team so they have the tools they need to create a great library together in which Jeff — and each of its verticals — and all of the products that support those verticals — can rely on.
Of course we’re still creating components as well, but with all the collaboration of the different Squads, our growth will be much bigger and have a better impact on the whole company.
We are also working on defining what the future of the Design System will be, how we want it to work and be implemented once we have a bigger group of complex components, and how we are going to share not only designs but also functionalities between future verticals.
It’s a very complex job to unify and have so many different products aligned in one single place, but we’re sure it will also be exciting to see our Jeff Design System expand and fill all corners of the projects, becoming an essential part of the Jeff ecosystem, and letting everyone enjoy THE GOOD GOOD LIFE.
