Creating digital products and services that do social good is not easy.
It’s very easy to have a good idea.
But it’s hard to know if it’s the right solution to the right problem, and even harder to design and build it in a way that people can easily use.
For the last 4 years I’ve worked at the intersection of charities, co-design and digital development. I’ve led new social tech projects, tried to save old ones and acted as consultant for others. In that time I’ve had my fair share of fails.
So with the kind of fanfare usually reserved for the Internet’s most epic #fails, here are my very best attempts to get it wrong!
1. Over-specified at the Start
It was my first social tech project. We’d won the contract by writing a detailed explanation of how we would build the product to meet the funder’s specifications. Our next step should have been to politely put the specification to one side and then spend some time with users understanding their wants, needs and digital lifestyle. After that we could have done a bit of wire framing or paper prototyping to find out what kind of product might help.
Instead we agreed the spec with our developers then went and asked users how it should look. While our designers went on to do a good job of making it look ‘nice’, we made some major mistakes around features and functionality. These mistakes led to features that never really worked and held the product back from growing.
The problems was we had chosen the wrong development methodology.
We’d chosen the Waterfall method – where a product’s features and functions are specified in detail at the start of a project. With Waterfall you tell your team what to build, they go off and build it, and a few months later you get your product.
While this might sound like a logical approach it doesn’t allow for your product to evolve iteratively or to be well tested before delivery. We should have used Agile methods. Agile allows for multiple small iterations where your product can be tested with users and the learning applied to its next iteration.
By choosing Waterfall we over specified the product, reduced our ability to reality test and ended up with many wrong, poorly designed features.
2. Over-focused on the Product
Puzzledout.com was a great social tech idea. It was needed, looked good and ran easy to use surveys of young people’s experience of local mental health services.
But no one had a clear plan for how it would be sustained when funding ran out. Even worse, there was a model that could have generated revenue but we hadn’t built the product with it in mind. As a result Puzzledout doesn’t, at the moment, have the functionality or funding to achieve its potential.
If we’d begun planning and business modelling at the start of the project Puzzledout could by now have been a roaring success. But we were so focused on the product that we didn’t explore its sustainability until after launch.
You’ve got to have a business plan, right from the beginning. If your plan changes it doesn’t matter. The point is just to have one and to keep adjusting it as your business and social tech understanding evolves. Your plan should act as a reference point and a stimulus for regular conversations about how your product will create financial value and generate income over the long term.
If you’re going to create a product that delivers social good then you have a responsibility to find ways to sustain it and manage the expectations it creates.
3. Didn’t Test It
Psst. Let me tell you a secret. I’ve skimped big time on user testing. I launched my first couple of websites without running any tests at all.
I presumed that if our developers built it then it would work right for its users. I saw the development as their job to get right, not mine. I didn’t know to ask about testing (nor did they suggest it!)
As a result the site was tricky to navigate and users couldn’t find the information they wanted. It delivered a pretty useless experience.
If we’d tested the site before launch we’d have learnt what confused users and we could have made changes. If we’d tested or prototyped it early on then we’d have built it differently in the first place.
It’s easy to ask people how they think your website should look or what it should do. But until you observe their behaviour or test how your product fits into their lives you’re just swirling around in hypothetical soup.
Testing isn’t hard. Give people tasks, in paper or digital. Observe and ask questions about what they are doing. You might save yourself from building something hideous.
4. Ignored the Easy Solution
When people tell me they want to build something that finds out the views of their service users the first thing I ask is why won’t Survey Monkey do it well enough?
Sometimes that’s the end of the conversation. Sometimes they come back with good reasons why the easy, simple option that Survey Monkey is, will not work. But that’s rarely the case.
It’s easy to ignore the simple solution because we all tend to think that our user’s needs are unique and so our solution should be too. The solution should shine and function in its own unique way.
Luckily I’ve never been in the position to make this mistake (though I’m sure given the chance I would have!). But I did encounter it when working for a now defunct membership organisation called CROA who had custom built a membership site to keep track of their 200+ members.
Unfortunately the site was clunky and poorly put together. It also didn’t allow CROA to mail their members, nor trigger online renewals. The navigation was complicated for users and admins. It was one of the reasons why CROA’s members were not renewing their membership.
The solution was to install an off-the-shelf membership site. It actually had everything they needed (website, forums, mailblasts and online payment facilities) and worked more smoothly.
CROA could have saved itself a lot of time and money had they started with an off-the-shelf solution and then refined it as they evolved.
Hindsight is Wonderful
Though I’ve made these mistakes and many more, they’ve all increased the success rate of my projects. MOMO, my latest social tech venture, has so far succeeded at every point of past failure. The biggest reason for this is making smart use of our team’s full range of past social tech fails and successes. Together we’re finding the best way forward.