MS3: Defining a Solution - ISIS3510-202410-Team23/Backend GitHub Wiki
Introduction
In this MicroSprint, we expanded on the problem and idea decided in MS-2. The problem selected was the Gastronomy Offer and after obtaining insights from an empathizing and defining process, we arrived at the conclusion of implementing an app to help students on campus find places to eat and assist others with reviews. We first reviewed the feedback from last week and, from this, we decided on the solution after understanding our potential customers through empathy maps and personas.
In this wiki you will find a description and explanation of the process made during this MicroSprint in order to select the idea we are going to implement in the next sprints. Additionally, you will find the empathy maps, personas, and finally, decisions that were developed throughout the week.
Table of Contents
Brainstorming Process
The following passage will detail the entirety of our brainstorming process. Our brainstorming began with an initial meeting on the 26th of January, during the first week of the semester. Here, before being presented with other problems by the ISIS3510 team, we met to discuss possible problems, ideas, and solutions to take on during the course. During this session, we first talked about ideas for a mobile application taking into account the domains proposed by the course syllabus: “circular economy, and apps for the campus/university”.
This first approach proved to be arduous, because we all had great ideas and motivations behind them, but we could not decide on one idea and spiraled with positive reactions tempered by specific reservations (e.g. "I'm fond of your idea, but ..."). Therefore, we concluded it was easier to think about problems instead of solutions first (granted this all happened before the design thinking lectures).
Consequently, we had two main takeaways from this first session. First, focusing on ideas and solutions was rather counterproductive because the ideas proposed did not tackle solving a specific problem. Hence ideas were not human-centric. Second, when thinking about solutions we need to always ask the question: What makes this a mobile app and not just a web application? What hardware features can we use to enhance the solution?
Later on, during our second week of classes, we took on some of the problems proposed by the ISIS3510 team. After completing the empathizing phase of design thinking through our interviews and situations, we gathered to have another brainstorming session. In this session, each team member briefed the others on their findings from the interviews, including insights, takeaways and pain points. We discussed the scope of each problem, how difficult it would be to solve it with a mobile app and if it was justified to do so, that is, if the solution would actually take advantage of a mobile phone’s features or if it could just be solved with a web app.
After a lengthy discussion, we took a vote to decide what problem to focus on for the rest of the Sprint, as seen below.
We further continued to explore this problem through the Design Thinking tool of Journey Maps, to gather more insights and paint points of the selected problem. With all this knowledge at hand we held another brainstorm session where any idea about the problem, pain points and solutions was welcomed, as detailed in the image below.
We had lots of similar ideas, so we decided to group them based on similarity. These core ideas were the ones we used to develop our initial prototype. This process began with a bare-bones mockup, where we tested and discussed different ways to satisfy the pain points through features. One of the advantages of this approach was that it made it easy to validate internally if what we were designing made sense before committing to a higher fidelity prototype.
Decision Process
We used the diverge and converge strategies to select one idea. Our earlier brainstorming process allowed us to diverge into several ideas for things that would solve the problem. We now had to decide which of these ideas to select. For this, we used the Four Categories method of the convergence strategy. As a team, we looked at each idea, discussed its usability and usefulness and selected whether it was a ‘rational’, ‘darling’, ‘likely-to-delight’ or ‘longshot’ idea. Below, we include a diagram that shows the final convergence of ideas:
Based on the convergence, we came to the conclusion that the general idea revolved around creating a community through restaurant reviews and using the information given by said community to satisfy their needs and pain points. These core ideas were based on those categorized as ‘rational’ choice and ‘most likely to delight’.
Still, some of the ‘longshot’ ideas were clear pain points for our users, but due to their complexity could not be taken on directly. We then discussed ways we could solvent them through different means. For example, keeping an up to date menu would require lots of (manual) information gathering, but if in every review we asked students what they had eaten we could build an ad hoc menu that could still provide insights into the type of food served by restaurants. Another of these ideas, real-time wait and occupancy monitoring would require us to track students’ location constantly, leading to privacy concerns and high computation costs, so it was discarded.
Empathy Maps
To understand some of our potential users (what they see, feel, do and think), we did five empathy maps.
Empathy Map 1
Empathy Map 2
Empathy Map 3
Empathy Map 4
Empathy Map 5
Personas
A Persona is a great method to model a set of potential users in one diagram. We can understand their needs, motivations, pains, and technical aspects. We did 3, one for each potential set of users.
Persona 1
Persona 2
Persona 3
Solution Description
The central idea of the proposed solution to the problem revolves around the community sharing their thoughts at different lunch places around campus through reviews that focus on important aspects of the experience. Through the use of the application, students can find a place on (or near) campus that meets their needs.
Since the success of such an application is based on the information our users provide, the rating experience needs to be as seamless and simple as possible while also capturing the essential data about each spot. First, we will ask students to categorize what they had for lunch at the restaurant they wish to rate, which will help gather data on their culinary offers. Then, students will be prompted to rate the restaurant based on predefined categories that most influence the decision to go to a place or not: waiting time, price, cleanliness and food quality among others. Finally, students can optionally provide a written comment about their experience and include pictures of their meal if they wish to do so.
When a student is deciding where to eat, they can find a browse page where they can quickly find the relevant information about a restaurant: price, distance, food category (vegan, vegetarian, gluten-free, etc). If an option catches their eye, they can find more details about the ratings and reviews it has been given, and its location on a map. Additionally, this detail will include the restaurant’s rating in terms of customer experience (food quality, waiting time, service, cleanliness).
Through our interviews and empathizing process, we saw that people stressed the importance of word of mouth and hoped to have a community-based system to emulate this. This is why we chose to leave out the restaurant owners themselves to avoid their influence on the information displayed (i.e., self-promotion, discounts, etc.)
Finally, as an add-on from the Friday, February 9th class, we discussed some potential smart features, like a recommendation system based on previous reviews the user has given, and automated categorization of the restaurants according to the most common food types that are placed in the reviews (i.e., fast food, vegetarian, italian). Additionally, we thought about context aware features, like a notification system for leaving reviews which prompts the user to leave a review after leaving the place or restaurant they were just at.