Post Image

Enterprise UI: 5 Ways to Adapt UX Thinking to the Enterprise | UXPin

Germaine Satia
By Germaine Satia on 14th March, 2016 Updated on 15th June, 2020

Internal politics, tight deadlines, conflicting or shifting priorities.

These are UX design challenges that all product teams face. But in the enterprise world, these challenges are present at a much more significant scale. As a result, the impact on the UX design process is magnitudes larger.

In this article, we’ll explain 5 useful techniques for designers and product managers to overcome the main challenges of enterprise UX. 

1. Think “functional persona” instead of “user persona”

Traditionally we’re taught that a persona represents a particular user. In the enterprise world, however, users are often spread across various business units and even continents. A marketing manager in the U.S. may have completely different needs from one in Kenya or Mumbai.

As a result, enterprise product teams should think in terms of functional personas rather than John Clark, Marketing Manager. What do I mean by functional personas?

Let’s take the example of an online content collaboration platform. On this platform, team members can:

  • Create content
  • Edit content
  • Review content
  • Submit content for review
  • Approve content
  • Reject content

In this scenario, the content creator, content reviewer and content approver will always be different people. And in some cases, the organizations using the platform can come from sectors as varied as healthcare, education, government and more.


Photo credit: Gather Content

With all the variances between industries, you can’t manage personas in the traditional sense of “one user, one persona”. A more practical approach is to examine the functional areas within the platform (create, edit, review, submit, approve and reject) and then create personas that address each area (hence, functional persona).

But how do you go about crafting a functional persona, for example, when the actual users have different, industry-specific needs? We’ll use the “Content Creator” persona to help explain the process:

i. Collect information from users representing each functional area: In our example, you’d want to speak with content creators from various industries. Don’t worry so much about their demographics. Instead, ask them about their task needs: how they go about creating content, the content format they need, etc.

ii. Map out the workflow for each industry: This can be a user journey map, a workflow diagram or post its on a wall that show the steps in the user’s workflow.

iii. Identify common themes: Examine each industry’s workflow and start looking for common themes that you can highlight. In the case of “Content Creator”, you’ll probably find that all users need to upload images. Another theme could be the need to reference or link to existing pieces in their content library.

iv. Build your functional persona: Once you’ve identified themes that are most common to all the industries, feed this information into your persona. You can use the themes to build the story around key things like user needs, user roadblocks and user expectations.

In terms of the metric for identifying common themes, look for themes that occur in at least 50% of the workflows for all industries.

2) Be proactive about politics

Enterprise environments bring with them a much longer chain of command and the influence of many leaders or stakeholders. You can’t avoid it, so you might as well face it head-on. 

Many of these leaders will want to take on the role of “decider” who gives final approval for product decisions. To help protect your Agile team from conflicting interests, here’s some tips for less painful collaboration.


i. Talk to all leaders vying for the “decider” role:

In my experience, you’ll have 2 to 4 key leaders in the company that might fit the role.

Talk to them individually or in a group meeting. Explain to each of them that you’d like to establish a clear review process for designs and specifications. Ask them if they’d like to be involved in those initial conceptualization phases.

Just by doing this, you can easily filter out one or two from the process because they’ll back out once they see the additional work required to validate their opinions.

It’s imperative that you talk to them first as opposed to imposing your ideal process on them and explaining later. You have to maintain collaborative harmony.

ii. Talk to your product team: As part of your process planning, talk to your product team, particularly your Scrum Master and UX Design Lead. Get their feedback on the preferred process for their individual teams.

iii. Present your process vision to all executives: Using the feedback from stakeholders and the product team, fine-tune the review and approval process.

Once you’ve mapped out the process, hold a short meeting (less than 30 minutes) with the remaining executives, Scrum Master and UX Design Leads to present your plan. You want everyone in the room for early sign-off on everyone’s role (or an open debate if any concerns arise).

3. Think in terms of account settings

As explained in the free guide The Future of Enterprise UX, the account settings (e.g. admin interface or admin module) is often the enterprise software designer’s best friend.

The sheer number of users and possible enterprise use cases means you can’t cram all the functionality into the default UI. You need to make the tough decision for which functionality becomes an admin setting.


Photo credit: Gather Content

To help decide correctly, return to your “functional personas” and user flows. Functionality common to most of your user groups should move up in priority as candidates for the default UI. Everything else becomes lesser priority in the admin bucket.

If a new functionality simply requires adding a dropdown menu or a couple of radio buttons, chances are you can safely add them to the UI without disrupting the UX. But if the new functionality results in an entirely new layout for an existing screen, you’ll need to reconsider placement.

For example, will there be a significant re-learning curve for existing users? You might ultimately be better off defining that functionality as an admin setting that generates an entirely new screen or layout only for accounts that opted in.

4. Work with sales teams to identify upsell triggers in the product

As you work on new features, talk to your sales directors or their representatives (such as the pre-sales engineer). Oftentimes, the sales team’s understanding of the market will reveal which features are a right fit for an in-app upsell flow. The knowledge is absolutely mandatory for any design team working within a “land and expand” business model. 

For example, Slack’s “Learn more” link below actually redirects to their pricing page. By placing the right upsell messages with the right triggers, you’re helping the company better automate expansion revenue.  


Photo credit: Slack

5. Work with sales teams to internalize buyer vs. end-user needs

Talking to the sales team early in the specification process also offers a better understanding of the actual buyer and end-user. In some cases they’re the same person, but very often for enterprise software, they’re different people.

Let’s return to our content collaboration platform example.

The buyer might be the CTO while the end user is a marketing manager. The CTO won’t care much about uploading a jpg vs. a png or importing a Word document. But the sales team can help you understand that they really care about data encryption, the location of data centers, and whether their content is subject to laws such as The Patriot Act (particularly relevant for non-US customers), and other security-related aspects.

While you might understand these needs from user interviews with CTOs, conversations with the sales team will help you see what functions are actually persuading buyers to sign the purchase orders. You help close the gap between field research and field results. 

Get to know the buyer and end user needs early so that everything from the functionality, color choices and language is balanced accordingly. Enterprise products must be powerful enough to sway the buyer, but usable enough for end-users to continue advocating for plan renewals.To learn more about designing a “consumer-grade” enterprise product, check out the free guide The Future of Enterprise UX.


UX design is always a delicate balancing act.

This is not to say that smaller companies means smoother sailing. You can still face significant obstacles if a single stakeholder (especially a co-founder) holds a very tight grip on decisions. On the flip side, enterprises can also have executives with a strong appreciation for the UX process.

The sheer scale of an enterprise company means that more hierarchy inevitably exists. As a result, every enterprise designer needs to learn to adapt to both bureaucratic sprawl and product complexity.