Music App - Process Page

Executive Summary

Our Team

The Project:

https://www.figma.com/proto/

Introduction

This is a summary of the development of our group project for Interaction Design 2. The goal of the project was to give us experience working with the Lean design process.

Lean UX (User Experience) is a design process and philosophy for creating a product that focuses on creating a minimum viable product (MVP,) or the most basic functional version of a product, in two-week design phases called Sprints. 

When the class started, we were put into teams and told to decide on an app we would make. Tyler Hayes, our team leader, proposed a bluetooth music sharing app called Crosspop. The rest of us liked it so we were assigned to his team by Professor Ott. This was a class project, so the Lean process was slightly shortened to allow for us to get a general feel for it.

The rest of this page catalogs the process we went through to create Crosspop. There is a section for Week 0 where we laid out what we wanted to accomplish, a section for the first Sprint, a section for the final Sprint, and a short conclusion to sum it all up.

Sprint 1

When we started Sprint 1, we knew what kind of product we wanted to design. We even had two target users in mind, one older user who wanted to find new songs and a younger user who wanted to share his favorite song. We created profiles for these target users from our own experiences call "proto-personas" as they lack the in-depth research true personas are made of. The We had made a list of all the features we felt should be included on our app based on our personas' needs, then we placed them on a grid. The ideas on the right being the most likely to fail and the ideas on the left being the least. After we had them arranged left to right, we arranged the from top to bottom, with the bottom being the least valuable to us and the highest being the most valuable.

This is a part of the Lean UX process called a Hypothesis Prioritization Canvas. It allows a design team to see what parts of the app are the most essential and should be designed first. 

We looked at our prioritization canvas and chose what we believed to be the most essential part of our app: the bluetooth sharing feature. Over the next couple of days we worked as a group to design a minimum viable product for our app around the sharing feature. We worked on several of these features over the course of our first sprint including a home page and a sharing page.

Once we had our MVP, we began the next phase of the Lean process: testing. Lean UX borrows many concepts from a design methodology called Agile methodology. Agile methodology says that designers should iterate and change their designs, rather than following a set path. That flexibility and ability to self-correct based on what you learn is what gives Agile its name. Of course, this flexibility in an ever-changing market can be vital. Gothelf and Seiden, the writers of the book Lean UX, called Lean/Agile methodology a "Loop that drives real organizational agility and allows your company to react to changes in the market at speeds never before possible." (Chapter 17.)

To take advantage of this process of iteration, we needed to know what we should change and to do that, we needed someone to test out app. We interviewed three acquaintances of ours who we knew liked to listen to music. These tests started what we call a "stand-up," a set period of time where the researchers and designers do intense research.

After the first test of our app's usability, the interviewee said our MVP was easy to use. However, he wouldn't have known how to share an album if we didn't walk him through it. In response, Amara and I put together a small tutorial that showed users how to tap to share an album if they took too long figuring it out. This is one example of our team adjusting to what we've learned.

Our next two interviews were largely positive. User three complained the tutorial was too complicated, so I shortened it as much as I could without compromising the information inside it.. After the test, asked the users various questions about using the app as well as sharing music in general. All our users either share music with friends frequently or would share music more often if they had an app like ours. This was the best answer of all to us, because it validated our assumption that cross-platform sharing should be the highest priority.

In week 2, we had another two-day stand-up with three more interviews. Our first and third testers were inexperienced with UX design, but our second user, a friend of mine, was another Interactive Designer. Even with such a wide range of experience, the users all agreed our app had a solid concept and a good start to its implementation. Week 2 then was an exploration of whether our assumptions from the first week were correct.

Sprint 2

At the beginning of Sprint 2, we reevaluated the state of our app and decided that although our main concept was still valid, it was about time to update our app's visuals. We spent the first week giving our app a visual overhaul  as well as adding many new pages. We started adding pages related to creating and sharing playlists as those were next on the Prioritization Canvas. We had all but moved on from our younger persona who wanted to share music as none of our interviewees wanted to share their music often. We focused our efforts on creating an experience for people who wanted to find music.

Sprint 2 was much more design-heavy than Sprint 1, and required much more communication from our team. Our MVP could no longer be a basic functionality test, but rather had to be a polished product We each had our own sections of the app, my job for pretty much the rest of the class was to maintain the pages related to sharing an app and keep them updated. We had some trouble coordinating what we wanted the redesign to look like, but we were eventually able to get it sorted out through trial and error. Now we had to test and see if our assumption about users looking for music rather than sharing music was true.

Once our new pages were done we got three more users. Two of them were friends of Tyler and Quinn and one of them was Amara's mother returning from the first 2-day stand-up. We asked them similar questions to the first groups. The first user shared music often, but the second did not. There seemed to be a healthy balance between users wanting to share music and not wanting to share music, meaning we may have been hasty in dropping one of our personas.

I week 2, our final two-day stand-up occurred. We had trouble finding three people to interview at first, but eventually we were able to find enough. 

With our deadline drawing near, Professor Ott told us our app's visuals were not quite as good as she would have expected. With our two-day stand done we spent the rest of our  time in the class refining visuals and adding functionality to our sharing screens, hwich remained largely unchanged since our first sprint. We again had trouble communicating what we wanted our app to look like at the end, but with time we were eventually able to get on the same page. One of our greatest strengths was out ability to see things from our teammates' point of view. We finalized our design with the version of the app seen above.

Conclusion

Overall, our team did very well. The process itself was a lot less straightforward than the reading led us to believe. Identifying our problem without immediately creating a solution was tricky. Once we had our solution, the only difficult part was deciding which aspects of our app we wanted to prioritize in our Prioritization Canvas. User testing was largely positive, too. Once we went through the process of establishing an idea, there was little we had to do to restructure it.

If I had the chance to do it all again, I would try to improve team communication. We had a great concept and we all worked on our own very well, but we had trouble communicating on what decisions we were making or why, which led to some frustration as the project came together near the end. Despite this, though, I believe the project was a success. Crosspop is something we're all proud of and we all learned the basic of how the Lean UX process works.