Designing for Change: The Drought Assist App
Picture the scene: It is November 2016 and South Africa, at that point, had been experiencing it’s driest year since 1904 with dams at their lowest levels of 53% across the country. The Vaal Dam, which supplies the Gauteng area with water, was standing with 26.5%. To put that into perspective: Just over a year earlier the dam’s capacity stood at 66%. A number which could comfortably supply Gauteng residents with water needed to go about their everyday life.
The dire water levels in November 2016 caused by the drought meant that water restrictions had to be put in place. Residents were urged to cut their water usage by 15% and for the neighbourhoods who did not comply had their water supply shut off for a period of time. Other suburbs introduced water cuts from 9pm-5am. This seems rather strict but, keep in mind, the dam levels were not continuously rising and areas using water frivolously (for example, washing their cars or watering their lawns) were using precious water that would be used as a means of survival in poorer areas.
User Observation:
With no one really knowing when the drought would come to end, many residents in Gauteng readily adopted methods to lower their water usage but were still affected by water cuts in their neighbourhoods due to their neighbours not cutting down on water usage.
In my user observations I noticed that a key issue around this was not lack of knowledge about the drought (although some users were uneducated in how to reduce their water usage) but a lack of knowledge in two areas:
1. What is their neighbourhood’s current water usage? Resident’s who are cutting back on their water usage are having their efforts sabotaged by ignorant neighbours. How is their and their neighbourhood’s current water usage communicated to residents?
2. How are water cuts communicated to affected residents? In most cases, a resident would only know there was a water cut once it took place and there was no communication ahead of time regarding this nor how long the water cut would be in place for.
User need to be fulfilled from app:
With the above observations in mind, and being an affected and frustrated resident myself, I set out to develop an app that could give users a real-time view of their and their neighbourhood’s water usage and give alerts on imminent water cuts.
App Journey:
Post user-observation I sat down and distilled what each user’s needs are that would need to be fulfilled. From doing that I realised the app already needed a change.
The initial goal of the app was to purely be a notification system to alert users on imminent water restrictions based on real-time data analysis. The user needs analysis indicated that users also needed to know what their personal water usage was at any given time and how they contributed to their neighbourhood’s usage.
Why? Water restrictions are applied on a neighbourhood basis due to how the water release system is built. Therefore, one person saving a lot of water is pointless if the rest of their neighbourhood is not doing the same.
And so, in the paper prototyping phase, the back-end usage analysis was brought to front-end of the app with smart data visualisation. It was a logical step to take and one that would build on, and not waste, a powerful tool.
Heuristic evaluations (HE) followed and was based on the paper prototypes. This step I found to be valuable and insightful as there were small details I had missed on the prototypes that wouldn’t be a huge issue to fix had I done a detailed digital prototype. These changes were incorporated into the first versions of the wireframes for the app.
User testing of the wireframes confirmed that making changes informed by HE were valuable and gave users a far better experience had the changes been excluded. The user testing revealed a few small, but important, changes needing to be made. Getting feedback from users in-person as well as online from more experienced testers was illuminating and gave good insight from different demographics that the app is targeting. I really appreciated the quick turnaround time that usertesting.com testers gave. I highly recommend that service!
Making the final changes to the wireframe, updating the design, and creating the branding was great. I was pleased with the final results and would certainly love to see my stretch goal of having the app properly developed and rolled out. I felt like I had accomplished something and had gained a good understanding of the user experience design process backed up by a logical project flow.
Conclusion
Although the drought that inspired this app is almost over, there are still lingering effects and I do passionately believe that an app like this could be deployed in areas outside of South Africa across various mobile devices in order to make users water-wise.
The execution of this app would ideally require, from my perspective, and overhaul on the current branding (logos redone from scratch and a CI rolled out by an experienced designer) just so that the app’s branding is 100% it’s own.
The technical requirements would involve detailed back-end programming and a system linked to municipal water systems. This would need to be done with a company that specialises in installing monitoring systems as water usage is monitored manually in Johannesburg and overhauling an entire water meter system for an app is a tall order. Thank goodness for modern methods!
Thanks
Many thanks to the Coursera/UC San Diego team, Scott Klemmer, Elizabeth Gerber, and Jacob O. Wobbrock for hosting such a fun and practical course that has given me the design skills I had been trying to learn for a while. Thank you to my fellow specialisation students for always giving constructive feedback and valuable insights. The time you’ve given on this is highly appreciated!
Like us on Facebook: https://www.facebook.com/DroughtAssist/
