Retrospective 1: Rapid prototyping
Create a rapid prototype for a mobile app to solve a problem given to me
My category was ‘food’ and the problem given to me was:
“I like to have supper but I don’t know if the place is crowded or not” — User 1
Before I dived into my user interview questionnaire, I set my research goals. I zoomed out from the specific criterion of crowdedness, the specific meal of supper, and wanted to find out:
-WHAT are people’s criteria when selecting a restaurant?
-WHEN do people book restaurants beforehand?
-HOW do they currently book restaurants?
-WHY do they use these methods?
That makes people who make prior reservations at restaurants my target users. I composed a set of interview questions themed around the above questions. The structure of my interview was:
- Ease in by asking about their eating patterns such as preferred cuisine, weekdays Vs weekends, eating out Vs home-cooked meals, and no. of daily meals (I wanted to see if most people even went out for supper).
- Find out what matters to people while selecting their restaurants by asking them to describe the last time they ate out, a specific good experience, and a specific bad experience.
- Find out in what situations do people make prior reservations. Ask them about their preferred method of booking, and a particularly good and bad booking experience they had. And just to make things more fun (but mostly just to get more information) ask them about situations where the booking process went well but the restaurant experience didn’t, and vice-versa.
- Ask them about their experience with using mobile apps for reservations, and if they don’t use any, what would be something that would definitely make them use one.
Very quickly into my user interviews, which consisted of 5 target users, I found that most people don’t go out for supper, crowdedness is not a concern while reserving tables [Fun fact: the good restaurant experience described by the person who gave me the problem statement was jovial staff and lot of strangers joining in the merriment, and the bad experience was when they were the only people in the restaurant]. Moreover, people were satisfied with their current modes of booking - directly calling the restaurants, since it gave them a sense of security that they didn’t have with 3rd party apps. My initial thoughts were going in the direction of creating a mobile app to make reservations while also providing a call feature.
When asked about bad booking experiences, one interviewee had mentioned having had to call the restaurant multiple times to make a booking. This led me to do a follow-up interview with the others, focusing on what they did when the bookings failed. These were the responses:
I’ll wait for the next available slot or call a different branch of the same restaurant.
I’ll go to familiar places that I know won’t be full.
I’ll look for another place that’s listed on Google’s ‘find a table’, I don’t like to call.
I’ll try calling till they pick up.
People were repeating the entire booking process using whatever mode of booking until they found a table somewhere.
My problem statement took an entirely different direction and was now changed to: People making restaurant reservations need a way to see table availability, because time is wasted when they try to book tables at places that are fully booked. My solution would be to create a mobile app that would:
- Display table availability of restaurants for a chosen time. (Priority feature based on implicit research insight)
- Filter and Sort restaurants based on cuisine, ambience, diet type, budget, accessibility to public transport, service quality, online reviews, seats available, and amount of discounts/promotions. (Features based on explicit research findings)
- Bookmark restaurants, provide a call feature, and a direct search feature. (Bonus throw-ins. Users can check their familiar places, and call if they need that sense of security. And in both instances, they would be still saving time as they can see table availability)
User flow and Prototype
I did not sketch out anything on paper as it was pretty straightforward and dived straight into creating a user flow in Axure and fleshing out the prototype on Adobe Xd.
I named the app - MESA which is ‘table’ in Malayalam (my mother-tongue) and many other European and African languages.
Learning outcomes and improvement opportunities
- It is possible to deviate entirely from the initial hypothesis and that’s fine. It’s probably why it is called a hypothesis anyway.
- It is not easy to look through the research data and organise them to synthesise implicit insights. This was the most valuable outcome of the project.
- I hadn’t checked out layouts of existing restaurant booking apps and got the feedback that my layout is very clean, unlike the existing apps. Though lucky this time, in future, it is probably best to check out existing apps in the research phase.
- I received feedback that I need to be louder and look more excited while presenting (I was probably channelling some Kristen Stewart).
What next for the project?
No usability tests could be conducted due to time constraints and perhaps the app could let the user opt to get notified whenever any of the currently unavailable restaurants have seats available.
Also, I have no idea how databases work to get the most updated table availability from all participating restaurants. I need to read up on this.
And although I can see the benefit for the users, I need to find out how to get businesses - the restaurants, on board as well.
Needless to say, some polishing up in the visual design department won’t hurt although it wasn’t a requirement for this project. And here is a pdf of the project presentation.