Eateractive
The all-in-one Point of Sales Solution
ABOUT EATERACTIVE (PROBLEM STATEMENT)
Family-owned restaurateurs need a way to improve customer dining experience before the restaurant visit, because owners often lose customers due to long and unpleasant waiting periods.
OUR PROJECT
USER RESEARCH
POLISHED PERSONAS
Our user research consisted of competitive analysis of products or services related to our project, as well as user interviews. Each member conducted research individually, so we could increase the volume and scope of our findings. The goal of our competitive analysis was to evaluate how well a product or service met the goals and motivations that it set out to meet. Being so early on in the design process, we had not yet determined what our product would be. By interviewing potential users, however, we began to understand what features family-owned restaurateurs could benefit from. Our interviews were semi-structured; so while we prepared a list of questions beforehand, each interview was open-ended enough to allow the interviewee to think aloud and provide us with more personal feedback. The information we collected while interviewing our users facilitated our understanding of family-owned restaurateurs. By recognizing the demographics, goals, needs, and pains of our user group, we were able to create several personas.
WHEN: Created during an upper-level undergraduate course on User Experience Design, in Autumn of 2017.
WHO: Our user group is family-owned restaurateurs.
​
WHY: Family-owned restaurateurs often struggle to compete with larger food chains, as they may not have the same resources and entrepreneurial experience more established restaurants have access to.
​
WHAT: An extension to existing Point of Sales systems (like Square), which adds four key features: restaurant traffic flow, a waitlist queue, an interactive menu, and a corresponding customer website.
​
HOW: Scroll down to see our process!
​
After conducting user interviews and competitive analysis, we synthesized our research findings to identify the key behaviors and motivations of our users. At this stage in the design process, our goal was to learn about who we were designing for. To better envision our potential users, we drafted several personas, or composite archetypes of our group, family-owned restaurateurs. We first created two provisional, sketched versions, which outline each persona’s goals, pains, and motivations. We also included what forms of technology they regularly use, and a scenario to more clearly illustrate who they are. To avoid enforcing stereotypes, all of this information originated directly from our interviews. Creating polished versions really brought our personas, Eric and Mae, to life. Eric and Mae persisted throughout our design process, and reminded us to keep our design centered around our users. In our upcoming user journey map, for example, we expanded upon a scenario in Eric’s life, to understand his behaviors and interactions in more detail.
USER JOURNEY/EXPERIENCE MAP
A user journey map is a visualization of the experiences a person has while interacting with products and services along a certain timeline. Such illustrations allow touchpoints in that person’s path to be meticulously evaluated and improved. We created a user journey map for one of our persona’s, Eric. Doing so allowed our team to flesh out his scenario and pinpoint the interactions in his day that elicited a strong emotional response. Recognizing Eric’s pain points in particular helped inform what problems family-owned restaurateurs face, and what requirements our design should fulfill.
DESIGN REQUIREMENTS
Before we could consider how our product would look and behave, we had to confirm what our product should accomplish. By creating ten design requirements, we were able to determine what information and capabilities our product should provide, so that Eric and other family-owned restaurateurs could better navigate the pain points introduced in our user journey map. We broke down each requirement to understand its action, object, data, functional elements, and context. Doing so also helped us ensure we were properly addressing our users’ needs and goals. Next, we created storyboards to illustrate how these requirements could be fulfilled in certain features and functions.
STORYBOARDS
Storyboards are visual narratives that communicate the potential context in which a product will be used. For this project, each of our team members created one hand-drawn storyboard, and one photo storyboard. Our storyboards helped us envision how our product could fulfill the design requirements we introduced earlier. Each one used a number of visual panels and text-based explanations to address how, where, and why family-owned restaurateurs would interact with our product. By collectively creating a large number of storyboards, we were able to compile our designs and select which features would be most beneficial to Eric, Mae, and the rest of our users. After deciding upon several key features—real-time restaurant traffic, a waitlist queue, and an interactive website—we set out to create an information architecture to depict the pathways and hierarchy within our product.
INFORMATION ARCHITECTURE
An information architecture is a visual representation of the organization and structure of a product. Creating an information architecture allowed us to clearly illustrate the hierarchy and pathways that exist between the pages of our design. In particular, we were able to the determine the relationships between the features we first illustrated in our storyboards. At this point, we decided to create an extension to existing POS systems, so family-owned restaurateurs wouldn’t have to juggle as many different technologies. Our information architecture also solidified how exactly our users could purchase and install Eateractive software into their POS System. Using our information architecture, we were able to visualize how family-owned restaurateurs would flow through our product when performing several tasks. We exemplify three of these task flows in our paper prototypes below.
PAPER PROTOTYPES
ANNOTATED WIREFRAMES
Wireframes are images that depict strictly the layout of a design by excluding all visual design details, such as photos and colors. The associated annotations eliminate the ambiguity of any component whose purpose is not immediately evident. We created digital annotated wireframes to outline the functionality of our entire system, and also to revise the design of our paper prototypes based on our usability evaluation findings. Moreover, our annotations allowed us to justify our design decisions where we anticipated they might be questioned. We also created three key path scenarios, which break down important interactions family-owned restaurateurs would have with Eateractive. During a critique session, we learned what aspects of our product needed revision. We used this valuable feedback to polish our design for our final artifact: high-fidelity mockups.
Using our paper prototypes, we conducted usability tests on several users. Usability evaluations allow us to identify what parts of our interface most regularly frustrate users. Our findings can then inform what aspects should be fixed and retested. To accomplish this step, we began by asking each of our users to share their occupation and how familiar they were with restaurant jobs and POS systems. We then asked our users to perform the three tasks we outlined earlier: check real-time traffic visualizations, delete a party from the queue, and add a category and item to the menu. During each test, our user interacted with our paper prototype while members of our group facilitated and laid out pages for quick access. In addition to having an observer from our team take notes, we asked our users to think aloud throughout the process, so we could better understand their emotions while they navigated through each task. Our tests revealed several issues with our prototype, including an unclear page title, vague symbols, and obscure traffic visualization affordances. For each troublesome feature, we suggested ways to improve our design. These changes are reflected in our wireframes, shown below.
EVALUATION FINDINGS
Paper prototypes are low-fidelity, physical realizations of the concepts of a product. For this project, our team created paper prototypes to develop and test a number of our design ideas. We first defined three tasks our system would allow family-owned restaurateurs to perform: check real-time traffic visualizations, delete a party from the queue, and add a category and item to the interactive menu. To prototype the features users would require to accomplish these tasks, we sketched many of the pages illuminated in our information architecture. Creating these tangible artifacts served useful in our next step. To evaluate our product, we used our paper prototypes to conduct usability tests.
HIGH-FIDELITY MOCK-UPS
High fidelity mockups include all of the visual design details wireframes lack. Each mockup resembles a screenshot, and features the same layout, content, and design that would appear in the functional product. Using Figma, a collaborative visual editing software, we created mockups of the most significant pages in our system, specifically focusing on ones that would help family-owned restaurateurs accomplish their goals. We chose a limited color palette to match our contemporary design, as well as to highlight important information and affordances. For each screen, we incorporated feedback from both our annotated wireframes and mockup drafts. Our final mockups allow our team to illustrate the many design decisions we made throughout this entire process.
GROUP REFLECTION
We learned a number of lessons throughout this expedited user centered design process. There were challenges and surprises along the way. Every week we learned about a new step in the design process. Some were more difficult than others, and some took longer than we expected. In the end, we created a product we are proud of—but we know there is always room for improvement.
​
Considering the abridged timeline we had to complete this project, our user research was quite limited. It would have been helpful to conduct more user interviews, so we could have a more exhaustive idea of who family-owned restaurateurs are and what they need. That being said, having time to supplements interviews with observation and shadowing methods would have been even better. To see owners (and customers) go about their routine and react to various touchpoints would be extremely valuable. Moreover, if we had more time, we would test our designs on more people in the restaurant industry, including hostesses, waiters, chefs, and customers. By expanding the scope of our usability tests, we could add or edit features that could potentially be useful to a wider range of people. While our goal was to help family-owned restaurateurs improve customers’ waiting experience, owners are not the only group our product benefits.
​
One of the most surprising and challenging aspects of this project was discovering how diverse family-owned restaurateurs, and their businesses, are. The owners we interviewed had a wide spectrum of experiences, from not having enough customers, to having to turn people away. One place had about 60 employees, while another had just 5. In other words, our interviewees all faced different problems. By creating personas, however, we were able to determine the most recurring, important issues; after all, every user we interviewed wanted their customers to be happy.
​
User centered design is a learning process, and there are many things we learned as a group. Creating visual designs as a team can be difficult, as members often have different style preferences. While navigating this challenge, we learned that each of our design decisions must be backed by logic. Having critique sessions also allowed us to enhance each of our artifacts. Learning how to respond to and grow from criticism was a valuable way to strengthen our designs.
