Design · User Experience Design

Is there a difference between designing for enterprise vs. consumer?


February 18th, 2015

It used to be that consumer apps focused on design and product, while enterprise apps "got away with" just working. It made it so designers didn't really enjoy working at enterprise companies. But given new frameworks and user expectations it seems like that is changing. Wondering if there are still differences between designing for enterprise vs. consumer. Would love to hear from designers on both sides as to what appeals to them.

Rodrigo Vaca Product & Marketing

February 19th, 2015

Let's take the question at face value. I'm not trying to be a smart-ass, but how we phrase a question can sometimes dictate the answer!

"Is there a difference between designing for enterprise vs. consumer?"

Enterprise - a legal entity.
Consumer - a person.

You can't design a user experience for a legal entity! In both cases you are designing for humans.

Now, the difference in the UI/UX for a home user vs for an enterprise user will be dictated mostly by the functionality and workflow you need to offer for that particular user. In word processing, I doubt a home user needs to do multiple rounds of revisions and track changes for her resume or letter to mom. For expense tracking, a home user will not need to get the expense approved depending on the amount, assign it to a project, etc. So the experience, actions, complexity of the screen will be dictated by the use case.

One of the major reasons "enterprise UIs" have improved is simple. Before, enterprise purchases by driven by the IT department against a list of checkboxes and criteria, that included security and -ilitys like escalability, manageability, etc. Usability was an unknown word. Today, with the cloud, departments, business units and individual users can purchase their own IT solutions with a credit-card. So that has upped the bar for "traditional" vendors.

So, coming back to your question - I don't think there's much difference today in terms of the thought that goes into designing for consumers or enterprise users. However, there's a selection bias. Enterprise-focused companies typically have slower release cycles than consumer-focused ones. And that's the part that might drive designers crazy, as their ideas take a long time to make it into the wild.


George Calvert

February 19th, 2015

Excepting stuff like network security, enterprise apps are mostly about delivering productivity.  Pretty, intuitive interfaces and short learning curves -- qualities consumer apps excel at -- improve adoption and productivity, particularly in the short-term.  But speed, power and flexibility are also very important in the enterprise -- and these mean balancing the equation differently.

To me, there's little difference in the process.  It's about knowing your customer/market, understanding their needs and being sensitive to the nuances therein.  You then imbue and invest your design efforts accordingly.

Nathan Bobbin Senior Director, Product Innovation at Travelport

February 19th, 2015

The most significant difference here is that the user is not the buyer. This fact will drive many important decisions for enterprise software - design and otherwise. 

Gavin Heaton Digital Strategist, Advisor, Keynote Speaker

February 20th, 2015

As always - design with the user in mind, but understand the use cases/user journey.

The "enterprise user" has a different "job to be done" than the "consumer". The enterprise use case will have multiple stakeholders and perhaps even multiple buyers. They will be looking for reassurances around privacy, security and data management. They may need (or wish for) integration with existing systems, single sign-on etc.

Effectively you need to design a "system" rather than just an app.

Michael ★ Vice President, User Experience at RingCentral

February 23rd, 2015

I certainly agree with the previous posts which present a version of the Consumerization of IT ( argument for why enterprise software needs to get better in a more competitive world with higher user expectations.

But, I think the issue is a problem of term definition. If "enterprise app" means any software tool used by people in the context of their job, it's too big to be meaningful.

Some enterprise software is very much like consumer software
We use Slack a lot at work. Slack is a very simple communication tool for local or disparate groups with a history and some basic notification features. It's about as consumer-y as you can get. The design process for Slack was very similar to the design process for a consumer app - start with a premise that some problem that you are facing is a problem for lots and lots of people, design the app to meet your need, then figure out how to market it. The key thing here is that Slack is a simple product solving a simple, well defined, and well understood problem for a user that has needs which are very similar to the personal needs of the design and development team. Someone using the tool at a law office, or a software firm, or even a bunch of grad students working on a project, would all use the tool in extremely similar ways

Some enterprise software is nothing at all like consumer software
Take another class of enterprise software product - server log analysis for high volume unstructured data flowing from mission critical cloud based applications. Here, there is a tremendous space for varied user context, and user needs. An IT administrator in the CIOs organization would use the tool very differently than a developer reporting to a VP of engineering, or a Dir SecOps reporting to the CISO. Each of these audiences would need to have their needs (both feature needs as well as UI design/consumability needs) met, or ignored, as a strategic decision by the firm building and marketing the product. The product is incredibly complex, and must meet very specific user needs. If the designers are targeting a certain persona with deep IT skills, because that's the audience that has money and that they can reach through their sales channels, then that audience will get a product that lets them solve complex problems quickly with the mental models that work for them. But, if you happen to be a weekend developer with limited SaaS architecture skills, the product will be overwhelmingly complex and your experience will be awful. Likewise, if the designers target a lower skilled user, the Sr. engineer will find the product to be slow and painful, full of unnecessary wizards and tools that just get in the way of what they want to accomplish.

Good software is good software
Please don't misunderstand my point. I'm not arguing that the world needs more crappy software. Good software gets designed in remarkably similar ways regardless of who is buying it, or using it. You talk to users, talk to buyers (maybe the same, maybe not) make prototypes, you test your ideas, you prioritize features and try to focus on the needs of your audience. And, yes, the world is full of crappy enterprise software. And, yes, a lot of that software was bought by someone who doesn't use it.

My point is to remember who the audience is, and it's often not you.

Joe Emison Chief Information Officer at Xceligent

February 20th, 2015

I think George Calvert has the best answer so far. The enterprise (and organizations in general) are more rational consumers, and they're also less creative and willing to just try things.  So when designing for the enterprise, you will be more successful if (a) you're providing something they already think they need (and hopefully are generally looking for), and (b) what you're providing has a relatively clear reason for being used in the organization (doesn't necessarily have to be clear ROI, but something in that neighborhood, so the purchase can be justified).

UX matters more and more, but in the enterprise, I think UX is more around retention than getting the initial sale.

Mike Rozlog Advisor at TechColumbus

February 18th, 2015

As a CEO that produces commercial software and in the past developed enterprise software, there is a difference, but the difference is becoming a much smaller gap IMO.  Why should internal enterprise software users have to put up with poor-designed software?  They should not, but it usually comes down to time and resources as all things do.  However, with some of the frameworks the time difference between doing it better and doing it wrong is not near as high as it once was.  

However, I will say if I build something for myself (situational application), that may be used by me and a few others... I don't worry to much about the design (however, I believe I design better than I used to in the past), I'm more worried about getting the functionality as soon as possible.  However, if I'm green lighting a project for internal use, I want them to plan adequate time for usability.  Therefore, I'm the classic the TV Repair guy, does not have a working TV for his family but everybody in town, does.

Rob G

February 19th, 2015

I'm not a designer - i still struggle with stick figures! But i have spent many years in the enterprise software world (from the engineering, sales engineering, sales and sales management disciplines) and one important aspect of the purchase/sales decision for enterprises acquiring software applications is user training and user uptake and on-boarding. These are often very big expenses for the enterprise and the application provider who can show that they can reduce these costs has a key differentiator. device and application developers who sell to consumes simply cannot afford to train users so they really had to focus on making the user experience intuitive to lower the learning curve. On the enterprise side, Implementation and training services have traditionally been huge profit centers for the big enterprise app vendors and the thousands of consulting firms that support them. But office workers are consumers too. They know what is possible and they are demanding applications that are more intuitive. Enterprise apps still need to show they are 'industrial strength' (bullet proof), but the more you can reduce the burden and cost of training and on-boarding the better. Also, user adoption is key. If a departmental application can spread 'virally' within an org that reduces the vendors cost of sales so it's to your advantage to consider features that help 'spread the word' behind the firewall. my $00.0000002 worth.

Stephanie Holt Owner, User Experience and Interaction Design at Tahiti Blue Interactive

February 20th, 2015

I would agree with everything said here, namely the expectations in terms of ease of use for enterprise software are close to those for consumer software, the design process should be the same, i.e. design for the humans using the system, and the organizations that deliver enterprise software are putting a much higher priority on having a good user experience than they have in the past.

I would just add that one practical difference tends to be the level of complexity involved in designing enterprise software versus consumer software. I'm not saying that consumer software isn't complex at times, but typically with enterprise software you will be dealing with things like large data sets, complex workflows, and interfaces that adapt based on user roles. I would say that all of this makes designing a good experience even more of a priority as a means of reducing confusion and complexity for the end user so that they are able to be as productive and engaged as possible when using these software tools.

Alex Eckelberry CEO at

February 20th, 2015

Just adding to what everyone is else piling on. 

I have spent the last 30 years in both enterprise and consumer products. 

The reality is you're dealing with living, breathing human beings in both cases. So you need to have a product that is actually usable. There was a time when it was believed that enterprise customers, for some reason, were a different species of customer. You had to be more serious, more conservative.  That belief system is no longer valid (if it ever was). 

That doesn't mean, however, that you oversimplify. Enterprise (or b2b) customers tend to have a higher knowledge of the value offering and your product, and their environments are more complex. Perforce, it will need to be somewhat more technical. 

But in the end, good UI is good UI. It should be intuitive, straightfoward, and highly usable.