The process of building a Design System
Photo by Iker Urteaga on Unsplash Working at Ezypay as a solo designer for the first few months was incredibly intense. I was trying to complete the daily tasks while learning the Product, meeting various stakeholders within the company, and trying to lay down the fundamentals for the work ahead: designing a new client-application to interact with the Product.
Ezypay's Product is a payment billing Platform, specialised in recurring transactions.
I knew I was going to need a Design System, to have a common vocabulary to use while talking with the Engineers and Marketing teams.
This is how I did it.
Step 1: Audit existing components
To get an overview of all the use cases we needed to cater to, it was important to audit existing components. Yes, this meant each and every component on each and every page.
This was a tedious one, but it needed to be done to track the progress. There wasn't much documentation from the previous design agency that had designed the UI.
For the audit, I took screenshots and used Trello to organise them.
I created a card for each component, with its label and colour.
Each list (lane) represented a page.
This allowed me to easily find components and where they were living among the old application.
Step 2: Research on other design systems
Here is a list of Design Systems I looked at (and still look at, sometimes) to get me started:
Following the best practices that I gathered from these references, allowed me to deliver the best results possible; especially considering I didn't have the luxury to use a trial&error approach.
I ended up starting from Bootstrap and customising it completely to make it comply with the Brand Guidelines.
The Brand Identity had been set by an external agency some time prior to me joining the company, and all the Marketing collateral material was based on those guidelines.
This provided a good starting point for the base colours and typography to use in the design.
Step 3: List out components
After running a few sessions with the Support Operators, the most frequent users of the application, I identified the components I needed to prioritise. This allowed me to filter the component list on Trello to keep track and plan time accordingly.
The components were also categorised as follow:
- Buttons
- Data Input
- Data Display
- System status feedback
- Navigation
The list got revised continuously and ticked off whenever I finished designing and building a component.
Step 4: Plan a timeline
It was time to sit down and plan.
Based on the conversation with the Support Operators, and the list of the most compelling components to be designed first, I started putting together a timeline, to help myself and the stakeholders.
The timeline was aligned with the Engineers Sprints, as at that time I was very much dependant on their availability.
Obviously, I had to start from the Atoms (as per Atomic Design from Brad Frost nomenclature).
I ended up having a weekly meeting with Engineers and Support Operators to coordinate the design and development of the application. In addition to that, we also planned the release of the following:
- Base design components (as Symbols in Sketch)
- Main pages layout for the app
This was fundamental for our frontend engineer to build these pages, and for the Support Operators to see some progress in the design and build of their day-to-day tool.
We would update the timeline iteratively at each sprint retrospective based on our progress.
Step 5: Research and discuss components
The goal of the discussions was to design each component with its properties and states, as well as establish its usage guidelines. For each component discussion, we reviewed its use cases on Trello and defined our own best practices.
We used Confluence to keep track of the things discussed in our meetings and the outcomes or decisions made. These records were important for future reference and to capture why and how we made certain decisions.
Step 6: Create design symbols
As the discussions progressed, I started building our styleguide. I created text and layer style libraries and the respective Symbol in Sketch including its states and variations.
The Support Operators and I went through our UI components and defined a common language: referring to each component in the same way. This sped up the conversations between the teams and reduced the incidences of misunderstanding that had occurred before this common language was introduced.
The Design System was starting to save time and headaches already.
We quickly got to the realisation that there wasn't a “one size fit all” way to name components for our organisation, or anyone else. It boils down to each and every Product's specific function and feature.
We decided to go with whatever name was able to fit our current workflow.
Step 7: “Design” the design system
We wanted to incorporate best practices from other design systems into our own. I designed mockups for each page after its components were symbolised, before passing it on to our frontend engineer to build these pages.
Instead of designing pages and having them coded by the Front End Engineers and wasting their already limited time, we decided that the best way to proceed was to create some interactive prototype and test it with the Support Operators.
Step 8: Implement the Design System
It is essential to communicate with the engineers, product managers and other stakeholders within the organisation about the state of development of the design and the application itself.
I used various tools to achieve the best outcome, depending on the audience and the context. There are a few that stood out for their efficacy.
The prototyping tool embedded into Sketch was very quick to use, and it was a valuable asset that allowed for a quick turnaround while testing things with the Support Operators.
Also, I found it very helpful to use Abstract and its versioning system to keep track of the changes made on our Sketch files so that we were able to get back to a previous version of the prototype in case we needed to.
Another tool I discovered being useful was Kactus.io (https://kactus.io/), which integrates seamlessly with git, and offers a user-friendly visual diff tool.
Deliverables
Please, note that for NDA reasons, the following are only representative examples rather than the original Design System I designed for Ezypay.
Spacing
Layers styles
Typography
Conclusions
All in all, this is how I started Ezypay new application's Design System from scratch. There was still much work to be done, but starting to build on solid ground is important for a positive long term outcome.
Building a design system is a never-ending task as it's not much about “building” it; it is more about updating and adapting to better suit the Product and user needs.
