Group Party Playlists

Daniel Lin
Daniel Lin
Published in
8 min readJan 16, 2017

I was presented with the following challenge…

“You’ve been hired at Bose to design the software for their next portable sound system. This system features “party mode” — a group playlist feature that allows multiple people to control the sound system concurrently and play music on it. Design the interactions for the party mode feature.”

Below, I’ve documented my thinking & approach to solving this problem, and an initial design solution, which roughly took ~6 design hours (strategy: 1 hr, sketching: 1 hr, design: 2.5 hrs, prototyping: 1.5 hrs; documentation: 3 hrs)

Understanding The Problem

Before diving directly in the interface experience, I took some time to think holistically about what Bose as a company was trying to accomplish, and why users found value in their products. I needed to identify how people were using Bose wireless speakers, and better understand the problem that this solution is solving, and pinpoint when it would provide the most value for users.

On their online store, the unique selling points for Bose’s wireless speakers centered around expediency and personalized experiences, in addition to raw audio quality:

  • Features like wireless connectivity, “one-touch access”, and a companion app hammered home how easy Bose wanted it to be for owners to simply start listening to music — anywhere, anytime in the comfort of their homes.
  • Features like third party integrations, personalizable playlist presets, and a system for adding/controlling multiple speakers showcase Bose’s careful consideration of how their speakers are used in specific contexts and over time.

Bose Corporation designs and imports audio equipment and sells products throughout the world, and are best known for its home audio systems and speakers, noise cancelling headphones, professional audio systems and automobile sound systems.

To structure the problem, I first considered, at a high level, how the successful execution of this feature might tie to company objectives. I gathered that their core revenue stream must come from consumer electronics / hardware sales, and used that to inform the following:

I then took time to consider the pain points that currently exist when multiple users try controlling a sound system:

  • Cumbersome: typically, users need to physically track down the “music controller” phone and its owner to unlock the phone and instruct them where to go. A moment of inspiration can easily turn into minutes of fumbling around to change a song.
  • Disruptive: From the host being repeatedly pulled aside for their phone password, to constantly stopping & swapping songs before they’re done, it’s all too easy to interrupt the mood or flow of a party. Party pooper!
  • Messy: Having little to no structure for coordinating multiple song requests presents awkward situations — if they come simultaneously, should the next person wait around to “save their turn” in line? How do you avoid mistakenly skipping a song that someone specifically requested?

By this point, I had a stronger foundation to finally begin exploring & assessing potential solutions, with a mindset that embraces the values and spirit of Bose’s brands and products.

Quick Notes On Design Process

For this quick design exercise…

I jumped out the gates with pen/paper to process and document my raw assumptions and questions, and Google to answer smaller questions on the fly.

I along the way, I asked myself questions like how should group privacy work? How do you edit a playlist, from re-ordering to removing songs? Would users want to see already played songs, and how? How do we imply if a song “belongs” to someone?

My doodles grew in fidelity as I began tackling questions in more detail — from words & bullet points (processing the problem at a high level), to “micro wireframes” doodles (exploring navigational flows), to wireframe sketches (organizing UI elements).

Then bounced into Sketch to explore UI concepts in finer detail and visualize the necessary states…

I prefer working in a single .sketch file per project, to help me quickly reference design inspiration, previous explorations, and my progress over time!

And wrapped up in Principle to visualize microinteractions & state transitions…

I prefer Principle for “lo-fi prototyping” for VISUALIZING new concepts quickly internally with designers. Beyond this stage, I typically prefer Framer when refining (micro)animations at a systematic level, testing incremental variations, and complex prototyping.

Solution & Design Rationale

1) First Time User Flow

The single biggest risk to feature adoption is the initial friction necessary to “jump in” as a new user. We can’t expect users to have the patience at a party for long app downloads or complex intro flows.

Hey, I just met you, and this is crazy” — Carly Rae Jepsen

I initially explored a model where they wouldn’t even need to install an app — hosts would simply generate a phone-number to distribute to their guests, and all they had to do was text their song request that would be parsed, processed for a “closest guess”, and auto-queued to the party playlist.

To minimize initial friction for new users, I initially considered a model where they wouldn’t even need to install an app (imagine simply texting your song request to the speaker). However, I opted for designing an app experience — because providing new users with a richer & more engaging introduction to the Bose ecosystem would best promote long-term user acquisition.

Although I didn’t fully detail out this FTUX flow, I imagine it having the following high-level properties:

  • New users aren’t forced through account creation. They’re only prompted to provide a first name and (optionally) a photo, IF there are available “party speakers” nearby to “join in” and immediately connect with. That information is saved and users are reminded to “finish creating their full account” at a later time.
  • “Hosts” auto-accept any guests that join their party. Assuming any user near the speaker is trusted by the host in the first place, I pushed to minimize the amount of disruptions & required actions from the host, by automatically accepting any guests that “detects” and connects with the “party speaker”. Instead, hosts can manually manage permissions & remove abusers via party settings.
doodles

2) Layout & Core Interactions

Interaction flows should minimize steps/actions/friction necessary for the most common & repetitive use cases, supported by clear visual hierarchy.

I got 99 problems and unnecessarily complex interaction flows for common user actions shouldn’t be one” — Jay Z

  • Overall Layout

At a high-level, I wanted users to feel as though all and playlist management and speaker controls would take place on an individual screen.

A persisted menu combines a “shared party playlist” and the player controls so users can (1) track playlist changes and (2) control music in an easily-tappable area.

When multiple users are concurrently controlling the system, a shared playlist could look completely different in just seconds — so I felt it was important to persist the playlist at all times so users can see changes as they happen in real time.

The “shared playlist” displays displayed in a horizontally-scrollable timeline, allowing users to explore upcoming (what’s playing next?) as well as recently-played (what was that just now?) songs.

The width of a song’s album image indicates the relative song length!

The primary motivation for using this layout is for supporting simple playlist management, further explained below.

  • Adding Music

For searching, adding, and reordering songs, I pushed to create an impression of a one-step process rather than one with multiple, potentially convoluted stages. This is especially important for parties — assuming users usually only request a single song at a time, they’re looking to get back to having fun as soon as they possibly can.

To accomplish this, I combined the use of (1) drag-and-drop gesturing for quickly adding a single song (2) and single-action buttons for queueing multiple songs in a search result:

(Left) This direct manipulation interface combines (1) song selection with (2) granular control of song order in one!

When searching for songs, users can choose between “finding” a specific song or seeing smart “recommendations” related to what they’re searching for. Recommendations can be especially useful in party settings, when users want to fill out their playlist based on a general genre/theme/artist rather than searching for songs one at a time.

Music Player Controls

Core music controls include play/pause, skip forward/backward, and volume adjustment

Core music controls are at the bottom edge of the screen for reachability.

Scrubbing through a song pulls up a waveform image, generated from the song’s audio file, to help users skip to their favorite part of the song without jumping around too many times.

Users can jump to specific songs in the playlist and play them immediately, and see other relevant actions via button tray — designed to be horizontally-scrollable for future extensibility.

3) Considering Social Dynamics

Optimizing for speed shouldn’t come at the expense of another user’s experience with simultaneously using the feature.

We’re alllll in this together!” — High School Musical

When users add a song to the shared playlist, their picture appears on the album visual — this helps (1) users realize when they’re skipping someone else’s song and (2) provides more social context behind newly-added songs.

To minimize party disruptions, the drag and drop interface prevents users from immediately stop-and-playing their song (although still possible two taps away), and instead guides them to choose a spot in line.

4) Considering Context and Designing for Experiences

To further promote engagement, don’t forget to find opportunities to delight & enhance the party beyond simply solving for group playlist management.

Where the, where the party at!” — Confucius

Seeking ways to further promote feature engagement in party contexts, I started drawing inspiration from karaoke lounges — where occasionally throwing in sound effects like applause (using the remote controller) as someone’s singing has the unique effect of playfully egging on the singer while getting everyone to join in on the fun.

I expanded on this idea and explored a “party shortcuts” feature, that allows anyone to play preset sound bytes that would add fun to the party! This feature hopefully encourages all guests, especially those who don’t typically request songs, to also engage with the app feature.

For generating presets, I thought back to the “classic moments” of my own party experiences, like how someone inevitably plays “Ignition” at least once, or tries starting a freestyle rap session.

Etc

UI States
Prototype

--

--