Recommendations
9.0 Recommendations
A crisis affects everyone, but the immediate concern for anyone within a crisis is themselves, their family and the ability to pick up the pieces as soon as possible.
By setting the stage for resiliency in the individual and community at large, the Prepare Wellington concept aims to be part of a solution that might encourage or enable this to occur.
Should WREMO and its associates choose to take forward the concepts presented in this proposal, here are some broad recommendations as this project transitions from research to the creation and further establishment of close relations between designers, developers, stakeholders, users, the public and the evolving state of experiences created by the product itself.
The recommendations in §9.0 are written with reference to the design of the experience, not to the technical build requirements. They would benefit from further discussion with stakeholders and development teams.
Even the most well-resourced and vetted software is not infallible. However unlikely, the introduction of a web based experience that people turn to for advice in an unpredictable event that may occur at any time may create unforeseen issues.
While ensuring that people’s data is protected to the highest level, the product should be owned by the stakeholder and public. The role of the public may take on many guises, such as: assisting in the creation as developers, providing feedback on the data and experience, or contributing the data that other members of the community utilise.
A mobile first strategy ensures that the experience is placed into as many hands as possible, as early as possible. It also helps to provide a focus for the experience thereby limiting ‘feature creep’.
An individual’s mobile phone is their identity expanded. Through the device’s capabilities, a phone can help describe more about the user than they might be able to describe themselves (through data collected by the device). The initial experience should take this into account as, treated respectfully, contributed data in the short term will encourage people to trust it when they need it.
Whether in the ‘business as usual’ or ‘crisis’ phase, the experience of Prepare Wellington has to record and reflect back to the user their situation and not their location. People know where they live in terms of their city; what they will want (or need) to know is the availability of resources immediately around them and specific hazards, if any.
The relationship that a person may have with Prepare Wellington and information within should be relevant and timely. Stale information, or a lack of response from someone in the community, will only prove to frustrate to the user and underline why they may not use or trust the experience.
While some of the experiences and ideas in this project have been tested in the field (albeit in non-dynamic, linear user journeys) the entire proposition requires more prototyping and testing with the public to ensure that it is understood, and that the user experience, and the concept more generally, is correctly vetted.
Beyond the experience, which will always transition as needs and trends change, the data underpinning the whole enterprise should be structured and constantly maintained to be accessible at least a decade at a time.
The likelihood of it ever being used in a crisis is low: the chance of an earthquake of ~7.5 is 10% in next century and 5% within the next 50 years (Rhoades et al., 2011).
The long-term nature of this project will necessitate ongoing investment in software and volunteer relationships – it needs to be ready to be used at any time. The trans-situational aspect of the concept well help ensure that the site is always up and operational.
9.1 Operating in public
How we treat one another matters, and not just in a ‘it’s nice to be nice’ kind of way: our behavior contributes to an environment that encourages some opportunities and hinders others.
– Clay Shirky, Cognitive Surplus: Creativity and Generosity in a Connected Age (Shirky, 2010)
Beyond examining the literal functions that help to guide and suggest its eventual rhetorical presence and the raison d’etre for the Prepare Wellington experience, one thing stands out: the product must be public in all senses of the word.
To achieve even the barest minimum of experience allowing for a trans-situational scenario in software, like all social experiences from cities to social media, the people who use it make the values it becomes imbued with.
As a semi-autonomous organisation, WREMO appears somewhat private, or invisible until they are needed. This presents a fine line that must be walked: the quiet security that WREMO gives society will need to be balanced with the promotion and dialogue that comes with owning software that may come to becomes part of people’s day to day activity, if not also representing their feeling of security.
This balance may require some form of cultural change so that the idea of partnerships, expressed in the National Civil Defence Emergency Strategy (2008), are also explicitly visible on any participatory and democratised product relative to the citizens that it will come to enable and ultimately serve.
Alongside active language, the name Prepare Wellington helps to communicate the communal value of the service in addition to promoting engagement: helping focus the use, and encourage respectful behaviour.
As discussed in §5.3, alongside identifiable trusted branding, people also need to see that a produced experience is reliable, maintained and safe to use. Additionally, no software is foolproof, nor is it impervious to misuse.
Like any other considerations in the design of social media platforms and even before the intended purpose of the site is stably identified, brand and reputation, user tracking, privacy, moderation and security are all things that may effect people’s impression of the site.
Having an open website that requires little registration and identification of its users is, incongruously, one of the values that will enable this experience to succeed in the short term, despite the risk of ‘vandalism’. However, eventually the utilisation of a light sign-in will help to provide an impression that the site is trustworthy and that contributors do not risk unwanted attention.
People may not contribute if they feel that they need to expose too much private information in public (especially concerning who they are and where they live). As a result, people will need to control and protect their privacy. The potential for abuse of that information by third parties is a real issue requiring analysis to mitigate.
People need to contact a site’s owner about questions/concerns, and provide feedback on operation. The owner needs to be visible and accessible.
The moderation and quality of the information entered into the software requires constant policing. This underscores the relevance and trust that people have in the service should a crisis eventuate and the experience tips from pre- to post-crisis.
Software that governs the security of data voluntarily contributed within this experience should be open-source to ensure the widest possible validation of its security is sought and found.