Drinking our own champagne: building a new dta.gov.au
Our new website recently went live. Our purpose was to create a new and improved website but it was also an opportunity to do things ‘the DTA way’.
When we first started redeveloping dta.gov.au, we knew we had to practice what we preach: we need to follow our own advice, policies and guides.
- Follow the Digital Service Standard
- Use our service design and delivery process
- Use the Design System, Content Guide and cloud.gov.au
- Follow our culture values.
Content editors had to write great content and perfect code, understand git workflows and errors. Making simultaneous updates and approving embargoed content was difficult. It was sometimes impossible to resolve the problems caused by multiple authors.
These challenges meant the Communications team could not provide the service we wanted. We needed a content management system.
Towards the middle of 2017, we kicked off a project to rebuild dta.gov.au using Drupal.
Solid fundamentals are vital to a project of this nature: trust, teamwork, a common vision and knowing you can rely on the expertise of others.
What we learnt:
- Start right with a good mix of skills, styles and personalities. Balance out skills early and change the team as your project changes.
- Do user research early and often. Get involved and check back on your progress, test and re-test and recognise and question assumptions.
- Use expertise and tools already available. Push boundaries, but don’t do someone else’s work again. Choose obvious over clever every time.
- Follow a service design and delivery model and the DSS, even if it’s hard.
One of the DTA’s culture values is ‘only new mistakes’, so if we help others avoid making the same mistakes, we have lived that value. So how did we rebuild dta.gov.au using Drupal?
Deciding on Drupal 8
A few factors led us to Drupal 8.
Given our role as an agency supporting digital transformation, it was a good approach to use the latest version of any platform we planned to use. Redevelopment at Drupal 7’s end-of-life in 2021 or a Drupal 7 to Drupal 9 migration were not attractive options.
We also wanted to support GovCMS, so while the alpha of GovCMS8 wasn’t suited to the DTA’s needs, it provided a great starting point.
Lastly, we needed safe and reliable deployment onto cloud.gov.au. We already had an internal proof-of-concept, so the work was to create reliable continuous deployment and integration workflows.
Building the right team
You can’t make a good product without a good team, and this is especially true of DTA products.
Working in a multidisciplinary team following an agile methodology, the size of our team changed during the project to reflect the project phase and meet our sprint goals.
Discovery can be ill-defined, and without a dedicated, full-time team, opportunities can be missed. The team was not balanced well and project output focused on content. Technical decisions reflected that.
During discovery there were 3 part-time roles:
- Product owner
- Content lead driving work around our audience and business needs
- Technical lead advising on technology
When the project passed the first 3 criteria for the Digital Service Standard, it moved into Alpha. The project was formalised and resources were made available. The team added a:
- Content designer
- Information architect
- Delivery manager
- Interaction designer
Only the content designer and information architect roles were full-time. The technical and content leads shared the delivery manager role.
Fewer resources mean less output, and role-sharing creates conflicts of interest. This became a real concern and as the roles concentrated on content, it reinforced the existing imbalance and continued to push technical delivery into the background.
During Beta we enhanced functionality, processes and systems, and did user research. With less content resources we achieved the right balance of skills. We also added a part-time user researcher.
Beta gave us space to work on things we couldn’t do during Alpha. For me, this was our deployment scripts, workflow, figuring out Composer, building functionality, and aligning the site with the Design System.
Management of the site is now business as usual. We continue to make improvements to the site based on internal and external user feedback.
A team only makes the best products if it knows who uses the service, what they’re thinking, and what they want.
During Alpha, our information architect tested the site structure using Tree Jack. The user indicates where they expect to find the answer to a content question in the proposed structure. We can then iterate over the information architecture and test it again.
We tested the first 2 iterations internally, getting feedback quickly and solidifying our direction. However, this set up future failures, as we baked in assumptions about how external users would behave.
Our Beta user research discovered these problems and we are working to resolve them. Each sprint, dedicated user research planning sessions and sharebacks built empathy with our users and developed the team’s user research skills.
The Design System is a set of accessible components designed and tested for Australian Government use. Based on thorough user research, each component comes with lots of background information and a rationale. It includes a grid, a font scaling system and other useful tools.
Implementing it in Drupal 8 was an interesting challenge and forced me to engage more deeply with the Design System and Drupal. If you’re interested in what I incorporated in the Design System, please check out the theme repository.
We will continue to undertake user research and respond to feedback on our site, making improvements to meet user needs and improve functionality. If you have any feedback, or would like more information on what we did, how or why - get in touch at email@example.com.