For the last 5 months the Design System team has been building a government service…designed to help users build better government services. We’ve worked following our own design standards to guide us. The team is committed to making all our decisions based on evidence. For this reason, when we started, we didn’t know where we’d end up.
Discovery
In May 2020 we began Discovery knowing that many people were using the design standards and the guides on digital.nsw. What we didn’t know is:
- Who our users were
- How they use the content (standards and guides)
- Whether the content is fit for purpose or if something else was need.
After extensive user research (interviewing 17 people in weeks), we found:
-
Across government there is a wide range of digital maturity. Different teams need different types of support.
-
Teams don’t always have the right capability in their teams and will often rely on resources like the standards and guides to help with their research.
-
As one user told us: “We need resources that help people think about the end to end process. Not the current way of thinking which is "add a payment gateway to this form”
This last point was reflected to us several times and we learnt that there is a gap in knowing how to deliver a service end to end.
Alpha
We began Alpha seeking to transform the pains into opportunities via ‘How Might We’ statements.
Pain point: teams want guides that tell them the NSW approach to delivering a service, and they want to when to apply them in the build process.
Opportunity: HMW we restructure the information architecture and content in the Guides so it’s easier for users to:
- know what information is available to them in each phase of the service design process
- be able to easily access and navigate to the relevant information
We brainstormed what this opportunity would look like. After vigorous debate and discussion, we decided to structure the guides by service design phase and show users what to do in each phase.
We built a low-fidelity prototype that tried to show users what they need upfront, and what stage they are up to in their project.
After several rounds of testing and iterating we learnt:
- Language matters! If you don’t get your titles for different sections of the guides people will easily get confused.
- Finding the balance between using plain English and industry specific language is hard. Lower capability might not know terms like “discovery, alpha and beta” however, it is incredibly useful for most medium to high capability teams.
Beta
We’re now in Beta we’re still struggling with tightening up our language. We’re going to go live in a matter of weeks. Keep an eye out!
For now listen to my colleagues as they reflect on what they’ve learnt through this process
James Fehon: Do user research early and often
Natalie Chehade: when we’re creating something, it’s tempting to want to come up with novel ideas or approaches – don’t underestimate reusing what’s out there. If it works and is backed by research, it can save you a lot of time and helps create a solid foundation for you to make improvements.
Siew Lee Seow: We walk the talk by using the service manual. The key ingredient to its success is being disciplined to hold back personal biases and jumping to insights and solutions. It requires adherence to users’ feedback and respect for fellow teammates’ perspectives to find the heart of the pain points. It’s hard but it reduces the risk of solving the wrong problems
Hamish Stead: Teams are keen to have an endorsed steer on ways of working “Just tell me what the NSW way of doing this is.”
We’re constantly iterating and can’t wait to share with you what we’ve been building!
