5 App-Design Lessons
co-authored with Dr Jonnie Penn
Dr Jonnie Penn and I worked together with open source app developers: Guardian Project and their Design Team OKThanks to develop WeClock - our privacy-preserving selftracking app for workers.
Here is a run down of our top 5 lessons for inspiration if you are considering building an app.
Technology is a means, not an end
Technology is not a silver bullet. To make effective use of digital technologies, you have to think of how they will help you reach a predetermined end, like better organizing, recruiting, or collective bargaining. Technology is a means to improve your existing practices, it is not an end in itself.
Co-Design with your Users (or: Beware the Super User Fallacy!)
Picture this: you sink precious time and money into, say, developing a new smartphone app to drive recruitment. You devote months into making it perfect. Upon launch, you learn, to much frustration, that no one wants to use an app in the first place! Even if it’s the perfect app, it’s just not what your users want.
This is an easy mistake to make. It is known by some as the Superuser Fallacy. If you design your tools for the 1% of users who do exactly as you hoped they would, clicking every button and sign-up, you actually risk alienating the other 99% of users who, often, just don’t care.
To avoid alienating the everyday user, one solution is to co-design your project with your intended users. Ask them what they want and see how you can provide that service for them. The learning process may surprise you! - it did us.
Seek out your Minimum Loveable Product
To save time and money, one useful idea we’ve kept in our back pocket is the notion of a Minimal Viable Product (MVP). The idea goes like this: when developing a new tool, start by considering what the lowest possible implementation level of your idea would look like. Example: do you need an app? Could a simple website or landing page solve your problem instead? Or does an off-the-shelf tool exist already that could solve your problem? (The answer, for us, was yes when it came to staging a Virtual Town Hall. Learn more about that here.)
The idea goes one step further when you consider a Minimum Loveable Product (MLP). This idea improves on MVP by adding to it that your offering should be engaging. So, rather than just considering the lowest possible implementation level of your idea, ask also what would need to be true in order for your idea to get people talking and feeling excited about the product or service. Thinking in this direction helps you design tools that people actually want to use. Once you have a MVP or MLP ready, you can incorporate user feedback to improve, and expand, your offering.
Find the Purpose for your Service Before you Start to Build, Not After
They say that when you hear the same thing from three people you trust, it’s time to start listening. In our case, a piece of feedback we heard again and again in the early stages of this project was that when you design a smartphone app or a digital tool to gather data about something (say, for example, an app that lets workers report unsafe conditions on a worksite), you must avoid collecting all the possible streams of data available just because they’re there and just because you can.
This is not what Facebook, Google, or Apple do. Those companies suck up every piece of data you generate, from sleep patterns to when you use the bathroom. To set a better standard, we’ve learned to outline our mission clearly before we start to build anything. This makes it easy to decide what type of data to collect (ex. photos from the worksite) and what not to (ex. your GPS, recent calls, or the frequency with which you check your phone).
Beware Mission Creep
The astronauts who walked on the moon would likely have loved to walk on Mars too, but that level of ambition would have derailed both projects. Technology allows for so many potential possibilities that is easy and intoxicating to want to try them all.
Again and again, we have been told to narrow our ambitions to a reasonable set list of goals. This avoids what is called ‘mission creep,’ meaning when your project grows in scope without end, until you and your team are flooded with new features and ambitions that end up compromising your core goals. Ambition is good! You just need to keep an eye on it...