During my internship with UNHCR Innovation, I have the mission of prototyping a reporting tool to track the monthly progress of projects that are managed/facilitated within the team, as well as any points that require the attention of the team’s leadership. Although I assumed the challenge with excitement, at the outset I was frightened by the idea of failure and a self-imposed pressure to deliver something valuable. However, I have collected some interesting conclusions about this journey.
After analysing the needs of the team members, identifying the common tools used within the team and hearing their opinions on the most important issues to report, I had to make a decision on the most appropriate tool to implement, and – the most scary of it all – test it!. The choice was not simple, particularly because the diverse perceptions of needs within the team weren’t leading to a common place as I thought it would.
I came to realise that my aim to solve everyone’s needs wasn’t going to happen. I then decided to prioritize the most pressing need, and I took into account some requirements that came out of my analysis: firstly, it had to be a simple tool which wouldn’t interfere with the multiple engagements of the team members; secondly, it had to be personalized to reflect the different nature of tasks among the team, and finally, it should report the relevant milestones, challenges and next steps of activities in order to build an easy traceable follow-up by the leadership.
After considering a variety of tools, I opted for simplicity, and designed multiple google forms with personalized, editable questions. This idea was first developed by our Engagement Officer in the Innovation team to capture project progress or impact stories. Based on this idea, I created separate forms with different sets of questions which respond to the requirements of a monthly reporting tool.
Currently I have finished the second refinement of the prototype and we will test it on a monthly basis. So far I have learnt to embrace the process in its uncertainty more than expecting remarkable results. I have given up the idea of coming up with a magic solution, and instead I have chosen to focus on the process, listen attentively to questions and concerns around the tool, and reflect on lessons for the future. Here are some of them:
Lesson 1: Don’t aim to make it perfect the first time
Even though I’d taken into account the users’ requirements, my first prototype didn´t adjust suitably to the users’ needs. I was partially expecting that result since I wanted to first test the appropriateness of the tool by sharing it with the team members before developing something very elaborate. This strategy proved to work because starting from that point, I was able to confirm that my initial steps weren’t mistaken and I could proceed to the first refinement.
Lesson 2: Sometimes the best solutions are not the most structured ones
I spent quite some time (and I still do) deciding on which prototype to test and thinking about the array of options available. For the first needs assessment I reviewed many tools, from the simple google spreadsheet to several project management apps. In the end, the google form prevailed thanks to its simplicity and flexibility. This shows that sometimes the most complete tools are not the answer and specially, maybe the answers are already there, but they just need to be adapted.
Lesson 3: Communication is KEY
After finalizing my first prototype I shared it with the team in order to test it and have their feedback, but at first no one replied. When I sent a short reminder, their reaction was a pretty uniformed state of confusion concerning the purpose of the tool. I should have expected that, after all, they didn´t go through my decision process and I hadn’t explained it before. After explaining the aim to everyone I was able to obtain valuable feedback on the tool and once I was done with the first refinement I asked each team member for their contributions. This direct interaction was very positive for addressing specific items for each team member’s reporting page.
I know finishing the prototype was the initial step towards success. Even though the team understands its utility, I won’t be able to call the prototype an innovation until I achieve the appropriation phase.
Do you have other lessons to share with us on prototyping?
If you’d like to repost this article on your website, please see our reposting policy.