.png)
For this project, my team and I utilized Lean UX, a process that focuses on an MVP (minimum viable product), where we move from a place of uncertainty to certainty to by testing and validating our assumptions. We moved through this process in a series of 2 sprints, each comprised of 3 weeks. We had a design week in which we created/validated our problem statements, business assumptions, proto-personas, product backlog, and sprint backlogs. Then, during our first week of each sprint, we spent time tackling our sprint backlog by putting together our wireframes. We then tested our wireframes through user interviews and testing sessions. Finally, in the second week of each sprint, we would focus on transforming our wireframes into a medium fidelity prototype that we could test by the end of the week. After we tested each feature, we would refine the design until we ended up with our high-fidelity prototype.
In Sprint 1 Design Week 0, we declared our assumptions for that would guide us to creating our first MVP (minimum viable product). We started with our problem statement, which set the direction for the project and allowed us to focus on the other assumptions we would need to make. We then created our proto-persona, Madelyn, based off of our assumptions, which allowed us to begin designing immediately without getting bogged down with preliminary user research to develop a user persona. Madelyn guided us through developing our product and Spring 1 backlogs.
To begin, we created our problem statement and went over the assumptions on which we would base our first MVP (minimum viable product). We covered product risks, competition, and how we should measure our success.
An excerpt from our product statement:
“Our product will address this gap by giving information about why it relates to games the user has already found interest in and go in depth as to what type of game is being recommended, if it is playable on the device the user has and what genre it falls under.”
With our assumptions and proto-persona to guide us, we used affinity mapping to create our product backlog. We came up with 12 of each business outcomes, user outcomes and features. From there, we narrowed this down to 9, which helped us decide what to focus on for each Sprint and how we would need to divide the work. By setting these goals, we gave ourselves a direction so that we could immediately start working, and it was a great way to track our progress each sprint.
1. personalized recommendations through onboarding process
2. a game catalog that updates regularly
3. recommendations based on other games the user likes
4. review feature
5. featured games section
6. “swipe” function
7. game profiles with detailed info
8. search filters
9. saved games section under profile
1. a game catalog that updates regularly
2. recommendations based on other games the user likes
3. “swipe” function
4. game profiles with detailed info
5. search filters
Once we established our Sprint backlog, we went to work on creating our MVP. We began with wireframing using Miro. We met to discuss how we wanted to divide our work for the wireframing, and decided that I would work on the catalog and profile, Roxie would design the match page, and Cady would establish our filter feature. We added sticky notes to explain screen interactions and elements, so that we would still understand the functions we were designing when referencing the wireframe.
It was at this point, I decided it would be good to establish a pattern for classifying our games and organizing the related game sections on the game profiles.
I developed this "matrix” which gives four categories to classify our games, under which I found most games could fit.
Then, I assumed gamers would want to see related games that were related by different aspects of the game, other than the typical ways of recommending games (genre, style, etc.) This way, games would have varying degrees of relation to allow a larger of variety for our primary persona, who wants to see more niche games.
An example of this relation would be games like Overwatch and League of Legends. Both games don’t have much in common other than their fans because they are both very competitive games, something that would only tick one box for relation.
During our first Sprint, we continually travelled between the stages of running experiments and creating our MVP. We interviewed and tested with a total of 4 potential users during Sprint 1, who all gave us feedback on different aspects of our work including the matrix, our wireframe, and the screens we had begun prototyping.
After each of our interviews/testing sessions, we did an affinity mapping exercise to determine what the key points of each session were. We did this by separately writing down the most noteworthy aspects of the interview, and finding the affinities among our answers by discussing them and sorting them into groups.
This is an example of one of those affinity maps that we did at the end of our first interview, where we were able to get a better picture of our users.
The changes we needed to make:
- Add more information to game profiles
- Update matching page to include swipe feature
- Minimize information in filter page
These are some of the screens in our initial prototype. After testing we realized we should be including a lot more information on our profile pages, and we would need to update our matching page to include the swiping feature that our users would be familiar with. We also received feedback on our filter page, which was described as “too much,” which we chose to minimize to reduce cognitive load on the user.
During this stage, we continued to go back-and-forth with our designs and testing, making changes to different aspects of our designs depending on the information we had pulled from our interview and testing sessions.
.png)
As you can see in this example, we made changes to the overall layout of the match pages. Before, we were unsure if we would be able to implement the swiping feature that we wanted, so we would rely on the “x” and “check” buttons for these pages to be functioning. However, once I discovered how to do the swiping using Figma’s smart animate tool, I reduced the emphasis on those buttons and chose to make the elements about each game exist on a simple card that would be swiped away.
Additionally, I created tags that aligned with the matrix and gave each one a unique color, something our users really liked.
At the end of Sprint 1, we had a meeting where we discussed what we did well and areas we would need to focus on improvement. We agreed that we had worked really well as a team, and had created an environment where none of us felt afraid to speak up or offer comments on the work of others, something that allowed us to create some great design work. I brought up how I felt that we could be getting more valuable information from our users if we had more of a plan when going into our next testing sessions. Since I had previous experience with user testing, I offered to conduct the rest of our tests, and we decided that we would spend more time discussing takeaways and next steps after our affinity mapping for each session.
During this stage, we re-assessed our assumptions after spending time with our app and users, and after many virtual meetings to make sure we were still on the right track. We determined that our product statement hadn’t changed and didn’t need revisions, as well as our product backlog, though we did need to make adjustments to our proto-persona.
We discovered through our interviews that we needed to make a change to our persona, Madelyn. We initially made the assumption that Madelyn was our primary persona, but we found we had a core group of user behaviors that was more important after the four rounds of user testing we conducted. We found that our core users were more casual players, who didn't play games often, but always did more research for the games they bought. Therefore, we developed a new primary persona called Jared, who better represented our primary user, and Madelyn shifted to being our secondary persona.
1. personalized recommendations through onboarding process
2. a game catalog that updates regularly
3. recommendations based on other games the user likes
4. review feature
5. featured games section
6. “swipe” function
7. game profiles with detailed info
8. search filters
9. saved games section under profile
1. personalized recommendations through onboarding process
2. review feature
3. featured games section
4. saved games section under profile
After establishing our second Sprint backlog, we went back to our wireframe and added the necessary pages. We worked together to design the elements we wanted for the onboarding process. Separately, I designed the pages under the profile section, Roxie designed the new featured games section on our catalog, and Cady developed the layout for our review feature.
As you can see in the image below, our wireframe grew as we continued to add the new pages and the connections between each page.
We continued to interview and test four more users to make sure we were on the right track. The main difference in this Sprint is that we were able to successfully implement the changes to this process we discussed in our Sprint retrospective meeting. After our affinity mapping, we would talk about what that specifically meant for the changes we would need to make to the prototype, and who was to make those changes. This made our process so much smoother, and I felt like we were including our user feedback much more in our designs.
During this stage, we continued to go back-and-forth with our designs and testing, making changes to different aspects of our designs depending on the information we had pulled from our interview and testing sessions.
.png)
As you can see in this example, I continued to make changes to the match page. Through testing, we discovered that users were having a hard time finding more information about each game, something that they would need to make a decision on whether they liked or disliked the game. I made a change to this screen by adding a “read more” button that would take the user straight to the game profile, where they could read more information to help them with their decision. This was a game changer for our final testing sessions, where users no longer had trouble finding more information on each game.
At the end of Sprint 2, we met again to discuss what we did well, and what we could improve on. Ultimately, we had much more positive things to say about this Sprint than our first. We discovered that the collaboration we did on the on-boarding process was very efficient despite all of us working on it together. We also discussed how all of the changes we had made to our second Sprint made a huge difference in our productivity and the use of feedback from our users.
For the game profiles, we wanted to fit enough information about each game, without cluttering up the screen too much. As one of our users put it, “I don’t want to have to leave the app to google something about the game.”
We learned that one of the main research that our users did across the board before buying was looking up streams and videos about the game. To cater to this desire, we included a section on each profile that would link to popular videos and streams of gameplay.
.gif)
We knew at the conception of the app, we wanted to have a swiping function that resembles that of dating apps. At first we were unsure if it was something we would be able to accomplish, but after some research, I figured out how to do exactly the animation we wanted with tools on Figma.
The layout of this page had changed many times, due to issues with users finding more information about each game, and what they felt comfortable with seeing on this page. We were able to test this final layout with 2 of our users who found it very easy to understand and use.
.gif)
We established the catalog as a requirement early on to give users the choice to browse and search for games, instead of just viewing games through the matching pages. We chose to present the games in separate swim lanes, divided by categories defined in the "matrix," that matched the conventions of streaming apps with similar layouts. This way, the user would understand right away how to find certain games they wanted.
We also knew we would need to have a featured games section to add variety, and give the opportunity for games to be advertised on the catalog.
.gif)
My goal for designing the profile page was to keep it simple and easy to understand, so I decided to house each of the game libraries in large buttons that could be understood at a glance. I also wanted to include the ability to update preferences, so that user's recommendations could be tailored at any time to the types of games they want to see.
We requested feedback specifically on the iconography of this page, as making the buttons understandable at a glance was very important in keeping the page simple and user friendly.
.gif)
This was a really fun project to work on, and I'm proud of my team for the effort and care we put into this app. Utilizing Lean UX allowed us to get a lot of work done without wasting time, and because of this, I feel like we worked very efficiently together. We created a space where each of us felt comfortable communicating with one another about the project's direction, and I think that led to a great final product.
If we were to develop this project further, I would love to explore the best way we could actually recommend games to our users. I think this is a really cool idea, and that it would be really fun to actually have a recommendation algorithm, and develop a unique way of organizing the games. I would enjoy doing more extensive research on this domain, and developing the app further.