Continuing to make meaty blog posts out of design leftovers, we now arrive at something substantial: the information and interaction design for a Menuito site. Click on through for sumptuous wireframes, raw early designs and the plated finished work to see how it all unfolded.
Since the idea for Menuito started from thinking about customers trying to find out about a restaurant on a smartphone, that was where I started the design work. I still remember doodling up this box-treatment in OmniGraffle, where I eventually did almost all the wireframing.
The information architecture for a restaurant, as far as what a mobile customer needs, is very straightforward once you have the purpose of the application in mind. With Menuito, we want to influence the go/no-go decision, and support the customer as much as possible in not only deciding but in actually getting in the front door.
Though intuition was strong about what that crucial information was, I read blog posts and talked to people about the details they wanted from restaurant websites. I even put a few friends in front of restaurant sites and asked them what they’d look for if they were thinking about going, then mapped that behaviour to what I knew about mobile.
The data that connects a customer to a restaurant (name, phone, location) also sat well with the restaurant’s hours. The backend UI demands that restaurant hours be explicit so that Menuito can read the device’s date and indicate whether the place is open on that day or not. Placing these items near the top, complete with a tap-to-call phone number, puts the customer in touch with answers to the top 3 questions: is the place open, how do I get there, and how do I contact them right now.
Working through the menus was a more tricky affair. I started to worry about trying to support any size of menu when designing the back-end interface, where nesting the various types of meals within a menu made me queasy due to the complexity of representing and storing that information.
When I took those complex menu structures to the front-end it really got messy, but gave me an insight about mobile context: do you really need the full menu, or is winning the mobile customer all about telling them the best of what is available? It’s still an open question, but we eventually went with space for up to seven signature items for each menu. Some people like that, some do not.
Nonetheless we stick by it, likening the mobile diner’s needs from a webpage to what a restauranteur would say if they called in in. Whoever takes the call wouldn’t read the whole menu; they’d say enough to get the person in the door. That analogy helped us in subsequent decisions.
Eventually the front-end design stabilized and this is the wireframe that we took into implementation.
Though a Menuito site would always be one page that grew as more detail was desired, I was very mindful of scrolling and careful not to fatigue or lose the viewer’s place.
To keep a measurement in view while wireframing and to give Frederick a sense of proportion to design with, I added the dashed outlines to show how many screens a person might end up swiping through with everything open. This allowed us to know how many ‘screens’ deep we were going without repeating the image of the phone over and over. It’s a great trick that I’ve used since to represent content beyond the anticipated frame(s) of a browser window.
As we played with the accordion open and close for showing and hiding details and thought about menus, it became clear that we’d need to next a second accordion to deal with an emerging structure of Category > Subcategory > Details. We really had a hard time settling on a way to deal with locations because of some specialized needs.
Location when looking for a restaurant with a smartphone is more than just a street address: there’s the tie-in with maps applications for the GPS-enabled, and we added a field for specifying extra directions in natural language that can help a person find those more out of the way places.
We started out with the street address and extra directions separated, thinking that people would only need directions when they decided to go, at the end of the page. This did not test well. So we looked at ways to unify location with direction and accessing the maps:
None of those worked well either, and we eventually found a way to make it work that didn’t create inconsistent interaction and capitalized on the accordion pattern we were already working with.
Looking back it seems obvious, but that’s what the hard work is for I guess.
Dressing It Up
With the page skeleton coded we added some style, and came up with the first of our make absurd concept restaurants: Gravy Grill. It’s still my favourite (over the runners up of Bowl, Pet and Trough) and that original, New York-inspired look became the basis of our strongest theme, Central. Some mid-stage work is shown here.
We mocked up a number of looks to see how the organization felt across different styles, and to flush out any bad assumptions about navigation and the interactive elements.
By trying out fictional and actual existing brands, we started to get an idea of how well the layout would allow for adaptation to different brands, and were pretty happy with how well it held together.
In the final product we ended up moving photos into their own expandable section so that we could increase the number from two to three (and maybe more later).
We also ended up spending a whack of time finessing the display of hours. To avoid a dumb list and to get the explicitly stated hours to convey in a warmer, more conversational way, we looked for consecutive days with the same hours and strung them together, paying attention to Saturdays and Sundays as ‘Weekends’, and so on. That effort also let us tidy up the display of hours to make reading more efficient and the best possible use of space, even in a collapsable area.
A lot of the time that we spent was on consolidating and eliminating stuff from the design. The pressures for doing so came from multiple angles: time, feasibility, aesthetics, and plain old asking do we really need this? It might seem trivial, but having the fictional Gravy Grill restaurant helped bring some personality into the design, and made us love it that much more. Gravy Grill acted much like a persona does by creating an empathic, emotional bridge to the goal, so that the design itself doesn’t become the goal.
The finished product is best viewed full size, using that very first and favourite theme, Central (Red variation).
If you really dig the wireframes, here’s a big-sized pdf (about 500kb) of the mobile site.
Next up, the IA and interaction design of the Manager’s Console, which proved to be much harder than initially conceived.