In a recent workshop, we were presented this quandary: ‘I get the challenge definition, but how do you nail down a solution’. I’m writing this blog to tackle this perhaps unspoken matter of contention for many working in Innovation and humanitarian programme design.
They hear about organisations such as UNHCR Innovation Service, companies like Ideo talking about ‘Design Thinking’ and think:
“While this sounds very good in theory, how on earth do I apply this in my job/on my project? I want to get moving and make an impact!”
Usually the first step of this process they can get behind (as noted above); work out what the challenge is. Sounds simple enough. By applying some of the innovation methodology this might differ from somebody’s traditional way of doing things; perhaps more bottom-up, and less top-down; perhaps a greater understanding where there are gaps / problems that people are facing, rather than what is important to us but they can more or less piece this together.
Where things get more tricky is as mentioned above how we can move from the arena of challenge identification, towards actually testing some solutions that start at least doing something but ideally make an impact in respect to our humanitarian activities. This is also from our experience where we and many others have become unstuck in delivering a solution.
UNHCR Innovation Service puts forward steps for Ideation and Experimentation that help people through this process and have identified numerous resources to support with this. It is a core part of the Innovation Fellowship; we support our Fellows through these processes and help unpack and explore over the course of the Fellowship different possible approaches to Ideation and Experimentation.
Yet for some these things don’t necessarily seem that concrete for people less familiar with the field. In our blog “What is prototyping anyway?” Sam Perkins outlines a bit about what ‘prototyping’ and ‘rapid prototyping’ practically mean in these Innovation processes / journeys that are often promoted by design-thinking gurus. While this provides a pretty straightforward assessment of what these are and how they apply, we still might be missing some numbers in this game of operational innovation bingo. How can you make that leap between having a challenge, and working out what you’re going to do about it in practical steps?
Beyond the resources outlined above I’m gonna let you in on the approach I take when I’m doing this. I’m going to use quite a bit of ‘tech’ terminology below (as that’s an area I work in quite a bit!) and while they outline a number of steps of what would apply in a software development context, taken in a more general form they can be applied anywhere. They generally take, as a given, a high level of engagement with end users prior to (and during) this process and also a ‘start small’ approach. We know that grand designs, while put together with the best intentions, are often the ones that hit the icebergs.
To note, while this process can help illuminate things that may have to this point been elusive to you, it may not guarantee successes and most definitely isn’t a formula for insta-creativity, alas that we must drum up ourselves by getting into the right headspace. It also isn’t completely linear. I’ve seen people come in at a later stage and go back to the first step of the process to get a project back on track.
1. Challenge accepted. What next?
Work out what the might work! Brainstorm and be creative. Don’t wed yourself to one solution or one approach but think about the types of solutions that could work. Is it low-tech, high-tech, a combo, or actually just a workflow or process? It is important to narrow the parameters a little otherwise you can end up comparing apples to oranges. You might also want to break it into two parallel tracks i.e. one for a new workflow to be established, and a separate thread for a software tool.
2. ‘User Stories’ or ‘Working out what your end-users will need to be able to do’
In software development, one way of ensuring we keep users needs at the fore throughout this entire process is to set up a selection of ‘user stories’ that essentially explain what each type of user whether it’s an end-user or the role of a UNHCR staff member needs to be able to do with a solution in order to address the challenge. These stories critically outline not only what a user might want to do, but why they do it – what they want to achieve. This helps move away from long lists of things people want to do but really honing in on why to ensure that it all stacks up. This type of approach can be – more or less, I feel – applied to many different types of innovations and isn’t only suited to web development. Whether this is creating a process or using absolutely no tech at all, we can still let user needs and intentions guide our approach to solution design. It defines the parameters, making sure we’re not adding a whole load of superfluous elements that often emerge in top-down approaches. Also, you might want to go back and revisit your user stories later on based on the information you’re getting from other aspects here.
3. ‘High Level Requirements’ or ‘Coming up with a list of what you need a solution to do’
User stories – while guiding – often don’t bring us closer to potential solutions. The next step is essentially to translate the user stories into the high-level requirements of a / many solution(s). This can require a little technical knowledge to understand how things fit together, what technology can/can’t do and where you might need different types of interventions to address certain other aspects of the solution. This can be as holistic or as specific as you might need. Generally more detailed ‘business requirements’ might be too specific for an agile process, but high-level requirements can essentially re-frame and ‘translate’ the user stories in a way that fits with the creation of the tools. As mentioned, while this is traditionally from a software perspective, it could also apply to a process i.e. how each user sees the process might differ from overarching process flow and design which takes a more systems approach.
4. Research your options.
No solutions come without scouting the horizons and putting the time into researching your options. This could be within a particular type of arena, for instance, a selection of out of the box software tools, like UNHCR Innovation Service did with the Digital Display solutions we used in the Mediterranean refugee situation. Together with Mercy Corps we scouted out 5 – 10 different solutions and looked at their features and specifications, mapping them to what we had outlined in our high-Level requirements. Having this overview enabled us to make informed choices about which solutions we wanted to take to the next stage of the process. If you’re lucky – and can google like a boss – you might find that somebody has already done the hard work for you.
Connected to this, often many ‘jump the gun’ and think that everything needs to be custom built for them. This should more often than not be a last resort option, and possibly even a decision taken later down the line. If other have and are investing in tools that do 90% of what you’re looking to do, it makes sense to leverage this. At very least as a prototype.
5. Start ‘Prototyping’ or ‘trying things out’
Sam’s aforementioned blog really covers a lot of this. Put the options through their paces and try and make something work. Even if there are sometimes some deal-breaking elements in that 10% of missing features that prevent you moving forward, getting to a working prototype with these tools can help in some many ways. The proof of concept can drum up support, provide a base for learning, as well as provide an opportunity to check back in with user stories and pivot if necessary. What this might mean is going back to your researched solutions and going through a one-week testing phase to see how core aspects are working or trying to go to prioritised functions and see how it fits together. In contrast to many bureaucratic tenders (which often go from nothing to tender win, to ‘you’re stuck with it) these are more gradual processes where you might jettison some options sooner rather than later and test some in parallel for longer periods.
If you are having to create something from scratch, start small and aim to tackle some of the key user stories. We felt in a way UNHCR Innovation was able to do this to some extent with our community engagement solutions in emergencies i.e. using loudspeakers on Boda-bodas for delivering messages and engaging with communities
Finally, find the right time to start testing with some users. Testing of even the most nascent solutions can provide some insight in the early stages. Best to keep this lightweight but getting these perspectives early on can really avoid headaches further down the line.
6. Build off what’s working.
Learn from where things go wrong, and when things start to work, capitalise upon them. This is also the time to clear up some of the more niggling aspects (including elements around sustainability, ownership, any other legal issues etc.) before you hit primetime. This is also a time when more formal procurement, contracting and tendering might take place (actually depending on your internal processes this might apply differently depending on your organisation – consult your own internal guiding documents for how to do this!).
Ultimately, the above should hopefully provide some insight on how to crack on with getting solutions up and running while following some good innovation methodologies. It’s not a matter of cookie-cutter replicating approaches or solutions for different contexts, but being rigorous, well-researched, putting users first, starting small and giving things a crack to see what works.
If you disagree with any aspects of this or want to highlight something I’ve (probably) missed, then please send us your feedback or write a comment below. There’s no one ‘right-way’ to do this but this can provide an insight on my personal approach in ensuring solutions we’re piecing together are adapted to the context and the constituents we’re serving.
We’re always looking for great stories, ideas, and opinions on innovations that are led by or create impact for refugees. If you have one to share with us send us an email at [email protected]
If you’d like to repost this article on your website, please see our reposting policy.