Why designing for enterprise vs. consumer products isn’t as different as you think

February 11th, 2015
4 min read
facebookx-twitterlinkedin
Why designing for enterprise vs. consumer products isn’t as different as you think article banner image

In a recent article titled The Distinction Between Designing for Enterprise vs Consumer Customers, graphic designer and author John Maeda explains why designing for enterprise is different, and maybe more challenging, than designing consumer applications.

But, as someone who’s designed applications for enterprise companies, as well as small business and consumer products, I’ve come to believe that the distinction between designing for consumer and enterprise applications has rapidly narrowed over the last several years, and today the distinction barely exists at all.

The user has become the decision-maker

Today, teams and employees often choose their own products. And that means it’s the best product and design that wins, rather than the best sales and marketing.

For traditional enterprise products, the model used to be that you sell to a C level executive at the company, and the employees use the tools they are given. If an application was painful, employees would use it as little as possible, and use time-consuming, often manual, work-arounds to avoid spending time in the tool.

Today, teams and employees often choose their own products. And that means it’s the best product and design that wins, rather than the best sales and marketing.

Users are picking the software they love, rather than the software that was forced on them.

SlackSketchDropboxSunriseGoogle Drive, and Asana are all examples of this trend. Because switching costs are so much lower than they used to be, it’s a lot easier to choose your own tools at work.

I see employees choosing the calendar tool that works for them, the communication tools, the document storage system, even design tools like Sketch. More and more, large team tool decisions are made bottom up. Users are picking the software they love, rather than the software that was forced on them.

What this means, is that companies building enterprise products need to be thinking less and less about wining and dining CIOs, and more and more about how to apply consumer thinking to enterprise product design.

Your goal as a designer is to build an app so great that your users want to shout about it from the rooftops, and share it with all their teammates.

Don’t rely on a sales team for user growth

Your goal as a designer is to build an app so great that your users want to shout about it from the rooftops, and share it with all their teammates. Adoption, in this scenario, is organic, and users will ultimately be more loyal to your product than something they’ve been ‘forced’ to use.

Create a first use experience that allows them to succeed on their own

Designers should strive to create an application onboarding experience that doesn’t require outside training. This is still an area where I see hesitation at companies designing enterprise products.

People will say, “Well, a little bit of training is going to be needed in order to help people understand this tool, because it’s more complicated than consumer applications.” Building for people when they’re at work shouldn’t be an excuse for bad design.

If you follow common UI constructs, orient users, give them a concrete user benefit, and leave them feeling that they’ve gotten something valuable for their time, they will continue to learn your product just as they learn video games, mobile apps, and everything else in our world.

Make your product customizable by the user and team

Enterprise customers shouldn’t accept the notion that they should need implementation specialists to tailor the product for the customer; customers should be able to do that themselves. If you design an enterprise application such that it can be customized by the teams using it, you give them a sense of investment and ownership in the product.

You empower them and give them confidence. Meanwhile, they customize it for themselves, and become much more loyal. What’s more, as an enterprise vendor, if you spend your time and resources on custom implementations for your customers, you won’t have enough resources to invest in applying customer feedback and innovating.

The risks and opportunities in designing for enterprise

Though the gap between enterprise and consumer user experiences is narrowing, there are a few lasting differences that are important to consider in designing business applications:

It can be riskier to be innovative

With enterprise tools, you’re working with data that is extremely valuable, so it can be frustrating for users if you bury that data in playful and unusual interactions. You want to adhere to user interface standards that already exist, focusing your innovation on the parts of your product that are better than what’s already out there.

As a Google Docs user, I don’t have to figure out how to use the document editor, because it borrows so heavily from what I already know from using Microsoft Word. What Google nailed in execution was focusing innovation on the differentiator: the collaboration tools that set it apart from MS Word today. The only thing I need to learn in the app is how to invite someone to edit with me.

Once I have that concept down, I can use the application in thousands of interesting ways, and build on what I’ve learned as I expand my use to other related products, like Presentations. I’ll be the first to admit that it can be hard for a designer to be disciplined in choosing where to use existing paradigms, and still be very focused on where to reinvent.

You rarely have the ability to “dogfood” your work

If you’re designing for a consumer tool like Facebook or Pinterest, you are probably already a user yourself. With enterprise or business applications, that’s not always the case. This means you have to be an excellent researcher, as well as designer.

When I was at Intuit, it wasn’t enough to know how to design a good web app; I also had to understand accounting constructs, and small businesses/accountant needs. I’ve never owned a small business so I had to spend a lot more time interacting with the people using the product, understanding their goals and motivations, than I had at other companies. I invited others (who knew more than I did) to design with me.

Thankfully, at Asana we use our app to do all our work, so we have benefit of experiencing what our users experience.

The beauty of designing for enterprise and other paid applications is that user goals and business goals are aligned.

I’m excited to see more interest from designers and design leaders in creating enterprise tools, and I think it’s because the gap between consumer and enterprise is narrowing. With consumer apps, you can feel good about designing a tool that impacts billions of users, and you can bring entertainment to the world. But there is a challenge that leaves the designer feeling conflicted over time.

Many consumer apps monetize with ads, so the user goals and the company goals are not in sync. The user is thinking “I’d like to watch this video,” and the company is thinking, ‘How can we get the user to view more ads before they watch this video?.”

The beauty of designing for enterprise and other paid applications is that user goals and business goals are aligned. The company benefits only when the user is successful at using the app. With enterprise tools, you are building products that help organizations, and their employees meet their goals, helping all businesses do their work better.


Prior to joining Asana as the Head of Design, Amanda Linden worked at Intuit leading the QuickBooks web & mobile product design teams, and also managed their payroll and payments experiences.  She was previously a Director of Design at Yahoo! She holds an MBA and a BS in visual design from UC Davis. Amanda has worked on a variety of enterprise products (i2 technologies, PeopleSoft, HP, Documentum) as well as consumer facing tools (Yahoo! Groups, Profiles, Answers, and Wells Fargo online banking).

Related articles

Role Spotlights

Why Asana is switching to TypeScript