Approach
- 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
- It was completely new way of design process compare to Goal-Directed Design.
- The Build, Test, Iterate methodology was encouraged to develop digital products in lean cycles.
- Communication and task management with teammates.
About CrossPop
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.
Introduction
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.
To gain a better understanding of Lean UX, we can look at the following design process:
- Understand: What are the user needs, business need and technology capacities?
- Define: What is the key strategy and focus and how might we explore as many ideas as possible?
- Decide: Select the best ideas.
- Prototype: Create a prototype that allows to test the ideas with users.
- Validate: Test the ideas with users.
Sprint 1
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.
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.
Sprint 1: Design Week 0
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.
Lean UX Canvas 2: Business Outcomes
Once the preparations are done, the official sprint begins. The work of defining the main goal is the most important, and the work in the following days revolves around this goal. We defined our main goal by starting with the business outcome to set a long-term goal and list the sprint questions. Long-term goals need to be long-term enough to guide future work. It requires the entire team to think about these questions:
- Why are we doing this project? What problems should be solved?
- If we can get to the end of the design sprint, what aspects of the product will have improved as a result of this project?
- What do we want the final product to be like?
Long-term goals make it clear where we are going, we need to consider again what factors will affect the achievement of the goal, so that the team is clear about the obstacles that may need to be faced in the process of achieving the goal, which will also guide us to find solutions together.
Lean UX Canvas 3: Users
Proto-Personas, also known as simple personas, are often used in Lean UX design. It is oriented to the target users, but not the real users, the virtual "user prototypes" based on user research. As shown in the figure below, the content of the persona covers name, portrait, background, needs, values, goals, pain points, and expectations. This creates a virtual image of the user and helps us to change our perspective and consider the problem from the user's point of view.
During this stage of sprint, we created the following 2 proto-personas that were based on our team's collective assumptions.
Lean UX Canvas 4: User Outcomes & Benefits
During this stage, we have identified our potential user's behavior that would indicate whether the user achieved their goals or not, we also were able to identify our users' hope/end goals to gain from our product.
To do so, we filled out this "user outcomes & benefits" exercise form, where we made assumptions about how we will know if our designs are “successful”.
What is the user trying to accomplish?
To be able to share music with friends crossed platforms without the unnecessary steps that come with having different music providers.
Why would your user seek out your product?
To share music with others on different platforms to not only share and receive music they might not know about but also to have a more social factor with music sharing.
Lean UX Canvas 5: Solutions
After we identified our users and what they are trying to gain from our product, we need to create a solution based on them. We started brainstorming ideas of what the solutions for our product could be in a limited time, 10 minutes for each person. After the 10 minutes timer, each of the team members had 2 minutes on explaining their ideas to the team and we voted on what solution we thought would be the best fit for our problem statement. The entire team drew their ideas on 6-Up grids displayed below.
Lean UX Canvas 6: Hypotheses
For our hypothesis, a more detailed and specific description is given to clearly define where we want to test our product. Take the assumptions that we made from the previous steps turning them into a more concrete hypothesis. Below here is the hypothesis table that we used in our product backlog, the core of an agile team managing the development process, all activities and deliverables revolve around the product backlog. There are many issues that come up during the development of the product backlog, but it is also kept up to date as we progress.
Our team essentially followed this structure:
We believe that [doing this/building this feature/creating this experience] for [these people/personas] will achieve [this outcome]. We will know this is true when we see [this market feedback, quantitative measure, or qualitative insight].
We then mapped out each hypothesis based on how risky they are with a hypothesis prioritization canvas. This allowed us to assess which features we felt should be prioritized with their associated risk.
Lean UX Canvas 7: We believe that...
After our hypothesis statement, we ordered them based on the most to least amount of risk and value, based on the question:
"What's the most important thing we need to learn first about this hypothesis?"
The sooner we find which features are worth investing in, the sooner we can focus on our limited resources on the best solutions to our business problems.
Lean UX Canvas 8: MVPs & Experiments
During this stage, we need to create minimum viable products (MVPs), used to conduct small prototype research, get to market quickly, reach out to customers and get feedback. With feedback, prototypes are constantly modified and iterative development takes place, greatly reducing the cost of trial and error.
MVP is necessary because our product does not have a ready-made "target market" and it needs to find the right target users through MVP. By asking the question: "What’s the least amount of work we need to do to learn the next most important thing?" And design experiments to learn as fast as we can whether we riskiest assumption is true or false.
Sprint 1: Week 1
During our week 1 design sprint, we did a 2-day stand-ups meetings, a short 15 minutes meeting held every beginning or end of the team meeting. The purpose of the stand-up meeting was to exchange information to synchronize each other's status, not to solve problems, and to listen to the teammates.
The content of the stand-up meetings usually focused on three questions:
- What did we do yesterday/last meeting?
- What problems were encountered in what you did yesterday that you are troubleshooting?
- What issues are expected to be addressed today?
Conducting User Interviews
User interview is a very common method in user research. User interview is a method of learning facts from users by using purposeful, planned, and methodical conversation. It is necessary to understand users' behaviors and their thought processes while building our products, to exclude false needs and filter the real needs.
Therefore, we conducted a few user interviews throughout the design sprint. We prepared a few interview questions aimed at learning about them and an interest in music and sharing music. We also asked our interviewees to go through our MVP then we would ask them questions we had prepared for them, and we would write them down in our notes for later use.
Affinity Mapping
Affinity maps serve as a visual representation of user problems and needs. By representing the data collected from the previous interviews we conducted, we saw the problems users are facing. Throughout the research process, we had the opportunity to understand the user's pain points, motivation, and preferences in a very personalized way.
After we had all our notes from the user interviews, we all went on FigJam as a team and put down the key characteristics, thoughts, observations, and any behaviors that we noticed on sticky notes. Then, we conducted an affinity map session where we categorized them into groups where they share similarities.
From the interviews we noticed:
Positive Feedback
- Could see themselves utilizing a share feature.
- They also found the icons easy to understand and are easy to see.
Negative Feedback
- Interviewees that are less tech savvy found very hard to navigate through our MVP.
- One of our interviewees said the MVP has too many steps to navigate through.
Interesting
- Most of the interviewees that we recruited do not share music that often.
- Most of the interviewees are under a family plan.
Sprint 1: Week 2
Moving on to week 2 of sprint 1, we updated and modified our wireframes based on the feedback we got from the interviews. The main goal for this week's sprint was to focus on the usability testing of our MVP. Thus, we recruited 3 more interviewees to dive a little deeper into our MVP. Taking their feedback and applied to our MVP once again, during this stage we have testified multiple times of our assumptions and problem statement to determine whether or not we are heading in the correct direction for our project.
Sprint 2
In sprint 2, we followed a similar structure and approach in the previous sprint. But in this sprint, we focused on designing a high-fidelity prototype that could be presentable to our audience/hypothetical stakeholders.
Sprint 2: Design Week 0
During week 0 of the sprint 2 design process, we mainly focused on revalidating our product problem statement, proto-personas, and product backlog, and creating a sprint backlog based on the research we have conducted in sprint 1.
Product Problem Statement
Based on our research, our product problem statement stayed the same without changing. Our users were right on track with our initial assumptions.
A recap of our product problem statement:
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.
Updated Proto-Personas
Although we did not change our product statement problem, we realized that the interviewees did not fit into our original assumptions. Since the interviews, most of the interviewees gave us similar feedback as the other interviewees.
Sprint 2: Week 1
In week 1 of sprint 2, we again, conducted a 2-day stand-ups, a recap of what has been updated individually off meetings. After the short 2-day stand-ups, we jumped straight to our interviewee sessions and asked them to test out our revised prototype, with newly added frames.
After we conducted all three interviews, we went on our FigJam board and completed another affinity map to look for similar characteristics and patterns in our interviewees. Pointed out differences or any outliers between the three interviewees. Based on the feedback, we figured that we need to create a playlist frame for the user.
Sprint 2: Week 2
For our final sprint week, we continued to work on our prototype, but instead of a low-fidelity prototype, we started to shift to a high-fidelity prototype. We wanted to make sure that the users can navigate through the application effortlessly without our help. Thus, we focused on finalizing the text styles, color styles, branding, and interactions within each frame. For our usability testing, we recruited two of our previous interviewees and one new interviewee to test out our final round of testable prototypes before the project's deadline.
We took notes on the suggestions that were made by our interviewee and took them into account when finalizing our product.
Our Final Prototype
Below here are some snips of our prototype designed in our final stage of design:
Conclusion
It was kind of hard to transition from focusing on Goal-Directed Design to the Lean UX design process. Since Lean UX approaches on Lean-Agile methods, implements functionality in minimum viable increments, and measures success based on benefit hypothesis analysis. Therefore this was a challenge to think from the new design aspects.
Some key takeaways from this project:
- Team communication and task management are extremely important.
- Be careful when creating a problem statement at the beginning of the project.
- Talk to the team member at the earliest opportunity about poor performance, role confusion, or interpersonal conflict.