Designing a data-heavy enterprise application — Part 2

A practical guide on designing for speed and repetitive use, accessibility and scalability in enterprise applications.

Ovidiu Boc
Bootcamp
Published in
17 min readJan 4, 2024

An excerpt of requirements for enterprise readiness: security, scalability, SSO, RBAC, compliance, cost control, efficiency, accessibility
Excerpt of requirements for enterprise readiness

First, let’s do a brief recap of the main topics covered in the 1st part:

  • Brief comparison on designing for enterprise vs consumer products.
  • Loading data: downsize on purpose, divide and conquer, manage the expectations, don’t interrupt.
  • Error handling.
  • Display data: no data, too little data, too much data, protected data, format data.

If you’ve missed the 1st part, please read it and show your support here:
Designing a data-heavy enterprise application — Part 1

4 more to go

In this 2nd and final part, we’re going to focus on yet another set of 4 practical guidelines we need to consider when designing a data-heavy enterprise application.

If you are a product designer who is already working on an enterprise application 👋 or you’re thinking about joining an enterprise team, you might find the pointers in this guide useful to take into account.

Take accessibility seriously

Low vision

I know you probably love using those subtle shades of graphite or that thin Inter style and I have to agree: they look amazing on a retina display. Sadly though, they won’t be visible on the vast majority of beamers (or even some smart TVs) you’ll find in most enterprises. Furthermore, they will definitely NOT be appreciated by the employees with poor or deficitary eyesight. Be considerate, use a decent contrast ratio and stroke width. Testing your designs using a different light and device setup will also help — e.g. try it on an old(er) laptop / monitor with low PPI density or see how it looks like on a beamer with the lights on.

Color blindness

Don’t forget about the color blind employees either — they will probably be amongst your users (latest statistics mention around 300 million people suffering from color blindness worldwide¹). To make your designs accessible to them, don’t rely solely on color-coding when displaying key data. For example, showing the health state of an item, the variation of a KPI or the status of a system using colors alone is not enough — back up the color indicator by using a label (text or numbers), an icon or a pattern. If you can’t use either of these, at least make sure you provide a short tooltip indicating what the color means — you should do this anyway, it helps ease the learning curve.

You’re still thinking about the “pattern”, aren’t you? 😛 I know it’s not a common or a popular choice, but it might be helpful in some cases — that’s why I’m going to focus on it for a bit. Let’s consider a health timeline that uses the classic RAG (Red, Amber, Green) convention to show the evolution of a system’s health state over time:

  • The Green usually means “healthy”, “no action required”, “the system is running as expected” and it’s the least interesting of all 3 colors. Basically, nobody’s really interested in the Green. And that’s because, under normal circumstances, everything is supposed to be Green. So… let’s make this as “dull” as possible and NOT use any pattern for it so it doesn’t stand out.
  • The Amber usually means “warning”, “you should pay attention”, “the system is deviating from its normal parameters”. Now this is something the user might be interested in, thus we need to make it distinguishable from the Green. Using some simple diagonal lines as a pattern should be enough.
  • The Red usually means “error”, “you must take action now”, “the system is malfunctioning or is in critical condition”. The user will definitely be interested in this and it’s clearly more important than the Amber. Let’s aim for consistency and build on Amber’s pattern by alternating the diagonal lines as a pattern for Red.
4 examples of health timelines using red, amber and green segments, with and without patterns
Top-down: unsafe for low vision and color blindness, safe for low vision but not for color blindness, optimal solution, simulation w/o using colors

I’ve used the diagonal lines as an example, but you can get really creative with these patterns — just keep in mind a couple of rules:

  • try to keep them consistent and don’t over do it, otherwise the whole interface can become really noisy, really fast;
  • tone them down, they should be subtle enough to be noticeable by color blind users, but not getting in the way or becoming a distraction for the rest of the users.

The advantage of using patterns over labels and icons is that they work nicely as a container fill (e.g. status / progress bars, gauge / bar / circular charts, etc) without taking up additional space. If used correctly, they can be quite effective.

Bottom line:

  • Low vision and color blindness are some of the most frequent accessibility issues you should be aware of and design for, but it doesn’t mean they are the only ones.
  • You don’t have to aim for the highest WCAG compliance level² (AA will do just fine in most cases), but not taking accessibility seriously means losing money when it comes to enterprise products and, sometimes, it might have liability implications as well.

Design for speed and repetitive use

Optimize page scanning

Improving the time spent by an employee to scan a page results in more tasks completed by that employee in a shorter period of time, which leads to a higher efficiency score. Let’s see how we can achieve this:

  • Mind the typography: a clear, well calibrated typeface, with good letter-spacing (even at small sizes), optimal body size (not too wide, not too narrow) and greater x-height will work out just fine for a data-heavy enterprise application in most cases. Due to the high volume of data, you will need to optimize the space usage whilst keeping an eye on the readability and legibility of the content. For example, a looser letter-spacing or a wider body size will increase the real estate needed to display the content, whereas a tighter letter-spacing or a lower x-height will make the text harder to read at small sizes. Last but not least, use tabular figures (monospaced numbers), rather than proportional digits, in tables or places where values may change often — they are easier to scan and compare with each other.
  • Let the data stand out and minimize the noise by removing, replacing or toning down repetitive labels and secondary content (e.g. helpers, subtitles, descriptions, etc.) to make the interface faster to scan.
  • Use visual anchors and proper hierarchy to drive the attention to certain areas and restrain yourself from emphasizing too many elements — soon enough you’ll be finding yourself in a tough spot where almost everything will be emphasized, thus nothing will stand out.
  • Respect the UI conventions used in the market your application is a part of to speed up recognition and improve scanning time — pay close attention to icons and symbols or other specific UI elements. Take it a a corollary of Jakob’s law³ if you wish.
  • Make consecutive items distinguishable so they are easier to scan: use alternating background colors on even vs odd rows in tables, separate (block) list items properly (e.g. more white space, dividers, etc), show the Y axis guides on graphs, and so on.
  • Group similar items together based on easily recognizable criteria to reduce the cognitive load and increase the scanning speed: group form fields into sections with suggestive labels, group settings based on application scope, group options based on impact or functionality, group menu items based on user interest, etc. Play with Gestalt’s principles⁴, especially the “common region”, “proximity” and “similarity” to achieve the desired result — try not to use too many borders and dividers, they tend to add a lot of noise.

Include keyboard shortcuts

To facilitate repetitive use and increase the task completion speed, consider adding keyboard shortcuts for the most frequent actions an employee has to execute. If you decide to support them, make sure they are easily discoverable — mention the keyboard shortcuts individually in context (tooltips, menu items, button labels, etc.) and reserve a dedicated place for them in the UI (e.g. in the help center, global settings, etc).

A panel showcasing the keyboard shortcuts used in Figma
The shortcuts panel in Figma

Regardless of the decision to add keyboard shortcuts or not, you should always check the basics as part of your QA process. Make sure:

  • Using the “tab” key to switch between form fields or actionable elements is done in the correct order — important for data entry tasks;
  • Hitting the “return” key submits forms and executes (focused) actions;
  • Pressing the “esc” key closes recently opened popups (e.g. drawers, modals, popovers, etc);
  • Using the up / down arrows goes over the options in a (dropdown) list;

Sometimes, it also helps to auto-focus inputs or primary buttons to make them easier to fill in or hit using the keyboard (otherwise, the user has to switch from the keyboard to do an extra click — it costs time).

Foster continuity

Speed of use also depends on continuity — avoid dead ends at all costs, they cause significant delays that add up to a slow employee performance (and frustration). Each interface should have a clear purpose (a primary action) and/or it should provide alternative routes the user can follow to move backward, forward or sideways (jump to another flow).

For example, try to include follow-up actions in the confirmation messages to either repeat the operation (e.g. add another), undo it (e.g. continue editing) or jump to a new entry point (e.g. submit for approval).

The confirmations message shown in Gmail after you’ve successfully sent a message, featuring an “undo” and “view message” follow-up actions
Confirmation message in Gmail

The 1st part of this practical guide on designing a data-heavy enterprise application⁵ includes additional tactics you can consider to create a fluid experience and increase the speed of use in different scenarios.

Set proper defaults

Unlike users of mainstream consumer products, employees are less likely to change the defaults provided by your enterprise application either because they are not sufficiently motivated, they are not aware they can actually change them or they don’t know how to do it. Lastly, there are also cases when certain employees are not allowed to change the defaults (insufficient rights).

Setting proper defaults (and remembering them if the user has changed them) can therefore save time and improve speed, especially for repetitive tasks.

When doing so, remember each user profile has different needs — personalize the defaults for each of them. For example, setting the default viewing to “list mode” might be a suitable choice for analysts, whereas “heat map” or “tree map” might be a better default choice for executives.

If possible, help the user by tracking his/her choices and set or change the defaults to match the most frequent ones (e.g. most searched keywords, most chosen export options, most used sorting criteria, etc).

Improve findability

This is a short but often overlooked one: ensure users can easily find what they are looking for. It saves time and speeds up usage:

  • Always sort items in a list or a table by using a clear, easy to recognize, relevant criteria (by name, time, size, type, etc) and try to avoid relying on abstract, hard to “visualize” or hard to understand sorting rules by default — if you must use one, offer an explanation (as a tooltip or otherwise) that includes both the “how” (how it works) and the “why” (why it’s used there).
  • Make sure the global / local search actually works as intended. It might be more expensive or even impossible to implement in some cases (due to the data storage architecture), but always aim to use a full text search over a prefix search as it feels more natural and it matches the user’s mental model better.
  • Meet the user half way when he/she is searching for something and give suggestions whenever possible — it increases the task completion rate.
  • Using a filtering system that allows the user to slice and dice the data presented to him/her should be a given. However, if you want to speed up this process, you should consider supporting contextual filtering (or “ad-hoc filters”) as well throughout the application. In other words, besides a dedicated place in the UI that showcases the available filters, attach an additional action to filterable items whenever they are listed in the UI (e.g. “add to filters”, “filter by value”, “exclude this value”, etc). This way, the user doesn’t have to spend time on selecting the value he’s trying to filter on, copy it, scroll / find the filters panel, paste it and scroll back to where he was initially — it saves time. Take a look at the example below:
An excerpt from a Grafana dashboard showcasing the use of ad-hoc filters
Ad-hoc filters in Grafana

Follow the function

“Form follows function” couldn’t be more appropriate for enterprise applications — keep this in mind when you think about adding shadows, glows, gradients, animations and other effects. Ask yourself a few questions before deciding to add them:

  • Do they have a clear purpose? Do they serve a function?
  • Are they scalable enough to be applied on other similar elements throughout the interface to keep consistency?
  • Do they increase the waiting time for the user? Does the user have to wait longer for a page to load, an animation to finish, etc. before he/she can move on?
  • Are they making the page harder to scan? Are the shadows, glows and other effects distracting the user’s attention from the content?

It’s not a black or white decisive process and it definitely does not mean you shouldn’t use any effects at all. It just means you should be able to justify their usage by explaining their added value.

For example, it’s perfectly ok and even advisable to use a slide-in / slide-out animation to show / hide a side drawer or to use a smooth scrolling effect to jump to a particular section in the page when clicking an anchor — they help the user better understand how the system reacted (B) to their action (A) by showing the transition of the UI between the two moments in time (A → B). It’s also perfectly ok to use shadows on elevated elements (e.g. anything in the “popups” category) or elements you want to stand out. And the list goes on.

But you should try to avoid glowing or fading effects on links and buttons, or animating everything that can be animated — just because you can, doesn’t mean you should. Especially with repetitive use, they can become rather annoying and delay the user’s task completion. Similar goes for shadows for example — if you use them on every container, they are going to add a lot of (unnecessary) noise and decrease the page scanning time.

Don’t over-simplify

Less is not always more, or at least not when it comes to enterprise applications and speed of use. Morgane Peng wrote a nice article on over-simplification⁶ that I highly recommend as it showcases different scenarios in which displaying information in space is more efficient than displaying information in time.

Contrary to Hick’s law⁷ (the time it takes to make a decision increases with the number and complexity of choices), there are cases when an enterprise employee needs all the relevant information at hand on a single screen to be able to do his job. For example, a broker or a financial analyst helping a customer over the phone has similar needs to a sound engineer in a recording studio or an airplane pilot in mid air — they all need their information spread out (in space) because time is of essence and their repetitive work routine, like a memory muscle, plays an important role into helping them making quick decisions.

In such cases, displaying information in time (e.g. using a multi step flow, progressive disclosure, etc.) would simply create a lot of friction and delays, and can even lead to unfortunate outcomes.

Plan for scalability

Ideally, you’d know beforehand the type of data your product is going to ingest and/or manage and you’d be able to start planning around it: navigation schema, red routes, layout structure, interaction patterns, taxonomy, etc. This is the ideal scenario 🤞 but, as it often happens with enterprise applications, it doesn’t always play out this way.

Instead, you’ll probably get your hands on a very basic data model (the foundation) to start width and, unlike most consumer products, chances are that this data model will continue to evolve over time. The challenge is to plan for a degree of scalability that will sustain this evolution for as long as possible.

In other words, try to anticipate and design a solution that doesn’t need a full redesign from scratch each time the data model evolves. You will eventually need a complete remake at some point, that’s inevitable simply because the entire structure will need a fundamental change in order to accommodate new requirements — take a look at Slack’s overhaul from August 2023 for example and the reasons behind their decision⁸.

You can think about this evolution as an array (1 dimension) that grows into a matrix (2 dimensions), a cube (3 dimensions) or… even a hypercube (4+ dimensions). In practice, a (very basic) evolution might look like this:

  • Products = The 1st dimension. It contains the core data of your enterprise application. You’ll most probably start here, with just an array consisting of the most basic information for each product. For the sake of simplicity, let’s say the most important data point is the all-time sales figure.
  • Regions = The 2nd dimension. It aims to give more accurate insights using a geographical segmentation. You now have a matrix, similar to an Excel sheet, showcasing the all-time sales figure for each product line, per geographical region. Previously, your data point required a single coordinate to identify it (the product), now it requires 2 coordinates (the product and the region).
  • Time = The 3rd dimension. Instead of having a single data point for all-time sales that uses 2 coordinates (the product and the region), we add a new one into the mix: distribution over time. Now you have a cube you can slice and dice as needed to get the data you’re looking for — the concept so far looks similar to an OLAP cube⁹ (see below).
An OLAP cube featuring “Products”, “Geography” and “Time” as dimensions
Credit: Cedric Chin / holistics.io

Let’s revert this back to your starting point: you only have the “products” dimension and, depending on their number, you might be tempted to use this as your primary navigation — why not, right? The users will have a quick and direct access to the products they are interested in. The layout you might be tempted to use will also reflect the simplicity of a single dimension. And so on.

Once we get to the 2nd point and add the “regions” into the mix, you realize the layout might need a few changes to reflect a product segmentation by regions. At this stage you might also decide to add some basic filtering and ordering criteria to enhance speed of use and findability. It is also at this stage that you have to ask yourself if a region might evolve into something that’s going to contain more than just product information. And, if that’s the case, shouldn’t they be considered a 1st class citizen in your navigation schema as well? This means you should probably reconsider the navigation structure you were planning for at the previous point. It also means you’ve created a pivot change in your information architecture — this is something that’s definitely going to happen quite often, plan for it accordingly.

Adding the “time” as the 3rd dimension raises a whole new set of challenges. It’s definitely going to be a widely used filtering criteria for many of your product sections, so you have to ask yourself if it makes sense to consider this a global, persistent filter across the whole application or a local, temporary one for each product section. Furthermore, chances are your enterprise application has to integrate with other applications within a larger ecosystem that will, most likely, have a time dimension as well — make sure you aim for consistency between your app and the rest of that ecosystem, you don’t want to end up with a different approach for the same concept, it will confuse the users and put a dent in your application’s usability score.

Care to make it more interesting? 😅 Envision adding more dimensions (e.g. business units, stock management, distribution lines, etc.) and try to anticipate the challenges you’ll be facing at each step. I’m going to leave it at this, but when it comes to scalability for enterprise, you should take into account the following:

  • Try to anticipate the evolution of the data model — look at your competitors, study where the market is heading, get some deep insights and forecasts from 3rd party advisors (e.g. Gartner, Forrester, etc).
  • Leave room for new dimensions to be added and always consider pivoting your information architecture for better discoverability (of the newly added dimensions) and greater flexibility (allowing the user to choose his/her own starting point). Looking at the previous example I was using to illustrate the evolution of the data model, you need to consider both the users that will examine a “product” across multiple “regions” AND the users that will focus on a “region” to examine multiple “products” — offer both entry points.
  • Opt for a versatile layout designed for growth, don’t make decisions based on the current requirements alone. For example, don’t go for a horizontal filtering system because you have a limited set of criteria right now — chances are you’ll have to fit more options when new dimensions will be added → opt for a vertical orientation or a progressive filtering approach; don’t use a toggle / radio button component as the main control for content segmentation in a product section — you’re probably going to need to display more criteria with longer labels when the data model evolves → use a tabbing system instead; don’t use a specific sidebar that serves a narrow purpose — soon enough you’ll have to repurpose it to fit new functionality → aim for a generic, multi purpose sidebar from the start if possible; and so on…
  • Use interaction patterns, technical language and other conventions that align with the market your application is a part of to minimize the knowledge gap between the mental model (what the user expects) and the conceptual model (what you design), and ensure better consistency with other systems (conceptual models alignment).

Match the learning curve

Analyze the existing (or potential) learning curve and give progressive reduction¹⁰ a chance if applicable. It is a tremendous and somewhat risky task to consider but, in the right context, it might yield some interesting results. Therefore, if you have to design a complex enterprise product, with an overwhelming UI, maybe it’s worth investigating this concept.

Progressive reduction makes the users’ life easier by simplifying the interface as they become more and more familiar with it. In other words, you reward the users with a much lighter, streamlined interface, tailored to their knowledge and experience over time.

A classic example is the button that starts off with an icon and a label — after the user has made the association between the icon and the label, we drop the label and repeat the process to keep only the icon as an interactive equivalent control to the initial button.

It might also be interesting to use (with caution) if the enterprise app you’re designing is prone to frequent and repetitive use (e.g. on a daily basis, going over the same tasks and executing the same actions).

On the flip side, it might be challenging and costly to implement and / or maintain, and it might backfire if there is too much resistance to change. Choose wisely 😇.

If you found this article helpful, please consider giving it a few claps 👏 . You can also ping me on LinkedIn if you have any questions, I’d be glad to help.

Bootcamp
Bootcamp

Published in Bootcamp

From idea to product, one lesson at a time. Bootcamp is a collection of resources and opinion pieces about UX, UI, and Product. To submit your story: https://tinyurl.com/bootspub1

Ovidiu Boc
Ovidiu Boc

Written by Ovidiu Boc

Experienced product designer on a mission to humanize enterprise and B2B applications... https://www.ovidiuboc.ro/

No responses yet

What are your thoughts?