Enterprise UX Design: 95% of Our Users Never Used It Alone

Enterprise UX design is the practice of designing software that organizations buy and their teams use for work: complex data, many roles, long sales cycles and users you rarely get to meet. The hard part is not the screens. It is that the person who signs the contract is not the person who opens the app. When I joined Accern, a no-code AI platform for financial organizations, we found that 95% of users never used the product by themselves. The customer success team did it for them. That one number changed how I think about enterprise UX.

This is the story of that redesign, what we did about it, and the parts you can reuse if your B2B product quietly depends on humans doing the work behind the interface.

What enterprise UX design actually means

Most definitions stop at "UX for big companies." That is true but not useful. The way I would put it: enterprise UX design is designing for a chain of people instead of one user. There is a buyer who cares about risk and return, an admin who sets things up, a power user who lives in the tool, and an occasional user who opens it twice a month and has forgotten everything since last time.

Consumer products can survive on delight and a fast first session. Enterprise products survive on whether a team can do real work in them without calling someone. If they cannot, the product still gets used, but through support tickets, onboarding calls and a customer success team carrying the load. On paper, the account is healthy. In reality, the product is a service with a login screen.

That was exactly where Accern was when I arrived.

The Accern story: 95% of users never used the product alone

I joined Accern in January 2020, after their seed round, as the first design hire. The platform let financial organizations extract insights from unstructured data with no-code NLP, so analysts could make better risk and investment decisions. The full case study, with the visuals I am allowed to share under NDA, is on my Accern no-code AI platform case study.

Before there was a design team, a beta had been built on blue-sky concepts. Prototypes had never been usability tested, the architecture did not scale, and technical limits had not been considered. Users also had to move between two separate products: Titan for text analytics and XYME for predictive analytics.

When we looked closely at how clients actually used the platform, the pattern was hard to ignore. 95% of users never used it on their own. The customer success team created the use cases, added the taxonomies and built the NLP models for them, because the users could not make sense of what they were doing, how to do it, or how to reach the result they wanted.

Here is why that number matters. A product where the vendor's team does the work does not scale with sales. Every new client adds load to customer success. And the client never builds the habit that makes them renew, because the value lives in someone else's head.

Why enterprise users are hard to reach, and how we worked around it

Our users were large finance enterprises. That is the classic enterprise UX constraint: you cannot just recruit ten people for a quick test on a Tuesday. Their time is expensive, access goes through account managers, and nobody wants a vendor experimenting on a production workflow.

So we did not pretend we could run a consumer-style research program. We worked very closely with the customer success team, because they were more connected to our clients than anyone else in the company. They were, in a real sense, our most experienced users. They knew every confusing field because they filled it in for clients every week.

On top of that, we ran user interviews with the clients we could reach and sent a usability check-in survey through SurveyMonkey to see how people felt about the product and where they struggled. From that research we built four personas based on behavioral and attitudinal patterns, plus an empathy map. Inside the company, we set up bi-weekly workshops with different departments to agree on where the product was and where it had to go, alongside daily standups with the VP of Product and the PMs.

My honest take on this setup: using your support or success team as a research proxy is not ideal, and you should say so in the room. They see failures, not the moments where users quietly gave up and never called. But it is far better than designing from opinion. Pair it with whatever direct contact you can get, even a handful of interviews.

The pain points behind the 95%

The feedback repeated itself, which is useful, because repetition is how you know a problem is structural and not a single bad screen. The main themes:

• Two products, one job. Users kept moving between two separate platforms to perform different actions.
• Jargon everywhere. Words like taxonomy, NLP and data store meant nothing to many users, and the language made it hard for them to explain insights to their own clients.
• Setup that required help. Creating a use case took forever and was not possible without the customer success team. Creating a taxonomy showed fields people had no idea how to fill.
• Unexpected navigation. Opening a use case dropped people into the data source, which is not what they expected to see.
• No guidance. There was no documentation or help for specific tasks, and limited ways to customize, export and visualize data.
• Trust in the model. Some users were unsure about the accuracy and completeness of the NLP models, so they did not fully trust the insights.

We wrote the problem down in one sentence: the functional architecture of the application and the understandability of key features stopped users from getting the full value of the product. Notice that this is not a visual problem. A prettier version of the same architecture would have kept the 95% exactly where it was.

What we changed in the design process

The first decision was structural: users should reach the product through one link and one path, and manage all their data in one place, instead of going back and forth between Titan and XYME. Consolidation came before any polish.

From there, the process was deliberately boring, in a good way. We reframed research insights into How Might We statements, ran workshops to generate ideas, and used an impact and feasibility matrix to choose what to build, always checking whether our personas would actually use each feature. We built storyboards of the user journey before designing screens, then user flows for the different scenarios, then sketches in Procreate that I moved into Figma as wireframes.

There was no style guide or pattern library, so the high-fidelity work happened in close alignment with the CEO and stakeholders on visual branding and tone of voice. After a few iterations I took the lead on building a design system and design patterns, which matters a lot in enterprise products: when the same table, filter and empty state behave the same way everywhere, users stop relearning the product on every page.

Enterprise UX vs consumer UX: what actually changes

Dimension	Consumer UX	Enterprise UX
Who decides	The user downloads and decides	A buyer signs, a team uses, an admin configures
Access to users	Easy to recruit, test weekly	Gated by account managers, often through proxies like customer success
Failure signal	Churn and uninstalls	Support tickets and the vendor doing the work for the client
Main risk	Boredom in the first session	Jargon and setup steps nobody can finish alone
What earns retention	Habit and delight	A team doing real work without asking for help
Design system value	Brand consistency	Predictable tables, filters and states across dense workflows

The result: from a service to a product

The published results from Accern: retention went up more than 200%, with users checking the platform at least two to three times a week and navigating it without help from customer success or anyone else. Support tasks dropped by 82%, which freed the customer success team and other departments. The company went on to raise more than $40M in VC funding and was later acquired. I also designed the Series B deck, and wrote about it in my Series B pitch deck learnings.

I do not claim design alone did that. Funding and acquisitions come from a whole team. But the 82% drop in support work is the number that matters most here, because it measures the exact thing the 95% was hiding: whether users could finally do the job themselves.

Enterprise UX design lessons you can reuse

If your product has a quiet army of humans making it work, here is the order I would tackle it in.

Measure the shadow work first. Ask your success and support teams what they do for clients that the product should do. Count it. "95% never use it alone" is a much stronger brief than "the UX feels clunky."

Fix architecture before screens. Two products for one job, or a click that lands somewhere unexpected, will beat any visual redesign. Consolidate paths first.

Translate your vocabulary. Internal words like taxonomy or data store feel precise to the team that built the model and opaque to the analyst using it. Plain language is a feature. The Nielsen Norman Group research on plain language for experts is worth sending to anyone who thinks expert users want jargon.

Treat model trust as a design problem. If users doubt the AI's accuracy, they will not act on its output. This is the same lesson I relearned later on AI tools for creators: designing AI features is designing trust. I go deeper on that in what AI replaced in my design work.

Use proxies, but name them. Customer success is a strong research partner. Just remember they hear about failures, not silent drop-offs, so add direct interviews wherever you can.

Where this does not apply: if your product genuinely is a managed service and clients pay for your team's expertise, then human help is the product, and forcing self-serve can hurt. The point is to choose that on purpose, not discover it in the support queue.

The same "earn it before you ask for it" thinking drove the onboarding fix that took activation from 13% to 65% on ViewStats, a very different product with the same root problem: users did not understand what they would gain.

FAQ about enterprise UX design

What is enterprise UX design in simple words?

It is designing software that companies buy for their teams. You design for several roles at once (buyer, admin, daily user), complex data and strict workflows, and the goal is that people can do real work without needing the vendor's help.

How is enterprise UX different from B2B SaaS UX?

They overlap a lot. Enterprise usually means larger organizations, longer sales cycles, heavier compliance and harder access to users. A small B2B SaaS tool can be self-serve from day one; an enterprise platform often starts with onboarding calls and has to earn self-serve over time.

How do you do UX research when you cannot reach enterprise users?

Work through the people closest to them, usually customer success, support and sales, and combine that with the few direct interviews and surveys you can get. At Accern that mix gave us four personas and a clear problem statement even though large finance clients had little time to test.

What is the best metric for enterprise UX?

I like "how much work does our team still do for the client?" Support tasks, setup requests and assisted sessions show whether the product works on its own. Retention and frequency of use come next.

Need this kind of redesign?

If your B2B or AI product depends on people doing the work behind the interface, that is a problem I have worked on directly. You can see more of my product design case studies, or look at how I build interactive prototypes in my AI design experiments. When you are ready, hire a product designer who has done enterprise UX and tell me what your success team does every week that the product should do instead.