Embracing Enterprise UX: Five Essential Practices

Let’s face it - enterprise UX isn’t sexy. You won’t catch a CRM system gracing the front page of awwwards.com. The internet isn’t bursting at the seams with design portfolios full of well-optimised order management platforms. Enterprise UX is as much number-crunching as it is creativity; it embraces a level of complexity its consumer-oriented cousin balks at, and it tends to reside under the allegorical rocks of non-disclosure agreements and exacting budgetary constraints.

Perhaps the main reason behind this lack of glamour is the fact of the captive audience. The user base of these solutions isn’t going anywhere, particularly for platforms like intranets and CRM systems which employees must use to do their jobs. There is no need to scintillate and build interest, to draw the user in or provoke an emotional reaction. So if there is no need for any of these things, why bother investing in experience design at all? It has become a cliché that enterprise UX is a contradiction in terms.

The obvious answer to this question is, of course, money. Improving customer & employee experience makes organisations more profitable. You don’t have to take my word for it, the research is there to back it up – and our Head of Marketing screams it into the void of LinkedIn regularly.

There are also the additional benefits which come along with "doing" enterprise UX; in particular, building a real understanding of employees and customers. These are the powerhouses of any organisation’s success and by happy way of positive externalities, research from enterprise UX projects can surface insights which are useful outside the ivory tower of the IT department.

Enterprise UX: Essential Practices #

So how do we get the most out of enterprise UX? After working in this space for over a decade, there are some simple rules of thumb we still follow.

1. Start small #

Like many good habits, user-centricity is best developed in small, easy-to-maintain increments. Particularly for teams or organisations towards the bottom end of the UX maturity scale it can be a daunting prospect deciding where to get started – especially where there are new skills to learn, or key stakeholders who remain unconvinced of its value.

In scenarios like this, it’s best to rein in scope and tackle a well-defined problem first, ideally one with multiple avenues for potential solutions. Large, “wicked” problems are ill-suited for an organisation’s first steps into the world of enterprise UX – instead, focus in on individual features or user journeys. Rather than taking on an inefficient order management system entire, try to tackle a particularly annoying search feature or a simple use case first.

This gives your team the opportunity to find their rhythm and build confidence in a context where failure is less likely – allowing your project to act as an advertisement for the benefits of UX more broadly in your organisation. More often than not, research for a smaller project will surface insights which will guide the way to larger user needs or pain points, allowing your UX initiative to grow and evolve organically.

2. It’s a Team Sport #

UX should be performed by a multidisciplinary team. It will not realise its potential if it is confined to a cloistered coven of “UX people” who absorb requirements and emit designs through a mystic and nebulous process involving lots of sticky notes and Murals.

Be careful to include a wide range of backgrounds and specialisms on the delivery team – researchers and designers are of course necessary, but they should be joined by developers, architects, business experts and analysts, marketing aficionados, customer advocates, and anyone else whose expertise might contribute towards improving the end user’s experience.

Ensure that the entire delivery team is involved in user research and testing, even if some members are only comfortable participating as note-takers or observers. Run collaborative sessions where observations sorted and solutions are synthesised, and go round the group to ensure that everyone’s input has been added to the collective.

In this way, even if some team members only devote a tiny fraction of their time to the project, their expertise can still drive better solutions through their contribution – and organisational siloes can be broken down as individuals from different business functions work together to uncover and process user insights. This makes it far more likely that the valuable understanding that comes from researching employees and customers can proliferate through the organisation.

3. Involve users early, and often #

It’s not user-centric if there aren’t users involved. Planning for (and more importantly, running) user research at the earliest stages of a project builds a solid foundation of knowledge, ensuring all downstream work is data-driven; if a solution isn’t backed up by research and validated by testing, you are effectively just throwing an idea at a wall and spending a great deal of money on development to see if it sticks.

It’s also important to cultivate a well-honed reflex to “go back to the users” whenever ambiguity or uncertainty is encountered. One of the key drawbacks of the traditional waterfall IT delivery model is the propensity for on-the-fly design decisions to be taken unilaterally by the delivery team. This leads to changes to the spirit and detail of a solution only being revealed to the people it affects during “User Acceptance Testing” – the kind of Acceptance which comes after Denial, Bargaining, Anger and Depression. By validating ideas or assumptions the team isn’t 100% sure about through ad-hoc user testing, bad ideas can be discarded early before sunk cost fallacies set in, and more time can be devoted to the good ideas which ultimately survive through design and development.

4. Trust your users #

UX design isn’t about listening to your users and doing exactly what they ask for – there’s a tired and dubiously attributed quote concerning a 20th-century car manufacturer and horses we might invoke.

User feedback (both from employees and customers) can be vague, unconstructive and occasionally self-contradictory. It’s not the job of the delivery team to question the validity of difficult or seemingly unhelpful observations – it’s their responsibility to parse together the clues and get to the root cause of user frustration.

Often teams forget that software platforms are just a small part of a bigger system or set of business processes which make up the total "user experience" - and it's that holistic view we have to take into account when solving problems for our users.

5. Measure success (and failure) #

To return to an earlier analogy, the worst thing we can do is throw an untested idea at the wall and spend money on development to see if it sticks. A close second is not checking to see whether it has stuck at all.

All user experience projects are fundamentally about changing the behaviour of users in a specified direction – an increase in desired behaviour, or a reduction in undesired behaviour. The hallmark of a well-developed UX team is the ability to analyse and understand how design decisions have influenced user behaviour in the past, and surfacing that knowledge in a way that facilitates better design decision-making in the future.

To do this, it’s as simple as defining a way to measure that behaviour, and take benchmarks before and after we make changes. There are a wide range of UX metrics we might choose, from quantitative measures of efficiency or accuracy through to more subjective, qualitative measures of user satisfaction. In any case, it’s imperative to measure the impact our UX projects have on end-user behaviour, and ideally to have some kind of idea of what success looks like – for example, we might target a 10% reduction in time-per-task. Then, either in the case of success or failure, we can review the design decisions and assumptions we made and move into the next phase with better understanding of what makes our employee or customer users tick.

In conclusion #

The field of user experience is constantly evolving, and often organisations need time and experience to hone their user-centric frameworks and processes – the teams which “do UX” best often never stop refining their UX methodologies. That said, these simple rules will always be useful when considering your next venture out into the wilds of enterprise UX.

If you'd like to understand more about how Boxfusion utilises UX Design processes, Oracle Redwood and how we can help you, please get in touch.