context

Juke was founded on Stanford's campus after Conner Smith realized that parties never seemed to have the right playlist. The people changed at every hour, and with it, the music taste. The DJ (or really, the person most willing to leave their phone at the speaker) would be left guessing what people wanted to listen to next, and so Mr. Brightside would play for the four hundredth time.

With his co-founders Kojo and Teddy, Conner decided to create Juke: an app that would allow people to simultaneously add to a live playlist, and vote on or off songs. No more swapping the aux cord across phones, or pushing through a crowd to request a song be played or skipped. By joining a stream, party attendants could easily influence what songs be played to make their night.

ORIGINAL DESIGN

The team first brought on friends who'd dabbled in design to mock-up potential UIs. They wanted Juke to share a similar brand identity to many of the music apps in the market so college students would easily migrate from their personal music hosts. They decided on cool-tone gradients with a darker user interface, and emphasized user participation. Juke earned hundreds of downloads.

However, they came across a couple problems: the flow was congested. Users struggled with how to add music and where exactly in the app they should be finding streams. What's the difference between a stream and a library? How do I find nearby streams? My stream? A different streams tab? How do I add friends? Huh?

Through a friend's recommendation, I was brought onto the team.

REBUILDING THE
ARCHITECTURE

Collected user feedback showed that users most struggled with three main challenges: five tabs that were not clearly defined, navigation UIs that were unintuitive, and the sense that there was "too much going on."

To simplify the interface, I set out by first defining a user journey. The team agreed that Juke's main use case was at college parties where someone wanted to request a song.

Storyboarding the process clarified what user interfaces would be necessary to accomplish the user's journey. The user needed to be able to accomplish five primary actions:
‍
- search for a stream
- join the stream
- make requests (add music)
- downvote music
- upvote music

By defining these tasks and researching how existing apps such as Apple Music and Spotify accomplish them, I was able to ideate and sketch how they would be accomplished in our app.

Primarily, I wanted to: simplify the navigation bar from five overarching tasks to three, emphasize the music and its art, and give up/down-voting an engaging treatment.

Simplifying user flow

Because the original design hosted multiple tabs with overlapping utilities, users were often confused as to where they could accomplish which tasks. I reorganized the app's functionalities into three categories according to their priorities: actions to be shared with the public, actions to create a playlist (or "stream" within the Juke environment), and personal actions. This clarified which screens were directed where.

We tested the wireframes against a target group of twelve regular users who verified that the simplification had eased usability. From here, the team and I met to discuss details in the user interface, such as: (1) general aesthetic to match the existing app, (2) making a button to create a stream readily available, and (3) how up-voting and down-voting songs would work. We, again, drew from the UI of market-leading music platforms college students would already be familiar with.

1. GENERAL AESTHETIC

The general aesthetic would remain within the Juke style guide, using cool-tone gradients with a darker user interface. The font was changed to Avenir Next to modernize the feel. The functionality of the gradient was also elevated to highlight key information or areas of action.

2. STREAM BUTTON

A universal "plus sign" button was added to the upper right of the Public page. This button would immediately transport the user to the Stream page. Conner and Teddy emphasized the app's ambition to be constantly hosting streams, so this action was a top priority. This button could functionally be placed throughout the app when needed and would be easily learnable for users.

3. voting

This interaction was taken from commonly seen trends in email forums, dating apps such as Tinder, organizational apps such as Pinterest. "Swiping" has become a popular way to archive information, make a decision, or enter additional paths of interaction. Within the Juke ecosystem, swiping on a song: (to the left) would up-vote the song or (to the right) would down-vote the song. In this way, unpopular additions to the playlist would make its way down or be removed. Popular song could climb their way up through designated thresholds (ie. 5 up-votes could get the song to the top of the playlist) through crowdsourcing.

This ultimately solves Conner's frustration of having to hear Mr. Brightside for the four hundredth time.

CONCLUSION

The final product increased engagement and successfully guided users through prioritized actions. Users also enjoyed the overall aesthetic of the app, saying, "I'll probably use it more now that it's prettier." That's always good to hear as the designer, you know?

thanks, conner

Founder Conner Smith expressed, "I want this app to be something I'm proud to share with my friends and peers, and this redesign makes me feel that way."

Thanks, Conner, for a really cool app to work on. I loved drawing from what I'd gleaned using my favorite apps like Spotify, and applying the design insights to a new app dedicated to users like me. We've all left a party because the music wasn't what we'd imagined for a deserved night out with friends. Hopefully, Juke solves that and we can dance until we can't tell what hurts more: our cheeks from laughing or our feet from dancing.

Juke