Bringing more value to users while utilizing existing systems
Spring 2019
Adding a Feature, Utilizing Design Systems, Focus Groups
Demonstrating the design process used for my co-op at LenelS2, this feature add for Spotify allows users to pair songs together.
the problem
While most albums are laid out with purpose, some artists decide to take the concept further and have songs seamlessly flow from one to another. But when these flowing songs are added to a playlist and put on shuffle, it results with an unsatisfying ending of each song.
Not sure what I'm talking about?
Give it a listen:
existing ui evaluation
While I have used Spotify for the past several years, to kick off the project, I went through Spotify's three applications, making note of any UI that could be of use to the pairing workflow.
lo-fi iterations
To start out the workflow planning, I identified the four steps for song pairing:​
Choose the first song​
Choose the pairing option
Choose the second song
Give the user feedback
Keeping Spotify's existing UI as a backbone, and the four steps to a perfect workflow, I created the first iteration on InVision's Freehand tool.
​
During the making of the first iteration, I quickly found that between the three application types for Spotify, there were subtle differences throughout. Things like the amount of features available, user feedback, and even down to the placement of the ellipsis icon. While these things made each application's workflow have some quirks, I thought it best to keep each workflow fit more naturally within each application's ecosystem.
left to right: Native Desktop App, Web Browser Player, Mobile App
hi-fi iterations
In order to allow maximum flexibility and realism, I replicated Spotify's screens by taking screenshots of key screens on their native desktop, native mobile, and web player applications.
​
Before the third iteration, I called this feature "Song Linking" but then I found that Spotify uses the link icon and term when speaking about URL links. Because of this, I decided to correct the homophone (same name different meaning) by using "Pairing" instead.
Due to Spotify's usage of "Link", I decided to go with "Pairing" instead. Using a musical note tie as the icon.
Once the fourth iteration's designs were completed, and my peers were giving it feedback, it became clear that having each song be paired and on it's own line, would cause confusion. Do fix this, I toyed around with putting paired songs together on the same line.
- or -
When showing off the third iteration, those giving feedback had a lot of questions what the UI would look like given certain edge cases. To fill in these gaps, I added an appendix in the fourth iteration.
left: Pair Song UI for Web Player (top) and Native Desktop App (bottom)
right: Example of edge case for the appendix
lessons learned
1. Access to programmers and past designers is crucial
Throughout the design process there were many times where I felt like I needed to talk to knowledgeable people.
Deciding if combining the two songs together on the front end would have been a helpful time to consult with a UI developer
2. Working around inconsistencies
When going through the three Spotify applications, it's easy to see the differences between them, and with the dropdown options and usage of feedback, I resorted to keeping things consistent with the application.
left to right: Web Player, Native Desktop, and Native Mobile
3. When designing workflows, be sure to mockup those edge cases
While it's easy to think about the most direct path in a user flow, interviewee questions brought to light the importance of an appendix, where I can demonstrate what happens when the user goes off the beaten path.
above: How the native desktop looks with a 5 song pair chain.
left: How the native mobile looks when the user pairs a song to an existing pair chain
and in the end...
