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.