Building a design system

Product/UX

︎ Back

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 vision

We 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.

Our vision
We want to be our customers’ champion, representing their interests and empowering them to do what they do best.

Our strategy
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 approach

We 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 guilds

Each 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.

Learnings

For 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 team

Bob Vickers, Marek Lenik, Padraig Flood, Oliver Wieland, Italo Moraes, Timothy GreigTunde Ganiy, Jakub Dziwoki, Michele Gatti, Priyesh ShahNaomi Melliss and Alice Williams.


︎ Back to top