Welcome back to the fifth part of our series on creating more consistent results from UX projects. The previous parts of the series can all be found under the UX Daily tab on our website. Today, we’re looking at what we do after we’ve ranked our ideas, agreed on principles for design, storyboarded our ideas and told a story based on them and we’ve collected some data.
Solutions from Review
You’ve defined a business problem and focused on it. You’ve got some original ideas and you’ve tested those ideas with your users. What comes next? It’s time to review your ideas with a certain amount of vicious detachment.
You need to look at proposed solutions and ask do they really meet the business needs? If they don’t meet the business needs the user experience is going to pretty much irrelevant. Creating stuff for users is a good thing but each time we invest effort in developing something; there needs to be a payoff for the business at large. Will this increase sales? Will it reduce customer care calls? Will it improve conversion rates?
Author/Copyright holder: Michael Cardus. Copyright terms and licence: CC BY 2.0
You want to get your data and see how the data supports your conclusions. You’re trying to eliminate the “gut instinct” part of design; how does the data show that you’re likely to achieve that business objective? If it doesn’t, what else could you do instead?
Go through each step of your storyboard and put it to the test. When you find that you’re falling short of achieving the business objective – revise the idea or replace it with another one.
You may find during this process that there are moments of irrelevance; for example, you might find yourself drawn into a discussion on how a colour scheme will help you meet your objectives. Don’t touch on these more aesthetic problems in this review – they aren’t directly linked to meeting objectives and there’s a great degree of subjectivity (and indeed science and pseudo-science to be called upon too) in these areas. Put them to one side and address them in another forum. If the question can’t be directly related to business objectives then it doesn’t really need answering immediately.
Author/Copyright holder: Ben Holliday. Copyright terms and licence: CC BY 2.0
Once you’ve ticked the business objectives off your list. It’s time to go back through the process and use all that lovely data you captured from your users – to ensure that the process also meets user objectives (it’s unlikely that you will achieve a business goal if the user doesn’t engage with the deliverable – that’s what UX is all about after all).
Summary
This process of revision is a key one. There should be no “sacred cows” when it comes to making UX design decisions; even if everyone loves an idea if it can’t be shown to support the business and user objectives it probably doesn’t belong in the project. A certain ruthlessness is required to make the best out of this process and a strong shared team understanding of why can help you get the right results from reviewing and creating ideal solutions.
Header Image: Author/Copyright holder: UX Pin. Copyright terms and licence: All rights reserved. Img
