Bad name, useful app. Drunchies is a painlessly simple experience that finds the closest restaurants and directs users to them. In addition to the mobile app, a desktop app available to restaurant owners allows them to easily write, schedule, and send a limited number of push notifications to Drunchies app users.
The publicly-available Drunchies app – an app for quickly finding restaurants, drinks, and street food vendors within walking distance.
Drunchies Dashboard: a portal for registered restaurant owners to log in and schedule a limited number of push notifications to send to app users.
Drunchies originally started out as a fun project dreamed up by one of my more eccentric friends as a startup idea. Starting out, he had a general idea of the concept – a stupidly-simple way to find which restaurants near you where the user searches based upon a simple "walking distance" criterion. As a way to monetize the app over time, however, we needed to get restaurant owners on board and provide them with a means of connecting with Drunchies app users – hence the invention of the restaurant portal.
The personas were really developed alongside additional research that we performed. In order to talk to the users of both sides of the platform, we performed two exercises tailored to those particular groups:
For the app users, we created a survey using Google Forms to ask some general questions about the potential usefulness of the app idea, and their general feelings around finding a place to eat late at night. A general finding was that it wasn’t necessarily difficult for them to find a place to eat – they usually just go to the first place that catches their eye, but they would also welcome a method for finding other options with little to no effort. A key consideration would be providing a time estimate for how long it would take to get to a restaurant to combat this impatience.
We sort of just go to the closest food place we can find. I’m sure there are a ton of places open, but I don’t have focus to look for much other than what I know.
-App survey respondent
For the restaurant owners, we turned to in-person and phone interviews of a handful of eateries that are open late in Boulder, CO. We prepared a list of questions to ask each about how they advertise to and attract late-night customers, but allowed the conversation to go wherever it naturally flowed. We got great feedback from this group, but also some surprises: They didn’t see much value in a mobile interface for scheduling push notifications, because they spent most of their time at the restaurant running around dealing with other issues. Based upon this feedback, we decided to make a responsive site that focused on the desktop version, but also add the ability to schedule messages via SMS.
I’m so busy when I’m at the restaurant, that I don’t have much time to do extra stuff. I’m going in between the kitchen and dealing with tables and all kinds of things. And I don't even stay there that late most nights.
-Boulder, CO restaurant owner
Once the concept for the app was in place, we created two relatively straightforward personas – one for the app user and one for the restaurant portal user.
Chet Waters, the app user, is a college student at the University of Colorado that often schedules get-togethers with his small group of friends on weekend nights on Pearl Street in Boulder. Since he’s more of the “leader” of the group, he often decides where to go to eat on late nights. He thinks it’s a drag that it’s so hard to tell if restaurants are open, but hates having to enter restaurant names into Google manually, especially when he’s had a little bit to drink.
Kate Robinson, the restaurant owner who manages all of the marketing and advertising aspects of her business, is the second persona. She's been having some issues attracting late night traffic to her restaurant, Burger Haven, because of its location near the edge of the night life scene in her town. Kate generally runs a few small ad campaigns in local college newspapers throughout the year, which helps with day traffic, but not as much during the night. Because she generally isn't even working late at night, she would like a system where she's able to connect with patrons in her area, but schedule the messages so she doesn't have to be up late at night.
A key finding with the restaurant owners, was they they weren’t interested in managing the traffic into their businesses on a minute-by-minute basis, like we initially assumed. They preferred a more “set it and forget it” method that they could sit down and set at the beginning of the week and schedule, or delegate to a manager.
Both the app and restaurant portal went through a traditional round of sketching, discussing with the app stakeholders, revising, then moving on to creating “duplos” of each of the app screens to show how they interconnect.
Given the fairly straightforward nature of the experience, each app only really had one major workflow. For the mobile app, a user would launch the app, say how far they’d like to walk (a search paradigm informed by the “we just want to know how long it’ll take” feedback we received in the research phase), then be presented with a list of close restaurants and how long it is until they close.
For the restaurant portal, we knew that we wanted a single dashboard that gave all of the details needed, as well as a screen for more advanced planning in advance of messages. Based upon the “set it and forget it” mentality of most of the owners we interviewed, we incorporated the “AutoBite” feature, which automatically selects messages from a user’s pool of saved messages and sends them out periodically, up to a defined limit.
The visual design of the app was based mostly upon Google’s Material Design – the key workflow in the app is to hand the user over to Google Maps for walking directions, so the idea was to make it feel like a continuous experience. Material Design served as a great framework for the style of the app, but other interaction and visual design inspiration came from the 24 Hour Fitness app, which featured a similar view the the results screen for finding and signing up for fitness classes.
The designs were created in Sketch; animated assets were created in After Effects.
Smaller UI details like loading indicators and other graphics supported the goal to create a "clean but playful" interface that was engaging to a user who may have had a few drinks.
.png)
.png)
.png)
.png)
After the stills were completed, I created a motion prototype to exemplify the interactions and animation styles to the developer. Animation guidelines from Google Material Design, such as how a restaurant card expands, or the animation when a user taps the "Feed Me" button, played into the style of the interactions.
Based on the feedback we received through the research phase, we knew that allowing the ability to schedule messages, vs. writing and publishing one message at a time was critical. This became the main focus of the Drunchies Dashboard, along with ancillary components showing analytics and other nice-to-know tidbits such as weather.
For the visual design style, we took a more "experimental layout" approach, positioning tiles on a main dashboard that displayed information, but also allowed users to immediately take action to cancel, edit, write, or send out a message. The user can also see their scheduled messages at a glance, as well as all previous messages that have been written. We've also included the ability to turn on the "AutoDrunch" feature here, which automatically selects and pushes messages without a need for the user to schedule them.
The "My Messages" page is the central location for writing and scheduling messages. Scheduled messages are displayed in a weekly or monthly view, with the user's bank of previously completed messages displayed below.
When composing a message, the user has the option to send the message immediately, schedule it, or save it for later in their pool of messages. To smooth the workflow, a list of randomly-selected times is provided to eliminate the need to key one in manually.
Ultimately, this project was a good exercise in user-centered design for mobile applications and creating applications for multiple platforms with a consistent visual and interaction style.
