Project

CrossPop

An application that helps the user to share music across platforms.

Music has become an essential part of our lives, whether at work or at leisure, we want to put it on our favorite song list and do what we like. With the popularity of music copyright, the music platform is divided. And our tastes will not be cut with the platform division.

Crosspop is a music aggregation application geared toward providing a way to share music (e.g., songs, playlists, albums, etc.) across multiple streaming platforms in their daily lives. Supports Apple Music, Spotify, Amazon Music, YouTube Music, and other music platforms. The design of the product CrossPop will help users have a better experience in sharing music cross-platform.

Info

Role

Visual Design
UX Research
Prototyping

Tools Used

Miro
Figma
Discord
Zoom

Team

Tyler Hayes
Yanxing Pan
David Cranfill
Quinn Smith
Amara Bush

Duration

Oct - Dec 2022 (8 Weeks)

Overview

Aiming to create...

a seamless music-sharing experience, CrossPop bridges the gap between streaming platforms like Apple Music, Spotify, Amazon Music, and YouTube Music.

Outcome

Focusing on cross-platform accessibility and user behavior, delivers a unified and intuitive music-sharing experience that aligns with users’ social habits, resulting in a seamless and inclusive solution across major music platforms.

Project Approach

What this project is about and what to expect.

For this project, we focused on Lean UX methods to analyze and solve our problems; A design process that focuses on creating a product as quickly and efficiently as possible.

This approach embraces Lean-Agile methods, implements functionality in minimum viable increments, and measures success based on benefit hypothesis analysis.

Challenges

01

It was completely new way of design process compare to Goal-Directed Design.

02

The Build, Test, Iterate methodology was encouraged to develop digital products in lean cycles.

03

Communication and task management with teammates.

Method Focused

Lean UX

This was a class project performed by following the Lean UX approach, and combining UX, Lean, and Scrum methodologies. A key aspect of Agile is that it divides the work into phases. As the project progresses, Scrum ensures the team remains aligned through a series of meetings. As opposed to UX, which focuses on the user and how they interact with the product. In Lean UX, a project is divided into sprints.

Because it was completed under the class timeframe, we completed this project over a period of 8 weeks. Focused on validating our assumptions, doing research, and testing our prototype for usability. As a result, this page will be designed based on sprints and how we used them to create a Lean UX-based cross-sharing music application.

Design Process

Lean UX

This was a class project performed by following the Lean UX approach, and combining UX, Lean, and Scrum methodologies. A key aspect of Agile is that it divides the work into phases. As the project progresses, Scrum ensures the team remains aligned through a series of meetings. As opposed to UX, which focuses on the user and how they interact with the product. In Lean UX, a project is divided into sprints.

Because it was completed under the class timeframe, we completed this project over a period of 8 weeks. Focused on validating our assumptions, doing research, and testing our prototype for usability. As a result, this page will be designed based on sprints and how we used them to create a Lean UX-based cross-sharing music application.

Sprint 01

Design Sprint is an agile workflow for making products, an innovation in work methodology created by Jeff Gothelf. It takes 3-5 days to complete requirements analysis, prototyping, and user testing to verify that a product or idea works. However, since this was our first experience with a design sprint, plus, it was performed in a classroom setting, we divided up into two design sprints.

Sprint 1: Design Week 0

During sprint 1, we started with brainstorming, creating proto-personas about the user, researching the business market, and defining our minimum viable products (MVPs) by frequently testing ideas. This saved our team's time and effort by testing out bold decisions early before refining our final prototype much faster than traditional project methods.

Each sprint started with a design week followed by sprint week 1 and sprint week 2. Week 0's design week is allotted by the team to develop project plans for the following Sprint 1 and 2. During this week, our team focused on creating a problem statement, assumptions, proto-personas, and product and sprint backlog.

Lean UX Canvas 1: Business Problem

Most of the activities in Design Sprint give everyone in the team the time to think about their ideas independently before moving on to team discussion. If there is always a dialogue without time for independent thinking, it is easy for the voice to be held by a few, and good ideas can get lost in the discussion. By thinking independently, we can ensure that everyone's ideas are heard and that better solutions can be generated.

Therefore, each of the team members brainstormed their business problem on the team's FigJam board with sticky notes, then we grouped the similar stickies together, and voted the main focus statement we thought was the best fit.

Thus, our product problem statement came out as:

The current state of social music sharing has focused primarily on trending playlists and gaining customers.

Existing products/services fail to address the simplicity of sharing music cross-platform and there is no central platform for sharing.

Our product/service will address this gap by creating a central platform to browse songs, ease of sharing across different platforms, and give the users the opportunity to connect with others through discovery or “For You Page”.

Our initial focus will be ease of sharing across platforms.

We'll know we are successful when we see the amount of page views, time-on-task, and user subscriptions.

Literature Review

Domain research on user behaviors & attitudes —

After the kick-off meeting, our team started researching about the domain as well as user behaviors and attitudes toward our application. Our main goal during this phase was to get as much information as we could about the motivations and frustrations when sharing and hunting artwork online. This phase is essential because it is important to obtain any prior knowledge on the domain of our application, competitors in the fields, and our users’ behaviors/goals, the literature review gives the latest information in the field by mapping the progress of knowledge.
‍
Our team gathered statistics on the status of the car remote market, smartwatch devices and their functionality, and existing applications by leading manufactures in he car industry as our application will be universal and compatible with any brand of car.

We found few articles that correlate with the application and its goals. One document we analyzed was a statistical table on the brands dominating the smartwatch market and it influenced our choice in designing the initial app for Apple and IOS smartwatches. Another article featured information on competitors and from this we were able to determine that our app will be compatible with various cars manufactured around 2015 and later.

Competitive Audit

The competitive audit is used to compare existing versions, prototypes, or competitors of a product. This section of GDD will allow our team to understand what makes other social media platforms different from others by examining the features they offer and the capabilities they have. This involved comparing our top competitors to determine gaps in the market that our product could address. By analyzing these applications, we found how our application could stand out in the market.

We focused our competitive audit on three major competitors: Viper SmartStart, OnStar Remote Link, and MoboKey. While the Viper smartwatch has unique features such as providing car status, parking location, among other features, its major downfall requires a separate device in order to connect to a car. In addition, it requires a subscription in order to utilize the car control. While OnStar provides personalization and a point reward system, its major fallback is the lack of a universal application and a required plan with the temperature control feature. Lastly, MoboKey is a smartphone app that allow users to control multiple cars, provide parking location, and share key option. However, the smartphone app does not come with a smartwatch that can be controlled from your smartwatch.

Stakeholder Interviews

After research about the domain and product but before user research, a design team must meet with stakeholders again to reaffirm their business goals. Some information to gather in a stakeholder interview that they could not discuss in the kickoff meeting would be product vision, budget, schedule, technical restraints, business goals, and the perception of users.

Since this project is a university class project, we did not have any real stakeholders to interview. Instead, we imagined what a stakeholder might have discussed with our team about the application. They would reaffirm that they want to make an application that is easy to use and can connect many people together. However, they would also be concerned with how to reach the application’s domain and how to earn revenue from the services provided by the application.

User Interviews

User research —
findings & insights

We conducted user interviews and mapped out our research into affinity maps to identify patterns and key details about our participants' behaviors and goals.

Discoveries

01

Make it easy for beginners, but also efficient for experienced smartwatch users.

02

Efficient for experienced smartwatch users

03

Needs of both groups and used this information to formulate our personas in the Modeling phase of GDD.

Why is it necessary?

The final step of GDD’s research stage concludes with conducting user interviews. To begin our user research and learn what goals, behaviors, and attitudes real life users had our team conducted user interview sessions. The first step of this process was to create a heavy focus on the persona hypothesis, information from previous literature reviews along with our competitive audit.

We conducted five user interviews that are all held through a virtual meeting to prevent the spread of the COVID-19 pandemic. We then synthesized our notes on Miro to create affinity maps for each interviewee based on the common topics, ideas or features that was constantly mentioned in our interviews.

Affinity maps serve as a visual representation of user problems and needs. By layering and grouping the data collected during each interview, this will be come the basis for subsequent for the team to define the user needs.

02 — 🧪 Modeling Phase

The modeling phase is often based on the analysis of target behaviors and workflow patterns found in fieldwork and interview results and synthesized in a user model. This mainly includes observation and situational interviews to obtain qualitative data on the potential users of the product.

Behavior Variable Map

Once we have identified all the common behaviors and patterns, we began to look for the most common characteristics among the six interviewees. After identifying them, we are ready to start the requirements phase where we identify the main feature to incorporate into our prototype based on the data we collected from usability testing.

The Personas

A persona is a descriptive model that is based on the goals and behaviors of real users. The purpose of creating a persona is to minimize subjective assumptions and understand what users really need so that we know how to better serve different types of users.

Our personas

Based on the research results and the affinity mapping, we ended up with two types of personas.

03 — ❗ Requirements Phase

The requirement phase is essential within the GDD process because this phase is where we find out the connections of our developed primary persona. Skye, between the design’s frameworks. How it would help our persona achieve her goals, behaviors, and needs.

Identify

To identify the potential steps from our persona would take to reach their goals, we constructed context scenarios that help achieve the goals, behaviors, and needs of our developed personas, when potentially using the application.

The main focus of context scenarios is generating a story based on the persona’s interaction with the application, to address how the application fits into her daily routine and how it helps to meet her goals.

Based from the context scenarios, we also created a list of requirements that helps to allow the user to successfully meet their goals.

Key Points

01

Quick Access Controls screen

02

Fast access to music player

03

Car location sharing

04

Simple and intuitive interface

05

Swipe feature as opposed to back buttons

06

Personalized car visual in menu

04 — 🔧 Framework Phase

In this phase, we transitioned user goals and requirements into visualization. Our goal during the framework phase was to create a low-fidelity wireframe that follows the key path scenarios and focuses on flows and the placement of the elements. Low fidelity wireframes are meant to be quick; it gives a possible layout idea of how the application would look and function. This task was completed using wireframing tools and elements that are provided on Miro.

Building the wireframes

Low-fidelity sketches,
ideas & flows

In the the Frameworks stage, we created the wireframes and low-fidelity prototype based on requirements identified in previous phase of GDD to create the wireframe after all the requirement lists are identified. Using the requirement lists, we created the low-fidelity wireframe and low-fidelity prototype in Figma. A low-fidelity helps our team to visualize what our app would look as well as test our concepts and design ideas.

05 — 💎 Refinement Phase

Once we completed our low-fidelity wireframes on Miro, we continued using the same key path and validation scenarios while constructing a refinable prototype on Figma.

During the presentable stage of designing, we conducted two usability testing interviews with previous interviewees. In the testing sessions, we gave the interviewees simple tasks and monitored them navigating through the application to see if they were able to complete the tasks smoothly.

Adjustment

Findings & iterations

After conducting the usability testing sessions, we further collected additional data from our interviewees on their thought process and attitudes about the smartwatch overall design. Through this, we were able to walk away with insightful information on the functionality of the smartwatch app which helps our team to develop better solutions in order to meet the user's goals.

Positive Feedback

Negative Feedback

Interesting

01

Our interviewees found the overall experience intuitive.

01

The interviewees found the swipe system difficult to identify unless told.

01

Users expressed desire for a car visual, showing their car above the quick access menu.

02

They also found the icons easy to understand and are easy to see.

02

Stay consistent with the design: the white color on the Alerts section in comparison to the quick access.

02

Valet Mode only makes sense to those who know what valeting is.

03

The interviewees like the features available in the Quick Access section.

03

One of the interviewee expressed confusion on the lock icon.

03

Generally, swiping was preferred to pressing back buttons.

After completing our prototype, we then tested it against two of our fellow classmates as the pandemic limited us to such testing. By testing with our classmates we learned that we needed to add our logo throughout the application, include more information on profiles, and make the photos larger on profiles.

Launch Prototype

06 — ✅ Conclusion

Since we have worked mostly with mobile application interfaces and none of us had designed for a smartwatch before; therefore this was an especially challenging design to tackle. We are proud of how the final product turned out but unfortunately due to time constraints some of the requirements we had listed before were unable to be added to the prototype.

I am proud of the work my team and I accomplished over the course of two-three months. Having no little-to-no prior experience with designing a smartwatch application, I believe we were successful in what we set out to do.

After completing our project, I've already noticed things I'd like to change. For instance, rather than only dark mode provided to the user, I think it would be better if the user have the option to change their whole layout. I think that would boost the overall flow significantly. Putting the Goal-Directed Design process to practice gave me confidence in my desire to be a UI/UX Designer. I'm now sure that this is where I want to be; this is what I'm passionate about.