Discovery playback – domain name administration

At the DTA we are responsible for managing the .gov.au second level domain (2LD). We want to build a new domain name administration service that is easy to use, secure and efficient, and the first step towards this was our Discovery phase. 

four people working on a discovery activity

Domain name administration is a technical and relatively obscure task, usually taken care of by our trusty IT administrators. However all government websites and services rely on a secure domain name.  

As the .gov.au registrar, DTA is responsible for approving and managing .gov.au domain names, for example dta.gov.au. Once approved, the .gov.au domain name data is passed to the Top Level Domain (TLD) .au registry. The registry maintains a master list of gov.au domain names, which is used to point internet users to the right websites when they search for a domain name.

Previously, domainname.gov.au was a self-service portal which included a payment service.

The portal was a proprietary product, meaning we had limited control over it and could not build on it to improve the service. The portal was retired in early 2018 with the temporary solution that the DTA will pay for and provide manual processing for all .gov.au domains.

Currently we are responsible for:

  • domain management, including changing name servers

  • assessing Australian Government and state and territory government domain name applications against the policies and registering once approved

  • support for the domainname.gov.au website

  • 24-hour emergency support   

State and territory governments are responsible for approving domain names in their third level (3LD) state or territory domain. Once approved, they are sent back to us for registration.

Discovery

We are using the service design and delivery process to build a user-centred service that will be simple, fast and clear. The purpose of Discovery is to get a deep understanding of the problems users are trying to solve. It helps us to challenge existing ideas of what the problem and solution might be.

Discovery activities

  1. Discovery kick-off

  2. desktop research

  3. 9 user interviews

  4. Discovery analysis and synthesis

  5. findings and recommendations

Desktop research

We began Discovery by completing a number of desktop research activities, including reviewing the current system, speaking with other government agencies, and researching the private sector for market comparisons.

United States government domain administration:

  • self-service portal

  • $400 USD per .gov domain, however they warned us that there is increased cost involved in collecting fees as it means the system is more complex and expensive to build and run

  • 5000-5300 .gov domains.

New Zealand government domain administration:

  • self-service portal, customised for approval process, off-the-shelf for domain management

  • portal uses two-factor authentication

  • currently no cost to register a .govt.nz

  • provides a Domain Name Server (DNS) service

  • planning to host other domains in the future, for example .co.nz

Private sector offerings include other features like:

  • DNS hosting options

  • availability search integrated with the application process

  • suggested domains

  • price view up front of domain names

  • responsive design/eligibility feedback

  • security - SSL, WhoIsGuard, PremDNS

  • domain manager

  • DIY website builder

  • live chat support

  • payment system and invoicing

User research

We developed a user research canvas to help us identify why we were conducting user research — our objectives, who our users are, what we knew, the stakeholders, our assumptions, time frames, questions, research methods and other considerations.

A series of comments on post-it notes grouped in the following categories: Why, Objectives, Who are our users, What do we know, Stakeholders, Questions, Research methods, Assumptions, When, other things to consider

Caption: Example populated User Research Canvas

User interviews

Then the fun part, we spoke with our users — 7 domain managers and 2 state administrators, from Perth, Sydney, Canberra and Melbourne. We captured their comments on post-it notes, which we then synthesised into themes, opportunities and ‘how might we’ statements.

Text on post it notes is not legible

‘How might we’ statements

Users want

  • secure and personalised access

  • renewals to be available and clear

  • a simple payment system that meets their department’s requirements

  • to enter information once - interface intelligence

  • an easy way to view and manage their account

  • the option to say yes/no to DTA DNS management

How might we…develop an intelligent, automated, secure product that builds on the features users enjoyed previously and showcases the DTA approach?

Users want

  • simple and clear information, without needing to read a lot

  • greater control and automation in a faster service

  • to understand what the process is and where they’re up to

How might we…design a faster, simpler, clearer domain service and reduce manual work for internal and external users?

Users want

  • responsive assistance

  • reliable guidance from DTA

  • reassurance that DTA is on their side

  • DTA to understand who is using their own site, how and why

How might we…assist, guide, reassure and understand our users?

Users want

  • to hear from each other and learn from their community

  • to contribute and stay up-to-date

How might we…help our users feel involved and assist them to build a community?

Users want

  • to know about all the available DTA products and services

  • to create human-centred services

How might we…engage our users with our products and services to assist them in creating human-centred services?

Personas

Personas represent fictitious people who are based on our knowledge of real users. We identified four user segments for domain name administration, resulting in the following personas:

  • IT team lead - Joe

  • state domain administrator - Beth

  • DTA .gov.au domain administrator - Mark

  • digital delivery - Sally

Creating personas helps us to understand the needs of specific user groups and gives us a shared understanding of our users in terms of their needs, behaviours and goals. They help us to ‘anchor’ design decisions back to the needs of user types. For example, ‘how often would Sally need to do this?’

Journey maps

To help us really step into the user’s shoes, we used our personas to develop journey maps. A journey map shows all the steps in the process that our user is trying to complete, from the user’s point of view. We focussed on what the user was doing, thinking and feeling. The journey maps helped expose user needs and pain points.

 The steps taken by each persona to complete specific tasks are represented by post-it notes in four rows, one for each persona. Text on post-its isn't legible. A fifth row represents the channel each step occurs in, with labelled icons representing 'in person', 'user's internal system', 'DNA website', "email' and 'Zendesk'. A fifth row maps the feelings of the personas at each step, represented by three 'face' icons, smiley face, straight mouthed face, and sad face

Domain name administration pain points

  1. too many manual processes

  2. too many people involved in approvals

  3. multiple channels that aren’t integrated
     

Design principles

  1. ask for information once

  2. optimise for one session

  3. lead by example - simple, clear, fast

  4. secure service

  5. access control

  6. showcase existing technologies (for example, Design System, cloud.gov.au, GA360)

Brainstorming

Part 1

We held a two-hour brainstorming session where we took our 5 ‘How might we’ statements and generated as many ideas as possible that address user wants and needs.

We then voted on these ideas to identify priorities for the user and grouped them into themes.

Part 2

At our second brainstorming session we reviewed the priority ideas, then individually sketched as many ideas as we could in 45 minutes.

Concepts were presented back and we established a broad understanding of the hypothesis to explore in Alpha.

Key hypotheses

In all we developed 26 hypotheses across 5 categories:

  • secure write

  • help

  • pay

  • additional services

  • technical

Below is a sample of the key hypotheses selected for testing in the Alpha stage

We believe:

  • providing write access to authorised users will achieve quicker completion times and reduce, or even eliminate, involvement from DTA

  • providing the domain name application form as a step-by-step guided flow for registered users will result in more accurate information being provided and reduce rejection rates

  • that giving registered users the ability to manage their personal details will enable them to update details if incorrect without the need to contact DTA

  • providing contextual help will assist users to understand what information they need to provide at each step, reducing confusion and enquiries to DTA

  • continuing to provide personal assistance from the DTA team will help users resolve enquiries that are not addressed by the system

  • introducing an online payment system for agency admins, managers, finance users, will achieve less confusion for agency users, less manual work for all users and more payments received on time

  • offering a DNS service to all agency users, will achieve a reduced number of pain points by moving across to another channel to make the updates with external provider

Next Steps

The next stage is Alpha, where we test our hypotheses by building and testing prototypes. The results of these tests will determine our Minimum Viable Product (MVP) for Beta. We’re looking forward to sharing our findings with you at the end of Alpha.