Challenge: When it comes to music streaming services, Spotify is a household name that resonates with people of all ages, all around the world. And for good reason. Spotify’s data-driven features have enabled users to discover new music that identifies with them on deeper, more personal levels.

Objectives:

• Design a social feature that is centered around music, in favour of human relations, and emotional connections

• Seamlessly integrate the app into the current Spotify UI

Before I went to collect first-hand data with users, I did a quick Heuristics Evaluation of Spotify’s usability to properly understand the strengths and weaknesses of the app’s current standing. Using established guidelines, in this case Jakob Nielsen’s 10 general principles, I took down a short analysis of how Spotify performs in each category. The result was overwhelmingly positive in favour of Spotify’s easily recognizable, and visible, controls. But lacking in terms of error recovery and help documentation.

With this in mind, I set out to interview 5 participants with the goal of answering my research goals (that I previously outlined in the research plan) and validating the information that I collected during secondary research. The results were collected in a raw format, and later used to create an Empathy Map.

Due to the confines of time and participation however, I was only able to secure a group of interviewees that were all of Asian ethnicity, female, and in the millennial age range. Furthermore, I was unable to authenticate the trend of an upwards tick in usage of TVs and Gaming Consoles, although it is not certain whether these factors played a part in it. However, I proceeded with the data collected with these users since there was no indication that gender or ethnicity would skew the results in a noticeable way; Spotify users have a close split between male (56%) and female (46%) users, and none of the collected information has suggested that ethnicity played a part in Spotify usage.

Having consolidated a list of features in the previous brainstorming sessions, I facilitated a group session to further validate the features I came up with. I invited 5 individuals that have Spotify Premium, to join a group feature brainstorm session with the context of being Spotify designers.

I first explained the scenario - the design challenge posed by this feature integration, alongside the limitations that the group must keep in mind (resources, seamless integration, uses existing technology). Then I gave them the same HMW questions that I posed to myself during my personal brainstorming sessions.

Before I began the Interaction Design portion of my process, I first needed clear and concise definitions of the Business and User goals, along with prominent technical considerations that may come into play. These goals will establish a criteria of what my design will accomplish, what features I must incorporate into the design, and a priority list of which features are the most important, and those that are not necessarily needed.

Having defined the various user and business goals, I further filtered my list of features with these goals as the criterion.

The features were then reorganized into a priority-based list in accordance with the following metrics: user goals, business goals, effort level (needed to create the feature), and confidence level (how much assurance I had in creating the feature).

In the final iteration of the feature list, it showcases a list of high-priority features necessary to solve the problem and conform to the criteria, along with the middling and low priority features that can be incorporated given enough time and budget.

From here on, I began crafting an overview of the app’s existing sitemap, and how the new features would place into this layout. Because seamless integration is the most important goal, I had to ensure that the my new features were placed appropriately, otherwise it would risk skewing the user’s overall experience with using the app.

Spotify’s layout on mobile (android) is fairly simple, 3 main screens are used to divide up the different functions that a user can access; the main screen directly leads into music playlists and associated screens, the search screen has all of the searching, filtering, and sorting options, and the library is a collection of all of the user’s followings. And therefore, I split my features into their primary functions, and divvied them up accordingly.

Affinity mapping allowed me to pinpoint several areas of concern: 1) Overwhelming Dependence on the Search Function, 2) Users look for the shortest route to their goal, 3) Confusion with the “music poke” feature.

To solve these issues, I made a list of actionable adjustments including: the enabling of the search function to find groups (unfollowed and followed), adjusting the group playlists on the home screen to include a link to the group, and re-labelling the poke button to indicate it’s unique functionality.

After putting together the Affinity Map, I went on to create Spotify’s style tile, to ensure that all of my elements were cohesive with the brand.

The UI Kit incorporates the atomic and molecular elements that were used for the creation of the new features as well and, at a glance, incorporates quite well into Spotify’s UI. As the app goes through further tests and iterations in the future, this document will change and reflect the new additions as well.

I implemented the solutions that I devised during the Affinity Map stage, and changed both the hi-fidelity wireframes and prototype.

The next step would be to formally hand off the assets to the client or developer. This would be followed by continued testings of the design updates since the last usability testing, update the UI Kit, and continuously cycle through iterations and testing for as long as resources allow.

Seamless integration into an existing app wasn’t as simple as I had imagined. Even during Lo-Fidelity sketches I realized that many of the features I had in mind could not be implemented since it would compromise the current design of Spotify’s layout.

In retrospect, I should have thoroughly researched into the app, information architecture, and branding of the site before ideating on feature solutions. This would enable to me grasp, more clearly, the look and feel of the new feature, and more importantly, how exactly it would integrate into the app.

This was most evident during usability testing, when users were showed confusion at how they were supposed to communicate with a group’s moderator through a poke function.

Overall, I do believe that I’ve gotten a good grasp of understanding how to integrate designs properly into existing applications, and will definitely rework my flow next time I have the opportunity to work on a similar project.