Eateractive
Roles
User research, UI design, usability testing, visual design
Context
During the HCDE user-centered design class (Oct ‘18 - Dec ‘18)
Problem
Family-owned restauranteurs struggle to compete with larger restaurant chains, due to insufficient seating capacity and technology.
Outcome
Designed high-fidelity mockups of a POS system extension that would enable restauranteurs to enhance their customers’ experience.
Family-owned restaurateurs need a way to improve the customer dining experience before the restaurant visit, because owners often lose customers due to long and unpleasant waiting periods.
user research
We conducted two user research methods: a competitive analysis of products/services related to our project, as well as semi-structured user interviews. 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.
At this point, 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.
personas
After conducting research, we synthesized our findings to learn about who we were designing for. To better envision our potential users, we drafted several personas. We first created two provisional versions, which outlined each persona’s goals, pains, motivations, and technology usage. To avoid enforcing stereotypes, all of this information came directly from our interviews. Creating polished versions brought our personas, Eric and Mae, to life.
Eric and Mae appeared throughout our design process, reminding us to keep our design centered around our users.
user journey map
We created a user journey map for one of our personas, Eric. Doing so allowed our team to flesh out his scenario and pinpoint the interactions in his day that could potentially be improved. Recognizing Eric’s pain points in particular helped inform what problems family-owned restaurateurs face, and what requirements our design should fulfill.
Before we could consider how our product would look and behave, we had to confirm what our product should accomplish.
design requirements
From our existing research, we resolved that our product should:
Help owners shorten customer wait times
Integrate a reservation system into a Point of Sale (POS) system
Allow owners to depict real-time restaurant traffic
Create a queue that shows the wait time for each party
Allow owners to present an interactive menu (while customers wait in the restaurant)
By establishing ten design requirements, we were able to determine what information and capabilities our product should provide, so Eric and other family-owned restaurateurs can better navigate the pain points introduced in our journey map.
storyboards
I created both a hand-drawn and photo storyboard to envision how our product could fulfill our design requirements. Each one used visual panels and text-based explanations to address how, where, and why family-owned restaurateurs would interact with our product. By collectively creating eight storyboards, our team was able to empathize with our users and ultimately explore what features would be most beneficial to Eric, Mae, and other family-owned restaurateurs.
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.
information architecture
Our information architecture illustrates the hierarchy and pathways that exist between the pages of our design. 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 IA also solidified how users could purchase and install our “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.
paper prototypes
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
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.
By testing our low-fidelity prototype, we could ensure that our product design was user-friendly and conceptually sound.
evaluation findings
Using our paper prototypes, we conducted usability tests on several users. To do so, we asked four users to perform the three tasks we previously outlined. During each test, our user interacted with our paper prototype while members of our group facilitated and laid out pages for quick access.
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.
ANNOTATED WIREFRAMES
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.
HIGH-FIDELITY MOCKUPS
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 allowed our team to visualize the many design decisions we made throughout this process.
TAKEAWAYS
Experiencing the full user-centered design process was both challenging and rewarding.
Conducting and analyzing user research (effectively) takes more than one week—respect the process.
Creating visual designs as a team can be difficult, as members often have different style preferences; as such, every design decision must be backed by logic.
Learning to respond to and grow from critiques make you a stronger designer.
Most importantly, empathizing with your users’ needs is what the process is all about.