There is clearly a big difference between software intended for consumers and that intended for business users, and even some variation between enterprise and B2B products. In recent years, lines have been blurred a bit, especially in regard to the user experience offered B2B users. There are still major characteristics that set SaaS enterprise apart from consumer applications, and these are no surprise to most. These factors include the complexity of workflows, scale of data, mission-critical nature and connections (or lack thereof!) to diverse or legacy platforms.
On a spectrum of complexity, one might position consumer apps at one end and large enterprise applications at the other, with a wide range of B2B applications in the middle that may tend more toward consumer usability standards, especially those targeting SMBs. Still, even in larger enterprise applications the long-term trend is distinctly toward offering a more consumer-grade user experience. Why? Because the facts have long shown the savings in time and costly errors (and in some cases even lives) are worth a more sophisticated approach to user experience.
I’ve spent a number of years designing enterprise and B2B applications in such varied verticals as health information technology, fintech, biosciences, cloud video surveillance and ecommerce—ranging from 0-1 projects to redesigning legacy systems, for startups and the world’s largest company—and I’ve learned there are some common enterprise UX pitfalls that plague such applications, regardless of the business classification. Often they involve not only the dreaded “technical constraints,” but frequently a simple, literal-minded lack of imagination that can negatively impact user experience. Fortunately, there are solutions to these obstacles.
Envision user routines rather than tasks
Enterprise software is often designed to enable a set of discrete individual tasks. These tasks are envisioned as specific, self-contained micro-flows that are treated as unrelated to other tasks. You can tell if your software is designed this way if you have to provide a manual that has headings like “How to add a sales estimate.” The problem with this approach is that the system pretends total ignorance of how a user approaches and completes tasks. These tasks, being discrete, often require a beginning, a middle and an end, and then the user must navigate elsewhere to complete another separate task, and so forth.
But if we know that a typical user will go into the application in the morning after getting a cup of coffee, and then has a to-do list of various tasks, we can help reduce time spent by assuming a certain sequence or even doing multiple tasks at once. The sequence may vary by the user roles, but customized flows can be offered for the main roles, always of course allowing for deviations and exceptions. A well-designed user journey map based on extensive user interviews can provide invaluable guidance in determining such flows and dramatically cutting the amount of time spent on routines, as well as reducing user errors. Even better: session replay software that allows you to follow the actual task flow of users, setting up funnels to see where they go and what they do. Using session replay has actually helped me to entirely redesign the navigation of an application and indicated exactly what analytics we needed on the dashboard.
Provide smart defaults and allow flexibility
There can be two extremes in designing the enterprise user experience: one is to be too constricted, the other to be too flexible. The constricted option is a hard-coded, narrow set of options that does not permit variation. On the other hand, if options may need to be more flexible, we may just force the user to make all the selections even though we know what they want 90 percent of the time.
Consider the example of user permissions. In a world ruled by the MVP, it’s obviously necessary that shortcuts be taken to ship an application. One of these shortcuts often taken is simplifying user permissions to a few roles. Think the classic admin, user, manager, visitor, etc. A database is designed that specifies four to five roles and that is often considered enough. But this seemingly simple approach can be a path to chaos.
Let’s assume that there are 12 types of permissions a single user may have, such as creating, updating, deleting, reporting, access to certain types of data, and so forth. Each of our user roles can have any combination of the 12 permissions depending on their job responsibilities, and the developers have hard-coded each of those arrays to each role. If a user needs a slight variation on those permission sets, a ticket is created for engineers to add a new role with that specific array of permissions.
Now I’m a designer, not a mathematician, so I had to ask ChatGPT how many possible set variations there can be with those 12 permissions. The answer: 4,095. I’ve seen user roles in an admin area that had dozens of permissions sets, maybe differing by one or two differences. And the endlessly scrolling interface for assigning user roles was a list of roles and which permissions were proper to each role, making it difficult to distinguish between roles. When I questioned why we were doing permissions this way, I was told they had realized their mistake too late and that it would take six months for engineers to redo the roles and permissions. In the meantime, an engineer was dedicated to adding new permissions sets each month based on customer requests.
The way to avoid this scenario, of course, is to have flexible permissions for any given role. Start with defaults, and make it easy to tweak a role for an individual, adding or deleting permissions as needed. This gives you the best of both worlds; the user doesn’t need to do all the setup from a blank slate but outlier cases can also be accommodated.
Allow for many-to-one associations
Many enterprise or B2B applications require certain supporting documentation or linkages to guide business evaluations and approvals or to fulfill regulatory requirements. Let’s imagine for example an application that requires for each expenditure an invoice and a contract. The typical approach would be to have the user pull up an interface to enter the amount of the expenditure and attach a receipt and a contract. (Let’s hope the system utilizes OCR and AI to read these documents without requiring the user to enter the data they contain!)
Now suppose that a single contract can apply to dozens or even hundreds of expenditures. It’s not an unusual situation. But a common approach to building out an application can include a data design that allows only one-to-one relationships because the PRD said “every expenditure must be assigned an invoice and a contract.” As a result, the user might have to re-upload the same PDF contract and invoice for hundreds of expenditures (hopefully not also having to re-input details about each invoice and contract: number, date, expiration, customer name, customer number, vendor, etc.).
The better experience, which can also dramatically reduce time and costs associated with this process, is to allow contracts and invoices to be uploaded and then associated with expenditures. There are likely similar cases of this scalability issue you can probably think of that pertain to your own company.
Let computers do their job and humans do theirs
Digitizing manual processes is often a priority for enterprise. This goal may involve converting multi-step processes based on paper or Excel (or both) to a SaaS flow, allowing more manageable use of data and better tracking of metrics, among other benefits.
In converting such processes to a digital platform, however, too many times the manual process may be replicated almost exactly without an in-depth analysis of whether all the steps are necessary. Manual processes that involve copying and pasting data from an application to an Excel spreadsheet, for example, may require the user to do the same in a new online form. And yet all too often we are asking for information the system already has. If we know the customer number, for example, why are we having the user copy and paste it into a form field? If the system has sales figures for a customer, why are we asking the user to compute and enter them? I’ve even seen forms that asked the user for the date. The computer knows the date.
I was once asked to design a flow for a complex financial process that required employees to complete 18 manual steps (including screenshots, Excel spreadsheets and paper), every day, for dozens of customers, taking about 45 minutes for each. You may or may not be shocked to learn there was an actual hand calculator involved! I did discovery on every piece of information that was requested in the process, and had meetings with engineers to discover which data were already available or could be easily computed or obtained. As a result, there was actually no UI required. The process was completed automatically every morning at 12:01 a.m. using available data, ready for final review and approval by staff, a task that took a few moments.
Disparate flows that are integrated into a system as part of digital transformation should not be assumed to be disconnected. If they are, there is likely a way to connect them and eliminate error-prone and time-consuming data-entry. Consider every point at which you ask the user to enter some data: where is the user to get this information? Do we already have it? Can it be easily obtained elsewhere by API or scraping and pre-populating? Some things computers will always do better than people, and empowering that is where the real benefit in user experience can be found.
Remember the decision-maker
One of the defining characteristics of enterprise software compared to consumer software is that the enterprise purchaser is not the user. But just because the person who signs the software contract is not a user doesn’t mean we can ignore them. After all, what basis will you give the purchaser for renewing the subscription? Will you have to justify the purchase with a presentation for every renewal, or worse yet rely on someone else inside the enterprise to do that for you?
It’s likely the decision-maker has expectations of the software. They may have required a significant discovery process, possibly involving build/buy analysis, and consulted the findings to make the decision to sign up. Or if the software is bespoke there is some data an executive expects. Perhaps that is now presented to the executive in an Excel download or a quarterly PowerPoint deck.
But what if the executive could have ready access to the data they needed from the application, on demand? Even in the form of a mobile dashboard that presented the top 6-8 metrics the executive was responsible for, that could be a gamechanger. It would greatly increase the chances of renewal or internally free up additional resources to expand the platform.
The best way of making sure the needs of this executive are met is through the persona process. Include all affected stakeholders as personas, even if they will never log into the application. And then explore ways to get them what they need. Is it a bespoke dashboard? Regular delivery of analytics by email? A system-generated deck of slides to be used in presentations? If we consider the user experience as extending beyond the application screen, we can imagine many ways of addressing crucial business needs in a holistic way.
What other assumptions are hindering your enterprise application?
These five keys are only examples of opportunities we can find in enterprise software that can dramatically and quantitatively improve business processes through product design. You will also note that all these solutions require expensive collaboration from the earliest stages with product, business and engineering. This team needs to work closely to identify similar issues based on scaling, database design, assumptions about existing processes and expanding the idea of who is a user. That’s when your enterprise application will become more than a series of spreadsheets and deliver benefits you never imagined.
Image: Unsplash, Filip Szalbot