Six Cardinal Rules of Designing for the Enterprise
As someone entering their 20th year of design consulting, I’ve had the chance to work across a wide span of projects: from simple consumer apps to large, complex enterprise systems. My heart, however, resides with those sometimes-pesky, always-interesting enterprise applications. I love the design challenges and having the opportunity to transform peoples’ work lives.
Along the way, I’ve developed six cardinal rules when designing for the enterprise. These rules are by no means a set of comprehensive design practices, but they are key elements that I’ve found lead to more successful design outcomes.
What is an Enterprise System Anyway?
First, I’d like to define what I mean by enterprise system, because the definition can be fuzzy, particularly with the consumerization of IT. I make a distinction between more general-purpose applications used in an enterprise (for example Microsoft Word) and what I consider to be “true” enterprise systems (for example, a claims management system). To help illustrate the distinction, the matrix below plots applications along two dimensions: whether the application is broadly functional or serves a specialized purpose, and whether the application is exclusive to an organization or more widely available as commercial software.
In this article, I am focused on the lower two quadrants (quadrants 3 and 4) of the matrix — applications that are suited to a specific business purpose and are often used by subject matter experts in a particular business domain.
Overall, “true” enterprise systems support the more mission-critical aspects of a business. The users are typically captive meaning they aren’t able to perform prescribed tasks outside of the system intended to support those tasks — and the tasks themselves are often part of a larger overall business workflow. These systems might include those that help users monitor network operations, perform legal discovery activities, process loan applications, or manage a surgery center.
The Six Cardinal Rules of Designing for the Enterprise
- Accept and embrace the primacy of business goals
- Design for the people who will use the system as well as the people who are ultimately served by the system
- Use validated scenarios to drive design
- Obtain real-world data — and don’t design without it!
- Create an experience that is consumer-grade, not consumer-like
- Design for task intensity and frequency
Accept and Embrace the Primacy of Business Goals
The user experience (and user research) is critical, but ultimately enterprise systems exist to support the needs of the business. Users may have thoughts and opinions that are at odds with goals that the business has established. In some cases, you may be designing a system that fundamentally changes (or eliminates) somebody’s role in an organization. This situation is never comfortable, but if you are designing for the enterprise, it’s a situation you may have to accept.
However, that’s not to say you would ever suppress what was discovered in user research. Findings can absolutely influence business goals, and you have a responsibility to bring forward the perspective of those currently “in the trenches” to team members or executives who may not be fully informed of all the factors to consider.
For example, I was working on a system that in its next generation would have an automatic dispatch function for field crews, replacing the current process based on radio communication between a dispatcher and crew member. However, the work that crews do is physically and sometimes emotionally demanding — and they often work alone. For crews, it was clear how vital social contact with the dispatcher was to them. This finding probably wasn’t a new revelation, but formalizing it pulled this factor into the design process. There was a risk that an already challenging job would become even less attractive, which could increase turnover in the role. Having spent time with crew members, I had great empathy for them, but I chose to frame the problem in business terms.
Design for the People who will use the System as well as the People who are Ultimately Served by the System
Enterprise systems are often used to serve others — for example, a claims processing system exists to serve those submitting claims; a utility’s network management system ultimately serves customers receiving service from that network. Even systems that are seemingly entirely internal, such as a cyber risk management system, often have internal customers (such as board members who require cyber risk updates).
It is essential, therefore, in the design process to consider the needs of those receiving the service or information provided by the enterprise system. For example, during a service outage, utility customers have a high need to be informed. While the network management system needs features that help engineers quickly restore service, at the same time it needs to communicate status out to customers.
Often this requirement results in a system having some type of customer-facing portal (or automated communication out such as via email or social media). However, even if the system does not have an external-facing component, understanding the needs of those served can impact design. For example, when working on a call center system used for a national smoking cessation program, inbound callers were stressed and fighting addiction. While there was a specific protocol of intervention, “quit coaches” needed to be able to go off-script or otherwise get through the protocol in unpredictable ways. We mapped a set of keystrokes to the data they needed to gather during the call so it could be quickly entered in a non-linear, ad-hoc way. Sure, this made the quit coaches job easier — but the driving factor was to better-serve individuals who were struggling to quit smoking.
Use Validated Real-World Scenarios to Drive Design
In the enterprise, the context is often highly specialized — and as a designer the domain may not be immediately (or ever entirely) understood. I am not a network engineer, an attorney, an earth scientist, or an industrial coatings specialist. Yet, I’ve designed systems for all these user types and the context in which they work.
How is this even possible?
Here subject matter experts are your best friends. Engage them early and often!
A key method is scenario-based design: identifying the key usage scenarios and writing them out as narratives. Authoring narratives accomplishes two things: a) it pulls you into the domain’s specialized world, by actively engaging with how work gets done and b) it gives you an artifact you can review and revise with your cherished subject matter experts. Through the iterative process of scenario development, you will both travel up the learning curve and create a solid foundation for the design.
There are necessary predecessor activities to creating these scenario narratives: interviews, observational research, current-state journey mapping, future-state journey mapping. I think of the scenario narratives as a “slice” from the future-state journey, providing more detail, more context, and more storytelling of how the work its future state will be accomplished.
Obtain Real-World Data — and Don’t Design Without It!
Some of the worst mistakes and poorest assumptions I’ve seen with enterprise design work is the result of using placeholder, made-up, or otherwise non-real world data. Purely from a screen design standpoint, you need to make sure that layouts work for the data as it really is. (And in the enterprise, real data is often a lot messier than one would expect.) However, more importantly, using real-world data forces you to engage with and understand the data. Without this understanding, you risk falling into false design assumptions.
Sure, it’s a lot easier, especially in the early phases of design, to skim on representing data accurately. However, the longer you wait to use real-world data, the higher the risk your carefully-crafted design is, in reality, a house of cards.
Create an Experience that is Consumer-Grade, Not Consumer-Like
If you’ve done any design work in the enterprise, you’ve likely at some point come up against the following:
“I want <name of enterprise system> to be just like <name of favorite consumer app>.”
— Big Important Project Stakeholder
The way to reframe this is to think in terms of creating experiences that are consumer-grade, no consumer-like. This idea comes from a talk by Alan Baumgarten at Convey UX, who put forth his definition of consumer-grade:
- Consumer-grade is contemporary. The user interface looks new, modern, and elegant. Styles are regularly updated to keep the design fresh.
- Consumer-grade implies desirability. Professionals often don’t have a choice in the technology they use, but the quality of the experience should assume that they do.
- Consumer-grade is intuitive. Even highly trained professionals should immediately feel comfortable seeing enterprise solutions for the first time; they recognize elements that align with their job. Task flows are sensible and obvious.
I have found these principles helpful in embracing, rather than recoiling from, the “consumer directive.”
Design for Task Intensity and Frequency
In the enterprise, users may be working on the system all day, every day. In fact, their compensation may be in part based on the quantity or quality of work that they produce. It puts a lot of performance pressure on the interface design. Even small design flubs can have an outsized impact…the so-called “death by a thousand paper cuts.”
It is therefore critical to understand tasks at a granular level, particularly for tasks that are performed repeatedly over the day. The depth of understanding required can only be gained through direct observational research.
For example, when working on one high-production system, I set up video cameras to simply record people doing their work. I later reviewed their task performance in detail by slowing down the video playback — and using the video in follow-up interviews with the individuals who had been observed. These interviews provided deeper insights into the current barriers (and some creative workarounds). The findings served as the foundation for re-working how these tasks were performed and dramatically improved users’ ability to do repetitive work.
Conclusion
This article is by no means a comprehensive guide to enterprise system design, but I hope it provides some helpful approaches and spurs your own ideas on how to design more useful and usable enterprise systems.
