Client: Australian Government, Department of Human Services (Services Australia)
Date: 2019
Who is Services Australia?
Services Australia (The Department of Human Services) delivers Centrelink, Medicare and Child Support payments.
The Website Review Pilot Project was created to reduce serviceable delivery effort in the telephone channel (i.e. stop people calling); we created a proof-of-concept website for job seekers.
Our multi-disciplinary team created a digital solution which was data driven, lead by research and iteratively tested, developed and delivered in July 2019.
I joined at the beginning of the project with the Project Director.
Our multi-disciplinary team was established with a mix of consultants and full-time staff. We worked in two-week Agile sprints and travelled regularly to Canberra and Adelaide.
We collaborated using Miro (formerly Realtime Boards), Slack and GovTeams.
Our project followed the Australian Government Digital Service Standard and progressed through the stages of Discovery > Alpha > Beta > Live.
1. Discovery stage — overview
We began by conducting internal research which would allow us to define our problem.
My role was to support the data analytics and service designers. I assisted with speech analytics, comparative analysis, call listening and reviewing internal research (e.g. journey maps, consultancy reports)
I established the design environment by connecting with other project teams within the department. I reviewed design patterns across government agencies, the Australian Government Design System and past project work such as the Medicare beta website.
2. Discovery stage — early findings
The aim of discovery is to gain a deep understanding of the business problems and opportunities. Our data suggested we focus on the job seeker cohort (user group).
I helped preparing these findings for research playback to our sponsor groups and began preparing for our end-of-Discovery phase activity: the Design Jam.
The main problems brought forward was that customers can’t find what they need and don’t understand what they find. The existing environment was too complex.
Our pilot project had the opportunity to really help people by giving them the right information so they could make an informed decision.
Over 80% of people that use the existing website cannot find the information they sought, or could not understand the information they found.
3. Discovery stage — Design Jam
The discovery phase completed with a session to aired a plethora of ideas from the team and selected guests.
I took the end results of the Design Jam and formed them into solutions we could do something with.
I put aside the really-out-of-scope things then identified and grouped ideas according to themes. I sketched five loose ideas which distinctly captured most of what we discussed.
Our team then took these out to research.
The department is a complex entity, and many themes that were not in our remit to solve, continued to be brought up in research over the coming months.
4. Alpha stage — the process
Alpha is about developing and testing our hypotheses with users.
We iteratively refined the ideas from Discovery and once we began to hear the same things over and over, we knew we were on the right track.
These consistent themes were grouped in another design session, called “The Big Sketch” and these became pages in our prototypes.
We validated every two weeks, and I made a point to keep a track of discarded versions and ideas. We checked these each month to make make sure nothing major was missed.
We iterated with staff and customers, visiting service centres in arranged interviews, intercepts, and with people living with a disability. We tested Australia-wide and even in remote communities.
5. Alpha stage — iterating the prototype
In a hybrid UI/UX role, I developed the prototype in InVision and eventually used Anima for interactions, while working closely with the service designers.
I increased visual design fidelity by referencing multiple design systems. I presented findings at stakeholder meetings and design critique sessions with the Digital Transformation Agency and the DHS team in Canberra who look after the current humanservices.gov.au website.
Our team (and prototype) had ‘health checks’ to see how were were progressing with the Digital Service Standard.
I intentionally kept the design simple and not trendy, to make it feel relatable to people who may be experiencing multiple layers of disadvantage.
A few highlights that tested very well included listing the popular topics on the homepage according to top 11 call listening topics. A large, bold, single column site without a government look and feel, and minimal, accessibility-orientated aesthetic was well received. Many design elements were designed to be identified while talking over the phone (e.g. “click on the purple airplane’, or “scroll to the bottom and click on the purple box”.
“It doesn’t look like a Government website… and that’s why I like it!”
6. Alpha to Beta
With glowing results from Alpha, we progressed into Beta.
My attention turned toward creating a familiar interface of design patterns which worked across desktop and mobile.
I also created a video highlight reel in Premier Pro which summarised our research findings. This made our findings accessible to senior stakeholders.
As our team expanded, I also defined guidelines to assist with onboarding and making sure our Alpha work was maintained.
The site, although simple, clear and easy to use has a lot of nuances. I didn’t want our hard work being undone:
1. Language was to be conversational
2. To avoid information overload, a page would have “enough” general information to answer “most” peoples enquiries. For more detail, people could go to the existing humanservices website.
3. Accessibility, familiar design patterns and a lightweight device-agnostic tech build was non-negotiable.
7. Beta phase — pre-developer
Beta is about developing a minimum viable service and making it available to the public.
Until our development resource was brought on board, my role was to progress visual designs while incorporating user feedback and update the prototype.
To cope with this challenge I checked in regularly with the team so everyone was across the iterations. I kept the site lean and used as much approved content in my designs as possible.
This wasn’t a time to be perfect, it was a time for progress.
Beta introduced our site information architecture. We iterated around user stories.
8. Beta phase — post-developer
When our developer joined our team, things moved very quickly. I stepped away from research activities and now spent time on iterating the visual designs.
Feedback was largely technical or based around business requirements such as messaging, how outage notices looked, and surveys worked.
The main issue for the project team was now gaps in content and approval processes.
The department has many interested parties and many design elements changed frequently. We didn’t test the design specifically with users to avoid any tensions with the newly-launched department website, but did action feedback which was mentioned voluntarily.
9. Live phase and project summary
We launched our product in mid-July 2019 and continue to monitor the site via data analytics and user research sessions.
There were many challenges as we launched and although not necessarily visual design in nature, are part of working in a complex organisation where user-centred design in our team may not be how others work.
I'll wrap up the project by putting together a design pattern library and research documentation.