Our efficiency gain with design systems
If you have read one of the previous editions of Shift or attended one of our conferences, you will have discovered how we started experimenting with design systems and developed our internal tools to implement them. Creating our own design system was quite a journey, and one with many lessons to learn along the way. We shifted from organized chaos to a well-defined process and collected a couple of crucial elements that every organization will come across when building their design system. We even created a tool named Hubble, our telescope to scale design in the future way of working with consistent designs in a fast and frictionless handoff to development. It offers a cross-platform solution that works for all the technologies in our organization.
The road to automating design to development handoff
When we started working on design systems, we knew right away that we needed to create something that worked for our internal teams, as well as for our clients. We quickly realized that our design system would need to be a platform that centralized all the design information for both our internal teams and the clients we team up with.
But building a platform like that requires a cross-functional team with multiple areas of expertise. It also takes a long time. How could we gain traction and get going fast? We assembled a small core team and defined a clear vision. Creating awareness across the entire company was the first step towards achieving our vision. We wanted to show our colleagues which problems could be solved and where efficiency could be gained by applying a design system. To do this, we defined what we call a 'lighthouse project': a first small project that would immediately demonstrate the value of design automation, acting as a lighthouse for future initiatives.
We prepared a pitch with a clear business need. This was necessary because at a company level, solving design or engineering problems are not a direct priority.
We started building our lighthouse project with a focus on web development, more specifically React, the most mature technology for making a system. We agreed to create an MVP to maximize value in the three pillars of our system: tools, documentation, and technologies.
Setting up a system is like a mini startup: it demands awareness and focus from every contributor. It is crucial to prioritize and find the right working methods when scaling the team, so that you can maximize their contribution time.
As in every startup, it is essential to keep your stakeholders in sync and demonstrate the impact you are creating to keep the systems alive. Hubble is already integrated into some of our existing products, and in those cases we witnessed 15% gains in the efficiency and quality of the software we shipped. Issues were solved faster; we had fewer tickets on our Kanban board, fewer design reviews and we collaborated better. We now have more time to focus on the bigger challenges facing us: architecture, UX and user delight to name just a few.
Distributing and adopting
One of the first things we agreed on with our stakeholders is that integrating Hubble is a no-brainer in every new project. With existing projects, it's a question of finding the right time. It is important to know when a team can adopt the system so that older features won't require any reworking. If we look at the statistics produced by the industry, adoption difficulties are the main factor that prevents a design system from being successful.
To work out the right time for a team to adopt a design system, you need internal champions in every team. These people are the ones who are deeply connected with the project and will be the ambassadors for the system. Our focus on a wide variety of technologies requires a person responsible for every technology.
To make adoption a success, there needs to be a close relationship with the user – in this case our colleagues – to ensure product/market fit. The user will help you improve the system and report it when it breaks. They might even be able to fix it. Ultimately they will also be building software in an agile way, so they know the system is never complete. One of the biggest challenges is the mindset change in how they build.
Supporting the entire organization means that we need to scale the team's capabilities. The ultimate goal is for every team to contribute their own solutions, so that decisions can be made without needing help from the design system team. Creating documentation and making it available throughout the company is one of the first steps. The closer you tailor your methods to the current way of working, the easier the adoption will be. Try to enhance the existing tooling if possible, instead of replacing it. That increases the opportunities for seamless integration. Nonetheless, our system does have some requirements of its own. For instance, the design tools we support should have an open API. You can find a workaround to work with the current tools, but it is essential to do an audit before your start integration. That enables you to make changes at the beginning of the project.
Adoption will help prove the advantages of the system and will give you leverage to onboard others. It will provide you with new insights so you can adapt your vision based on the user's needs.
Ultimately, our systems build relationships between disciplines and empower everyone to speak a shared language. The best time is to start now.
So if we look back, these are the things you should do to make it a success:
- Audit your current way of working to spot existing initiatives and potential starting points
- Define a small but highly visible 'lighthouse project' that will quickly show the value of design systems to the entire company
- Create an implementation plan for both new and existing products or features
- Make the system shared and collaborative, with a core & contribution team that is as cross-functional as possible
