News — 02 April, 2021

Design Sprintathon

hot_tech kicked off 2021 with what started out with a big idea to run some rapid assessment and design sprints (RaDs). We learned that sprint, drastically underestimates the epic time & efforts it takes to get a sprint across the line. We also learned so much about the collectives we serve and how we can serve them better...

Well, what a start to the year it’s been.

It’s taken a little while to get this post together, as I think myself and the rest of hot_tech needed a bit of time to recover after kicking of this year in 6th gear with two back to back RaDs.

Some of you may remember these daily posts introducing everyone to the concept of hot_tech Rapid Assessment Design Sprints (aka RaDs). Back then, in writing, it all seemed so clear and clean. Now writing this, I remember just how muddy and messy this process is in action. A process of continuous lessons and learning.

Lesson 1: Sprint by name, marathon by nature. It may be called a sprint, but it requires the dedication, resilience and effort of a marathon.

Round 1

Our RaDs started with the intention of better understanding of who hot_tech served and how. Our BIG QUESTION - “What makes our groups stick, tick and thrive?”. We connected and explored with groups such as members of OSM Francophone, UN Mappers, Slum Dwellers International and a host of other super interesting collectives. We learned so much that to capture it all here would result in a post that is either too long, or under representative. As such, a few key learnings I wanted to share and the rest can be content for future posts.

My reflections:

We are one, but we are many - I can honestly say, that no two groups were the same. Their values, purpose, motivations and priorities vary as far as the geographies they span. And, they change over time. Understanding the diversity both within groups and across groups, makes our space both challenging and exciting. From a design perspective, it also makes it really difficult to identify your typical user for a personal perspective, it highlights just how diverse people that come to OSM are, which, I celebrate emphatically, as it means that we have a near infinite about of potential.

It’s more about time, than tools - I think this probably rings true for life in general, but time is a precious resource. Time is even more precious to those that have less of it, such as volunteers with competing obligations, capacity maxed-out staff and during disasters. A tool should amplify the efforts of the user. Not convinced? See how long it takes you to sink a nail with a screwdriver.

Motivation needs means - One powerful ‘penny-drop’ moment I had (and keep having), is the relationship between motivation and means. No matter how strong the motivation is to contribute to the map, without the means, it is meaningless. What do I mean by means? The free time, the access, the tools, the education, the training, the technical ability, the not having two jobs. For many people reading this, especially those who volunteer, think about what you have that allows you to map. Then realise, not everyone has that. Without those means, contribution comes at a higher cost.

Output:

Nice reflections Bo, but what did you actually do? Where did you end up? Well, glad you asked. We developed a prototype for an idea to support the individuals that are coordinating collectives to encourage and engage more mappers. You can see the prototype we built on figma here.

Round 2

As if we didn’t already feel the 2am meetings and the 6am starts hard enough, hot_tech decided to go back for seconds. This time in partnership with Accenture and two of their wonderful designers who added some external enthusiasm and expertise. This time we decided to switch the focus from remote collectives to local ones by exploring the focus: Identify and breakdown problems maps can help solve. I can honestly say that this did not go in the direction I had in mind, and yet ended exactly where it was supposed to.

Lesson 2: Trust in the process, revel in the chaos.

Bo’s Reflections:

What do needs, need? - One thing I found really interesting in this sprint was exploring what people need to support other needs. For example, what data do you need if you want to support water or sanitation projects in your community? For those that have been around OSM and mapping for a while, we often make the assumption that people know exactly what they need and why. We learned in this sprint that assumption is often not the case.

Mapping starts before mapping starts - Somewhat connected to the point above, we really learned that mapping begins much before any mapping has taken place. Mapping starts with a problem or a need and then once that need is clear and understood, then there are still a few steps before it begins. What we learned in this sprint, is that these steps are understood more by people with more experience and vice versa.

Power in priorities - The people who set the priorities hold the power. Traditionally, the needs of mapping projects have been defined and prioritised by ‘remote’ actors in the mapping ecosystem, with local needs an incidental bi-product. Many local communities who map find this disempowering that development is being done TO rather than WITH local communities. When the data is created, the value and ownership then falls to the group (often larger NGO or multilatérales) leaving the local community mappers with varying degrees of data that may or may not help them solve local problems. This was a significant wake up call for the need to have the local communities determine their needs and map with these needs as a priority.

Lesson 3: Collectives’ needs are what collectives need.

Output:

So where did this all end up? We ended up a with a prototype that aims to connect with people before they start mapping to better understand and identify what people within local communities are looking to solve and then connect them to other projects in other communities who may have tackled similar problems by collecting map data. This was the step before the start. The phase 0 kind of approach. You can see more how the prototype plays out in our figma prototype here. Go and have a play and feel free to tell us what you think.

What next?

Now what? Well, over the course of these RaDs we collected a lot of thinking material. Our conversations lead us to so many different places and now we have to boil this all down to something usable and useful. The next steps you will soon see coming from us are:

• Capture all our problem statements and refine them into one simple list

• Share that list with all of our collectives to understand what resonates most and what hot_tech should be prioritising

• Develop an open and accessible backlog based on the priorities to show exactly what we plan to work on over the coming year or so

• Create a feedback loop to ensure connection and engagement are open and ongoing.

• Share both the roadmaps and the journey with you all as we undertake this a new collective-centric approach to hot_tech’s work.

Bon voyage!