Why is user experience important to the enterprise?

All enterprises, regardless of their industry, are seeking to maximise the output of their efforts whilst reducing the effort in creating the output, basically, creating ‘more bang for their buck’, which is why the inefficient, difficult-to-use and expensive-to-own applications they commission are such a bone of contention.

But, why historically does this process always tend to go wrong? The stakeholders outline their needs and hopes, the business analysts look at the processes, the system and data architects figure out the technology and topology, the project manager organises everyone, the developers build the solution to the specifications they are given, and everyone involved is world-class at performing their jobs. The end result should therefore be a world-class piece of software.

However, it is often the case that the intended performance targets are not being met, users are complaining it is difficult to use (even though they have each been given an online manual and training on the new tool), and all involved parties are pulling up their drawbridges, manning the battlements and preparing for the inevitable ‘blame war’.

Even if you think your business has a perfectly enlightened, easy-going, blameless culture, where everyone is part of the team, all pulling in the same direction, all sharing plaudits and successes as much as critique and failures, in reality, this is very unlikely to be the case. Inevitably, many projects tend to not live up to expectations, and in the full analysis, terms such as ‘wasted resources’ (in relation to time and money spent on the project), ‘responsibility’ (relating to the idea of a single failure point) and ‘fix’ (in terms of putting things right) will be floated. History is littered with a litany of failed IT projects which need to be justified if not to the CEO, then at least to the shareholders.

Knights in shining armour

Against this backdrop of disillusioned users and below-par performance, help is at hand from specialists who are trained how to extract the insights of how a business operates, examine software issues and the way people work in a way that other professionals haven’t been trained to do.

User experience (UX) designers are intrinsically problems solvers and they are very good at it. They take a holistic view that many other team members on a project don’t do. The UX team focus on specialty tasks, and organise that view in a way that works not only for the project at hand, but also the future development and evolution of the project.

Having UX professionals involved in the project from the very beginning brings a list of quantifiable benefits over and above the wider programme of software development in an enterprise, not just on one project, but for the entire enterprise:

Consistency
The UX team will recognise elements from other projects they have worked on and be able to utilise transferable knowledge, solutions, techniques and processes that will be easily incorporated. 

Re-usable patterns
Although it may seem obvious to create a catalogue of elements to be used in interfaces, or of the code to undertake repeatable processing, it is surprising how often this isn’t codified in an enterprise’s software development programme. This is a natural instinct for the UX team as they are able to look outside of the project silo and cooperate across the whole of the enterprise.

User engagement
Studies consistently show that happier staff are more productive. However, businesses often misinterpret this to mean providing better food in the canteen, or subsidising gym membership, whilst failing to notice that the real cause of poor engagement is more likely to be the tools they are required to use. More often than not, these tools are cumbersome, difficult to use or simply unfit for purpose. Engaging with the users to discover where they experience their biggest work issues, UX teams help prioritise the most important problems to be overcome and improved. 

Accelerated adoption
By involving the end users of the new tools in their design and development, a UX team can ensure that any changes, new features, new ways of working or automation makes practical sense to the user. If the user sees the benefit of such changes because they were involved in making them happen, they will embrace them more quickly. It is human nature which makes us all wary of trusting new things until we try them, but we’ll happily carry on using them if they allow us to achieve our goals and objectives.

Increased productivity
As a result of the work with the users, the UX team will be able to design solutions that shortcut or automate certain processes, including any necessary checks and overrides, ensuring that repetitive, onerous and tedious tasks can be eliminated or minimised. This, ultimately, allows users to get more done in the same amount of time, creating an increase in productivity. 

Decreased cost, increased profit
Whilst the act of adding a UX team to an enterprise may initially seem like an expensive option, over time the team will create extensive benefit and efficiencies. The UX team will provide consistency, re-usable patterns, focused problem solving through user engagement, and accelerated system adoption by end-users, leading to increased productivity much sooner than otherwise possible. In the medium to long term, this turns the investment into a positive benefit, rather than an expense which can be demonstrated against defined key performance indicators.

Speed to market
User experience teams tend to think in defined stages for each part of a project, culminating in the minimum viable product (MVP). However, the MVP is not necessarily an entire tool or software product that replaces an existing platform like-for-like with no new or additional features. The MVP may only replace part of an existing larger solution, but does so for the entirety of that part, so that data fed into the new MVP solution, its processing and ultimate output back into other systems, is able to happen without interruption to the overall business process and with no loss of quality.

In this way, replacing an entire system can be broken down into discretely deliverable stages that have the potential to deliver the desired business improvements in rapid succession, reaching the market more quickly than a monolithic system replacement project. This also means managers can be measured on a series of short term goals that lead to the longer term KPI success.

Development roadmaps
Keeping track of which features, improvements and automations are planned in a project (and when they are due to become live) could be the task of any number of contributors, from the project manager to the business analyst. However, it is unlikely, that while delivering their specific day-to-day roles they would be able to take on the additional tasks required, such as maintaining the complex relationships between the design system, the pattern library, and the needs and requests of the end-users and the business.

This is something that UX professionals are superbly equipped to do, since they are able to determine where in the development timeline the boundaries between stages exist, prioritise which elements might need to be advanced or held back as the needs flex, and draw up the development roadmap to show where each element fits together. In this way, everyone else on the project can continue to focus on their areas of expertise and their own delivery.

At the same time, the UX team will naturally also be thinking about the ultimate vision of the complete system, and how shifting requirements in markets, technologies or unforeseen circumstances might affect the timeline, such as with the Covid-19 pandemic. This disruptive example caused major issues for the unprepared, with major changes in user behaviour creating the need to completely re-evaluate the work to date, determining what is still applicable, what can be adapted and what needs wholesale replacement.

As part of their natural approach, the UX team will also put together a list of possible future features and functional improvements that haven’t even been requested yet. This thinking depends on the current scope of work that influences future timings and the impact of what is currently in scope and what the future could bring. 

In conclusion…

Armed with this list of concepts and this approach, you could engage an existing enterprise development team and ask them to implement this way of working; it may even work for a while, but eventually team members will become focused once again on their core competencies. The proposed new tenets and approaches will likely fall by the wayside, and the project will fall back into the historic pattern of delivery. The stone walls and drawbridges of the ‘blame war’ castles will slowly be raised once again as the project fails to stay true to its goals and age-old divisions and defensive behaviours re-establish themselves.

Unless, of course, your enterprise employs a skilled UX team who can ensure the project is implemented and managed in a far better, more intuitive way.