Draft Lab+ work plan
Read the blog post about this Lab+ work.
April - June 2017
Draft for discussion and feedback
Life is about people, not agencies. When customers contact government they usually want to do something broader than the agency’s scope, but often services reflect agency priorities and silos. As we move to a digital by default model of service provision we need to place customers at the centre of service design but we also need a model for agencies enable cross agency, cross government and cross sector service delivery.
Lab+ is an experiment to explore how we can do this in a sustainable, scalable and effective way, that taps into the needs and natural motivations of citizens, agencies, private/community sectors, and the system as a whole.
Lab+ is also an “innovation lab” for government as a mechanism to bring together design, technology, information management and agile development for more rapid and targeted service design and development.
The Lab+ team
From the Department of Internal Affairs: the Service Innovation team with support from Government Information Services, the office of the Government CIO and experts across the agency
A broad cross section of agencies involved in various life events. We will add more specific information in coming weeks.
Various contractors including Assurity, Creative HQ and others.
By publishing everything we can publicly, we also include you, the broader community and companies, as part of our team.
- Test the “innovation lab” model for rapid design and delivery of integrated services
- Test the Federated Services Delivery, technical & integration assumptions
- Explore new operating model based on “government as a platform” with an ecosystem of service delivery
- Conduct the discovery/design for two life events/services & deliver a first iteration integrated service for one life event
- Apply agile + user centred design + engineering + evidence & analysis
- Deliver at least one reusable component
Lab+ planned outcomes
- Discover, design and implement alpha service for one life event including futurestate mockup and service finder
- Discovery for another life event
- Implementation plan for futurestate based on functional requirements
- Analyse system needs (the service delivery ecosystem, agencies, etc)
- Develop services register with public API
- Analyse of the Lab+ model for all of government (applied innovation lab)
- Create Service Innovation Toolkit update and lessons learned from Lab and Lab+
- Insights, designs, prototypes and code made available for public validation
- Showing what a cross branch, cross agency and cross disciplinary approach can achieve
The people problem
The traditional model of designing and delivering government services can not meet the modern needs of people. Individuals often see government as one entity, albeit with many agencies but they want to deal with the complexities of government structure to get what they need. Often user services appear to be designed for agencies first, so the individual experience remains inconsistent, split across different agencies and split across public and private sectors. People want the benefits of a connected government that meets their needs whilst respecting privacy and giving them more control over their experience.
The agency problem
Agencies are being asked to apply a “federated services” model to integrate their services for customers but because there is no reference implementation for this, they are having to undertake the financial and technical risk in interpreting what it means. Some agencies are heavily investing in APIs and channel strategies which are usually constrained to individual agency needs and would benefit from a holistic “Govt as a Platform” approach. Decision making is split along functional lines (eg information management, service design and ICT). Agencies are naturally constrained in scope & and motivated by their individual budgets, mandate and priorities but want to deliver and support better services and would benefit from engaging with and supporting an ecosystem of private and community sector service delivery.
The private/community sector problem
The private and community sectors are naturally motivated to deliver integrated services for citizens, but cannot access a lot of authoritative information, APIs or other programmatically available government data, content, transaction services or business rules in easily consumable ways. They often resort to scraping information and business rules which although more comprehensive across the public sector, are not highly accurate and are expensive to maintain. They also have to at some point refer citizens to individual agencies as the delivery of transaction services is limited to those agencies.
Solving the user, agency & sector problems
A systemic change is required that builds on the work of individual agencies combined with the natural motivation of a broader ecosystem to deliver integrated citizen services. If we build “government as a platform” wherein the data, content, transaction systems, business rules and common components of government are programmatically available, three key benefits emerge:
- people receive integrated services designed around their needs;
- agencies can more cheaply build and iterate their own services;
- private, community and public sectors can build integrated services; and
- the efficiencies of machine to machine automation, with citizen consent.
Moving from silos to integrated services
Text version of Figure 1. Moving from Silos to integrated services
Where do I go? There are so many doors that redirect!
When service information is siloed, people don’t know what agency delivers the service they need or where to find the service.
Information may be fragmented across agency, cross-agency, NGO or private sector websites. Agencies provide incomplete or contradictory information about a service making it difficult for people to get what they need. This can be seen in circumstances such as:
- private sector or community websites redirecting to agency services eg Citizens Advice Bureau
- cross-government information websites redirecting to agency services eg Govt.nz
- agency websites and systems redirecting to some common services
- standalone agency websites and systems.
No wrong door!
In an integrated services system, there is no wrong door for users. Consistent information is delivered through APIs using open data and served up by any organization that offers the services or information about the services. In integrated services:
- the system builds on user-consent driven automation
- uses common capabilities including but not limited to services register, identity, delegation, user consent, API, middleware, etc
- agency systems
- agency data
- agency rules
- agency content
- government API platforms / marketplace services range from completely secure to completely open
- allows authoritative integration by:
- agency services integrating their own APIs
- other agency services such as Govt.nz
- trusted private or community services consuming services
- or redirects by unknown private or community services consuming open services
User Centred Design + Technical + IM
Everything we do will be led by user centred design. Users include end users of government services and system users such as gov or non-gov service providers or M2M. This approach maps out the users, their needs, journey maps, and pain points. This will be compared against existing research for both validation and to identify areas where research, need or service delivery are heavily or lightly subscribed. It will also inform the future state mockup clickable journey to test a cross agency, cross sector ideal experience for users.
We will also apply modern technical and information management concepts to solving the user needs, so the future state and first version service are based not just on what could be for users, but what could be for the systems, technical architecture and policy frameworks of government.
Finally, how do we measure success in this space more broadly? This will be a critical question we explore throughout the process.
Review research and work done to date across agencies to identify problem areas, end users, system users, and other stakeholders.
Identify the user / stakeholder segments and describe / define corresponding profiles.
Interview users / stakeholders to identify user journeys, pain points, user and system needs unfiltered by sector or agency view.
Design future state mockup options that address user needs and reflects how the journey could look if not limited by current technology and organisational constraints.
Test future state options with users and identify functional, system and governance requirements for all of government.
Develop first iteration service based on future state to immediately improve user experience.
Validating design assumptions
|Additional design assumption to test||Proposed method of validation|
|Are the user needs already fully captured through existing approaches?||Compare user journey mapping with existing agency research and map where there is a focus on service delivery initiatives to date.|
|Information vs services.||Do users differentiate between information and services? At what point do they want to authenticate? How much do people want to interact with government if given the choice?|
|Government vs community/private sector service delivery.||Do users want single portals, myriad agency apps, many doors in, or do they differentiate strongly between private, community or government sector service delivery?|
|How do users see their circumstances?||Insights captured about the “life event” model.|
|How do we measure improvement?||User feedback on what “good” looks like to them.|
We will follow a full user centred service design process, and will test a lot of the usual assumptions therein. Below are a few additional considerations.
Validating technical assumptions
|Technical idea/assumption to test||Proposed method of validation|
|Federated services model: seamless digital services for users, consumable authoritative components (data, content, transaction services, business rules), personalisation?||Do users have to contact agencies (testing seamless federation)?Can components be consumed M2M, by 3rd parties, govt.nz?
What federated services exist and what is their takeup?
Functional requirements for futurestate mockup?
|What common service capabilities are needed?||Analysis of futurestate and system user needs. Possibilities include identity/auth, web platforms, service analytics, delegation, info, wallet, services register, business rules engine, etc.|
|Single solutions/doors versus federated solutions/many doors, and what is needed to enable an ecosystem of service delivery?||Test both approaches through futurestate with users, agencies & service providers. Collect system needs inc API discovery & marketplace needs.|
|Unauthenticated, authenticated & user consent.||Test options in futurestate with users, including consent by design.|
|Information sharing versus verifiable claims.||Test futurestate with users. Analyse where actual information required (eg, IRD number) vs where verification/eligibility is required (meeting a means test).|
|How hard is it to build integrated services?||Build one and assess how much effort it was to do so.|
|How do we measure progress/improvements?||Assess service analytics capability and requirements moving forward.|
Text version of Figure 2. Lab+ timeline
|May||1st Life Event||Begins discovery process. Experts invited to contribute ideas to the Future State mockup of the 1st Life Event.|
|1st Life Event||Future State mockup published for public feedback and testing|
|1st Life Event||MVP service design begins|
|Technical workshop||Technical workshop|
|2nd Life Event||Begins discovery process.|
|Service finder and register||Begins discovery process.|
|June||Service finder and register||MVP service finder version 1 built.|
|Technical workshop||Future State implementation|
|Ongoing||Weekly blogging, Open Lab showcases and feedback to validate outcomes|
- Last modified: