- Alice Mendeleyeva
- Vasilisa Pugacheva
- Figma
- Miro
- Notion
Some competitive analysis was conducted to investigate existing solutions to the idea. Most of the ideas are not user-friendly, or are predominantly in the US.
A table addressing a few key details can be found on our Notion page.
The UX research started with an online survey that was distributed among various age groups. The survey was created prior to the project phase but was redistributed among a new set of participants after the project was selected for the project phase. A total of 91 participants took part in the survey. The survey included questions on bar visit habits, drink habits, payment habits, and pain points. The survey included a mix of multiple choice and open ended questions. The results could be investigated in more detail here.
As we can see from the survey, the most frustrating things are related to someone cutting the line in front of you, not getting the change back, bartenders not paying attention, and just the business of the bar.
Following that, we conducted qualitative research with bar-goers and bartenders. We conducted structured interviews where we asked bar-goers if they prefer to pay separately or go rounds, cash or card if they typically order the same things or try new ones, and what is frustrating about the whole process. As for bartenders, we asked them about the main challenges on the job, how they speed up work if needed, and if they can easily remember the order of drinks they have to prepare.
In-depth notes of interviews can be found here.
Based on both qualitative and quantitative research, we created an affinity diagram, where we identified key topics based on individual points we could identify.
5 overarching clusters were identified:
- Bar’s hospitality and workflows
- Difficulties in workflow and cocktail making
- Staff memory capacity
- Efficient bar workflow
- Hospitality/customer service
- Conversations with bartender
- Demographics
- Bar as location
- Bar atmosphere
- Bar as a “comfort zone”
- Customer fears and pain points
- Wardrobe and keeping items safe
- Customer pain points
- Ordering and payment
Consequently, we created two user personas based on common pain points and interview results.
You can see the work completed on our Miro board.
We also created two customer journey maps, both for a bar-goer and a bartender, but at this point due to time constraints we had to decide who is going to be the persona we are going to build our prototype for. At this point we decided to focus on a bar-goer, and focus only on the customer experience. We did not build the bartender facing part of the app, nor did we conduct further research on it.
The next step was the real challenge for us. We started to draw the actual comprehensive user flow based on all the features we wanted to implement and realized that we want to include too much in there. Our first journeys included everything: from finding a bar on the map to scenarios when users may choose if they want to do a part of the process offline, which ended up in having a lot of branches to our journey (screenshot of work in progress below).
At this point, our mentor suggested that we prioritize our solutions using the “Impact versus Effort” framework. We had another look on our affinity diagram, personas and customer journey map and started selecting different pain points that we identified.
Brainstorming:
Impact vs Effort framework:
As can be seen from the diagram, using this exercise, we identified low-hanging fruits and decided to implement the three must-have features that would have a high impact on our users by solving their problems, but at the same time require low effort from the developers’ side, which was important given the time-constraints of the project.
Following the previous exercise, we narrowed our decision down two two possible user flows as you can see below or in more detail on Miro and proceeded to UX Design process.
Queueing + ordering flow
Queueing + ordering + payment flow
After completing Customer Journey Map, we also decided to meet in person to sketch some ideas and brainstorm before finalising the user flow. You can see some of our sketches here.
After all the research was completed, we begun sketching out the flows on Figma.
We still were unsure if we want to have only a virtual queue feature where the user would scan the app to queue virtually and order offline, or the user would be able to order their drinks online and pay at the bar, so we decided to craft an AB Test to address our assumptions: which is a more important “waiting” problem for the customer? Is it to wait for your turn to order, or to wait for the drink to be made?
To test our assumptions, we conducted a total of 8 tests using our medium fidelity interactive prototypes as linked above. To validate our hypothesis we needed to have at least 70% of people prefer one of the two. Our test showed that 7 out of 8 (87.5%) people preferred the flow where they would order the drink online, rather than queuing online and then ordering offline since this requires too much switching between the tasks and therefore overcomplicates the process. Detailed report of the AB test can be found here.
In the end, due to time constraints, discussions with our team and feedback received from users, we decided to not only go for the “order online” but implement the payment through the app. At the same time, as in Berlin very often it is not possible to pay by card, people might be carrying cash out of habit, so in the final design we added an option to pay with cash as well, on the order summary page. At the end, users can also evaluate if they liked the drink so that our AI mechanism could give them recommendations for the next time.
There were several versions of the design created. Original version used some of the colours from the logo. After creating the first version, following mentor’s feedback we redesigned the pages after ordering and then we asked for some feedback from the team, the mentor and some other people regarding the copy and colours.
Figma: Medium Fidelity Prototype
Although the general consensus was fine regarding the colours used, it was discussed that these colours are too light and don’t evoke a “bar feeling”. Therefore, these were redesigned later on. Following a general consensus from the team, we proceeded with the candy gradient version which was extracted from the cocktail icon on the logo (for Logo brainstorm see here).
The user story for the working prototype that would need to be completed is:
You are at a bar with 2 friends - you want to order all together from your phone. You as a group want to order 2 Augustiner Helles and then a Moscow Mule. After you put these in your cart, one of your friends changes their mind about Augustiner Helles and asks you to order BRLO IPA instead. You want to place the order, add a 10% tip, and pay by card. After waiting and picking up your drinks, you give a rating.
I think for me, this whole project phase just reaffirmed the importance of UX and UX research particularly. It also showed that it's important to start small and build from that onwards, while keeping the main purpose of the app/product you want to create. If the whole process of project phase would be structured differently, with UX having the first 4 weeks to explore the problem and just discussing with teammates regarding capabilities, everything would have worked much better and in sync. We had to work faster to deliver ideas to Web dev to code the product as fast as possible. There were a lot of mismatches in UX work and Web dev work just because Web dev started to Code without us finalizing on which issues we will tackle and how will that interface look.
There are several takeaways for me. The first one seems obvious: you have to keep in mind what problem a user has and not what solution you already have in mind (this is why it is called User Experience, huh?). I could actually grasp it once I wrote an initial user statement that contained the wish to have an app that would help (of course the user doesn’t want our app, they want not to queue, and that is!). The second takeaway is prioritization. There is a temptation to collect all the ideas in one flow, but the resources are always limited and the problems are actually specific enough to address them in a simple and concise flow.