Rapid UX Project

Vision Statement

Domino’s Mobile Group Order App is dedicated to bringing people together and making pizza easier to order. By being able to invite your friends to order pizza, not only will this bring you and your friends closer together but also make the ordering process easier and more enjoyable.  

The goal of this Design Sprint is to achieve a solution from a targeted problem. My teams’ goal is to come up with questions in response to a challenge, brainstorm problems, and prototype a solution all while using generative research techniques. The goal of this five-day period was to work collaboratively and quickly to find a solid solution to a never-ending feeling of being hangry. Over the next five days my team will understand the issues, sketch these problems out, decide on a direction, prototype a solution, and validate our final product.

My team’s targeted goal is to create a valuable app that is both user-friendly and ties in with the Domino’s brand. We will determine our success on Day Five by either categorizing our app as an efficient failure, a flawed success, or an epic win. Either way, my team and I hope to learn a lot and gain insight on how to be better UX/UI designers.

‍

The Challenge - Problem Solve and Design Quickly

The Design Sprint is five-day challenge that exercises a group’s ability to rapidly prototype and test ideas with users. For this Design Sprint we were divided into groups of four and given the task of helping people order pizza for their group or family members through Domino’s before they get hangry. “Hangry” or “Hanger” is when you get hungry and angry at the same time.

Domino’s Pizza Company is a leader in the food industry when it comes to delivery service. This is largely due to the fact that their company identifies as a tech company. With a carefully crafted point of delivery interface, Domino’s relies on digital ordering. With so much invested into their ordering app, my team decided to take their app a step further and derive a plan to help Domino’s end hanger. And to better understand the infamous hanger feeling, we came up with the following scenario in order to get a better perspective and understanding of the problem.

‍Scenario: It’s getting late and you’re with your friends as the night is winding down. All of a sudden hunger strikes! You and all of your friends now have an important pressing issue. What do we want to eat? Pizza of course, who would want anything else late at night? So now you have to decide how you and friends are going to pay for this pizza, so you and your friends are satisfied.

The root of this problem derives from the issue of being able to split up orders fairly. Who gets what? What if one person doesn’t want to pay as much as the other? This causes a hick up within the ordering service and overall user experience with Domino’s. Our team’s challenge is to investigate this issue and help users avoid this problem when ordering pizza for their group.

Day 1 – Understanding

The first day of the Design Sprint is about understanding the underlying issue of the problem. To do this our group gathered together and wrote down questions that started with “How Might We.” The “How” assumes that opportunities exist. The “Might” claims we don’t have to find something. And the “We” is all about doing this together. Overall, we came up with nine total questions using this technique. Below are the questions we came up with.

• How might we remind customers to order food in time?
• How might we help people simplify their order?
• How might we reward returning customers?
• How might we broaden our customer base?
• How might we make our pizza more available?
• How might we do more than pizza?
• How might we help customers learn to make our pizza?
• How might we keep customers aware of our menu?
• How might we keep our customers engaged?

After we listed these questions out, we turned to an empathy exercise to gather insight into what others have experienced when ordering food when they are hangry. My group sat down with various users over the next few hours and had them explain their past experiences and the technology available when ordering food. The people we interviewed explained various scenarios that all began to sound the same. Most of them revolved around the issue of payments and not getting their order right.  We then sketched a set of tasks that outlined a situation of ordering food. We asked them to talk out loud while doing our tasks in order to help us visually understand where problems arose during the process of ordering and checking out. Doing this empathy exercise helped us get an idea from a user perspective of what problems occur when order food online.

When my group got back together after these interviews, we discussed what we learned and narrowed our “How Might We” questions down. During our first day we learned from our interviewees that a lot of issues arise when searching for the right food for everyone in the group. We also discovered that payment became an issue. Who pays what? What if one person doesn’t want as much food as the other? These are often problems that our subjects said effect their final decision when ordering food. This can cause people to press the eject button before hitting the final “Place Order” button.

Overall our first day was very successful. We were happy with our initial research and figuring out what problems exist. Coming up with a group of questions helped us start in the right direction for solving this scenario. We got together later and divided up our roles for our part in the Design Sprint. I was elected the group leader, and as the leader, I had to organize tasks, communication methods, and have a timeline for how we are going to address the rest of this Design Sprint. Moving forward my team began to think of how to visualize the questions we came up with.

Day 2 – The Sketch

For Day Two, my team gathered back to sketch our questions out of how this might look on paper. But before designing, we first practiced a comparable problem competitor exercise. We each looked at a different company and their model of business which were comparable to Domino’s. I looked at Chipotle and its online mobile ordering service. Although Chipotle is based around serving Mexican food, they also have the same business model as Domino’s. Chipotle has never been known for delivery services until recently. I found that Chipotle uses third-party apps for delivery, such as Grub Hub and Door Dash. This makes it cost-effective on Chipotle’s part as they don’t have to hire their own driver and spend company hours driving to people’s locations. Using a third-party delivery service seems cost-effective, but Domino’s delivery service plays a major role in their connection to consumers. The next interesting part about exploring Chipotle was the rewards system that they offer. This can be easily tracked through their app and as they earn points with their purchases, they receive credits towards their future meals and coupons.

After my team looked at various company’s problems and solutions, we began the next phase for Day Two in the Design Sprint. We began our Crazy 8 sketches to flush out all ideas we had in our minds; The Crazy 8 sketches are designer to quickly draw out what solutions would look like to your problem in 8 minutes (one minute for each sketch).  I found this exercise to be challenging as you only have one minute for each sketch. These are supposed to look rough in a wireframe format, however, it’s tough not to spend time on the small details.

After the Crazy 8 sketches each of us in our team taped them up on a wall and discussed what we came up with in a critique format. We talked about the ideas behind each sketch and what issue each one would address. After everyone was done presenting, everyone in our team went around to each sketch and voted on what screen was their favorite. We took into account the overall issue these sketches were going to solve and how this would look.

After voting we all decided on what idea we wanted to go with based on the sketches. It was a tough decision for my team and a lot of back and forth on which idea would be successful in the time frame available to us. The final ideas came down to the following:

• Creating a social map for Domino’s that allows you to find people and order together.
• A random pizza generator that would automatically create a pizza for you.
• A pizza reminder that notified you to order food and would display a map that shows the nearest Domino’s locations.
• A split ordering chart that would allow people’s names and amounts to be put in and the pizza would be divided based upon the amount contributed.

‍

Day 3 – Decide

Following our previous session, we reevaluated our initial “How Might We” questions to see if we were still on track. Then Day Three was the Decide Day. Each of our group members came up with 3 highly stylized sketches that we based around the final ideas we voted on the previous day. But instead of focusing on the entire idea, we focused on heat map voting, this is assessing the aspect of each element of a screen. For example, headers, footers, and navigation bars.

After we sketched our three screens out, we taped them up together on a wall to present our screens and describe how these would be useful to our users. Each of us spoke for 5 minutes to flush out our screen ideas and engaged in a Q&A about each screen. After all of us presented, each of us had ten stars that we placed on each other’s sketches to see which ones we liked the best. The voting that took place wasn’t necessarily on the overall look of the sketch, but rather which element of the sketch we liked best (heat map voting). For example, you would put a star next to the typography of a certain sketch if you felt that it was a good feature to have on our prototype.

Once we were done voting, we discussed which elements had the most votes and why people voted the way they did. This gave us an opportunity to voice our opinion on the aesthetics and layout of the app we were creating. This also gave us any last chances to say our creative thought’s before deciding on a specific aesthetic. Unfortunately for my group, a lot of the same layouts and elements had the same number of votes. However, this gave us a chance to problem solve and work with each other to find a happy medium that satisfied the team. After going back and forth for an extended period of time, we came to an agreement on how our main screens should look by combining each other’s designs. This was great teamwork in our part to make sure everyone was satisfied, and all of our voices were being heard. Our main focus for our Domino’s app was to include a group ordering feature that allowed people to place their names and amounts contributed towards the pizza. The pizza would then be divided up accordingly so that everyone got what they wanted. We also decided to incorporate a rewards system to keep the customer engaged and reward the consumer for ordering food.

We proceeded to sketch out what the customer’s journey would look like after our voting session. This was done with five main screens based on our sketches to make sure everything was coherent and understandable. We then presented to the class and opened it up for discussions to receive helpful feedback. Overall our feedback was great. However, questions arose of how would this look if everyone wasn’t in the same location? And, could everyone in the group order receive the same rewards? This was all valid feedback that left our group thinking about how we would asses these concerns.

Day 4 – Prototype

After my team’s Day Three session where we decided on a direction, came Day Four the prototyping phase. This was especially challenging since designing with fellow designers can be tricky when it comes to stylizing and aesthetics. To avoid any confusion when it came to typography, font size, logos, buttons, and color usage we developed a branding guide to keep us all on track. This proved to be crucial since we divided up the screens for each one of us to develop.

After the brand guidelines were created, we each used Adobe Illustrator to create our designs. As the team leader, I created templets in Illustrator then handed the files off to the rest of the team, so everyone was working on the same sized screen. We chose to go with the iPhone 6/7/8 screen size as our research showed that those are the most common screen size at the time this Design Sprint took place. For our team, Jimmy was in charge of designing the main menu, Mo was in charge of the login and check out page, Cho was in charge of the pie and bar graph, and I was in charge of the rewards feature. Due to the quick nature of this exercise, we had to design quickly and efficiently.

Once everyone was done designing their screens, each one of the team members sent me a jpg of their designs and their native files in case I had to do any last-minute tweaking. After everyone sent me their files, I uploaded them into Marvel – an online prototyping software that was a project requirement. After uploading everyone’s designs, I went back to the native files and adjusted some elements so that they would all be in align with one another.

One aspect of this day that I wish I could’ve changed was when I designed the templets. Looking back, it would’ve been a lot more counter-intuitive to have designed the overall header and footer so I wouldn’t have had to go back to the native files. Since we were on a time crunch, I had to go back quickly and efficiently fixing small issues and reupload the screens in Marvel.

Following the upload of screens to Marvel, I prototyped the buttons and all clickable links. This proved to be time-consuming as I wanted to make sure all of the transitions were consistent depending on what button you pressed. This became frustrating because of how many buttons we had. Each one had to have a specific action and motion to follow after being pressed. This was to ensure a user reward for continuing through the navigation of our app.

Our team’s Day Four session was successful. After I uploaded and prototyped our app, I sent the links to all of my team members so they could try it for themselves. We initially saw issues and possible flaws, but we decided to wait until our user testing phase so that we could work out all of the kinks at once.

‍

Day 5 – Validate

Day 5 came the usability test. This was my team’s chance to finally test what we created on actual users. The main purpose of this usability test was to see if our app was a success or a failure. We only tested our app on five users as studies show that after five usability tests the feedback will repeat itself. Our team sat down with the users and gave them specific tasks to perform.  The first task was to “Start a group order from the menu and proceed to check out.” The next task was to “Find your rewards that you just earned from ordering your pizza.” And the final task was to “Create an account and login.”

During our usability tests, we recorded the screen and audio of our test subjects navigating through the app. Each test took around 10 minutes and our team wasn’t allowed to help the user of they got stuck or confused. We only stepped in when it prevented the session from continuing. We also had each user speak to us out loud about what they were seeing and their thought process behind each move they made.

Each task that we had the user complete gave us a chance to learn what was working and what wasn’t. Having the subjects talk out loud also helped us know when certain parts of the app became confusing by the tone in their voice. For example, if a screen became too confusing, the user would talk to us in a confusing tone about what they are seeing. While the users were performing the tasks, one person on our team was also taking notes to pick up on these ques along with the facial expression that would later be revisited for clarification which was Cho’s role. My role in this was to be the moderator, which I also shared with my fellow team member Mo. She also became the documenter and was able to capture photos during this process. Cho was our note-taker and was given the task to pick up on user cues. Jimmy sat in and also volunteered for other groups to test their app.

We found it challenging to ask the user what to do and give them tasks all while not giving away important information that might help them along the process. After the first couple of tests, we became efficient at explaining the tasks and goals while not skewing our usability test with unwanted help. These tests became extremely useful as we were able to gain actual insight into what worked and what didn’t. This was the moment that our whole Design Sprint was leading up to. To validate our initial claims, come up with a solution, and test our solution. Although this was a nerve-wracking day, it was fun to see all of my team’s hard work finally pay off.

Finally, after our user test, we all gathered back together and discussed if our app had three types of results. An efficient failure, a flawed success, or an epic win. We decided that based on our user tests we had a flawed success.

‍

Outcome

It’s important to review outcomes on projects and learn from your mistakes. Based on our user testing and flawed success result we learned various things as a team. First off, our initial idea and concept was a hit. But due to time restraints, we weren’t able to include everything we would have wanted to. Also, we would have wanted multiple usability testing sessions. But the point of a Design Sprint is to rapidly problem solve and prototype.

Our first major flaw was not having a full portion of the app where you could create a profile to add new group members. Initially, we just had a “Name” field, which is great, but it doesn’t give additional users a place to put in their important information for the rewards system. This also hindered the process of payment. At first, our intention for the app was placed around the idea that the group placing the order would already be together and would figure out the monetary information on their own. As only one person would put in the order, we would assume everyone else who was pitching money would Venmo, Zelle, or have the cash to pay the group leader. However, we failed to see the part of making it easier for the users to exchange money through the app. To fix this problem we would have had to create a whole different side of the app that could deal with a secure banking and money transfer system. Going down this road we realized that we should have incorporated one of our ideas of making this a social app. Where you could create a profile, add friends, and make secure payments with each other.

The next major flaw was the hierarchy of information and button labels. When you first open the app, you are at the main menu. Below are two buttons, the “New Group Order” and “View Group Order.” These can be confusing as they are both the same size and stacked on top of each other. This can be confusing for first-time users as our test subjects said this could be contradicting when first opening the app. We later went back and revised this to make it clear which button is the main element of the app, our CTA button (call to action). Another confusing aspect of the app was the button to proceed to the next screen. We initially labeled this button as “View” as in to view the next screen. All of our users found this wording to be confusing. After this feedback, we changed the button to say “Continue” as this is more recognizable.  

Overall our feedback was positive, and our users were very happy with the results.  We hit our mark on the idea behind the app and the navigation of it. As well as answering our “How Might We” questions. However, we did overlook a couple of aspects that we should have flushed out during our Day Three session Decide Day. But we learned from this and gained valuable insight into what we should’ve been thinking about more during this Design Sprint process, the user.

Retrospective

This Design Sprint proved to be extremely helpful in rapid problem solving and prototyping. However, there were parts of this project I found to be challenging.

The first challenging part was being an elected group leader. While I’m always up for taking on new challenges and showing initiative, this role was difficult. I wanted to take charge without everyone feeling like I was controlling what we came up with. I also tried to make sure everyone’s voice was heard and that each team member played a crucial role during this process. It was definitely a balancing act that took a while to adjust to.

The next challenging part of this role was to make sure that everyone was communicating, as well as being on the same page. I initiated a Slack Channel and a group text message that helped us communicate any time of day to make sure everyone was on the same page and could always ask questions if unsure about anything. This was also a great solution for sharing files and making sure everyone had access to all the information we were gathering. Overall this role was challenging and probably the most difficult aspect of this project for me. But going through this I learned a lot about myself and the qualities that are necessary to be a leader.