Easing the use of Multiple Applications By Unifying the Experience
Design System case study
business goal
Easing the use of multiple applications by unifying the experience
project ROLE
I researched and designed a component in the Spotify Design System. I also coded this component in React/Typescript & Storybook.
overview
Spotify is an audio streaming product that started ut by easing access to music and have since moved on to becoming the best go-to streaming platforms for not just music but in recent years podcast and soon audio books.

I was within the Content platform team which focused on supporting the content teams that were focused on artist tools and tools that enabled and supported internal team for compliance and knowledge.

I did a 3 months internship between June and August 2021 while on my summer break in between my UX Masters education at Jönköping University, Sweden.
project goal
Unify the experience across several tools.
Achieve higher efficiency, consistency and scalability when building more or expending more tools.
Discovery
Study/ Review
For this review I decided to focus on two things:

1. What the several existing variant of the component to be designed looked like across different products and try to understand how they are being used.

2. I decided to study how other component had been added into the design system and what that process looked like through various stages. The goal here was to understand how the design system is handled and improved upon within the team.
understanding/DEFINE
Stakeholder Interviews
In this phase, I had a call with all the product designers that had a variant of this component in their product.

The goal here was to understand what their need of the component was and how it related to the purpose of the product they were building.

At the end of analysing all the information, It was clear every designer wanted different things for the product they were building.

Working with design systems, designers are the users and not just any user but expert users. With this knolwedge,
DEsign
First Sketches
Using the knowledge I had gained from the designers on their needs of a component I went ahead to design a first version combining to the best of my knowledge what was important.

As the component had several variant existing prior to my task beginning. I decided to draw out a version that I thought suited all the designers.

This version had size variants in big, medium and small as well as other elements that could be enabled or disabled.
TESTING
Iteration 1
One common feedback was that content team involving in reviewing thousands of content daily had to easily be able to identify what type of content they were looking at without thinking so much.

To make this more recognizable, I proceeded to add different icons representing content types like Track, Artist, Album, Vodcast, Podcast alongside the content type.

With a first version, I went back to my users ( yes! the designers) with a prototype and allowed them to test and try it and then asked questions afterwards on how they saw this fitting into their products.
testing
Craft Session
For a second round of feedback, I hosted a workshop session with all the 4 designers.

The task was to screenshot a part of your product and recreate the component in your screenshot with the component I created.

The purpose of this was to see how the component could fit within existing products without it being broken/detached.

At the end of the exercise, I noticed that some designers had to still detach and edit the component to make room for some elements which wasn’t in my version.

Conclusion
At the end of designing the component, a maturity level was assigned to show that the component would have further changes in the future as the products that incorporated this component were still being shaped and tweaked.

I further went to developing this component in code with React, TypeScript and Storybook and at the end added this to the Git repository.
“A design system isn’t a project. It’s a product serving products.”
— Nathan Curtis, EightShapes
... and as such, you can only get to a satisfactory point and then you grow again from the last point.

If the products that gets defined by a design system keeps getting improved upon, how do you expect a design system that backs such product not to get updated also
Learnings
Working within Spotify for this short period taught me the following lessions:
Associated Articles