Transparency First
How We Designed Cover 2.0
Cover is driven by the heart of awesome dining experiences — enjoying great meals with friends. The app splits and pays the check automatically so you can enjoy the moment.
How do you decide when you’re ready for a redesign? For some folks it may be a pivot, a new business direction, or just the need for a fundamental change that’s impossible to iterate toward.
At Cover, we had outgrown the first version of our app. Version 1 was an experience that worked really well when we only had a handful of restaurant partners and users — its focus was simply and effortlessly paying at the nearest restaurant. But now that Cover has over 300 restaurants in NYC, San Francisco, and Los Angeles we needed to rethink how the app can offer the most value to our customers.
How We Solve Problems
We believe that design is a process, not an artifact. Our approach to solving problems is essentially the same whether we’re designing individual features or tackling holistic UX thinking. We go through five phases:
1. Transparency First
“Design is for everyone.” — Cap Watkins
By creating as much transparency as possible, design didn’t disappear into a corner. Instead, we invited everyone to be a part of the design process. Our team arrived at solutions together. That built trust and gave us the momentum we needed to build quickly.
Throughout the redesign we held office hours every Tuesday and Thursday. Regardless of where we were with a given task we shared our design progress. It was important to have a regular and scheduled opportunity for the team (product, engineering, design and marketing) to ask questions face to face.
For example, some of our proposed new features to make splitting the check extra-easy introduced a lot of complexity. Simple UX solutions became huge engineering challenges: What if two people start a check at exactly the same time? What if you’re splitting with a friend who’s already checked-in at the restaurant but not in your contacts?
During office hours we surfaced our UX ideas early and were able to talk critically with engineering about what this meant. Eventually we arrived on common ground, and when Chris, Jeff, and Kippy had to spend time working on these non-trivial splitting changes, we were all bought in to why it was a meaningful investment.
In addition to meeting with the team regularly, we also had a war room and frequently posted updates in Basecamp, which helped broadcast our progress to the team.
2. Define the Problem
We kicked off the project with product management, engineering, and marketing to list problems and goals as a team. We worked simply from a Google Doc, but it added value throughout the process and made sure that everyone was the same page and had the same answer to fundamental questions: What are our priorities? What’s in scope? What are we actually trying to accomplish here?
For the redesign, the team identified a few priorities:
- Do a better job at getting folks to great meals. With so many restaurants now on the platform (and new ones joining each week) we needed to add better discovery tools. We want to help you find the right restaurant whether it’s brunch with friends right now or planning for date night.
- Improve the dining experience. Magically paying the bill at a restaurant with your phone and leaving when you’re ready is the most complex part of our product. Folks didn’t always trust the magic — sometimes they simply didn’t believe it was OK to leave. We needed to offer more support, give better signals along the way, and build our customers’ confidence in the product.
- Make splitting the bill even easier. Being able to easily split the bill not only solves a real problem for people but is also a competitive advantage for us — not many other products offer it or do it well. We wanted to both highlight the feature and make it effortless.
- Maintain the simplicity of the current app. From the beginning, the vision of Cover has been a non-disruptive experience. If you’re at a restaurant and want to check in and pay, it’s quick and seamless. We wanted to preserve that easy transaction.
3. Discovery & Exploration
We spent time researching: How do other people solve similar problems? What are some examples of products that inspire us even if they’re not in the dining space? Do we know anything about our existing customers’ behavior that may be helpful?
Discovery wasn’t about emulation, but created critical discussion about the context that our product exists within. We examined other products that shared similarities with ours, are in the food space, are location-based, accept payments, etc. and formed some jumping off points for how we wanted to approach (or not approach) our solutions.
From early on the team was thinking about things like density, adding value to maps, designing scalable patterns, and achieving an overall visual sophistication to the design:
Aaron, our Senior Product Designer, and I began ideation with post-its and pencil sketches. Working in the abstract helped us distance ourselves from the current experience and avoid falling back on existing patterns just because that’s how it’d been done before.
We wrote down all of the actions in the Cover experience and grouped them. When we were satisfied with the groups, we labeled them, took a photo, and then repeated the exercise.
The funny thing is that all of our exercises ended up being very similar with the exception of one or two actions:
Ultimately this didn’t have a literal influence on the interface of the product but the exercise laid the foundation for how we thought about the architecture of the app. We discovered a natural distinction between the “now” and “later” halves of the dining process — something we later reflected in the structure of the app. We began thinking about transitions and design details to communicate where in the process the user was.
For example, if you’re in a Cover restaurant we make it as easy as possible to check-in (preserving that seamless experience from our first app), but otherwise you land on an experience designed to discover a restaurant you’re interested in.
4. Validate Ideas, Narrow, and Iterate
We validated the new app as much as possible in low fidelity before going into visual design. By user testing wireframes we were able to get valuable feedback and any design or engineering changes took less time. Our ideas weren’t precious and if we learned that something wasn’t working it was easy to make a change.
Overall we did almost 20 rounds of user research over the course of three months. Approximately half of those were on UserTesting with Flinto prototypes and the other half happened in real restaurant experiences with new users testing beta builds of the app (most still in low fidelity). It helped us answer whether folks could onboard to the app, discover new restaurants, and feel confident paying with Cover.
For example, we found that language details in the button to check in and pay at a restaurant influenced the understanding of when an action should be taken. If we said “Pay at Slanted Door” it signaled to folks that it was something to do at the end of the meal because that’s when you typically pay for things, but if we said “Check in at Slanted Door” they understood it as something that needed to be done on arrival.
Another source of confusion was what was supposed to happen at the end of the meal. The magic of Cover is that you seamlessly pay and split the bill with your phone and can leave when you’re ready. There’s no physical check or handing a card to the waiter. After you’re checked-in at a restaurant on the app there’s nothing else to do unless you’re inviting friends to split or changing the tip.
But what we had designed was feeling like a dead end. People didn’t know what to do next. They didn’t feel like they were “done” and were looking for another action to take. We found that offering a “settle up” button (though technically it isn’t necessary) helped give folks confidence that Cover worked.
5. Polish Details
After we were confident in our UX and product solutions we shifted our focus to the visual design of the app, prototyping key transitions, and rebranding Cover to reflect our new strengths and priorities.
The visual design phase itself went through lots of discovery, ideation, and iteration. What’s the right typeface for our UI or headings? What hue of purple shares DNA with the history of our product but looks amazing on screen? Which titlebar treatment offers the right hierarchy throughout the app?
We honed interactions and transitions in Origami. Aaron focused on the most common and crucial transition — checking in at a restaurant. The sequence needed to both feel transactional and hint at a tappable lower drawer.
Check it Out
You can download the new iOS app from our website (Android updates are on the horizon) and use Cover in NYC, San Francisco, or Los Angeles.
We’re proud of what we’ve built and how we built it. We believe it offers real value to the folks who use Cover and allows you to focus on what really matters: your meal, the company you’re sharing it with, and the atmosphere that brings you all together.
A huge thanks to everyone on our team who worked hard to make this awesome: Aaron Shapiro, Frank Harris, Christian Whitehouse, Chris Rotella, Jeff Manian, Robbie Mitchell, Arielle Shipper, Sarah Arnold, Michelle Capocefalo, and Sarah O’Mealia.
Read more about design process and collaborating with teams:
- Sharing Our Work: Testing and Feedback in Design by Jessica Harllee
- Great Teams, Great Products by Cap Watkins
- A Matter of Principle by Julie Zhou
