Deliver

After refining our solution through the POC's feedback on our paper prototype, we shifted our focus to bringing the solution from an idea to a reality. Given the time constraint, it was unlikely that we would be the ones implementing the solution, so we had to make it easy for the Annexe Communities to take on the solution. To do so, we identified a list of relevant stakeholders to communicate with to obtain the permissions or seek services from.

Day 8 - Turning Ideas into Reality

We were surprised to find that the implementation stage would most likely take more time than the designing of the solution itself, with the multiple stakeholders to contact and certain steps having a minimum waiting period, such as to get a geocache verified.


Knowing who to contact and in what order, we began by attaching a high-fidelity prototype in an email to the first stakeholder on our list, outlining the project's background and what permissions we were seeking. Since the feasibility of part of the solution hinged on the approval from this stakeholder, instead of stalling while waiting for an approval, we began usability testing to see how we could optimise the implementation of our solution.

The usability tests were designed to measure the feasibility of the part of our solution which had the most questionable feasibility, due to the number of stakeholders whose approvals we required. Our hope for this test was to determine how we could improve on the implementation, such that the benefits are strong enough to support our case in seeking those approvals.

Day 9 - Solution Enhancement and Usability Test Planning

The details of the usability test can be found here.

We hit our first major setback in the project - the usability test we conducted did not reap meaningful results as the footfall in the area was lower than we expected. As such, we were unable to collect sufficient data to make a comparison between different implementations of our solution.

Morale was low and we became fixated on what could have gone wrong, and even started shooting down our parts of own solution. Perhaps it was because everything so far was so smooth-sailing that we expected a successful outcome. Looking back, we could have better prepared ourselves for handling a failed experiment by coming up with contingency plans in our usability testing - predicting what could go wrong and what we could do from there. This would help us see that a failure in the testing did not necessarily mean that our solution was bad, it could just mean that the test failed due to external variables such as bad weather resulting in low footfall. We experienced first-hand how easy it was to put on pessimistic lenses after a setback.

Day 10 - Usability Testing

Key Takeaways:
1. Predict what could go wrong with the usability testing and make contingency plans.
2. A failure in testing does not necessarily mean that our solution was bad, it could just mean that the test failed due to           external variables.


While thinking of how to proceed with our solution, with a schedule too tight to squeeze another usability testing in, we proceeded to the next step of getting our solution primed for implementation - recruiting people from the Annexe Communities to implement and sustain the solution.

We shared the solution in person with the Dreams and Aspirations group, a subcommunity of people hosted by the Annexe Communities. This group contains members of the communities who want to organise activities, events or help out in community efforts, such as our project.

We created a deck of slides to complement the explaining of our solution. However, during the presentation, we noticed some gaps in knowledge of the audience - for instance, most of them did not know about the Geocaching concept. However, after explaining it to them, they were able to see the value of it as part of our solution, and were very receptive to the overall solution.

Day 11 - Securing the Future

Day 12 - Preparing for Exhibition Day

Day 13 - Exhibition Day