Well, the Service Innovation Lab (the Lab) at the Department of Internal Affairs (DIA) has celebrated its first year of existence. Together with our agency partners we’ve accomplished a lot and proved that there is a need for a place like this to bring people together to work on areas of shared interest.
Due to the nature of the Service Innovation work programme, our focus has been on government digital services for New Zealanders but also helping shift Government capability and capacity to better support these services. We’ve been reflecting as individuals and as a team on the work we’ve done within this context: what went well? What didn’t go so well? What can we learn to work better? This blog post reflects from a design perspective on the expectations about digital services and constraints we’ve noted plus how we’re using the learnings to inform how we do things in year two.
Expectations about digital services
Digital services are regarded as the preferred way of helping the majority of people navigate and access government services as they are often seen as low cost way to provide service. But, how successful they’ll be really depends on the quality of the design work that underpins them. There seems to be a perception that digital services are easy to make and because of this there is a rush to get more delivered and into the hands of people but the reality is quite different.
We’re all familiar with digital services that work really well: they are designed well, appear seamless and easy to use, plus meet extrinsic and more importantly the intrinsic motivations and needs the user has. This makes them successful. What people don’t see is:
- the design and development effort required to establish their viability from a economic and maintenance perspective
- feasibility from technical perspective
- the desirability from a user perspective.
The user experience really is the tip of the iceberg of what’s needed. Digital services are alive and there needs to be a clear and present ownership, plus consistently good development and design experience to keep the service current and relevant.
There is a lot of excitement and awareness about what technology can offer, but we’ve noticed a lack of understanding, knowledge and maturity associated with the creation of digital services in the public service. This places pressure on design and development teams who are expected to articulate opportunities and quickly turn these into a deployable service.
For things like a ‘life event' agencies are collectively not in a good position to identify systemic opportunities as they’ve never looked at services through this lens before and/or have never had the time or capacity to review. This is because of the pressures of just keeping up with business as usual work plus competing agendas and tight budget constraints.
As a result, it generally requires more customer research and service design work to identify the best opportunities for an integrated service. This will take time. However, the lessons from one will inform the next, and the pipeline to delivery will get faster over time. In the interim, specific improvements and changes to infrastructure (e.g. government as a platform, reusable components) are required to support life events transformation, and user-facing services will take more time.
Constraints to delivering
We’ve all got good intentions and the desire to create a great integrated digital government experience, but we’ve come across some constraints to our work. In addition to the understanding maturity, other constraints were: the limited capability and capacity to create services, access to subject matter experts and designers from agencies, but also a lack of understanding of what service design looks like and requires.
Further on this last point, hackathons, lean startups, accelerator programmes and other rapid innovation practices – while extremely valuable in helping people get an understanding on where to start – often give people the illusion that the design work required for a service is mostly complete and deployment is just a formality.
The reality is that the design work has only scratched the surface and more is needed to assess the viability, feasibility and desirability to a point where we know that the idea will meet the people’s needs. It will require deep research, lo-fi prototypes then advanced prototypes before alpha and beta phases of software development. Racing to alpha too quickly without the design work raises the risk that we will miss things and it won’t satisfy the needs of the users, or it might shift the problem onto others. Effectively good service design is a risk mitigation process.
This however does not mean it has to be a waterfall process, this would be a mistake. What we’ve found is that the best results occur when we have developers and designers working side by side as early as possible in the design process (e.g. Rates Rebates) and using an agile way of working complements this approach. It also reflects the type of people needed in our team: they are people who are good in their own field of expertise but can be also flexible and comfortable working with others in theirs.
So what’s next?
With the range and variety of work at the Lab we’ve been lucky enough to try a range of approaches: most of these are anchored in design theory (i.e. human centred design) but we’ve also used aspects of a lean start up. We’re working through how can we meet agency needs through better refined process that manages expectations for ourselves plus the partners who work with us. This will help us to:
-
Apply the right type of skills, methods and approach to a piece of work. This includes the scoping of problems and opportunities in order to create smaller pieces of work that will enable us to create outputs and outcomes faster and that are easier to measure.
-
Help onboard others on what we do and how to get involved as a individual, team or project – this includes new team members or new partners we are working with.
-
Better use our people within initiatives that we work with in the Lab. But also how we adjust our service to the constraints we’ve come across over the last year to better serve agencies. For example, how do we reduce the impact on resourcing and leveraging champions of this way of working from within other agencies and organisations?
It’s been a good start but there is plenty to do.
As always, interested in your thoughts and comments so please let us know.
If you'd like to stay across the work from the Service Innovation Lab, please join our mailing list.
Cheers
Glen
