Designing Byron Burgers’ App
Don’t want to go through the hassle of table service? Then use this App
The Brief
While at the General Assembly UX Design Immersive, we had a group conceptual project assigned, where our group (4 members) was tasked (in 2 weeks) to design a conceptual mobile App for Byron Burgers.
The tasks I took care of
- Represent User Research into Affinity Mapping, Persona and Empathy Map.
- Conduct Usability Testing.
- Take care of layout and spacing of elements in the wireframes.
- Move the wireframes into high-fidelity and create the Style Guide.
The software we used
- Figma, for UX and UI design.
- Trello, for tasks/time management.
- Miro and Zoom, to share information and interact with the team.
- Google Forms and Sheets, to research and manage information.
- Google Slides, to present our work.
The Framework applied
To begin this project my team and I applied the Double Diamond process, which is a framework that segments the design process into 4 stages: discover, define, develop and deliver.
Understanding who they are and what they want
Byron Burger is a chain of burger restaurants. They pride themselves on their unique style of burgers and the different aesthetic of each restaurant. Seeing an opportunity in today’s landscape of growing popularity in apps that let users order and pay for food, they want to create an app that can fulfil these needs for their customers.
For this project they wanted an MVP (minimum viable product) -a clickable prototype- that included:
- The ability to order and pay for food.
- A visible restaurant’s layout, and the availability of the tables.
- And to find a way to showcase the different styles of the restaurant’s venues.
Seeing what’s out there and what’s working for people
Checking out the other burger restaurants
After understanding their position in the market, we decided to research on Byron’s competitors; restaurants focused on selling burgers and other restaurants that were doing great in general. We identified 6 of them and ran a feature Competitive Analysis, finding that:
- 1/6 restaurants let you book a table.
- 0/6 show the restaurant’s layout.
- 2/6 restaurants have mobile apps
Therefore we saw the opportunity for this new app to come into the field and fill the existing gaps.
User’s Behaviours and Frustrations
To begin to comprehend the users, we created a Survey on Google Forms and distributed it on social media; I specifically wrote questions about their behaviour, their past restaurant experience in general, if they had any frustrations, etc.
Our 63 responses allowed us to have a better understanding, but as we needed to find the issues, we contacted 15 candidates to interview. The key findings were:
- People struggle to book a table, as they can’t see the restaurant layout, to sit in their preferred area and feel safe (due to Covid-19).
- when paying in groups, they get annoyed when they have to manually split the items they consumed and pay their correct share.
Therefore, my team and I decided to create an Experience Map to showcase these findings visually, and specifically, in the user’s journey, the pain points as their emotional state declines:
Synthesizing the information
Representing our user
After laying the foundations of the project, I took our user research and distilled the insights to create our Persona, Sam, with a technique called Affinity Mapping.
This helped us to summarise and find the needs, pain points and challenges the users experience when eating out.
Sam helped us to keep the main user’s needs on track, and at the centre of our design process.
I specifically created an Empathy Map, which is a technique wherein quadrant format, you write what a user (in this case, our persona Sam), says, does, thinks, and feels. It helped us to externalize more knowledge of our persona.
Our user’s Problem
After representing our user’s problem through Sam, we framed them as Problem Statements, a concise description of an issue to be addressed on. We identified two:
- First one referring to the struggle Sam goes through trying to book a table as most restaurants don’t have the option to do so.
- And the second one regarding Sam getting frustrated as she has to manually split the bill to, later on, pay her share.
Afterwards, we tackled them with a technique called How Might We (HMW), where we turned the challenge of the problem statements into opportunities for design. We run a Design Studio, where each member of our group had to come up with some screens that could solve the problems; the green dots indicate features that each one of us liked.
From this technique and the features we designed, we knew some of the features that the app would need to cater to Sam’s needs. Now talking about the app structure, we created an App Map that helped us to categories the key features, and have an idea of how the app was going to be structured.
Sam’s flow through the App
After knowing the structure, we created the User Flow, so we could see which screens we would need to design. We then focused on the booking and payment aspect of the app, as these flows could solve Sam’s problems.
Designing the solution
Sketching on paper the possible solutions
Putting all these ideas on paper, creating the different screens needed, was the next step, to start testing out our ideas with a Prototype. Below are some of the screens we used:
We assembled the prototype and tested it out. All of us conducted 2 Usability Testings, to understand what was working, what wasn’t, finding that:
- In booking, the testers found the shade/differentiation on the tables was confusing, a confirmation page was necessary.
- In payment, testers found the entire process too long and not intuitive, features like dragging items and splitting them by amount consumed had to be redesigned.
Iterating on the digital screens
We then decided to create the same screens in a digital format, Wireframes, applying the feedback received. Wireframes are a visual representation of the skeleton and elements of the app/website. I was responsible for the spacing and layout of the elements and features.
We conducted 8 usability testing for each level of fidelity. Here below the wireframes, we designed, moving from low, to mid to high fidelity, with some of the testing’s findings:
- In this flow of screens, users struggled to differentiate the available and non-available tables.
- In this flow, users were confused as to how to allocate items and felt that the wording could be more helpful.
- In this flow, users pointed out that there were too many screens to actually pay.
Interestingly we had difficulties with most features, in the low and mid-fidelity prototypes as we didn’t use words and colours, respectively. Because such features were a bit abstract, the users really struggled to understand the meaning/functionality behind then. But once we added colours and text, which wording was iterated, the experience improved a lot!
After all the needed iteration, we assembled the final prototype, which you’ll see later.
Delivering the Byron Burgers App
The App’s visual identity
Because Byron Burgers has already a website, were extrapolated the visual design elements from there to incorporate them into the wireframes, as we wanted to keep ensure consistency with the brand identity and aesthetic.
I then created a new Style Guide to reflect the new and existing elements.
How everything ended up looking like
I’ve attached a few images of some of the final screens, so you can see how the Byron Burgers App would look like:
Final prototype
Finally, here’s the link for the prototype on Figma!
Before you go ahead, let’s remind you of Sam’s scenario (the situation in which she would use the app for a specific purpose): “You want to make a reservation for 3 for today, at 7:30 with a specific table”. And after, test the payment path: “You already ate with your friends, they don’t have the app, so send them a request, and allocate the items for yourself and David, it’s his birthday, so pay for him as well!”
Conclusion
As you’ll have seen, for this MVP we didn’t focus on all of the items in the brief, for example, ordering, as we found out in the interviews that people struggled more in the other areas. Hence, we went in that direction as it was going to be the main challenge for this app actually to work for customers.
Okay, but what’s next?
- Continue to do more user research on the targeted audience,
specifically customers from Byron Burgers. - Further test and refine our final prototype to improve user experience.
- Reach out to Byron Burger for their feedback.
- Pitch accessibility changes to Byron Burger.
Did somebody like what we ended up with?
- The prototype got great feedback as they said: “looks robust”. They liked the amount of nicely integrated and iterated features, with user feedback.
- The project felt a bit hollow, as it looked almost too pretty because we didn't speak about Byron Byrons’ values and personality.
The lessons I'm taking from this experience
As I mentioned before, we struggled with usability testing, and later on, we realized why. You have to know specifically what you want to test, is it mind models? Most times you don’t need text and other details, but if you just want to know if people understand the pages and its functionalities, then you might need to add those details in order for them to make sense to the user.
We weren’t doing that properly, but now, we will! Thank you for reading this journey.
