Case Study - MyRates web app
Posted by Graham Nelson
To support the recent proposed changes to New Plymouth District Council Long Term Plan we launched a multi-purpose web app called MyRates. The purpose of the app was to explore the relationship between the proposed changes & the users' rates bill during a defined consultation period.
With broad goals like “empower the rate payer” and “reduce council workload” we set about defining the product. After many productive client workshops we had a clear set of goals that the product had to deliver on, these were:
- Show the average rates bill for the 2014/2015 year
- List the 5 Proposed changes to the Long Term Plan
- Allow the user to agree/disagree with the proposed changes
- View the impact of their decisions on the average rates bill
- Enter their address and view the impact on their rates bill
By accessing the council's rates database the last of these goals is probably the most powerful as it will give accurate up to date information on the users' rates and how the rates will be affected by the proposed changes, thus greatly reducing the load on Council staff receiving phone and email rates bill enquiries.
The time frames were tight yet with a well managed workflow we were able to take the product through various iterations, each a little better than the last and we hit our deadline producing a product we could all be proud of.
In this article I thought we’d share with you our process and how we dealt with some of the natural scope changes and testing outcomes that often arise to cause a product like this to adapt and change during development.
We’ve already touched on scoping and defining so let’s look at the next step in our process – wireframing.
Wireframing often begins with pen and paper before moving to a wireframing tool.
As with all projects of this type we quickly sketch out the app and its functionality through wireframing. Wireframing is a great way to bring usability to the centre of a project and gets the team and the client focusing on clarity, simplicity and outcomes. Wireframing also enables quick assessment of a product and its ability to meet project goals. You can find out more about wireframing here.
We do most of our wireframing using a dedicated wireframing tool which allows us to work quickly and iteratively, but often before we kick into this we’re sketching out ideas with pen and paper and on whiteboards - a super simple (and cheap) way to get conversation and debate happening.
We use the wireframe exercise to really refine and simplify the interaction in our app - reducing clicks and providing clear instruction up front.
One of our key learnings from this exercise was that some of our early assumptions were incorrect. For example, displaying the entire yearly spend of the Council on running the city was neither necessary or relevant to the users' tasks. We were also able to figure out how to handle some of the multi-step interactions on smaller screens and mobile devices.
It is important to work closely with the client when wireframing, as it gives them great insight into how we do things while also giving them an appreciation of the amount of work involved. Not to mention having them roll up their sleeves and pitch in with ideas gives them a greater sense of ownership – all worthwhile things in any project.
We do allow iteration in the design and even development phase but we also insist on having a clear blueprint of what needs to be built once the wireframe sessions are over.
Still low-Fi but quick to iterate on, wireframes are a great way to nut out complex interactions.
Our initial thoughts on visual design was to use a battery analogy to help reinforce the notion of rates powering the city. This worked well initially but as the information the app was dealing with changed with a view of simplifying things we quickly learned the battery analogy was not working as the battery would never reach the 100% full point. So we focused on creating a simple device loosely based on a barometer which used a mix of flat design, a vibrant colour scheme and an image of the Len Lye Wind Wand to create a friendly simple interface with an element of fun and place.
Another aspect of visual design we poured over was the type of button to use to encourage the user to add or remove each council proposal. These buttons caused much debate and went through various design changes and tests both internally and externally before it became clear the “switch button” provoked the best user interaction.
An early mood board
One of the early visual design treatments
Dealing with large data such as a council rates database for a city the size of New Plymouth and all the factors that impact on rates such as type of water supply, sub divisions etc. meant that our team had to work closely with Council stakeholders and the IT department to ensure a reliable calculation was happening each time a user input their address through our UI. Speed with which the information gets served up was also another problem to work thorough.
All in all our team did a great job working on MyRates and the app delivered on its goals! During the consultation period, engagement through the app was extensive and MyRates ended up as a finalist in the 2015 ALGIM Web & Digital Project of the Year Award. The information the app collected has been invaluable to the Council and has enabled public opinion to influence the decision on the proposed changes.
The consultation period is now over and so some of the app’s features have been stripped back to offer a new, quick and easy way for the New Plymouth public to access their rates information online – thus greatly reducing the number of calls made to the council's support team requesting rates figures.
Visit MyRates at myrates.npdc.nz