Designing within the constraints of enterprise UX.
For the uninitiated, enterprise UX is UX for the internal applications, software, and products employees use. If you work in a mid- to large-size company, you use enterprise applications.
You know where you pull up your pay stubs? Enterprise.
You know where you take those mandatory compliance courses? Enterprise.
You know that antiquated system that you have to use that looks like it was designed in 2002?
You guessed it… enterprise.
“Enterprise UX means managing problems and constraints that you may never encounter in consumer-facing UX.”
Consumer facing versus enterprise
But I design enterprise apps, so when I tell people I work in UX at Comcast, they think I work on this:
But I actually work on something closer to this:
Which sometimes makes me feel like this:
Working on enterprise apps doesn’t make you uncool. In fact, doing enterprise UX means managing problems and constraints that you may never encounter in consumer-facing UX.
And if we love UX, doesn’t that mean we love solving problems? Well, welcome to enterprise UX!
Enterprise UX problems to solve
1. Antiquated, non-functional “legacy apps”
Some of my work is redesigning insanely outdated legacy apps. Now, “legacy applications” aren’t exactly a bad thing all the time. Currently, Apple keeps asking me to “upgrade” to High Sierra, but I’m passing on that until some bugs get figured out. In this instance, I’m choosing to go with a “legacy app” based on the Wikipedia definition.
With enterprise, “legacy” refers to products, applications, and software that are either no longer or minimally supported. For example, 52% of companies are still running Microsoft XP and Vista.
Some enterprise applications are even older and were created without consideration for affordances or any thought of how a user will interact with the product. These apps were built choosing function over design. Sadly, sometimes these apps don’t even function.
Scenario: There’s a new framework being implemented that will change the UI of some legacy applications. Let’s get you, a UX designer, in here to work on this!
You then have to explain that you are not just going to adjust fonts and colors (more on this later) and dive into your UX process, validating (and sometimes invalidating) requirements ensuring that this legacy app is now not just more aesthetically pleasing but users understand how to use them (bonus points if users also enjoy them!).
2. Managing all types of platforms, systems, and software
Enterprise UX means you have to design to ensure integration across various platforms, frameworks, and sometimes software. In enterprise UX, big companies buy lots of different types of software and the consequences of integration aren’t considered.
But it’s a UX designer’s job to decide (within constraints) how to make sure the interaction will work across all these frameworks.
Recently, I completed usability testing for a redesign we’ve worked on where there are 2 searches competing against each other (one of them OOTB).
This was confusing users. Part of the work is figuring out how to possibly suppress the OOTB search while making recommendations on placement of the search we want users to select.
3. Back-end developers may not be able to help
I was designing a form and I needed fields to only be shown when relevant. But the project didn’t include back-end configuration work, so I needed to redesign within those constraints. The conversations I had challenged my development team to consider what they could do on the front end. They couldn’t build the form according to all my design specifications, but driving UX process made the form infinitely better.
4. Designing for pro and general users
I designed an application for 60 HR pro users. I broke conventions on nomenclature and jargon because after doing user interviews, I knew I could. Other apps I work on touch 90,000 employees. One of the advantages of enterprise is that you have a guaranteed customer base. You have the monopoly! They have to use you!
So design it right. Not because you have to—but because you should.
5. Getting understanding and buy-in of UX
This is the big one. Unlike my consumer-facing design counterparts 3 floors down, enterprise UX includes the need to ensure “buy-in.”
Enterprise UX is changing and developing, so your product owners may not totally “get it” early on—you have to explain to them that following a UX process will yield desirable results.
When I started at Comcast, I needed to explain—and more importantly demonstrate—what UX was, how it differed from development, and why it was going to make their app better. This means asking a ton of questions around:
- The requirements that were decided before completing foundational research (oy)
- How the user will actually interact with this application
It also meant sitting in meetings that you may not need to be in but you go to because there’s going to be a powerpoint slide describing an egregious UX fail that only you (the sole user-centered focused person) are going to catch. And fix. And you just changed the direction of the build for the better. #uxwinning
But those moments aren’t always so heroic. Once I designed 3 different prototypes as better alternatives to what the business owner thought we should do. After looking at the additional development hours, a senior leader decided on going with the lesser experience.
So sometimes you lose. But part of enterprise UX is making incremental change—small wins that make the products that employees are required to use better. Take it and keep building.
Big challenges and big learning
Enterprise UX has real, big challenges. Old systems, big bureaucracies, limited UX understanding—but being able to navigate all this and design quality products will make you a better UX designer. With big challenges comes big learning.
So, problem solvers wanted. You in?