Reflecting on some of my past projects, and trying to study the thought process of some of the projects that I have worked on, I thought of laying out some questions which can act as a set of “tips” for my future projects.
- Invest some time to understand the problem & hear it directly from the concerned parties or communities.
- Ask yourself: Is technology really needed here? Or is there a solution lying elsewhere?
- Study what technologies are already lying around or have been used by “concerned parties” or communities and how they are currently using it.
- Can your solution be built using existing technology that the people(“concerned parties” or community) already use? If not, try to spend a decent amount of time to find the answer to this question again. Chances are, it’s possible.
- Keep in mind that your solution should require minimal (or no training) i.e. The focus should be on a lower barrier to entry & a decreased learning curve. [If answer to 4 is still no]
- Build your solution in a way that you wouldn’t be needed at all after the implementation.
1. Invest some time to understand the problem & hear it directly from the concerned parties or communities.
When you are told about a problem that possibly requires a tech solution, you might start immediately with brain storming in your head(alone) and maybe search for existing solutions that have been tried and tested elsewhere in this world. While that might seem to be a good thing to do, I feel the first thing should be to have an open mind and just try to understand the problem statement at hand. That should be done by direct interactions with everyone involved in the process that involves the problem. For an NGO, it could be project staff, administrative staff, the community or volunteers. Technology enthusiasts often let invention be the mother of necessity. They think of the new thing on the block and then force it to work as a part of the solutions, even when it does not fit the context they are working within. So having an open mind that isn’t clouded by the next big thing that you’ve read about in the technology world or any other special tool that you fancy, helps in coming up with a more just approach to finding a solution to the problem.
2. Ask yourself: Is technology really needed here? Or is there a solution lying elsewhere?
Start by asking those involved, “What if there was no technology available?” How would they then, solve this problem? In any case, technology is mostly just a tool and real solutions are only aided by technology. So in a parallel universe, where no form of technology exists, how would this problem be fixed? I think that if a significant amount of time is spent trying to find answers to the above two questions, things would become clearer as to whether the solution should have anything to do with technology or not. If the answer is in the negative, as a technology practitioner, it’s best to move on and call it a wrap.
3. Study what technologies are already lying around or have been used by “concerned parties” or communities and how they are currently using it.
The keyword here is “observe”. What exists around? Radio? Computers? Mobile Phones? What kind? What make? How do they use it in their daily lives? What is the extent of their usage? Are they able to use all the features of a mobile phone? What Operating System are their computers running? What tools/software do they use frequently? How do they power these devices? We should observe the behaviour of the people who are supposed to be part of the solution as well, because in the end they are going to use whatever you propose to them. So studying their current level of knowledge in using technology & general behaviour is useful to understand the user experience aspect.
4. Can your solution be built using existing technology that the people(“concerned parties” or community) already use? If not, try to spend a decent amount of time to find the answer to this question again. Chances are, it’s possible.
The idea here is to include existing technology as a part of the solution if possible, or to understand the extent of effort that might be required in case something new is proposed to them and then match the training aspect with their current behaviour so that it saves time and effort later on and learning becomes easy.
5. Keep in mind that your solution should require minimal (or no training) i.e. The focus should be on a lower barrier to entry & a decreased learning curve.
I read somewhere that “the best technology is” that which is “invisible“. It’s something that we should keep in mind always, from the usability perspective, when designing solutions. I tend to focus on decreasing the time and effort I need to spend in training people to use the solution I design for them. How does one achieve that? The best way would be to include existing skills that have already been trained to them(by their own self or otherwise). If they know how to make a phone call using their mobile phone – let’s try to think if we can do something using their mobile phones which just involves making or receiving a phone call. If they know how to write an SMS, maybe we setup an SMS system and interact or communicate with them using that. What if the staff only knows how to use Excel and to check their email? Then maybe, I’d design a web form simple enough to do their task.
6. Build your solution in a way that you wouldn’t be needed at all after the implementation.
If people are still calling you with questions on using the system or with some problem they have, quite frequently, chances are that the job was not well done. Implementation includes training well, troubleshooting and hand over the system to its users. Of course there will be problems, but the idea here is to minimise that by training the ground staff completely.
This post also appeared on ICTWorks in 2012: http://www.ictworks.org/2012/07/16/6-simple-guidelines-ict4d-project-success/