Instant access to burritos bigger than your head is the clear selling point of Chipotle’s iPhone app (iTunes link). But if we put culinary convenience aside, the app itself is an interesting mix of simple design, e-commerce functionality and location tools.
I’ve been digging into the app for a while (digging does not equal “eating,” in case you’re wondering), and I found three aspects to the app that could prove instructive for developers and businesses pursuing their own mobile paths.
I asked, repeatedly and from a variety of angles, for revenue information related to the app — direct sales, percentage of total sales, etc. Chris Arnold, Chipotle spokesperson, politely declined to answer the money questions. The closest I could get was the total number of app downloads, which is currently at 600,000. And since Chipotle has around 1,000 restaurants, that’s considerable overlap.
Arnold did open up about the app’s integration into Chipotle’s ordering and payment processes. What I found most notable in this regard is the oddly detrimental role of franchises. The Chipotle app represents a case where corporate centralization led to a relatively painless product roll-out.
Here’s why: Chipotle owns all its restaurants, and Arnold credits this with allowing the iPhone app to mesh well — and quickly — with existing systems. “It can be hard to get all of your franchisees to participate in a new program like that, particularly if investments in technology or other infrastructure are necessary,” Arnold wrote in an email. Centralization ensures the Chipotle app works at all of the company’s restaurants.
Chipotle also benefitted from a pre-existing online ordering system. “If you don’t have that infrastructure in place when you start your work on an iPhone app, you’re going to be in trouble,” said Pervasent’s Stuart Williams, CEO of the development shop that handled the Chipotle app’s programming. “It’s certainly the case that mobile ordering follows in the footsteps of a decent web order.”
2. Defining the use case
Chipotle and its development partners constructed the app with a particular customer in mind: a young, urban professional who needs to grab lunch on the go. That’s not to say customers outside this very specific example are irrelevant; non-hipsters can benefit from the app as well. But this defined use case proved important during the development process because it led to functionality and conclusions. Here’s two examples:
- Young professionals and iPhones go hand-in-hand, so the justification for creating the app is built in. It doesn’t make sense to develop an iPhone app — or any mobile app for that matter — if your customers don’t rely on app-friendly phones.
- Since lunch is the primary meal in this use case, that means the customer is probably visiting a Chipotle restaurant near his/her office over and over again. As such, the app asks for and remembers location on the first launch, but subsequent location look-ups have to be initiated manually. This isn’t a “road warrior” app that automatically discovers nearby restaurants. It’s about defined, ongoing convenience.
3. Limited options
One final observation …
It would be tough to create a simple, easy-to-use mobile app that encapsulates the breadth of meals and ingredient variations at restaurants with long menus. A website can tackle this task, that’s for sure, but the mobile experience carries unique usability issues. Something as simple as going back and forth between screens can get real clunky, real fast on a small device. Chipotle’s menu, on the other hand, works well in the app world because it’s uniform and limited.
“The app is designed very much around their menu,” said Williams. “It’s not like you could take this app and service a white tablecloth restaurant. Or even service a Subway. A really well-designed app for Subway would work different than a really well-designed app for Chipotle.”