Optimizing the Goodself colour system for white-labelling and efficient design handoff.
UX/UI designer
Lead UX/UI designer, product manager, lead developer
2 months
Goodself is a health and wellness platform that provides patients with expert-led resources and health-focused groups.
Working with the team on this project, I evaluated the existing design system, proposed a design direction, and led the implementation of design changes.
Please note that screen content has been edited for NDA compliance.
I was consulted about the feasibility of turning Goodself into a white-label platform.
To gain a better understanding of what would be required, I looked into best practices for white-labelling.
An evaluation of the platform revealed three main underlying issues with the colour system.
I evaluated the existing screens, the colour system, and how the designers are implementing the brand guidelines.
Issue 1
Colour usage is overwhelming and makes information unclear.
Colour is used to differentiate items, but when so many different colours are used sporadically, the hierarchy of information becomes unclear.
Issue 2
The colour system does not represent the Goodself brand.
As colours keep being added, it is difficult to understand the brand's visual identity.
Issue 3
The lack of colour guidelines causes inconsistency.
Unorganized colour naming convention makes designers unsure which colours to use in different scenarios.
These significant issues needed to be addressed before we could consider white-labelling.
Discussing these issues with the product manager and lead UX/UI designer, I proposed a plan to update the colour system.
I consulted the team to set a realistic scope for colour changes, making necessary tradeoffs.
Considering that the team is fairly small, I needed to ensure that the updates would be feasible.
The system must be adoptable by designers and developers in a quick turnaround time.
- Product manager
The system should account for what designers and developers are already familiar with.
- Lead UX/UI designer and lead developer
Determining brand colours and scaling down colour system.
I confirmed the brand colours with the product manager, taking into consideration the preferences of our CEO and what best reflects the platform. The colour system was scaled down by removing colours that can be used for the same purpose, from 37 total colours to 25.
Setting up colour usage guidelines on a separate file.
I set up an excel sheet to keep track of colours and document colour updates, as both designers and developers preferred this format. This enabled designers to refer to the sheet for colour selection and direct developers to the sheet for any colour changes.
There were 2 key changes to the colour system.
Using mental models when assigning colour usage guidelines.
Colours were being used to indicate specific actions or statuses, but inconsistent colour usage can make it difficult for users to predict what they mean. I used mental models to address this confusion.
Creating a understandable naming convention that accounts for updates.
I created a new naming convention that allows designers to understand what the colour is used for and accounts for new colours added in.
Implementing changes to the existing screens.
Passing on the sheet to the rest of the design team, I reviewed the colour changes on the Figma file to ensure they followed guidelines and explained the changes to the developers.
Result 1
Design handoff made more efficient by 30%.
Calculated based on average number of colour related revisions to ticket or design after handoff.
Result 2
100% of designers thought the changes positively impacted their workflow.
After the changes were implemented, I consulted the UX/UI team again for feedback.
A revised design system that enables white-labelling and improves design effectiveness and handoff efficiency.
With a updated naming convention, easily understandable guidelines, and scalable system, the colour changes are currently in development and is the first step towards preparing the platform for white-labelling.
Learning when to make changes to a large design system.
Through this experience, I learned the importance of having a solid and effective design system. Without a strong foundation, the underlying issues will still remain. This experience highlighted an example of needing to step back and make the necessary changes for product longevity.
Working with the limitations and advantages of a small team.
Working at a startup with a small team meant limited time and people to implement changes. I had to adapt and account for these factors, making sure that the changes would be both impactful and realistic. At the same time, this gave me the opportunity to be hands-on for most of the process.