Building a design systemProduct/UX
How we built a tool that helped us design together.
When I joined the team, designers operated from a few templates here and there and shared sketch files with UI and styles. Typically, a handoff would happen and development would begin from there.
We needed a better process to enable designer/developer collaboration. Design wasn't united, and there wasn't a single source of truth that teams could challenge and improve on together. My role as Product Designer was to contribute to not only the design, but also the process of how we we developed our system together.
Problems we faced+ How do we build a tool that will champion our users needs?
+ How do we design and build collaboratively?
+ What is the ‘source of truth’ for design?
Starting and starting again Our first failure began with documenting our design components before knowing the purpose of the project. You could say we knew we needed a system, but the team hadn't formalised the true value it would hold just yet.
The process of documentation was awful and we didn't collaborate as much as we could, so a lot of rogue-like work was done. We were definitely progressing, taking a shoddy trello board of components to the beginnings of a storybook library. This first phase made the system valuable for front-end developers, but it was yet to become useful for designers.
Forming a visionWe began asking designers and developers what a design system is, what it means to them and how it would benefit the people who would interact with our product and experiences. We synthesised this to form our shared vision and strategy.
We want to be our customers’ champion, representing their interests and empowering them to do what they do best.
We’re building a design toolkit to help us all better communicate our brand and create seamless, cohesive product experiences.
Once we had a strong vision and strategy, it became clear we had to treat the design system as a product in itself.
Atomic approachWe were inspired by Brad Frost’s atomic design approach, so we approached a lot of our components this way. Later on, we discovered this became a nightmare to maintain. It was a bit ambitious at first for where we were at the time. Through this lesson, we discovered that documentation was our greatest asset in the onboarding of new members to the team and keeping alignment strong.
Visualising the behaviour of atomic components from atom to page layout.
Weekly guildsEach week developers and designers talked about the way we were working and how the system could help achieve our goals. These weekly meetings were core to motivating the team and keeping the ball rolling.
Solutions+ This project led the tech team to think in new ways about how we build great products that empower our users.
+ We formed a vision
+ Full component documentation
+ Live code in storybook for reuse and improvement
+ New products built faster, and without designers on the team
This is the storybook, it started taking shape with documentation both from both designers and developers.
LearningsFor a while the leadership was passed around during my time at LendInvest, each new leader taking it a bit further. With the incredible direction from Marek and Bob, we realised the design system needed to be treated as a product of it's own.
+ It takes great leadership to get even the most important projects to become reality.
+ It takes visualisation and clear communication to enable people to share a common goal.
Thanks to the dream teamBob Vickers, Marek Lenik, Padraig Flood, Oliver Wieland, Italo Moraes, Timothy Greig, Tunde Ganiy, Jakub Dziwoki, Michele Gatti, Priyesh Shah, Naomi Melliss and Alice Williams.
︎ Back to top