Enterprise UX and The Olive Garden
You may remember a few years ago an elderly woman, the local restaurant reviewer for a newspaper in Grand Forks, North Dakota, wrote a review extolling their new local Olive Garden. And the Internet received it with great derision. The Olive Garden? In a nation where every major city has a bevy of elite chefs, someone likes the Olive Garden?
But in the discussion came a sobering truth — Grand Forks, like most minor cities and small towns in America, didn’t have a vibrant restaurant scene like the major metro areas. But now Grand Forks, filled with greasy spoons and diners, their menus overstuffed with 50 different combinations of meat, cheese, and bread (don’t ask about the vegetables) had a place that represented something different. So-called “casual dining.” Where the food and the experience were consistent from suburban mall to Times Square. Pasta. Caesar salad. Free breadsticks. An aesthetic that said they were better than a greasy spoon, but you don’t have to dress in a suit (unless you’re a high school kid and this is the pre-prom dinner).
In a world of greasy spoons and diners, “casual dining” stands out. No, they’re not French Laundry or Eleven Madison Park, places that hold high the standard of American (if not world) cuisine. But casual dining is an experience that’s consistent in story and appearance and taste, a chain of restaurants that will always be a little above the diner. And just like that, date nights and congratulatory dinners happen at The Olive Garden, or Applebee’s, or Macaroni Grill. They’re just “better.”
Let’s transpose this to enterprise user experience.
I was using my employer’s expense reimbursement system the other day. It was one of the kludgiest things I’ve ever worked with. Attaching a receipt to an expense was a delicate yet under-explained process. If you attached the wrong receipt to the wrong expense there was no easy way to undo that. The button text was never clear; half the time I was looking for a Next but kept hitting the Cancel button — neither of which was labeled “Next” or “Cancel.” There was no help available to explain which expense category an expense would (or should) go into.
And using it made me think about Concur.
Concur is a SaaS-based expense reimbursement system used by thousands of companies worldwide. And Concur’s UX is pretty terrible. In older versions, it was easier to use your phone to attach images of reimbursement receipts, but at the same time it was far easier to use your desktop computer to create expense reports. So every expense report I filed through Concur meant I would:
- Create an expense report on the PC using the Concur website,
- Grab my phone and take a picture of the receipt,
- Open Concur on the phone, find the expense report, and attach the image,
- Put my phone down,
- and then return to the PC to finish the expense report.
Most everyone in the company did their expenses this way. It was a kludge.
But, compared that to my company’s bespoke expense reporting system, Concur is a radical improvement in both UI and UX. It’s not intuitive, but it’s easier to follow the flow.
And now I understood why Concur was bought out by SAP for over $8 billion. Concur isn’t a great user experience, but it’s better than all the other ones that are out there.
Concur, the Olive Garden of expense tracking systems.
Many (OK, nearly all) enterprise applications are a mess to work with. Some are homegrown, created by developers to solve the problems as they understood them, but not in the way the actual users would work with them. Many require inordinate training and documentation just to keep people using them. (In an earlier career I remember taking a two-day course to learn how to use the university’s financial software system.)
But then you look at the SaaS triumvirate: Salesforce (for sales and customer leads). Workday (for HR). ServiceNow (for service management). They’re all a pain to work with, a pain to use. But all three replaced far, far worse systems. They were systems that required specialized knowledge, systems that seemed to care less about the end user and more about making the vendors money (through sales and support).
Salesforce destroyed all that came in its wake with its messy API and its disjointed, straight out of 1985 UI. And they still dominate, because the enterprise software world is still the land of the “greasy spoon application,” one that does all things less than well while serving the base function it provides.
If all you have to do to become an billion dollar enterprise software company is to be the Olive Garden of your niche, then why would you put the effort into design? Why hire UX at all?
I recently had dinner at a trendy new restaurant in Seattle. They raise, then butcher their own cows. Their menu featured cuts of beef I hadn’t seen since my childhood, when grocery stores had on-site butchers that sold the whole cow (and we’d often end up with strange cheap cuts). On sets of chalkboards around the restaurant they listed the available cuts (and price), then marked them off as patrons order them. It became a race to get the best cut — if there was one you really wanted (e.g. a Chateaubriand), you better have made an early reservation before somebody else grabbed it.
The decor was French, the table slate, and the waitstaff friendly and more than willing to help. There was a window into the meat locker where you could see the bresaola hanging along with cuts that were air-curing. This was a designed experience, one that brought you into the idea of a steak restaurant that was less about steaks and more about the cow, more about the ambience.
That restaurant is not one it’s going to be easily reproduced across all the cities in America. It’s not going to go against Olive Garden in the Dakotas. It’s going to make something niche, well engineered for the experience of eating a gorgeous piece of beef, but not for the experience a nice meal out once a month — or once in a lifetime — would provide.
The differences between the niche steak restaurant and the Olive Garden highlight the collision I see all the time between enterprise UX and consumer UX.
Enterprise UX means designing systems that a thousand people will use a million times and ten thousand people will use once. Consumer UX often means building things people use (and enjoy) and then replace with something else; they “consume” it. People expect more out of consumer grade applications and services because of this “replaceability” aspect.
Enterprise UX has to focus more on the usability of something, less on the feel of something. Less delight, more satisfaction. Enterprise design is not about making the complex simple; it’s about making the complicated understandable.
But when you talk to the leadership of these enterprise companies, they want a consumer-grade experience built into their SaaS-based billion dollar applications.
So they bring in consumer-grade user experience designers, raised on user-centered design, taught that “innovation” is supreme. Bolstered by a “make it pretty” attitude in the executives, they set to work trying not for Olive Garden but more Eleven Madison Park — locally foraged! Haute cuisine! Sous vide!
And their resulting designs end up emphasizing the wrong things. Icons get prettier. Cool new animations in a cool new iOS version of the application. The aesthetics are greatly improved. But the underlying functionality is still a mess, performance is still slow, and even as they’re defending their slick new mobile app there’s a nagging doubt whether someone really does want to review complex spreadsheets on their phone. The drive is on presentation, but experience driven design goes by the wayside.
Workday is a great example. It’s very, very pretty for a SaaS solution. But it’s a dilly to use. You’ll fill out a form, but not know you have to confirm it. When you confirm it, you get a message ping up. It’s confirmed! Okay. But on another form, it auto-updates when I tab away. So, yes, nice coat of paint there on that machine, but I’m never sure if it’s going to take my finger off.
So, how do designers get beyond that coat of paint and into fixing the customers’ actual problems? They do the work to create understanding. Yes, you need a sense of how to come up with new ideas, iterate, and create, but design is more than just post-it notes on a wall. It’s about translating the ideas we have into concrete guidance for making the complicated understandable.
But when you look into design teams, are people doing the work to drive? A friend of mine the other day was complaining that the design team he just took over loved their post-it notes, but they wouldn’t wireframe, not even on a whiteboard. They had these great ideas, but they didn’t know how to translate them into work that product managers and engineers (or executives) understood.
They were trying to be chefs, but they were skipping over the work.
Most chefs start off in the kitchen, doing the cutting and prep work as they move up to sous chef. They do the dirty work of the kitchen until they become leaders. They use mentors and the people around them in the kitchen to learn how to get better. They iterate, they test, they keep pushing. Not all cooks become chefs, but great chefs only rarely begin their careers running a restaurant, much less a successful one.
Product managers, engineers, and the whole of an organization looks to the design team to produce the collateral they need — the instructions — to create the right thing for customers. If we’re not providing it, user experience is ignored.
If we want to truly push enterprise UX beyond just being the Olive Garden in a world of greasy spoons, we need to be chefs of the cuisine of great experiences. We must lead strategically and have a big vision for the experience we are driving. But we must also be cooks: Willing to do the UX equivalent of prep work, stand over a hot stove, and plate the food. And that means learning the business, getting our hands dirty with the people who make the company run. It means sometimes we’re going to have to do the extra visual work to drive understanding, or producing deliverables that explain the ideas in a vernacular our stakeholders can understand.
I had a project recently where the best solution for driving product design alignment ended up being a 24x36” poster-size document breaking down all the flows within the product — who did what, where, and how. Suddenly the room shared a vernacular for the project, and that made it easier to deliver design since it had something to root it to. It took an interaction designer and me two days to hammer the design together into something readable and grokkable (even as I flubbed a spelling here and an alignment there in the final print). But it was needed. Because someone had to do the cooking.
Even in my lead designer role, I have to fight my urge to grab the tools of wireframing and solve design problems on my own. Chefs never stop being cooks. The great ones learn they don’t have to, though, because they know what they want and can teach their staff how to deliver it.
If we want to push the full field of enterprise user experience design well and beyond making Olive Gardens in a land of greasy spoons, we need to be willing, as designers, to get in the trenches and out of our custom designer spaces. Enterprise software that changes the market only has to be marginally better designed than their competitor. Slightly prettier. A more fashionable lipstick on the pig. We need to become chefs and lead our employers and leaders towards quality. Maybe giving them a dose of Olive Garden and free breadsticks gets them to the table. But the next frontier is to take them beyond the incremental improvements of “just a little better” and towards a fully iterative cascade of experience design that transforms companies and their products.
And it starts with doing the work.