August 2014 – April 2015 (on and off, not 100%) – Melbourne, Victoria

My Employer: Outware Mobile (Melbourne, Australia)

The Brief

Consumer Affairs Victoria, a state government department of Victoria in Australia, approached Outware with the intention of refreshing their existing RentRight app, and extending the functionality from hosting content for renters, to now include landlords as well. The app is designed to enable communication between renters and landlords, with email templates on different issues drafted up and then sent via email, and information resources. The major update for v2 would include:

• Refresh of the iOS design from iOS6 to iOS7
• Addition of Android as a platform
• Personalisation features
• Ability for landlords to communicate with renters using email templates
• Functionality for landlords to create condition reports, inspection reports and exit condition reports all through the app

My Role and Process

I came onto the project when the first draft of the iOS wireframes had been handed to the client. I then took over the UX role from the outgoing UX practitioner, and completed the Android wireframes in Omnigraffle, made iterations to the iOS wireframes, wrote formal user stories, and provided development and testing support.

Early 2015, the client ran the wireframes through independent user testing. I attended some of these sessions, and were able to see where the users were able to successfully complete tasks and achieve findability, and where they struggled. Based on these results, I refined the wireframes again for both platforms and created user stories for the developers to follow.

When development was close to finishing, I did a final review of the app, and ensured all functionality was correct, that the UI elements were right, and that the accessibility guidelines had been adhered to.

Challenges During the Project

An interesting angle on this project was the client’s requirement to adhere to the AA standards of accessibility. Being a government agency, they wanted the app to be inclusive to all possible users of the app. We followed the W3C guidelines for the web, and translated them to native apps. As a team, we wrote a blog post on how we did this, which I lead. I find accessibility to be incredibly interesting, as it promotes inclusion and should be a natural part of all internet-based projects.

One of the main functionality pieces of the app is the ability for landlords to create PDF reports. Prior to the app, all landlords were required by Victorian state law to complete paper reports for the property when a tenant pays a bond. A main app of this release was to add this functionality to the app, and therefore be able to add more detail, contextually. Rather than filling out an assessment for all rooms, and then attaching a bunch of printed photos to the report, photos could be contextually based under each room they belonged to, as well as any notes that a landlord wrote about a room also being positioned locally to the room. Working out the layout of the PDF was a challenge, due to the ordering of tasks within the app, whether a user filled out a room or not, and whether they added photos and/or notes to as assessment. I looked at the existing PDF report, and the user flow within the app, and worked on the business logic of showing, hiding, and ordering.

I had to work out the flow of the screens when creating a report, which I mapped out for the two platforms. The Android wireframes depict the user flow for assessing a room, prior to generating the PDF. The PDF report contexualised all information for a room, with the example showing one room and associated information in the PDF report.

Personalisation throughout the app was also a new addition in this release, and also had it’s challenges. Based on the type of the profile the user was (landlord or tenant), and then the status of the property (owned, owned and empty or tenant occupied), the app allowed access to different functionality. For example, when a landlord went to create a condition report, they could only select from properties they owned and were tenant occupied. A renter who did not own their property (and therefore were not a tenant) would not have any properties to select from, and thus couldn’t undertake a report. We also had legal considerations to think of, such as what point in the process that a bond number is issued. Since a renter will usually move into a property a day after a condition report has been completed by a landlord, they won’t have a bond number ready for the condition report, but will have one for following reports. Therefore, we didn’t make ‘bond number’ a mandatory field when filling out a property’s details. We also thought of properties with multiple tenants, and how the landlord could save all tenant details, and therefore then have all communication from the app reach all tenants, and not just a single tenant. We thought about accessibility during filling out these fields, and using permanent field labels (static on iOS in a two-column layout, and floating labels for Android), how to show errors (visual cue on iOS, and change of field label on Android), as well as using voice-over.

Examples of using permanent labels in forms for both platforms

Learnings

From the RentRight project, I learnt the following points:

• accessibility is incredibly important, and promotes inclusion. I had completed voice-over text before on another app; RentRight used many more accessibility features and therefore had a lot more that I needed to look out for. These elements, such a permanent field labeling, is something that I can use on all future projects
• business logic is incredibly important to get right – I worked on the PDF logic for a few days before being really happy with it. I sat down with the developers and testers and walked them through the printed report, and what we required in the app. Both of these actions and attention to detail resulted in the reports being delivered successfully
• users might not value the same prioritisation of features: watching user testing, I discovered that users prioritise different features to what I had initially thought. A very small piece of functionality – being able to add a reminder to a property, such as when to pay a bill or rent, was a very popular feature amongst all users. For me, this was just a single field on the ‘Property details’ screen, which then lead to a calendar entry screen. However this received very positive results in user testing, which then helped us to refocus on really refining this functionality, and elevating it on the screen (e.g. being able to add and/or edit a calendar entry from multiple places now, instead of just one).

Results

In April 2015, we released the Android and iOS apps to the respective stores, with both exceeding more than 5,000 downloads.

The app was the winner in the ‘Accessibility’ category for the ACCAN Apps For All Challenge, awarded September 2015. The second release which I worked on, which introduced accessibility features, as well as new features and an Android app, won the ‘Most Accessible Mainstream App’. Read more: http://accan.org.au/news-items/media-releases/1092-apps-winners-2015