me&u Design System

After 4 years of development, me&u had a lineup consisting of 4 products with no shared design system. I lead the development and internal adoption of the design system from concept through to execution and its ongiong development. This included the initial plan, designs, documentation and ongoing development plans.

Development

To get things started, I started looking at building out some guidelines — as our digital products grew, our experiences started to diverge, both visually and interactively. We lacked a central depository that a design system would provide us, and implementation was often different between squads, however, building out and implementing a design system is an extensive undertaking, given that the whole projects development was not green-lit yet, we needed to take steps that would contain usable deliverables at every stage to ensure a consistent value add.

The benefits investing in a design system would deliver to us:

  • Single source of truth
  • Redesigns and updates could be better managed at scale
  • Designers were able to free themselves up from visual appearances and more on solutions.
  • Consistent look & feel across products and squads
  • Faster implementation and replication by using off-the-shelf patterns
  • Reduce wastage

For the first milestone, we built out the colours, typography and basic styling rules (spacing, layouts, elevation, etc). I also wanted to modernise our implementation in the codebase by evolving our variables into tokens, allowing us to continue growing the design system and codebase in an accessible manner.

Colour tokens using Figma Variables

Following this initial development phase, we decided to take the approach of ad-hoc implementation, any new projects would require updating references to the new tokens — by doing so, we aimed to reduce the upfront development cost while still gaining value through staggered implementation, allowing us to continue prioritising relevant projects across our squads.

The next step was to start designing out the components of the design system, starting with a full audit of all the components we currently used for redevelopment. Through conversations with our development team, we evaluated whether we should either restyle our existing components (still using the current open source library), build our own, or, look outwards for another framework that better suited our current usage.

What we decided:

  • We’d primarily build our own framework from the ground up using React, with Storybook housing all of our design system in the codebase
  • For complex patterns, we’d evaluate developing our own, or using external libraries to jumpstart the development effort. (For example, we’d eventually use libraries in the future for our date selector)

We decided that for implementation of our patterns and upcoming components, we would continue with our ad-hoc implementation as we felt that it best suited our development targets for the design system, while maintaining a healthy capacity on the roadmap. We’d also expand on this philosophy by staggering development of components until we had a pattern or project that required its development.

With our components, we wanted to set some ground rules before opening the floodgates to ensure that our design system scaled as intended, without the challenges we found ourselves with before one was in place.

Our component philosophy:

  • Reduce the overall amount of current implementations
  • Consistent experience across device sizes
  • Avoid wastage with ‘one-off’ patterns by describing a designer contribution workflow
  • Any contributions should be peer endorsed to ensure the overall integrity of the design system

Today, we continue to evolve the design system — the benefits we’ve felt as a product team have lead us to faster design & development cycles, and to the merchant, a more consistent and expected experience. In practice, this has also lead to growing design democratisation, allowing product & development teams to visualise and contribute to projects with confidence.

Read more
Navigation