Over the last year Tech For Good Global has been working with Comic Relief and Paul Hamlyn Foundation as a learning partner on the Tech For Good programme. Part of this work was to understand how to create a stronger ecosystem surrounding “tech for good” projects and indeed to continue building this field. Cassie Robinson explains [Read more…] about Get involved with the Tech for Good Community
Article by Joe Roberson, Guest Blogger and Tech for Good consultant at Working with Joe.
So you’ve won some funding for your project?
Ace. Nice work. You’re going to have so much fun building your product…
You’re probably thinking about the social impact you want it to create.
You might even have thought about the user value it should create.
Tech for Good video playlist
The below videos show how some existing problems can be solved using innovative tech solutions. In the 2017 programme, Comic Relief and Paul Hamlyn Foundation co-funded 10 digital transformation projects, covering a range of issues including homelessness, addiction, disability, and domestic violence. We’re excited to show you what our projects were working on from April – July this year.
To learn more about the individual projects – see our Current Projects page.
We are hoping to run another Tech for Good programme later this year. Please keep an eye on Comic Relief’s Open Initiatives page for updates.
Tech for Good Programme Wrap-Up Event
On the 24th July, we marked the end of the second Tech for Good programme with a public wrap-up event at the Impact Hub Westminster near Trafalgar Square. Making the most of the opportunity to have all of the support team, the funders, and the 10 projects in the same room, we split the day into three parts. Firstly, a morning session for the support team, followed by an afternoon workshop with all of the projects, and finally a public showcase in the evening.
The support team along with staff from Comic Relief and Paul Hamlyn Foundation met first to share learning and reflections. We also discussed possible tweaks and improvements if the programme were to run again (we very much hope it will!).
In the afternoon, we held a workshop with all of the Tech for Good projects. This was a chance for everyone to reflect on how they found the programme, what did and didn’t worked for them, and what could have been done differently. Finally, we also discussed what support projects needed in moving on beyond this funding period.
The evening was a reception with an audience of around 100 people, who came to hear the 10 teams talk about their projects, what they’d learnt over the four months (lots!), and what their next steps might be. The teams had 10 minutes each in which to give a short presentation, and take a couple of questions about their work. Audience members were able to submit questions via Twitter – using Slido these were collated (using their hashtag) and displayed as they appeared. Teams then had a couple of minutes to run through some of the questions at the end of their slot.
The presentations were great! Most teams went for PowerPoint slideshows, though Ed from Bristol Braille didn’t use slides at all, instead showing the audience the latest prototype of the Braille e-reader. Harry Harrold from Neon Tribe (working with Alexandra Rose) braved a live demo, which worked seamlessly.
David Kane is a Data Scientist working for Cast and Beehive Giving, who has produced an analysis of applications to the Tech for Good programme, as well as a searchable directory of applications. Please see his introduction to this analysis below.
As part of applying to the Tech for Good funding programme, applicants were informed that their application would be made public even if they were unsuccessful.
This meant that when Comic Relief asked us to analyse the applications to the fund we could expand the scope of analysis beyond just the ten successful applications. Looking at all applications allows us to look at wider trends – such as who is asking for tech for good funding, what do they want to do with it, and what stage of digital development are they at.
The analysis looks at five main questions:
– What types of technology are being developed?
– What approaches are adopted?
– What’s the focus of the application?
– Who are the target audience?
– What stage of development are the projects?
Surprisingly, the first of these was the most difficult to answer. Reflecting the criteria of the fund, the projects were generally at the concept or pilot stage. This meant that applicants had often not yet come to decisions about the technology they would be using – and described the project outputs in more general terms as an “app” or “website”. I believe this should be seen as a positive – a sign that applicants were focusing on the problems they wanted to solve, rather than letting the technology drive the project goals.
You can read more answers to the questions above in the application analysis. The analysis showed that the typical application was from a larger registered charity based in London, but that there was variation beyond that typical picture. The largest focus of applications was on health and wellbeing, and generally applicants were aiming to provide services directly to beneficiaries.
Eve from Snook, one of our evaluators, shares her views about the learning from camp.
Applying the agile methodology (see our last blog post here) to their various projects, the Tech For Good teams arrived at valuable insights, new problems and, in some cases, some healthy confusion. In this post, we outline some of the key learnings from the camp.
Agile ways of working
Most fundamentally, teams used the camp to better visualise their project plans. This was particularly important for teams that would be working remotely and to different schedules, such as WESC’s multidisciplinary team. A Disrupt Disability team member said that the degree of structure he gained through the camp to relay to the wider project team would not have been possible without the exercises. The Shelter team refined what they felt was possible in a four-month timeframe, and built contingency into their plans, as a result of the various planning exercises.
The second key theme in this regard is the identification of new assumptions. This is not surprising, given identifying assumptions is a key tenet of the agile methodology. Some teams struggled to pick assumptions to focus on that they can reasonably close within the 4 months programme.
Team Oxfam saw their core assumption shift: from the assumption that food banks offer little ongoing financial resilience support, to the assumption that services want to build financial-resilience support to the assumption that, given financial resilience is key to food security, food-bank staff should refer users to Quidsin.
Other teams gathered more specific insights, relating to a particular assumption. The Shelter team, for instance, realised they had paid too little attention to testing the assumption that the simple intervention of a digital button would solve the problem. This, in turn, had led to an inability to fully articulate why – or whether – their intervention was needed. Similarly, the Women’s Aid team realised they had not tested the assumption that young women would indeed use their service and the context around it. For their part, one of the assumptions the Alexandra Rose team identified was that their voucher printers could print barcodes. Finally, the Bristol Braille team shifted their focus from the physical design of their Canute e-reader to user need, realising they had failed to test assumptions relating to demand.
From assumptions to prioritising things to test
This points us to the third grouping of lessons: the need for more user research. Bristol Braille and Oxfam both decided they needed further user research, around user demand and user experience before using the QuidsIn card, respectively. The Shelter team went one step further and decided they needed a UX designer and user researcher.
Understanding key problems
The fourth key theme in terms of what the teams learned during the camp was a clearer sense of the key problems and potential obstacles they faced. This arose largely from the journey mapping exercise. The WESC team, for example, identified problems around data permissions as a critical juncture – one with the potential to hinder further checkpoints. Similarly, they identified a key collaborator who had the potential to become a bottleneck.
The teams learned all manner of other lessons – some pronounced, some subtle. The aim of this blogpost has been to outline the key themes and to note the way they followed from the tenets of the agile methodology, outlined in the previous blogpost, that ran throughout the camp.