The enterprise experience

Enterprise UX: An inauspicious past

I’ve had the pleasure of working on many enterprise software projects ranging from engineering and science to education and oncology. The patterns and problems that I experienced in these projects were on the whole remarkably similar, and mirror those experienced by many others working in enterprise software development. Sadly, this type of software can appear far from the mark when it comes to a good user experience. Lack of investment, many years of bolted on features (‘growing organically’ as I call it), an unmanaged backlog, out-dated or un-scalable architecture are common culprits. A further reason usability has been less of a priority with enterprise software thus far, is that the person buying the software is not traditionally the person who uses it. Features trump usability because features sell; users get what they’re given.


With this inauspicious reputation, when an enterprise software house decides that they want to get in on the act and invest in providing a better experience for end users, we rejoice. However, there are often misconceptions about what an improved UX actually means for their products. Planning meetings containing statements that a product needs to be ‘sexy’, ‘cute’ should be familiar. Or that it should contain social elements in order to seem more ‘fun’ to encourage users to engage more with the product.

Now, I have nothing against ‘sexy’ at all. Moments of delight have their place, and for the bulk of consumer software out there this is what we aspire to. However, this type of engagement is much less desirable for software that is used principally as part of a person’s profession: to do a job and achieve a necessary goal. A radiologist using software to diagnose and determine treatment for cancer patients isn’t in need of software that is primarily ‘delightful’. The pilot looking up landing checklists or airport plans on a Surface in a commercial cockpit isn’t really in need of ‘sexy’.

So, what do enterprise users need? 

Broadly speaking, this can be distilled down into three key aims:

Feeling in control: Users want to feel that they know what the software is capable of and how to accomplish the tasks they need to do using it. I’ve seen several instances now of users building independent communities centred on sharing workarounds for tasks where they lacked confidence in the provided software solution.  A user-centred approach with key user groups is hands down going to be the best way to identify requirements, processes and restrictions to minimise functional problems and increase confidence in the solution.

Reliability: It goes without saying that software needs to be a reliable work partner: robust, scalable, secure and relatively bug-free. Data is securely stored, performance is good and consistent, and nothing goes ‘missing’. This need can be met with a full and robust testing regime during development and any subsequent updates, a good change control process and a strong underlying systems architecture.

Om: Enterprise users may already be dealing with stresses relating to the day-to-day of their job; they don’t need the software they use to add to that. Performance problems, an overly complex or unnecessarily fussy interface can lead to the software being another problem to deal with rather than a cooperative work partner. Design around the tasks that need to be accomplished and keep the interface simple and functional. Chill it out. 


I’m not saying enterprise software can’t have some small moments of delight, nor am I saying it has to be staid and dull, but the primary needs of the users need to be met first and that, for the most-part, is to make it work, and make it work well.