UX Case Study: Jamr (Sprint 1)
An app to get you back to jamming!
Project 1 at General Assembly (concept app project)
Team: individual project
Client: Paul Woodley
Duration: 3 days
Methods: Interview, storyboarding, task flow, competitor analysis, user flow, participatory design, interactive screen flows and clickable prototype.
Tools: Pen and paper, POP, Keynote
For Project 1 of the General Assembly UXDi course, we were asked to work in pairs to design a rough interactive paper prototype that addresses a key common problem in our partners’ life.
I worked with Paul Woodley, who wishes it would be easy to find places and people to jam with. After 3 days of research, sketching solutions and testing them, I came up with a first interactive paper prototype of an app, which gave Paul confidence it would solve his problem.
Part 1 — Identifying and analysing the problem
It all started by conducting an interview with Paul in order to get to know him, his daily routines, main interests and activities, as well as his long-term aspirations in life.
Who is Paul?
Paul is a young graphic designer based in London, currently taking up new challenges in his professional life to do what he loves, and to secure a better a life-style for him and his wife.
Paul has really busy days, mostly spending his time at work, commuting, and helping his wife to setup her business. He loves music and plays guitar daily before heading to bed. He used to play in a band, and very quickly in my interview he mentioned he misses the fun of jamming with his friends.
“I wish it would be easy to find places and people to jam with.” — Paul
I immediately thought and shared with Paul that it should be possible to solve this problem with an app that would connect him to other amateur musicians sharing the same desire to jam again, Jamr! Excited by the idea, we went through further more detailed questions: we discussed the ways he previously tried to search for people to jam and why he failed; we talked about how he would feel and what he would expect regarding meeting new people and jamming with strangers.
It allowed me to identify possible issues that could arise with the solution I had in mind. For example:
- difficulty to find the right type of musicians and styles,
- difficulty to find drummers,
- difficulty to keep Paul’s motivation up.
However, at this stage I was confident enough to start exploring solutions for his problem.
In order to capture and share my understanding of the problem I storyboarded Paul’s current situation. It reflects the past joy of jamming sessions with his friends, and his current frustration of not being able to quickly and easily find places and people to jam with.
Part 2 — Exploring a possible solution
Once we agreed on the problem to solve, I presented Paul with a storyboard of what my solution would feel like when using Jamr app. I then immediately started to sketch user flows and concept maps with him so as to involve him in the design process and validate early assumptions.
The solution proposed with the Jamr app is to connect amateur musicians by matching similar user-informed profiles and recommending jams to its users. Each user profile would describe the location, musical taste and style, instruments played and repertoire.
An important hypothesis for implementing this solution is that there should be enough people and/or organisations willing to share their place (a studio) to jam.
The first concept map I sketched started to reveal some essential tasks and events to handle such as:
- finding and joining a jam,
- organising a jam,
- receiving jam invitations or recommendations.
Through sketching my user-flow I identified the main ‘happy’ path that Paul would take when he feels like jamming:
Part 3: Designing an interactive paper prototype
I then translated my user-flow into screen-flow through sketching, focusing on the happy-path identified before. By doing so, I naturally identified features I didn’t foreseen, like for example in a filtering button for the list of jams.
Based on my previous interface sketches, I created paper mock-up elements to test my happy-path scenario with Paul.
Test scenario: I instructed Paul to use Jamr paper prototype to check if there were any jams going on he would be interested in joining.
Testing was a lot of fun! I I video-recorded the whole process so that I could review it later. It helped me to validate assumptions I had made, and Paul gave me feedback on what he would expect at each step of his journey.
I realised that the low-fidelity nature of the mock-up allowed Paul to express his expectations in a more unambiguous manner, and therefore improve my design (this-must-do-that kind of observations).
What I have learned overall included:
- criteria for selecting a jam: people, location, music style
- criteria to assess jam success: jam duration, participants rating, and comments
- need for visual confirmation that a jam had been scheduled
- need for better handling of the JOIN button states
- need for higher-fidelity mock-ups to layout information relevant in the user jam review process (location, date, etc…)
Overall the experience of Paul using Jamr was very positive. His reaction when confirming his participation to his first jam illustrates this nicely:
“ahah! that’s ace!”
Resulting clickable prototype
I created and tested myself a first clickable prototype using POP, based on some of the feedback I collected during my previous usability testing.
The following figure illustrates a short happy-path a user would take to find, review, and decide to join a jam using Jamr.
Should you want to test the prototype, it is available here.
5 weeks later, during Visual Design week, I created a high-fidelity mockup for 3 key screens of the app. If you are interested, read Case Study: Jamr (Sprint 2).
Thanks for reading!