Designing & Developing “UberEATS for Duke”
We all love food — the joy of discovering great dishes and prolonging our survival by ingesting tasty calories is unbeatable. But most of us would rather enjoy those feelings without pouring sweat and tears into hours of preparation and execution, and instead skip to the yummy part.
Enter the world of online ordering and delivery services. The list is long — Postmates, Favor, Eat24, Caviar, OrderUp, and native restaurant platforms like Domino’s, Jimmy John’s, and Pizza Hut to name a few — and as a college student I’ve used my fair share of them.
But these platforms lack a huge feature that could boost college orders astronomically: payment with university food points. Since these points are preloaded on each student’s account at the beginning of each semester, they constitute an already parted with currency and thus have a much lower barrier to use than cash.
Ordering services that take advantage of this fictitious currency can not only increase order volume because more students will be willing to spend on delivery, but most likely their average order size as well since the feeling of loss that comes with spending money will be much less acute.
GoBringIt Delivery is such a service, founded at Duke University as a division of Campus Enterprises a few years ago. I joined Campus Enterprises last spring when GoBringIt was a purely web-based service and quickly noticed that while its value proposition was solid, the current execution required significant improvement. Not only was the website not responsive and thus difficult to use on laptops with smaller screens, but it was also impossible to use on a mobile device — the most popular platform for ordering food!
I went to work designing a native iOS app to expand the platform’s reach and tap into a market dominated by personal delivery apps.
I began the design process by writing down a couple of key adjectives that I wanted to eventually describe the app’s experience. I did this mainly to guide my visualization of the app and serve as a reference at every milestone to ensure that I was achieving my goals and staying on path. These adjectives were:
- Intuitive — the app should just work. I wanted an understated interface with an emphasis on content (think Instagram) that would be familiar to what users are used to but also tailored to an audience of college students.
- Efficient — college students always act pressed for time (whether they truly are or not) so the path from launch to checkout should be as direct as possible.
With the core values defined, I set out to construct an experience map of the app. Experience mapping, a cross between wireframing and UX brainstorming, lets me visualize at the most primitive level how people will interact with the app and helps describe the emotions each screen and each action should elicit. Here is mine:
The key insights you can gather from creating a big picture, experience-focused map like this are invaluable and often overlooked by overenthusiastic designers who go directly from mental ideation to wireframing.
For example, I discovered that while my target audience (college students) wants an app that can get the job done efficiently and reliably, they would also most likely appreciate a touch of personality and personalization to make the experience more about them. This would translate to liberal use of images and graphics, reward reinforcement techniques, and a few magical animations and interactions.
Sketches and Wireframes
Sketching and wireframing is often an unstructured process, so I try to manage it by breaking it into three parts:
- Sketching the initial storyboard
- Drawing low-fidelity screens with only essential information
- Redrawing in Sketch
- Sketching the initial storyboard
At the end of this step, I will have a visualization of the storyboard with empty screens matched with their experience map descriptions and the type of navigation pattern (tab bar, nav bar, etc.) I will employ.
I began by drawing a horizontal array of rectangular artboards and writing an experience map description underneath each. Next, I drew directional arrows between them to signify relationships and create a more apparent visual hierarchy. Once this was done, I could more easily visualize which secondary screens I needed to add — previous order details screen, sign up screen, etc. This created a mess of artboards, descriptions, and arrows, but I would clean everything up when I later translated the designs into Sketch so I moved on.
2. Drawing low-fidelity screens with only essential information
One of the most important parts of designing any specific screen is prioritizing information and presenting it in a clear and concise way. Consequently, under each empty screen I first listed the essential information I wanted to present, and then abstracted its elements into low-fidelity design patterns which I sketched on the screens.
3. Redrawing in Sketch
I used Sketch’s infinite canvas to reorganize the wireframes in a more organized, hierarchical structure, making tweaks to the design as needed. For example, although the initial wireframe of the home screen employed a simple table view, I noticed that a cards-based approach would be much cleaner, separating different restaurants clearly and displaying key information succinctly as well as representing a larger tap area for users. Reflecting on the benefits of this approach in multiple screens and wanting to maintain continuity, I eventually decided to incorporate the cards design language throughout the app.
As we approach the beginning of prototyping and development, we arrive at one of the most defining aspects of a great app’s experience: its interactions. Interactions can seem as simple as smooth and continuous transitions, timeless but rewarding animations, responsive taps, etc., but executing them well can pose a challenge.
Having read avidly about interaction design on Medium like here, here and here, and on daily design inspiration blogs like this, this, this and this, I really wanted to get this part right. I broke down the app into four primary interactions:
- Opening a restaurant — This action should reward the user and reinforce the choice they made, perhaps with a delightful animation and a mouth-watering image of one the restaurant’s dishes. By pleasing users visually and immediately guiding them toward their next decision — choosing a menu category — the app is more likely to increase conversion rates and retain potential customers through a vital step in the ordering process.
- Adding an item to the cart — Once again, this action should be simple to execute and reward the user. In this case, the screen with the menu item the user is adding slides down, and a large bright button slides up to inform the user that there are now items in the cart. A discrete order total is also visible to guide the user’s next steps.
- Checking Out — Potentially the most important part of the process for both us and the users is the checkout flow. It’s the step that brings us income, and the step that ultimately brings them food, so we should strive to make it as painless as possible. To do so, I placed two cards and one large checkout button on the screen. The first card shows the user’s delivery details with the opportunity to edit them, and the second shows the order summary with all important details (quantity, price, sides, special instructions) and a large total at the bottom. Clicking the checkout button presents a bright confirmation screen that serves to reinforce your order decision and build trust — it thanks you for your order, shows you how much you spent, and gives you an ETA on your food.
- Reordering — An easy shortcut for students who have a favorite order or don’t want to explore new dishes every time they get delivery is reordering, so this feature is key. I settled on a calendar-list hybrid design to display previous orders and their key information. This way, users can see at a glance when, where and what they ordered, and decide whether they want to order that again. With one tap, they see the specifics of a previous order, and with another tap they can checkout.
Finally comes the fun part — taking the abstract, black and white screens and turning them into a beautiful app mockup. With all the planning and initial iterations I had already done, this part came naturally.
But I didn’t just accept my first draft as perfection, nor did I complete the design process alone. After every screen that I completed I asked my family members and a few friends for critiques. Sometimes I would walk around my house and shove my phone in their faces and ask them how they would perform a specific task or tell me what they liked or disliked about my design. I would then implement some changes and return with more questions.
I learned a great deal from this rapid prototyping technique, especially since each family member had wildly different suggestions that I never would have noticed alone: my mom commented on readability, my dad suggested a simplified navigation, and my brother told me that the add to cart action was confusing and that the pictures I had for each of the restaurants “sucked.”
Finally, I reached a version of the app that I was happy with, and I switched to my developer’s hat and spent part of my summer implementing my designs (perhaps I’ll write another article on the development aspect of this project). Below is a demo of the finished product:
I hope you’ve enjoyed reading about my design process! I’ll summarize the main points here in case you want to take any elements and incorporate them into your own:
- Define your app’s values and create an experience map to guide the rest of your design process
- Go through the low-fidelity sketching and wireframing process to test hypotheses and discover the best approaches and design patterns for your app
- Carefully craft the key interactions that will define your app’s experience
- Translate the above into high-fidelity mockups and iterate with constant feedback
- Turn your designs into reality