Executive Summary

ImBible: 

is a mobile app that allows users new to the bar industry to learn and develop their knowledge of drink etiquette and discover their ideal drink of choice.It offers informative and educational content to complement a market of coming-of-age people who have not been taught the ways of the bar industry.

Approach:

Lean User Experience (UX) Design is a user-centered design process that embraces Lean and Agile development methodology to reduce waste and create products centered around the users. It allows continuous engagement with shared understandings by changing some of the organizational way a team manages and develops a designed software.

Challenges:

There were many small challenges faced throughout our design process that made us really considers the users wants and needs. At a point, one of our biggest challenges was to make sure the app did not feel like a social media tool. The app, ImBible is to be educational for the user in real-time, if needed.

Roles:

  • Research

  • Moderator

  • Wireframe + Prototype building

Duration:

  • Aug - Dec 2022

Members:

Introduction

Have you ever been to a bar or any other drinking setting and just felt so lost? Or maybe you’re already familiar with a few of your favorite drinks/cocktails, but want to try something new for a change? Our app, IMBIBLE, is setting out to solve these problems in a fun and convenient way!

In the fall semester of 2022, we were tasked with creating a new and innovative idea for a mobile app prototype. We would present those ideas to the class, and all of the students ranked the projects they’d like to work on the most in order. It did not take long before myself, Lindsey Smith and Kristen Sitro would all choose Lauren Johnson’s idea for “IMBIBLE” as our #1! During Lauren’s presentation, it was made clear what the parameters of the application would be, not to mention that the idea itself felt fresh and original.

Week by week, we implemented a process called SCRUM to stay on task with the process of Lean UX principles. SCRUM is a designing methodology that takes you and your team through weekly “sprints” to help organize tasks. The benefit of Scrum is from a more long-term point of view that displays an organized integration of practices such as stand-ups, prioritization, MVP experimentation, and interviewing/testing.

Sprint #1

To begin our first Sprint, we had to have our first meeting. This was considered “Design Week 0”. For week one of our first sprint, we were asked to conduct stand-up meetings, host interviews, and test our MVP experiments. Since this will be our first time experiencing a sprint, we had to keep in mind our sprint backlog without going off track. In this meeting, we also talked to Lauren about her idea for IMBIBLE and put in our own input for features that might be nice to see. In addition, we laid out the goals and problems that our app will set out to solve as well as a created hypothesis about our target audiences and first draft personas to fit those assumptions. In Lean UX, a persona is a made-up character comprised of all of the characteristics that would constitute someone to use your app. In many cases, there can be more than one persona as there may be more than one kind of target audience, but more often than not, there is always a Primary persona that is most considered when creating the design. For IMBIBLE, our primary persona is an early 20s, maybe college student, that’s on a budget and unfamiliar with the drinking world. Some of the hypothesis conclusions we made early on were based on this persona and how they might like to take a quiz to find some new suggestions. To finish week 0, we completed a product backlog, which included a list of main goals and features we’d like to have feedback on by the end of our two-week Sprint #1.

Moving forward, we began doing 2-day stand-ups to stay on track with their work ahead. A 2-day stand-up is a meeting every two days where the group can talk about what we have and haven’t done since the last stand-up, and what we need to accomplish before the next. As soon as Sprint 1 began, my group members and I slowly began putting together our prototype or MVP to test our assumptions in Sprint 1 Week 1. an MVP is a Minimum Viable Product, which is a shell of what the product should be, but enough to test certain scenarios out with users to get feedback. Our three most focused functions for sprint 1 included the drink suggestion quiz, the favorite drink feature, and the bar lingo page for those new to bar settings. After putting enough in our MVPs to test, we began user interviews. In these interviews, we asked a few questions about that person’s experience being in drinking settings and then allowed them to walk through the prototype. Then, they were allowed to give any feedback and ask questions in regard to what they liked about the app, and what else they might like to see. For our first sprint, we interviewed people that fit closely with our primary persona and received a lot of positive feedback as well as suggestions for improvements. We learned that the simple interface and quiz approach we took was working, but each user asked for more information one way or another in each of the interviews. To conclude our Sprint 1 Week 1, we met for a weekly retrospective to discuss that week’s accomplishments, next week’s goals, and ways we could improve working together as a team.

For the following week, we continued to interview new people while addressing a lot of the concerns we heard in our interviews. For one of these interviews, we tried to find someone like our secondary persona: a middle-aged man or woman with drinking experience that is looking to try something new. Still, there was a request for more information about drink recipes and the strength of certain beers, cocktails, or liquors. Thus, we continue to collaborate through our 2-day stand-ups to continually put work into the prototype to satisfy our customer’s needs.

Sprint #2

The biggest concept in Sprint #2 was re-validation. The process of re-validation is to go back to your original persona(s) and hypothesis and determine if those needed to be changed to fit your application’s needs more. In tweaking your original persona, you’re creating what is called a proto-persona. Some of the things we re-validated were our primary persona, and what is most important in a drink to most of those people. Originally, we had made the assumption that flavor was most important, but after our Sprint 1 interviews, we found that a lot of people look for alcohol strength first. So, we determined that it was important to add a “strength meter” for each drink. For Sprint 2 Week 1 it was important for us to emphasize the new features added, and how they provide more information about drinks for those that were looking for them. The main difference in Sprint #2 is that the challenges and changes we were faced with were no longer based on assumptions but on user feedback and research. Therefore, we had a lot more confidence when implementing these new ideas into our design. To conclude the interview process, we re-interviewed a few of our earlier participants to get their opinion on how the newer version MVP lives up to their wants and suggestions.

For the final week of Sprint #2, our process mostly consisted of collaborating for stand-ups and finalizing changes to the prototypes and personas. By now, we had tested all of our assumptions and our focus was on implementing the answers we found into our prototype/MVP. We finished off our testing sessions with one more re-interviewee from week 1 and took all of Sprint’s feedback into consideration at our end-of-week stand-up.

At this point, our primary and secondary persona had been revised to the point of near perfection. Our target audience remained to be the 20-something-year-older working student who’s just started to get into the drinking world. Followed by a secondary persona of an older person that’s just looking to try something new, or find ingredients so they can make the drink on their own. In addition, we had accomplished all of the features we had set out to create in our app while not getting too carried away. From here until the final prototype submission, we were able to take the time to make small design changes that enhance the user flow/experience.

Conclusion

For so many reasons, I’ve come to appreciate the amount that I’ve learned from this project alone. As a student, it was a good opportunity to work in a team on a semester-long project that had a lot of the same dynamics as a lot of real-work-world scenarios for people with our degrees. Also, it was so important for us to be able to apply the Lean UX process to what felt like a real product at times. Along the way, we encountered a few technological issues as well as scheduling issues. But, through consistent collaborative work, we were able to work through each of those problems as a team.

As far as the product goes, I can confidently say my group members and I are proud of the prototype we created as well as confident in the research/testing we’ve done to support our design choices. Using Lean UX we were able to separate tasks and tackle things in a more prioritized manner. We were able to get feedback from our testing to further improve our product while still evaluating all of the risks and re-evaluating all of our assumptions about our consumers along the way. If we were given the opportunity to develop this design further, I’m sure there are a few more features, like a search engine, that the consumers would like to see.

Overall, our team is excited about the success we’ve had with this project at the end of a long semester. Links for our IMBIBLE prototype and more work-logs are located in the executive summary at the top of this page. Hope you enjoy our work!