Building an inspiration board is a key part of the discovery phase.
Inspiration boards help you think about what solutions other people found to similar problems. How did they meet the needs of their users, and the needs of the business?
But the really, really important thing they help with – along with the rest of the discovery phase in fact – is to get you to focus on outcomes at an early stage.
Basically, why are you even doing this thing? What are its measurable outcomes?
Note the use of “measurable”. Yes fair enough, think about outcomes; but you absolutely need some way of knowing whether those outcomes have been successful. We want this thing that we’re doing to encourage more high quality postgraduates to come to our University. So does this thing that we’re doing actually achieve that aim in a way that we can somehow quantify?
I never said it would be easy(!) but at least we’re asking the right questions.
Using measurable outcomes as a starting point and not an endpoint is a key tenet of Lean UX. But it’s pretty common sense, really.
It’s absolutely essential to involve your key stakeholders in the inspiration board process. Get their feedback. What do they like? What do they think?
It helps everyone focus on why the service is needed, because you can look at what it was that other people achieved. Why do your stakeholders think this thing would be good, and how could you measure whether it is any good?
In our example we found several news sites, and focussed on those elements of form and function which interested us.
We then tried sketching up all kinds of ideas, just to get some kind of feel for what people were thinking. And as a kind of focus for discussion.
What were we looking for from a news site?
Were we even looking for a news site at all?
We found that the process of going through an inspiration board and sketching up some of our own ideas really helped solidify notions such as: Do we want to do the same as other people? If we do, why is that a good thing? And if not, how is what we’re doing more suited to our business needs and user needs?
Looking at other systems can help to because it can create a sense of realism about what is achievable. The more you look at how other sites are built and structured, and how other people addressed similar but different needs, the more you might realise how much time and effort has gone into their design.
This brings us back to a cornerstone of Agile: build something that your stakeholders and users actually want, fast. Preferably go live with it. Then iterate.
Nothing is ever perfect. Certainly no IT project is ever perfect first time. It just needs to be good enough first time. You can always build on that once you have the confidence and buy-in from your users.