1 DKK spent up front will save you 10 DKK in the long run. Basing your IT-projects on the humans who will actually use the solution will mitigate the risk of delays, backtracking, scope creep and budget overflow – and increase NPS (and other satisfaction measures) immensely.
Actually, human-centred design should probably be at the core of all projects for those exact reasons – but I mostly know about IT-projects. So here goes:
Most IT-projects start out with an idea of what kind of solution needs to be delivered at the end of the project. Some of the more fortunate projects have actual requirements or descriptions of what the finished product is supposed to do. Or if you’re using agile development: you have a backlog of epics and some detailed user stories ready for the next sprint. After the solution is launched at the end of the project, many find that even if it meets the requirements or lives up to the original descriptions, it doesn’t quite ‘hit the spot’. It does not actually solve the problem that spawned the project in the first place. It turns out that while the solution might indeed solve *a* problem, it doesn’t solve *the* problem. Or it might solve *the* problem – but not for the people it was meant to help. All the training in all the world won’t fix that. It might help. But it won’t fix it.
Sometimes you realise this before launch. So you change the scope of the project. This cuts into the project plan and messes with the expected launch date. Features need to be recoded or added (extra time needed for development and test) or removed (time wasted on development and test). Usually those kind of changes don’t sit well with the existing architecture. So the design needs to be ‘re-architected’.The carefully balanced project triangle is disturbed when the scope is changed: Do you change the deadline or can you find additional resources? Otherwise you end up compromising the quality of the launched solution.
In hindsight when looking back over the requirements or user stories on the launch date you often have to credit some of them to ‘it seemed like a good idea at time’!
So how can we minimise the number of ideas that don’t stand the test of time? How can we make sure we are solving the real problem for the right people? How can we upset the project triangle as little as possible once the ball starts rolling?
By putting users at the very core of the project: user research and evaluation with users should drive all aspects of your project.
Start by figuring out the real problem. Not by inventing a solution, though. People don’t want an app. They want convenience. People don’t want a chatbot. They much prefer to figure stuff out by themselves. You are not your user! Your chief of marketing is not your user. Observe some of the people you think will use your solution. Who are they? What are their needs? When do these needs arise?
“If I had asked people what they wanted, they would have said faster horses.”, Henry Ford allegedly uttered. And Steve Jobs claimed, “People don’t know what they want until you show it to them.” So why should you talk to your users?! The operative word in both quotations is ‘want’! Talk to them about their goals. Observe their pains. What people say and what they do are two very different things. Once a user has figured out a work-around, it’s no longer a problem – if you ask them. That doesn’t mean there wasn’t a pain there to begin with. Figure out what they actually need and when. Then you or your designers/developers are free to come up with ways to fulfil those needs in ways that users could never even imagine!
Let your ideas run wild for a while. Validate your them against the goals for the project and your company’s vision. Ultimately, you decide what shape your solution will take. Once Henry Ford decided that a car would be the best way to fulfil his potential customers’ need for faster means of transportation, he also decided: “Any customer can have a car painted any color that he wants so long as it is black”. Once Steve Jobs decided to offer a user friendly, no nonsense laptop, he also decided he had to restrict control of the machine’s core functionality and to screen it off from user intervention.
“How much is all this user research going to delay start of development?” , I hear you ask. Just long enough to make you confident in what problem you are solving. Experience shows that extensive analysis of use context and establishing project scope *early* will mean 30-50% risk reduction and 10-25% savings on total project costs (see sources at the bottom of the article). If you’re doing agile, you not only do incremental development, you should also do incremental research and validation to ensure the acceptance criteria point to a solution that will be of value to your user.
“Be stubborn on the vision, flexible on the details”, says Jeff Bezos. So once you’ve come up with ideas for solutions that fit your vision, test them with your intended users. Test them on paper. Test them on wonky wireframes only held together with string and tape. It doesn’t have to be pretty – or expensive. Again, with agile you are given something to test after each sprint: the features that are demo’ed anyway. One of agile’s strengths is putting something tangible in front of users so they can assess it. It also puts tangible stuff in front of internal stakeholders so they won’t be surprised over the direction the solution has taken once launched.
It doesn’t even have to be a direct test: if you want to keep your ideas confidential, there are backhanded ways of eliciting user reactions to your ideas. But do evaulate them with real users! It is the only way to ensure that your project is based on knowledge rather than intuition.
Through early testing you can actually get a handle on the overall design concepts before even a single line of code is ever written! You can test whether a potential feature will be of value to one user or to most users. You can test if the terminology you use, can be understood by the people that need to understand it. You can – and should – test all sorts of things. Tests can be as big as a comparative diary study over a number of months or as small as asking the woman in reception her opinion on a mock-up of a screen layout.
Insights into user needs should not only help you decide which features to include. It should help you prioritise them. It should help keep your solution design within the boundaries of the project budget and the original vision. If you document your insights properly, they might even give you a head start on your next projects. Users and their needs don’t change so much (just ask Maslow!) – but their context might. So, by all means, reuse insights about your users across projects – just remember to validate them.
You might already spend money on ‘user experience’ – but you need to consider when to spend money on ‘user experience’. Correcting errors at the beginning of a project is so much cheaper, than correcting them at the end – or after launch. Rather than: ”I’ve spent 10% of my budget on UX. What did that get me?”, you need to say: “I have 10% of my budget for UX. How do I get the most from it?”. Furthermore, by spending around 10% of the project budget on user experience before any coding has begun user satisfaction will increase on average by 135% (see sources at the bottom of the article).
By putting human-centred design at the core of your IT-project, you don’t waste time and money developing features that will never be used. You will not be swamped by change requests after launch. You will – in all likelihood – have created a solution that ‘fits’. That is, a solution that is of value to both you and your user.
Want to know more: