Benjamin Wong - UX Designer
Benjamin Wong /
UX Designer
DrinkR. App Concept
A mobile app to order drinks at bars
Brief: Use research to find the pain points for bar-goers and understand how technology can improve their experience.
Duration: 2 weeks
Team: Benjamin Wong, Nico Mele, Srimathy Karuppiah
Project tools: Paper & Pencil, Sketch, Invision, Google Forms
Skills: Interviews & Surveys, Research Synthesis, Competitor Analysis, Personas, Rapid Wireframing, Prototyping, Usability Testing, Design Iterations
Research Phase
Interviews and initial findings
We decided to look into the local bars around the city to see if there was a way to help them improve business.
We performed a series of interviews, first with bar-goers to gain some insights as to what negatively affected their experiences.
After speaking with 6 bar goers, we found some common trends.
-
Waiting extensive periods before ordering negatively affected their nights out.
-
Large crowds around the bar meant that people would be less likely to order.
-
Many of our interview participants set budgets before going out for the night, but generally went over their spending limit.
From there we spoke to 5 bar workers to understand any problems on the opposite side.
-
Bar workers noted that the most significant issue for them was cutting off highly intoxicated people.
Following our interviews, we decided to put out a survey to see if our findings were consistent across a larger group of people.
Survey, Results and Project Direction
Following our interviews, we decided to put out a survey to see if our findings were consistent across a larger group of people.
The following questions were included in the survey:
What are the factors that stop you from ordering at a bar?
What is the longest you're willing to wait to have your order taken?
What factors help determine which bar to go to?
How important is budgeting to you on a night out?
Overall, our survey results affirmed what we learnt in the interviews, and we were able to determine the direction in which we would want to take our project:
Rather than craft a solution centred around a particular business, we decided to cater to consumers to minimise or eliminate the pain-points that they experienced when going to bars.
Problem: Bar-goers don’t want to wait for extended periods before having their order taken,
and want to avoid large crowds.
Solution: Bar-goers need a way to easily and conveniently place orders, while also being able to gauge how busy the venue is.
Personas and Empathy Mapping
Pictured is our empathy map - a way for us to understand what users see, think, feel, hear, say or do.
Empathy maps were created to help us form the basis of who would be using our application, and what issues we would want to tackle. Combined with the previous interviews we had done, we created two key personas to better understand our target users.
Our two personas were:
Charlotte - “The wait hater” who does not go out too often, and therefore does not want to spend a large amount of her evening waiting to order.
Olivia - “The bar owner” who wants to keep her customers happy, and thereby improve business.
Proposed Features
While there was a large list of features that we would have wanted to implement into the final product, we focused mainly on trying to address the core user concerns that were raised during interviews and surveys.
-
Ordering system for drinks
-
Estimating wait times for orders
-
Estimating crowds
-
Integrated payment system
-
Spending tracker
Pictured is a list of potential features, sorted by what Must, Should, Could and Won't be included.
Design Phase
Wireframing via. Timeboxes
We ran a design studio where we had 20 minutes of individual design sprints, to very quickly transfer our ideas of the core features to paper, receive feedback and brainstorm once again. After a few cycles, we combined the best components of each member’s design into our first paper prototype.
Paper Prototype Testing
We began our first round of testing directly afterwards, providing participants with ordering two beers and reaching order confirmation screen.
While the task was relatively straightforward, they noted that there was some confusion in the navigation and ordering steps, and they did not immediately recognise the filter icon and its purpose.
As such, we decided it would be best to begin prototyping digitally so that we could better represent the icons and overall navigation.
High Fidelity Prototyping and Wireframes
We divided the work by choosing some of the different stages that were represented in the paper prototype.
-
I created a logo and the order confirmed + order ready screens.
-
Nico worked on the “Find a bar” screen and Hamburger Menu
-
Sri created the menu and order confirmation screens.
Once these screens were all completed, I placed them in Invision.​
Presenting the Prototype and Further Feedback
We presented our high fidelity prototype and provided a walkthrough of the application and its features.
While the simple design and inclusion of some interaction details was well received, there were still some issues that were pointed out.​​​​
The colour purple was used too much in the menu and cart screens, making it harder to distinguish some of the “Call to action” buttons
Consideration was made for some interaction and disclaimer elements, however this were noted as hard to see when doing the walk through of the prototype.
Final Thoughts and next steps
Overall, the DrinkR project was extremely insightful. While I have had previous experience in design, this was my first opportunity to apply my research skills. This was also my first experience in designing a project collaboratively. I am very happy with what we were able to achieve over the two week period, and would like to continue to push the concept further.
-
The first step would be addressing the issues in the current iteration.
-
I would then like to continue to test and refine the iteration across a larger number of users.
-
Finally, I would like to begin the process again, this time building the business side of the application.