My #tech4good journey started back in 2010 when I left the world of mental health advocacy and struck out on my own into the world of digital.
Back then I still associated the terms lean and agile with high jumpers and skinny monkeys. I thought of adoption as something that went along with fostering and the idea of having a business model was something that, well, commercial businesses had.
I’ve for certain learnt a bit since then. In my head ‘user participation‘ has been replaced with ‘user-centred‘, ‘consultation groups‘ with ‘iterative design‘, and ‘service promotion‘ with ‘adoption strategy‘. While some of this reflects my increased familiarity with the world of digital design and app development, it also represents an evolution in how I now think about using digital technology to achieve a social mission.
If I could talk back to myself as the tech 4 good newbie I was in 2010 here’s some of the advice I’d give.
Learn About Lean
Lean principles will help you make better decisions when developing your app or website. Simple as that. They will also give you a more reliable methodology for building services and products that people want to use. The Lean methodology is better than just asking people what they want.
Lean methods aren’t a panacea for every app or service design problem but they are a solid foundation that will quantum leap you beyond the world of focus groups and vanity metrics and into the world of measurable impact, validated learning and more informed decision making.
Start Your Business Model at the Beginning
If you’re serious about building a new app or setting up an online service then you’re going to need to think seriously and constantly about your business model right from the start. Hoping for another grant in a year or two’s time isn’t good enough, nor is leaving working out how your app will make money until you’ve launched it.
If you leave your business model until the end then your product probably wont be designed to fit it. I’ve done it this way, leaving our business model ’til the end, and I’ve also planned it from the beginning. The results? Well, the app I planned ahead with has so far generated more of a sustainable revenue stream in its first six months than the other one has in three years.
Start Adoption at the Beginning
This is another activity you don’t want to leave until the end. Don’t expect to wait until launch before you begin marketing and engaging users. You need to start way earlier by finding people who really dig your idea.
These people who are most interested in your product are also the most important. These are the people who will become your first true fans. Some of them will even test your product for you. Ultimately they will teach you so much about how to design and talk about your product before you’ve even launched it that without them you’re much more likely to fail.
Of course, your early fans will also become an even better mouthpiece for your product than you can ever be and, if your app is good, will help bring on many more second stage adopters.
Pick the Right Technical Partner
Everyone likes the idea of developing an app for good. Including developers who only know how to build websites. Just because they say they can build an app for a few thousand pounds doesn’t mean that they have the skills and experience to walk alongside you on your journey.
Look not only for shared values but also for a track record in developing browser-based and native apps. Look for an established methodology around user centred design and find out what kind of prototyping and testing practices they would expect to use with your product.
You may have to pay more for a developer with the right experience but it’ll save you the time and wasted money of them not being quite good enough for the job.
User-centred Design Trumps Co-production
Three years ago I wouldn’t have believed this.
Today I do.
To design a product that is truly user centred you need to understand your users. You need to understand them so well that the design process becomes almost empathic. That’s the ideal, gold standard.
Now, having users work alongside you, co-producing the app is an admirable ambition. It is essential that they are involved. However I don’t buy the idea of them being involved everyday of your project, nor in making every key decision.
I do believe in talking to them (a lot), finding ways to test early and involving them in beta testing. But good decision making and good end products come from lead team members being invested with the responsibility to make daily decisions based on both technical expertise and a deep understanding of user needs and behaviours. While users are experts on their own needs they aren’t always experts on their own behaviour, and rarely are they also a product’s design potential or technical needs.
Feel free to challenge this, I’d love to hear from you.
Make Your Team Small and Multidisciplinary
Ever worked in a large team on a part time project, where no one is on it full time and its nobody’s core business?
Chances are if you have that it failed. If a team is too large and working in silos or across different sites its almost impossible to keep focus, engage creativity and make effective decisions. I’d always rather a small team of generalists working closely together than a large team of specialists trying to understand each other.
If the core of your team is only two people then in my view that’s better than three or five. Build your specialists around the core people you need, but keep that core small, agile and responsive. Your momentum, and end product, will be better for it.
What Are Your Tips?
These are mine, from my journey so far. What are yours? Scroll down to share them.