Including user experience in software development is now common practice in the development of consumer products, but many software development projects in the enterprise sector still fail to include it.
Why is this?
LACK OF AWARENESS
In many cases, these projects are being managed by business people, with little or no prior experience of delivering software.
In other cases, projects may be run by an I.T. function that has lots of experience in the delivery of large-scale infrastructure projects, but little expertise in the delivery of end user interfaces.
WE HAVE ‘BIGGER PROBLEMS’
Enterprise software projects typically have significant challenges with scale, complexity, performance and security. All of these are important problems and must be attended to, but they can make the UI seem like a minor inconvenience in comparison.
However, whilst a failure in any of these areas would be disastrous for the project, delivering a mediocre UI can also seriously impact success: increasing the costs of training; slowing adoption; reducing data quality; impacting staff morale; and increasing staff turnover.
IT WILL SLOW US DOWN
A common response to the idea of including user experience in a project is that it will slow things down: surely creating designs and seeking feedback from users at the start of the process means delaying the start of the build, which means delaying the end of the build?
There are several fallacies at work here.
- That the length of the build process is fixed and can be accurately predicted. Software projects are notoriously unpredictable and can be delayed for many reasons.
- That starting sooner means finishing sooner. Experienced managers know that taking time to plan properly up front can save weeks of effort later.
- That completing the project on time is the key requirement. Being on time is useless if you build the wrong thing.
The user experience process is unlikely to slow a project down and getting user feedback early can end up saving weeks or months spent building the wrong thing.
Doing design work up front also helps everyone on the project to understand what they are trying to build, improving communication and helping projects run more smoothly. Design can also be seen as a form of planning, helping those on the project to prioritise
IT’S NOT AGILE
Occasionally, a project group will take the view that, because they are doing Agile development, design and user experience is unnecessary; or even that these methods are contrary to Agile.
Agile helps to reduce project risk by building functionality incrementally, and practicing continuous integration and continuous deployment, so that a working version of the product can be demonstrated at the end of each sprint. This allows for regular reviews and feedback, steering the project as it runs.
Far from being unnecessary or opposed to Agile, user experience can act as a useful accelerator: design work before the first sprint helps to set the overall direction, ensuring that the big picture is considered and feedback is gained before a single line of code is written.
Design can also help to make individual sprints more efficient by giving everyone a clear picture of the deliverable for the current sprint and thinking through the general direction for the sprints to follow. Again this allows the project to gain feedback from stakeholders before the code is written, steering the delivery and improving the likelihood of getting good feedback once the working version is ready.
WE’LL GET FEEDBACK IN UAT
‘User Acceptance Testing’ (or UAT) is a common step in project delivery, where a nearly-complete version of the product is given to a select group of users late in the process. This allows them to report bugs and provide feedback.
However, it’s far too late in the process to make major changes, so we should take the naming of this literally: can we get users to accept what we are going to give them, or do we have to make some tweaks to appease them?
Don’t get me wrong, trialling software prior to launch is a good idea, it’s just that getting feedback earlier in the process is an even better idea.
THE SOFTWARE IS ONLY INTERNAL
In essence what this means is that, whilst good design and usability might be worthwhile when making software for customers, it isn’t important when building solutions for staff.
It means that you are happy paying staff to waste their time using inefficient software; happy to invest weeks of time training them to use unnecessarily complex interfaces (and maintaining that cost when dissatisfied staff leave); and happy to pay for extra support staff to resolve the problems that will arise.
Presumably, it also means that you are unaware of the concept of an employer brand: what does it say about your company when you aren’t willing to invest in giving employees the right tools?
WIREFRAMES AREN’T DETAILED ENOUGH
For many of these projects, the current modus operandi is the creation of huge lists of requirements in Excel, or bulky requirement specifications in Word. In comparison to a 175-page document full of minute detail, drawing a few pictures of what the user interface could look like can seem a bit childish.
However, there are a number of fundamental challenges with the traditional approaches to documentation. Chief amongst them being that they are not readily consumable by ordinary mortals (who are typically the people you are going to be working with).
Whilst wireframes may seem overly simple, they are a fantastic tool for expressing the requirements to everyone involved, because they are simple, easy to follow, tell a story, and focus on the core use cases – the ones you have to get right, rather than getting mired in the thousands of edge cases and failure states. Wireframes aren’t a replacement for requirements, but they are a hugely valuable addition to them.
WE ARE BUYING IN A THIRD PARTY SOLUTION
The reality for many enterprise projects is that they are not actually building a UI. Instead, a third party solution is being adopted, and the focus of the project is on deploying that solution; integrating it with other internal systems; and customising it to fit the specific needs of the business.
However, even when a third party solution will be used, this doesn’t imply that user experience is irrelevant.
When choosing a vendor, it would make sense to analyse the quality of the UI solution on offer and factor that into the decision, alongside considerations of cost, performance and security.
There may also be significant flexibility in the way in which the solution can be customised. Products like SAP and Oracle effectively provide a toolkit from which the UI is built. Whilst the elements within the toolkit may not be ideal, there is much to be gained from creating the best possible experience using those elements and user experience designers can help with this.
Unfortunately, using a third party solution typically means delivering a relatively poor experience to users, but it is a reality that cannot always be avoided.
CONCLUSION
The user experience process can help to reduce project risk; improve communication within the team; reduce overall delivery time by reducing the need for rework; and improve the quality of the final deliverable.
It can also help to deliver a product that works better for end users: reducing the need for training; reducing the task time; improving morale and retention; and helping to improve the company’s brand.
The question you should be asking is not: “why do I need UX?” But: “how do I justify not including UX in my project?”
Martin Colebourne 