Imbible

A mobile app prototype designed to serve as an informational bartending tool.

Executive Summary

Throughout the Fall Semester of 2022, my team and I worked through the process of Lean UX in order to create a prototype called Imbible. We followed specific approaches and guidelines that abide by Lean UX; Lean User Experience (UX) Design is a user-centered design process that focuses on Lean and Agile development methodology to reduce waste and create products centered around the users. Imbible is our interactive IOS interface that serves as an informational tool to help adults become more involved in the world of cocktails and bartending in a fun, anxiety-free way. This project was completed as part of an Interaction Design II course at Kennesaw State University. The purpose of this project was to learn the Lean UX process and have an opportunity to execute it.

Approach

Lean UX was the method used to bring this idea to life. This is a design approach that embraces fast-paced, team-centric environments; made of UX, Agile, and Scrum, Lean UX is the perfect way to have continuous collaboration with a cross-functional team in order to produce user-centric products.

Role

Team leader, interaction designer, user research, content design

Tools

Figma, Discord, Outlook Teams, Photoshop, Illustrator

Duration

August 2022 - December 2022

Challenges

Aiming to make this app educational rather than a social media hotspot, educate those of legal drinking age that have not been introduced into the bar industry, meet all user goals, creating a quiz that was personalized to the user’s tastes

Links

Prototype (links to Imbible’s Figma files)

Figma Workspace (link to Imbible-related research process)

Meet the Team

Introduction

As mentioned above, the prototype developed for this project is called Imbible, an app intended to educate college-aged adults about drinks: what they mean, what’s in them, what to get, and how to order it.

This project was part of the course Interaction Design II, instructed by Dr. Michael Lahey, and designed to cooperate with the concept of Lean UX. At the beginning of the semester, each student in the course presented their own ideas for an interactive user interface to possibly be developed. I pitched the idea of an app that would allow people to learn bar lingo and figure out what drink suits them the most. This stems from my background, as I have been bartending for 3 years now and get countless people in their early 20’s come in that are absolutely overwhelmed by ordering a drink and don’t know where to start. Unfortunately, it’s just not realistic for me to sit with every single customer on a busy night and inform them about the 1000 different variations of drinks, although I would love to. That’s where the idea of Imbible came in: what if there was an app that could teach them instead? We then voted on the pitches we wanted to work on the most, and my idea was ultimately chosen as one of the six possible teams. I was excited and honored to be able to be a team lead for a group of wonderful, creative minds, and thus began the semester-long project.

My role as the team leader came with several responsibilities:

  • Organized all team meetings

  • Set up/moderated interviews

  • Presented my ideas for content, design, and goals

  • Facilitated discussion amongst my team about the app and relate it back to Lean UX

  • Set up a team calendar to keep my team organized

  • Making sure all of my teammates were on board and engaged with every design/prototype change

  • Designed and prototyped the Drink Dictionary, Bar Lingo, Icons and Pictures, and some parts of the Quiz within Figma

  • Revised the final prototype before turning everything in at the end of the semester

Log in Screen

The Lean UX Method

Lean UX utilizes fast-paced, cross-collaborative environments. This cross-collaboration helps in having multiple figures who are specialized in one aspect of UX in order to bring more perspectives in creating a quality final product. Agile and Scrum are both important aspects of Lean UX as well; Agile is an approach that is based on delivering an iterative of certain requirements throughout the work cycle, while Scrum is a specific Agile methodology. Scrum is work done in sprints, contains daily stand-ups, and once the work has been evaluated, it is adjusted and done again. In short, Lean UX is “designed to guide the conversation from the current state of your product/system to its desired future state” (Gothelf & Seiden, 35).

It is worth noting that the version of Lean UX we used was adapted by our professor to fit the timeframe and accessibility limitations of our course. Pictured below is the Lean UX canvas we loosely followed throughout the semester.

Below you will find a more in-depth process of how we went about building this app, divided into 2 sprints and a conclusion.

Sprint 1

To begin this Lean UX process, we were tasked with completing our first Sprint. A sprint is a length of time that designers have to create a specific amount of work in order to make the overall workload more manageable. This sprint was divided into 3 chunks: Design Week 0, Sprint Week 1, and Sprint Week 2.

Design Week 0

The first week in this 6 weeklong process started with my team and I focusing on filling out our first iteration of the Lean UX Canvas, which is a method used to help move your product idea into reality. My team and I met during our regular class time in person to work on this, which included brainstorming our business problem statement, creating Proto-Personas, making hypotheses, finding solutions, and filling out a product/sprint backlog.

I established what I was hoping to see in the end product with my team, and from there we started brainstorming for our business problem statement: a statement that contains the current goals of the product, what has changed in the world and how it has impacted the product, and a request to improve the product. This in turn helps the team focus on solving problems rather than implementing features.

We then moved on to business outcomes to determine how we will measure our success. With the BPS and outcomes now complete, we could move on to creating our first two proto-personas. The proto-persona is an assumption that the team made in order to create a shared understanding of who the target user(s) will be.

After creating our two proto-personas, 22-year-old Emma Bolton and 32-year-old Theodore Brown, I guided my team into discussion about what would be our riskiest assumptions, and we all collectively decided on what would be the most important assumptions to test and collect data from. From this information we could then combine all our assumptions into Hypothesis Statements, which were organized into multiple Hypothesis Tables.

1st iteration of our primary persona

1st iteration of our secondary persona

With this information we gathered, we completed a Product Backlog, detailing which goals we will be designing and testing. This information also gets inputted into our Sprint 1 backlog, which shows what goals my team and I will be aiming to complete for this first Sprint.

Sprint 1, Week 1

Now that the Lean UX Canvas was complete, my team and I could finally begin the first official week of sprints. During this sprint we were required to hold stand-up meetings every two days, build a Minimum Viable Product (MVP), conduct interviews to evaluate our MVP, and utilize affinity maps.

My team and I needed to start out by building our MVP to understand value, “What is the most important thing we need to learn next?” (Gothelf & Seiden, 89). I discussed possible options with everyone, and we all came to the consensus that jumping straight into Figma to build a prototype would work best for the ideas we had. My team and I started by laying out our design inspiration, the icons we would be using, and the layout of the screens. We then built a very basic homepage, quiz, the bar lingo page, and a favorites page. We decided to go with these features because by allowing the user to test these out first, we would be able to confirm/throw out the assumptions we had established in Design Week 0.

Our team conducted three interviews in Sprint Week 1. To prepare for these interviews, I wrote a rough interview script to follow before asking the participant to go through and explore our prototype. Each interview was held virtually and began by having the interviewee sign a consent form, and then we asked them the questions found in our script to give them a sense of what they will find in our MVP. From there, we then sent the link to the prototype and had the participant explore the app, providing feedback along the way. This allowed my team and I to discover two major patterns found in most of our interviews: ideas that confirmed our existing assumptions, and new ideas/goals the user gave us that we needed to implement. After each interview ended, my team and I then utilized affinity maps. These affinity maps allowed us to organize our notes from the interviews and pick out significant patterns from the data. This is where we started to recognize our two major patterns within our collected insights.

During Sprint Week 1, I conducted stand-up meetings with my team 3 times a week, with each meeting being around 15 minutes long. The purpose of these meetings was to keep everyone on the same page, remind the team of important dates, see what we have accomplished, and what is next for us. This is where we decided that our assumptions were valid, but we needed to implement other ideas in order to fully meet our users’ goals.

Our 1st week of stand-up meetings

Sprint 1, Week 2

Moving into the last week of Sprint 1, we kept the schedule relatively the same, with our 2-day stand-ups still taking place. We started the week off by implementing a few new features that were feasible in our timeframe in order to meet the user goals from previous interviews, such as the “strength-meter” found on various screens. 3 new interviews also took place, in which we again confirmed assumptions and collected new ideas to improve our solutions. However, since this was the last week of Sprint 1, I conducted a Sprint Retrospective meeting at the end of the week. The Sprint Retrospective was an hour-long meeting meant to make us as a team think about what went well during this sprint, what needs to change, and how to improve for the future.

After completing the first Sprint, it was obvious to my team and I that we were on the right track. We had confirmed many of the assumptions we had made by testing our prototype with users, collected data for new ideas to implement to improve the user’s experience, and got a good feel for how a sprint should work. Moving forward into the second sprint, we knew we needed to make major changes on the prototype in order to allow the interviewees in Sprint 2 to give us relevant feedback. These changes would be made based on the information we found from interviewees.

Sprint 2

My team and I kicked off Sprint 2 knowing that our assumptions were accurate based on evidence from Sprint 1, and we already had in mind the new solutions we needed to implement to meet user goals. We worked on the app for a period of time, turning it into an high quality prototype that was highly interactive and finalized in design choices.

Design Week 0

The work my team and I completed in Sprint 1 gave us the opportunity to test the waters regarding our assumptions and backlog goals and determine if we were on the right track in meeting user goals. Sprint 2 meant that we needed to revalidate these ideas. We reiterated the process of working through the Lean UX Canvas in order to see what we knew to be accurate, and what needed to be adjusted. This process showed us just how fast Lean UX is, and that needing to change portions of a project can be a good thing.

Going back into our Lean UX Canvas, my team determined that a few things needed to change: the business outcome section of the canvas needed a missing leading outcome metric, the download link feature that we originally included in the product backlog was irrelevant and needed to be removed, and we needed to update our proto-persona to be a more accurate reflection of the interview data. This process helped us learn that it’s ok to be wrong and even a good thing to realize that something is not right this early in the design process. If an assumption is found to be inaccurate after collecting evidence from users, it needs to be removed, and the team needs to reiterate to figure out what would help the user meet their goals.

This insight helped us make changes to improve our proto-persona. When we originally thought we had two main audiences, we realized that most of the audience can be grouped into one category, so our secondary persona was removed. Our new proto-persona was adapted to what we found from our interviewees: the user wanted to be able to share drink ideas with friends, educate herself on bar lingo so as not to be “embarrassed,” and to browse/discover drinks without needing to take the quiz.

2nd iteration of our persona

Sprint 2, Week 1

Our team was quickly approaching the final weeks of developing the prototype. We kept most if not all design choices the same, as all of our users stated that they enjoyed the design and layout of the app. We instead chose to improve upon some features already implemented, like the quiz, as well as add a few new ideas, such as the “more info” feature on the quiz results page. The process in this sprint was generally the same routine, with 2-day stand-ups continuing to take place, and 3 more interviews being conducted as well.  

The interviews for this week were still held virtually, and they all still gave us content to populate the two categories we had derived from the first sprint (new ideas/confirmations of assumptions). We found from these interviews that our users wanted to see an in-depth list of cocktails (drink dictionary) and a way to retake the quiz.

Features we added to the quiz results in Sprint 2

Sprint 2, Week 2

My team and I were now in the final week of our sprints, meaning we needed to make final major decisions regarding our prototype to ensure that we were meeting user goals. Our stand-up meetings were still taking place, and we conducted our final 3 interviews, in which we brought back interviewees from the first week of testing in order to get a good perspective of what went right/wrong with our changes.

Before the final interviews, we included the last few features that users requested from previous interviews, like populating the homepage to include a “Suggested Drinks” feature, a link to retry the quiz at any time, and the Drink Dictionary, which is an in-depth list of all cocktails that includes recipes. The affinity maps for this week, however, differed from Sprint 1 in that we no longer had new ideas to implement, but rather just confirmations of our assumptions.

 A final Sprint Retrospective Meeting was held this week as well, in which I led the discussion with my team about everything we had accomplished, what we did right, what we could do differently in the future, and final touches to be made to complete this project. 

 A 3rd iteration of the proto-persona was something my team needed to consider as one of our final work sessions. However, after much discussion and referencing our evidence from user testing, we decided that our proto-persona was sufficient in accurately representing our user, and did not need to be changed. We learned that all of our user’s needs had now been met, our assumptions were all accurate, and our final design/prototyping choices were met with consistent positive feedback.

Completing the second sprint was a major milestone for my team, and we felt incredibly accomplished and confident in our work, knowing that our users were happy. It was time to make final tweaks to the prototype and turn it in.

Conclusion

Working in this team was a phenomenal experience, and I absolutely enjoyed being a team lead to my incredibly talented team members. I feel working through this project in the role that I had was a great way for me to step out of my shell and guide people through a process in order to reach our end goal: provide a great user experience. Of course, like all projects, this process provided me with challenges I had to face as well, such as finding a good candidate to interview, scheduling conflicts, ensuring that user goals were being met, building based upon assumptions, and validating said assumptions. There were instances where we needed to add a feature in order to meet user goals, such as adding the Drink Dictionary. However, I embraced these challenges as best as I could and lead my team to success, and learned that adaptation to change is important, being wrong at first is ok, the importance of validating assumptions, and how the process of Lean UX aided me in my growth as a UX Designer.

I think if I were given more time on this project, I believe I would attempt to flesh out some of our content more, such as the bar lingo and drink dictionary terms. Due to limited time, we had to put a cap on how many terms we could include, but in an ideal world I would have made the list quite long to be as in-depth as possible. I would also have loved to implement a feature mentioned by an interviewee in Sprint 1 that we did not have time for; this interviewee wanted to see a feature when you’re viewing a page such as the drink dictionary, where the user can tap a term they may not be familiar with in order to be brought to its terminology page and learn about it. A search engine was another feature mentioned by an interviewee, but again, due to time, this was not feasible for us.

I thoroughly enjoyed the process of learning about and executing Lean UX, as I love the fast-paced, collaborative nature of the concept. Being a team leader was a wonderful opportunity, and I am incredibly grateful for my team to allow me to guide them through this project and grow with them in the task of becoming better UX Designers.

One example of a bar lingo screen, in which I would want to flesh out more.

Previous

Museumid
Next

Ethnography Study