Exciting stuff, huh! There’s no gags, puns, alliteration or other clever stuff in the title of this blog because it’s time to talk risk management which is – as you know – a very boring serious matter. This blog looks at user experience strategy as a risk mitigation tool for web and software projects.
User experience is often miscast as usability or user interface design – which sound a little bit non-essential and nice-to-have. Yes, UX encompasses those things but it’s the whole process that is important and sometimes misunderstood. It’s about getting the deliverable right so I’m not going to talk much about usability or user interfaces here, just plain old projects. And with projects come risks. Sometimes risk is all that people understand and if you’re a fan of the psychology of behavioural economics then you’ll know about loss aversion. In plain English, that means that people are more likely to be motivated to act if they think they will lose something than if they think they will gain something and risk is usually about losing something. Which is why everyone loves, or rather hates, risk. That includes project managers and rightly so. So, let’s not sell the benefits of a user experience and instead sell the risks of not doing it.
Every project pack worth its salt has a list of risks and mitigating actions to ensure project success. Risks come in many flavours but can include issues such as poor user adoption/loss of confidence, regulatory breaches, costly errors, loss of revenue, loss of reputation and so on. Those risks can play out both internally and externally at an organisation and everyone wants to get the project right. So, how do you get it right? You go to the business or customer, ask them what they want, write it up in to a 72 page document, ask them to review it (which they don’t), call a meeting to talk them through it, chase them to sign it off (which they do – because they want the project done), maybe write a functional spec, hand it to the developers, months go by and, fingers crossed, test against the functional spec and done!
That’s a cynical but not wholly inaccurate take on the so called ‘waterfall’ software development method that has a linear set of steps. Best of luck to everyone involved. Unsurprisingly, it often doesn’t deliver to expectations. People are now starting to turn to ‘agile’ because of this very fact – they have concluded that waterfall doesn’t work. Agile is an iterative, little and often, show-and-tell approach with lots of questionable terminology (‘sprints’, daily ‘scrums’, ‘war rooms’) to make the new thing sound clever. Naturally if you show a system bit by bit to users then you can clarify the direction of development which is great to ensure correct delivery but it can be hard to control scope and get the thing finished. It’s also fun and removes planning and documentation so those that like to avoid such things love agile. In other words, it manages some risks but raises others. In some cases agile might work well, especially for an innovative piece of product development but for many projects it just misses out the steps and the clarity required to get things done properly, hence it’s often dubbed ‘fragile’.
So, nothing works. Ok ok, I’ve been rather unfair about both these methods but the methods aren’t the point – the approach is. I know waterfall can work well and someone must have seen agile deliver to keep on doing it. However, the fundamental issues when projects do go wrong are simple – not getting the requirements right, not getting the design right, not getting sign-off right, not doing testing right, not communicating right. I’d love to see these risks in a project pack – instead of lack of resource and the usual ones PMs feel they ought to put in.
This is where user experience design proper is meant to help: UX is doing waterfall or agile or whatever, right. A user experience approach entails getting into the shoes of the user, identifying the types of user you have and noting their needs and preferences, observing them using a current system or process, interviewing them, understanding their decision-making processes, etc. It doesn’t have to take that long but proper research needs planning in to the project. Once you start to gather this information you can clearly map user types (personas) to processes and draw visual diagrams to represent this alongside written scenarios. These are the sort of documents that users will understand – and will sign off for real. Requirements done then you can start to design to these requirements through standard techniques such as wireframing (as well as functional specifications). There might also be a need for information architecture to help organise and label information in the most useful way. This information should feed into the wireframes and a site/app map if required. A visual design exercise may then come into play (especially if it’s a web application). Again, visual designs can be signed off by users before commitment – even if the build has started. Use workshops to present and validate the design, not to brainstorm and put the onus on the users. Tweak it and build it and test it, against the functional specification but also against the scenarios and get the users to run through the scenarios – and observe them. If it’s not obvious for them to use then it’s a problem. Dig deeper and make changes before final testing commences. Write a Quick Start Guide to help people understand the capabilities. Again, ‘test’ it with a few users.
What’s good about this approach is that the users are engaged throughout the process to mitigate against the risk of designing to abstracted requirements. The users are also involved in the design, sometimes in the information architecture or sometimes in discussing options around wireframes and designs. There will be few chances for surprise and disappointment. Also, with a defined set of users you’re doing change management by engaging them and getting them to sign off on tangible deliverables, helping to communicate the change and helping them to own the design. In other words, the chances of adoption are greatly increased.
So, UX helps you get the system right because website or application building is a design process that needs to go through steps. When you use words like architecture, design and build then the clue’s probably in the metaphor – it’s not too unlike building a house. Waterfall and agile are sort of besides the point. Only the largest corporates are beginning to understand the need for UX for software projects but you’ll see this approach catch on hugely in the next few years so it’s worth catching on before you have to catch up.