The majority of IT projects fail and do so at an alarming rate. I've been involved in a few hits and a few misses and I want to use this post to talk about one aspect that is crucial in the success of a project - the user.
In past positions I've been a training and implementation manager for a workflow management solution, a product lead for the same solution, and an operations director who has implemented internal and client focused IT solutions. In all of these, user experience (or UX) has been a critical factor in the success or failure of a product. The surprising thing to me is that this should be of no surprise to anybody yet it so frequently is an area of failure. Surely to design a solution without an underlying understanding of the end users is a project doomed to fail from the start. How does it happen and how can it be combated? I can't state that I definitively know the answers to this but I proffer my own thoughts...
Can't see the wood trees for the trees wood
Most IT projects stem from a business need. Something has been identified that can be addressed by an efficient and modern process driven by IT development. There is a big idea - either already in existence in some less efficient form or else a new whizz-bang process/solution for the business. Everyone is excited by the idea of the promised land. The focus is on the bigger picture and the pesky details take something of a backseat. In this case some of the pesky details are the users that will ultimately be working with this new system. But they're an afterthought and, anyway, won't they just do what they need to do to make this work? Implementation is a long way down the line and someone else is in charge of that anyway. Let's just get on and build this thing!
I genuinely believe that a lot of UX failure is, unfortunately, due to this kind of thinking. It's not explicitly stated to disregard the user and to do so would be a shocking admission but on some subconscious level the users, the people who will make your development sink or swim, get left by the wayside until it's too late. Often there can be a core assumption that your development is so important that it will naturally become part of the Standard Operating Procedure and, with that in mind, perhaps the user experience is neglected for the functional requirement of the development. If a user is mandated to follow the SOP then why is their experience a priority? We've got limited resource on a tight deadline - the priority is to deliver a system that functionally does what we said it would do - that is what matters. Isn't it?
Manifestation - the problems and solutions
How does this type of thinking manifest itself? I've experienced this in varying extents in a number of areas but I'm going to concentrate on three that I think are common and key...
Product Design and the User Interface
The problem
From a functional perspective at least, just because something can be done doesn't mean that it should. Too often the user and their journey has not been fully considered at each and every stage of the project design. If your business requirement is only to the expected benefit of the business and not the user then you do have additional challenges to consider. E.g. If the business objective is a compliance monitoring system then be wary of a design that might only ever be seen by a user as an unnecessary box checking exercise to facilitate a big brother approach.
And what of the interface itself? Is it well designed to modern and expected standards? Does it look the part and does it adopt all required and expected modern conventions of User Interface design? Is it easily navigable? Is it pleasing to look at and use?
The impact
In terms of product design sometimes less is more and if the user has not been sufficiently factored into the final functional design decisions then you are running the danger of building a product that functionally works to the expected Business Requirement but is not adopted or usable by the people that are required to run it. Is enough consideration being given to the core objective?
UI consideration (or lack thereof) is an area where I've seen the struggle first hand and it's easily understood. The team is focused on delivering the core functionality. All too often the user journey has been neglected so you can forget about basic front end design, font decisions, use of white space etc. But these things matter and increasingly so as modern design standards increasingly become expectation rather than simply nice to have. If a user doesn't like working within the system you have created then you are facing an uphill struggle for acceptance.
The solution
Consider the user at all stages of product design. It's critical to have user perspective as part of the design team and this should be factored in at the very earliest design stages. Additionally by involving users in the design stage they will feel engaged and empowered and can act as ambassadors of the product to the users that they represent. It's therefore important that the users that you choose for engagement at this stage are not only knowledgeable in their respective fields but are also respected by their peers and will perform a strong positive marketing exercise both in the run up to implementation, during implementation, and afterwards as champions and points of contact between user and product development and implementation teams.
Don't underestimate the power of good user interface design. It's important. It is the first impression a user will have of a new system, and it is something they are expected to work within frequently. Users are accustomed to good, modern design. If your user interface does not deliver that then you are immediately on the back foot. I would argue that you are indicating a degree of disregard for your users. Resource is scarce and deadlines are tight - that's a fact of life. Don't allow shortcuts in design to undermine your implementation.
If your project is not first and foremost to the expected benefit of the user then I would urge that you do consider how you might be able to give back to the user in some respect. Some small concessions to the user will go a long way to acceptance of required business process and adoption of your project. Carrot is usually better than stick!
Implementation
The problem
A new IT project will very often require changes in behaviour and users can be very varied in their acceptance to change. Additionally large business wide initiatives may require different groups of users with differing expected engagements and understandings. It may be that a new solution is entirely disruptive to one group of users but a minor adaptation to another.
The impact
If implementation and training is considered at too late a stage then design decisions may have been made that did not fully consider the user and the users may be put in a position where a new product launch is sprung upon them without sufficient notification to start to move them along the change curve as defined by Kubler-Ross.
Image 1: Kubler-Ross Change Curve
Acceptance of process change and receptivity to training may be compromised. The delivered product may be viewed unfavourably. The implementation challenge will be significantly increased.
The solution
There needs to be consideration and respect as to the extent of change that the project introduces and the impact that this will have on users. In all of this an understanding of change management and an ability to structure training and implementation at the right level to the right people is a critical factor in the implementation process. Product documentation is not an afterthought to be added in later. It needs to be comprehensive, easily accessible and understood, and available right from the start.
Consider how the product implementation can be engaged at the very earliest stage to start managing the required change management process. As with the product design and user interface if you can engage users at the earliest opportunity then they can help be ambassadors for the product and will provide a huge boost to implementation efforts both pre and post launch.
Non-functional expectation
The problem
You've built a system that meets all the stated functional requirements. Well done! But have you adequately considered all the non-functional requirements? How dependent is the user/business on your project? Can they reasonably tolerate any service interruptions that might be required? Is the system stability tried and tested and monitored and are their agreed SLAs in place and KPIs to effective monitor.
The impact
In a worst case scenario if your system is buggy or unreliable then it is hampering the user and the business. There will be very limited tolerance for either.
The solution
It should really go without saying that your delivery must be reliable to an expected and satisfactory degree. Some downtime might be unavoidable but where possible this should be agreed and planned and as minimally disruptive on the end users (and hence the business) as possible. Ensuring clear communication and setting expectation on this front is vital. Have mechanisms in place to notify users of planned downtime and maintenance. Unplanned downtime needs to be considered and the correct level of redundancy and backup applied. Nothing will turn a user against your system faster than it being unreliable and disrupting their work. Prior to release there must be enough testing piloting, and monitoring to move into a full production release and implementation.
Final thought
There are plenty of other reasons why IT projects fail and these UX considerations alone will not stave off project failure but they will certainly help to increase the chances of success.
Nobody sets out to purposefully make life more difficult from a user perspective but at the same time it's all too easy to give them undue consideration in the early design stages. Technical error and user/human error are very different propositions but if you're not focused on the user experience then you are arguably increasing the chance of user error and that points to a failing in your design rather than a failing in the user.
Respect for the user will be paid back by respect from the user.
