Master's thesis – Spotify
Spotify forever changed the way we think of music when releasing their music streaming platform. Their huge success has inevitably lead to big competitors like Apple, Amazon and Google to step up their game and enter the fight for listeners.
Being a fast-growing product company like Spotify, with a fleet of 250 (and counting) autonomous teams in an agile environment, means great potential in terms of what can be done. However, steering the vessel becomes trickier for each additional team and demands more from the organizational structure, as well as from the suite of technical solutions. The Platform Developer Experience tribe at the company, with an overall goal of providing the best possible conditions for these teams to perform well, suspects that this autonomous set-up creates bottlenecks, ultimately hindering the end-to-end productivity. This tribe wanted us to find and better understand these bottlenecks, and furthermore to design and present features of an enterprise software aiding in their elimination.
What: User research / Product design When: January 2020 - June 2020
Project preparation
The project started by talking to several stakeholders to understand their expectations and view on the project to be carried out. Given the limited time frame of the project and the expected deliverables from Spotify’s side, as well as from Chalmers, a time plan had to be mapped out, including internal deadlines making sure we progressed as planned. The idea was to go through a full design thinking cycle, with an etnographic lense guiding the chosen methods for each phase.
User research
In order to fully understand and to be able to map out the problem space of productivity blockers, a thorough data collection had to be done. Since the users and target group of our study was developers of Spotify, it meant we had to talk to them. A lot of them. This was done primarily through semi-structured interviews, contextual inquiries and focus groups. The latter was considered more fruitful since it allowed several users to elaborate on each others ideas and it opened up for additional perspectives of a given topic.
An important aspect, initially expressed by Spotify, was to talk to a wide spectrum of developers; ranging in tenure, coming from different discplines and office sites.
Trip to Manhattan
To not risk capturing a new ”Stockholm syndrome”, we traveled across the Atlantic to Spotify's office site in New York. During our visit, we ran additional interviews, focus groups and guerrilla research sessions across the different floors in 4 World Trade Center.
We also got the chance to present our initial findings to the Platform Developer Expeirence teams based in New York. This opened up the chance for them to give feedback and further feed our knowledge of the problem space.
Analysis
Data collected from 49 different developers was transcribed and analysed using affinity diagramming and thematic analysis. Quotes addressing similar issues were clustered and themes started to emerge. To risk mitigating bringing biases to the table, this was done seperately between the two of us for the first few transcriptions. The results were then compared and a shared code book was created to use on the rest of the data.
The larger themes were evaluated based on their predicted return of investment (ROI) and impact. After close discussions with the main stakeholders, it was decided to move forward with the problem of code exploration & evaluation – one of the sub-problems of the umbrella theme Discoverability.
Problem statement
Developers have different ways of approaching exploration of code and reusable components, arguably because they are coming from different verticals and are writing different kinds of business code. But there seemed to be some shared issues that made the situation a lot trickier. In short, the problem of code exploration & evaluation could be divided to four fundamental issues, namely:
- It is difficult determining best practice exemplar.
- It is problematic to find example code.
- The current Spotify search tools are inadequate.
- Developers are missing a natural marketplace for reusables.
The lay as much of a good foundation as possible for the ideation phase, it was necessary to convert the problem of code exploration & evaluation to an actionable problem statement using Point of Views (POVs) and How might we questions. These were the two POVs brought forward:
- Developers at Spotify need to be able to more easily discover reusable code components because it would prevet them from having to reinvent the wheel.
- Developers at Spotify need to be able to evaluate code because it would help them in their choice of which code to utilize.
Ideation
Using Crazy 8's and the POVs, we created a myriad of different ideas to explore the solution space. Despite having come up with a few promising ideas, we decided to invite a few developers and stakeholders to the ideation in a remote design workshop.
What followed was the work of merging, abandoning and refining ideas. Once three concrete ideas had made it through the screening, six design critique sessions were held with developers. During theses sessions, the ideas were presented briefly and some low fidelity paper prototypes were shown. A discussion regarding their general thoughts and concerns followed, and these opinions were used as support when deciding the idea to proceed with.
The Use Case Marketplace
The idea we decided to move forward with was a new concept called The Use Case Marketplace. The idea is quite simple, instead of trying to find reusable code components through their names, which many times are arbitrary and far from descriptive, the developers can now discover reusables via a new storefront; namely their use case and intended functionality. This way, we utilize what the developers already know when starting their search journey, that is, what they are looking to do and what functionality they need, and remove the current necessity of knowing the name of the reusable.
The concept was prototyped and taken from a low fidelity to a medium fidelity state. The medium fidility prototype was then user tested and evaluted with six Spotify developers. The developers were taken through a discovery journey of trying to find a use case, see picture below. The focus of the tests were to examine the usability and the test participants’ overall perception of the concept as a whole; was this something the developers could see themselves use? One of the major learnings was the need to rethink how a developer narrows down the number of results. Being able to add addtional filter chips both through the search bar and via the dropdown menus was percieved as confusing and needed to be addressed for the final prototype. Overall, the learnings from the tests were used to iterate and tweak the concept before taking it to a high fidelity state.
Final prototype
The Use Case Marketplace concept consists of two parts: (1) the marketplace where the developers search for and find potentially useful use cases, and (2) the use case page itself where the developer would read up on the use case.
Searching for use cases
A developer narrows down the number of use cases by adding keyword-based chips in the search bar, describing what functionality they are looking to achieve and the current constraints they have. The system then presents the developer with several cards, each representing a use case matching the specified chips.
Conclusion
The final concept was presented for Spotify stakeholders in the begin of June and was very well perceived. The future of the concept remains unclear, but the work to put more focus on discoverability across the Spotify ecosystem has already started.
Alongside the final concept, 15 user experience factors to consider when designing for discoverability in enterprise software was extracted and served as the main result for the academia and the final thesis report. If you are interestest in the report and the 15 factors, feel free to let me know and I will share the report with you.
