Medicspot design system case study

Creating a custom design system for both internal and external products




Web and mobile





My role

I worked on this project as a sole designer. I worked mainly with the development team from project planning and requirements gathering to testing and implementation.

  • Research
  • UX and UI design


Medicspot partly uses Google’s material design system, but there were no guidelines on how to use it. I was the first product designer in the company before that it has been a mix of product managers, developers and the marketing department designing the products, and this led to inconsistency across the products.

Not having a design system also increases the design and development time.

The challenge

Speed and scale

The company wants to be able to scale development and designs and quickly create solutions for existing and new initiatives.


Even if some of the products use Material design components there was a lot of inconsistency in the products. Material design is a flexible system that gives a lot of options, we needed to decide what we use and how the components are used together.


Being a healthcare company there was a need to make sure that the products created are accessible.


To better understand the problem, I had discussions with developers and other parts of the business to see what we needed. I researched and analysed existing popular design systems, I also looked back at what I learnt creating design systems in my previous companies.


I audited the products on different platforms and looked at what is currently being used in the code base and made a list of used components.

Heuristic analysis

I completed a heuristic analysis of the UI, to see how it compared with standard design principles and I listed out the potential problems.

Key findings

  • Inconsistent UX patterns make it harder and more confusing for users
  • Inconsistent UI doesn’t give the user confidence in the company
  • No guidelines and no common components make design and development harder
  • The products are not accessible, making the product harder to use

Ideation and design

We looked at future initiatives and discussed what components we were going to use and made a prioritised list. I structured the design system into:

  • Styles (Commons styling like font, colours, icons)
  • Components (Building blocks like buttons, forms and lists)
  • Patterns (Building blocks put together into patterns)

I researched and we discussed components and I started building out the design system in Figma. I created components with variants. I had a constant dialogue with developers to make sure it would be straightforward to develop.


I identified which colours and fonts we had and what we needed, I kept the structure of the Material design system, but customise and removed the styles not being used. I created font sizes using typescale to create a clear hierarchy. I made sure accessibility standards were met. Together with the development team, we decided on a naming convention to name components the same way in Figma and in code, for easier communication.


We already had components from Material design, I removed the components that we were not using at the moment and I started to work through each component. Some of them I wanted to change to fit the business better. We knew we were going to work closely with the NHS, so I spent some time understanding how the NHS used different components. Accessibility was an important factor for the company, so I did more research on the best practice when creating accessible designs.

Form elements were something that we had user tested in other projects and decided to follow the NHS route with labels outside the fields


I knew from my previous company that patterns are important for consistency and speed. I have also seen that even if we use components, there are many possibilities to put components together in different combinations causing inconsistency for the users. I created a list of commonly used patterns and created components for example cards, sections and pages.

Test and improve

I used the new components when designing, in that way we got parallel feedback from user research from other projects.


A developer created the components in Storybook and from there the developers could start using the new components early on in the process. Using Storybook gives developers and designers an interactive library of components in addition to Figma designs. You can see live how interactions look. Another very useful feature is Storybook’s accessibility function, for example, you can see how someone with blurred vision sees the component. Using Storybook gave us quick feedback from developers working on real features that have been released. We kept a close eye on how new releases performed.

Outcome and learnings

  • New products could be designed and built more quickly using the components
  • Helps us keep consistency across different platforms
  • Changes to existing components could be done quickly both in design and code
  • Helped me as one designer to support the different projects
  • Helped developers become more aware of UI changes
  • We could tweak the current theme to quickly create a starting place for a theme if needed for a new initiative

Reflection and learnings

This project was an initiative from me and the developers, to create something that would make our life easier and to be able to deliver everything that the business needed, so it had to be squeezed in this between other projects. I think we would have benefitted from getting a bit of a head start with the design system instead of doing it in parallel with other projects, to avoid going back and forth redoing designs and code.

A process on how to maintain and improve the system is important going forward. Make sure everyone knows how to use it and report gaps and improvements.

An idea could also be to look at A/B testing to tweak components to get the best result.