top of page

Design System.

Creating structure where there was none.
DS green.png

Imagine a world with no rules, no templates, no structure. Sounds fun? It is… for a while. Until you realise you have:


11 shades of a primary colour, all of which should indicate the same thing. 


8 different types of a card, most of which aren’t even cards. 


45 Button variants, with 0 distinction between links and buttons.
17 drop-downs that vary in style and behaviour.


Links are not links but some texts are links.


A variety of styles and plenty of missing states.
Inconsistent interactions.

No rules.



​

Designers are consulting the stars. Developers are winging it. QA have no idea what’s going on. And users are in despair. 

​

This was my world - our world, at Sastrify.*

*Sastrify is a leading European SaaS management software startup helping hundreds of customers achieve cost savings through benchmarking, negotiation and procurement support, renewal tracking and tool recommendations.

Context

I was a senior product designer in a design team that started as an army of 2 trying to do their best to provide an excellent user experience, fast. As the company grew and consequently the design and engineering teams acquired more members, working without a design system became increasingly painful. Each new feature was slightly different and the product was slowly turning into a patchwork of styles. Due to an abundance of hardcoded elements and next to no guidelines, any attempts to streamline this were complicated and time consuming.

​

In an effort to resolve this once and for all, I proposed we finally implement a design system and stepped up to lead the process. Throughout the process I was supported by my fellow designers and engineering leads.

Approach

Application audit

Pitch to stakeholders & buy-in

Evaluate possible solutions

I worked in a team of 4 designers who all very much felt the lack of a design system and supported me throughout the process. We carried out an application audit, listing the biggest discrepancies and pain points resulting from an inconsistent platform UI and UX.

Using our gathered evidence, we presented the problem to senior leadership and were given the opportunity to dedicate some time and resource to a design system. I was assigned as project lead and took it from there.

Based on our existing platform, I identified the most common components as well as components that may be required in future, given our strategy and direction. Since the majority of our components were fairly standard, utilising a pre-built design system was a valid option. I took it up with our engineering team to review and decide on the best option.

Bespoke or Pre-built

Bespoke

  • Freedom and flexibility in defining actions, interactions, behaviours and styles

  • Could better represent the Sastrify visual identity

  • Great learning opportunity

  • Allow us to define the adoption guidelines as we go

  • Longer to implement and requires more design resource

  • Continuous design & development resource will need to be accounted for new components, edits etc

  • ​Will require more extensive testing

Pre-built + customised

  • Faster to build and style
    It will be quicker to implement, if supported by existing react libraries (MUI, ANT, Carbon, etc)
    Many systems have a Figma and react library ready to use

​

  • Pricing

  • Less brand identity

  • Time invested in adoption of new guidelines
    Reliant on external versioning / updates

As we were leaning towards a prebuilt system, I used material UI to mock up parts of our platform and evaluate whether the components work well with our existing features. I was able to address most use cases, however there were some interactions and features in flight that would need a more custom approach.

​

We decided to leverage an existing, relatively low cost system (Material UI) and adapt it to Sastrify styles. In addition, we also accounted for the possibility of creating new bespoke components or molecules and organisms from the existing material UI components.

Create consistency

I mapped every component currently used and clustered them into categories. ​

 

We had a large number of components that achieved the same result (example: 17 dropdowns). I analysed these to understand how they can be replaced with a single component within the design system.

 

We had 45 different buttons to replace. I reviewed these and split them into a structured 3 tier hierarchy (primary, secondary, tertiary with set guidelines on how and when to use them

 

This helped me create a shortlist of components to take from a prebuilt library and those that needed to be created as custom components.

Redefine colours

I noticed that the application was extremely overwhelming and it was difficult to distinguish what was important from secondary actions. In order to address this I proposed we redefine our primary colour in addition to the hierarchy changes.

image.png
image.png

In addition, we were using many tags that did not match accessibility standards. I redefined these colours and selected appropriate background colours to an AA standard.

​

I added this proposal to our initial proof of concept, tested it and received approval from leadership to include this change. This would also support a clear pattern of “Good, informational, needs attention and optional” actions and messages.

Define layouts

Almost every view in our app used a different layout. This was not responsive, compromised readability and made it difficult for users to work with different parts of the platform.

​

I defined a set page layout with guidelines on header information, actions placement and components sizing, based on a 12 column grid. The layout was designed to work on our smallest used screen and scale responsively.

Prepare for implementation

With a clear direction and a huge to-do list, it was time to set up our new design system in Figma and Storybook.

I set up a Figma library with a section dedicated to each one of them. Using material UI patterns as a base, I styled the components for Sastrify, optimised Figma components for our designers, wrote guidelines to ensure consistent usage and prepared Jira tickets for development. In the meantime, our engineers set up storybook, following the structure I provided.

Figma Setup

Figma Setup

Challenges

Styling and guidelines required more effort than expected

Material UI provided guidelines but they were often use case specific. I had to understand our own use cases, select the correct guidelines and adapt them to suit. There are also a variety of accepted practices out there to choose from which needed to be defined.

I wrote our own detailed guidelines that defined when to use our primary, secondary and tertiary colours, how we use typography and which styles are appropriate for different use cases.

Guidelines

We faced a transition phase where new UI was entirely different from what was previously used. Most notably, we decided to change our primary colour from orange to green. With the risk of our users being even more confused, we had to thread lightly and find a good way to phase out old UI.

Our teams were split between working on smaller improvements that were part of existing features and new standalone features. We decided to use this as our starting point to shift the UI. New features would use new UI while old features would use new patterns but retain old styles and colours. However, we standardised the existing colours and limited them to a set hex code, that could be changed easily in future.

Old was inconsistent but new was entirely different

Old

Transition Period

New

Continuous accumulation of tech debt

While we were trying to fix the inconsistencies and promote a design system, several projects were in flight. Projects with old designs or development already on the way or developers and designers following old ways of working.

Within the design team we reviewed every upcoming project and identified required components. Based on project timelines, I created and prioritised components in Figma that were required first, so that they could be built and added to storybook as part of the upcoming project. This enabled us to leverage the resource of other teams, for work that they would have to carry out anyway.

Implementation

We formed a dedicated design system team, consisting of myself as project lead and two engineers supporting development. Together we ensured both design and development were always aligned. We prioritised work according to product requirements while also planning for larger initiatives such as major UI updates, redesign, UX improvements and large scale component swaps that would all be needed in order to fully adopt the new design system. 

Results & Impact

Our interfaces started adapting a more coherent model which reduced information load. This improved our users learning curve and their general experience interacting with our app.

We introduced new patterns aimed at helping users understand the urgency or importance of an action and guiding them to become more self-served and autonomous over time.

​​We revised a colour palette that met the minimum AA standards of WCAG guidelines in components and texts

Usability

Not only did we have a library to draw from, we also had pre-set and customised components to work with both on design and development side.

  • Concepts that took a week before now took 1 day

  • 2 sprints to develop turned into 1

This enabled us to spend more time on things that really mattered and custom experiences where they made a difference. We could quickly prototype, experiment, learn and iterate.

New members in design and engineering teams were onboarded much quicker, having a library to use instead of having to approximate existing patterns and verify with the team

Velocity

​Design system brought a single source of trut with tried and tested components that can be used for any project.

  • From 11 shades of primary colour to 1, including a change of primary colour that ensures we can use standout colours for actions and information crucial to our users.

  • From 45 different buttons & 7 categories to a structured 3 level hierarchy (primary, secondary, tertiary)

  • From 17 dropdowns that vary in style and behaviour to two

  • From a variety of layouts on cards to 1 customisable style that adapts based on requirements and context.

  • A new defined layout with set behaviours for different screen sizes and an agreement on placements of actions

Consistency

Buttons old

Before

After

Containers new.png
New dropdowns.png

After

Dropdowns old.png

Before

Before

Buttons before

After

Buttons new.png

Final thoughts

Building up a design system was not only an impactful and exciting challenge to tackle but also one of my biggest learning experiences. It gave me the opportunity to work with an entire platform all at once, while considering both internal and external stakeholders, managing expectations, navigating feedback and considering all of the moving parts of a living app being changed on the fly. 

​

This case study focuses on the proposal and implementation of a design library and a few global UX improvements. But it does not stop there. Our follow up projects tackle some of Sastrify's most used and most impactful features and their redesign, in order to improve the overall user experience and elevate our platform. You are more than welcome to continue your read about it in my platform redesign case study.

bottom of page