In celebration of an approach less travelled

I’m in San Francisco this week on a surprise trip to collect an award for a product I designed and built over a decade ago. The fact the early work of FrontlineSMS is still being recognised twelve years on speaks volumes to the approach, and the impact it had – not only in the hands of users themselves, but also in the minds of others looking to apply technology for social good. It struck a chord with an emerging narrative that said we should build appropriate tools that genuinely empowered the people closest to the problem, and that our job was, if anything, to build those tools, hand them over and then get the hell out of the way. If you look at the tweets from the many ICT4D and social innovation conferences today, this remains an approach popular within our sector.

But while tweeting and speaking are one thing, doing is another. Sure, for me this week should be about celebration, but I remain frustrated with a sector which claims to be hungry for learning, and hungry to scale ‘ what works’, yet very little of what made FrontlineSMS successful has been made use of in any meaningful way. This is not just disappointing on a professional level, but a personal one, too.

Nothing quite matches the energy and excitement of grassroots organisations building out their own ideas and solutions off the back of a platform you’ve created. The idea that you might stop what you’re doing and others will continue the work is something we should all aspire to. In the global development sector we call this ‘sustainability’. Yet, how often do we see it?

Nothing quite matches the organic growth that becomes possible when you build genuinely open, empowering platforms. I’m immensely proud of the way our users embraced it, and equally proud of the smart, young innovators such as Josh Nesbit and Ben Lyon who were drawn to our work, and whose early efforts with FrontlineSMS:Medic and FrontlineSMS:Credit lead to the creation of two incredibly exciting and innovative organisations in Medic Mobile and Kopo Kopo. Kevin Starr once told me that he was fascinated by how FrontlineSMS had become an incubator for so many other ideas and initiatives. Sadly I’m not sure what I can point to today that does anywhere near the same thing.

While we were clearly doing something right, funding remained a constant struggle, and the lessons we were learning and sharing were falling on deaf ears. Only two studies of note examined the impact and approach of FrontlineSMS – a paper by Medic Mobile, and a brilliant chapter in Bits and Atoms written by Sharath Srinivasan. For a project which had such a high profile, and one that powered grassroots interventions in over 170 countries, the lack of interest in trying to understand what truly made it succeed is a huge disappointment. After all, as a sector we’re hardly blessed with success stories of initiatives that scale. From what I can tell, the sector is just too busy chasing the next big thing at the expense of existing opportunities right under its nose.

When I look around today, I still see tools being built far away from the problem with little understanding of the users or their context (except for the odd trip some projects take so they can tick the ‘HCD’ box). Challenges and competitions are the new big thing, with entries voted up or down like a beauty competition by others with little idea of the problem or those effected by it. You don’t stop someone on the street and ask for medical advice, so why do the same with an idea to solve a medical problem in a developing country? I recently wrote about the madness of innovation challenges here.

So, as I attend the awards ceremony this coming weekend I’ll quietly thank all those unsung heroes who helped turn FrontlineSMS into the breakthrough story that it first became all those years ago. And I’ll continue to hope that we can be brave enough as a community to work through many of the problems hindering our ability to build yet more tools that genuinely put the power to change in the hands of those who need it most. Unfortunately, experience tells me to not hold out too much hope. 

Turning point.

I remember that morning well. A week or so earlier I’d been informed via a random phone call that a group of Nigerians would be monitoring their forthcoming Presidential elections using FrontlineSMS. There had been frantic activity ever since, culminating in press releases and text messages with Bill Thompson, emails with Jon Fildes, and a Skype call with Gareth Mitchell – all journalists connected with the BBC. With the election only a couple of days away, the story had to break now else we’d miss the chance and it would no longer be news.

I woke up early, around 5:30am, and headed straight to my office. I was on a Fellowship at Stanford University at the time, and was living in what I jokingly called my ‘Global HQ’. It was, in fact, a 1973 VW camper van which I parked up on the edge of campus. As a result, it was a very short walk to my desk.

Once I got there I went straight to the BBC website and immediately saw the headline. I remember reading the article over and over, excited, nervous and proud and not yet aware of the implications this breaking story was to have on my future, and that of my work.



As far as turning points go, this was a big one. Almost everything that has happened to me and my work since can be traced back to that 5:30am start. I hate to think where I’d be now without it.

You can grab a PDF of the citizen monitoring report that came out of the process here.

1995. 2005. 2015. Two decades of code

Precisely ten years ago this morning I sat down at a kitchen table in Finland and started coding. Armed with a Visual Basic.net manual, a laptop and GSM modem, a couple of SIMs and a Nokia 6100 and cable – and plenty of coffee – I delved into the world of Windows programming for the very first time.

I’d already done a fair amount of professional software development over the years, designing and building a membership/fundraising system for Jersey Zoo, and a range of accounting and amortisation systems for a legal firm, but that was ten years earlier in the mid-1990’s when QuickBASIC was my weapon of choice. Ten years had passed, and I’d never written anything event-driven before. I was on a steep learning curve, but was motivated.

quickbasic

I’d already figured out earlier that year that I could drive a mobile phone by sending it a series of Hayes commands through a cable – that was my epiphany moment, so-to-speak – so my task that summer was to try and build a nice user interface around it. It sounds almost crazy now to think that a lot of this was new, but back then very few people were building messaging platforms, and even fewer building messaging platforms aimed at grassroots non-profits in the developing world. After two years working across South Africa and Mozambique it had already become blatantly clear to me that there was a growing need there that nobody seemed willing, or able, to meet.

One of the big advantages I had back in 2005 was that it was easy to hide away and be left alone to focus on a project like this. Anyone with no team, no money and a big project idea knows all too well how important it is to be able to get away and focus. Thanks to the luxury of being unknown in the ICT4D world I was able to hide well enough to write a working prototype of FrontlineSMS in just five weeks.

FLSMS-vb-net

Designing the ContactManager form

FLSMS-coding

Coding ContactManager

FLSMS-ContactManager

The finished, compiled article

FLSMS-web

The first FrontlineSMS website, built in a day. The field banner was the view outside

Fast forward to today, I once again sit hidden away taking on a new coding challenge (my decades of code seem to take me from 1995 to 2005 to 2015, which may or may not be significant). In a similar vein to my attempts to tackle Windows programming in 2005 – which didn’t turn out too badly, I guess – today I’ve started work on my first iOS app. With a long list of ideas it’ll hopefully be the first of a few. Not surprisingly, they are pretty-much all based on improving how we interact and engage with the people, causes and world around us. I’m close to securing angel investment for the first app, which is another first. And it has a solid business model, which is another.

Interestingly, my brushes with code seem to have taken me through each of the key platforms of the past twenty years – MS-DOS, Microsoft Windows and, now, iOS. And, like 2005, I find myself with a window of opportunity to hide away and code as I continue my summer sabbatical. Watch this space for more.

How “Designing with the end user” undermines ICT4D best practice

After years of near-invisible end users, it’s promising to see the beginnings of ‘end-user recognition’ in much of ICT4D‘s emerging best practice. It looks like we’ve made a big stride forward, but we’re not where we need to be yet, despite making all the right noises. To a great extent, we’re still saying one thing and doing another.

The international development sector, which includes the ICT4D community, is famously uncoordinated. That’s no surprise to many of the people who work in it. You would hope that, at least if the wrong things were being done they’d be being done in a coordinated way, but that’s rarely the case. Haiti is a great case in point, where “a confused aid effort‘ has only added to the difficulties. You’d be right to ask why so many people continue to live in tents nearly five years after the earthquake.

Very recently, the Narrative Project – which I blogged about here – included a call for “a co-ordinated development sector”. It also made the point that independence and self-reliance, i.e. people in the developing world solving their own problems, should be key development objectives. And that people need to believe they can make a difference. This is good to hear, but they’re empty words if ‘best’ practice continues to undermine it.

You could argue that “designing with the user” is a sensible approach – it’s certainly better than designing without them – but is it taking us closer to an end-game of “people in the developing world solving their own problems”? It may if you’re working with them to build a tool or platform which they, and other communities elsewhere, can then take and subsequently deploy on their own terms to solve whatever problem they see fit, in whatever way they decide, without the ‘solution’ provider needing to be involved.

To me, “Design with the user” makes more sense to a local solutions developer, who can simply jump on a bus to go and work with them. But it doesn’t for the overseas solutions developer, for example the student group designing an ICT4D intervention as part of their design thinking course. Local empowerment can only genuinely happen if it’s local people helping local people. So what we need to do is work towards a place where that can happen. “Allowing the user to design” is that place.

The truth of the matter is that far too many ICT4D projects are still initiated from the outside. When I initially launched FrontlineSMS in 2005, the platform was squarely designed to allow local people to conceive, design and run their own projects. The only outside help they needed was for someone to provide something that allowed them to do that. It really isn’t rocket science.

Yet, despite its successes, it still seems to be a model, and an approach, in the minority.

I worry that people who read, study and follow the “Design with the end user” mantra might feel more than ever that they’re doing the right thing, but they’ll simply be reinforcing the outside-in, top down approach without realising it. “Design with the end user” is a step in the right direction, but it’s not the end of the journey, and we shouldn’t kid ourselves that it is.