The way services get created changes in a platform ecosystem. Rather than being built from scratch, they are assembled from common components.

This characteristic, used in combination with a service design approach, means new types of service could become possible (or at least much simpler to create). These include services that allow people to interact with multiple parts of government at the same time, real-time services, and services from the public, private and third sector that overlap and complement each other.

1. Design services, not policies

In a platform ecosystem, designing new services largely becomes a job of joining together platforms. With this reduced effort and reduced duplication comes the potential to save time and money. However, increased efficiency is not the most significant opportunity.

The biggest opportunity is the potential for radically better public services. That’s because it does not just become simpler and quicker to design services, it also becomes simpler to design new types of service that are designed around the needs of a user rather than the organizational structure of government.¹ Looking around the world, we can begin to see that approach happening.

Estonia is starting to design new services around ‘life events’, like having a child, that transcend the boundaries of government agencies. They can do this because of the common cross-government data infrastructure they have developed.² Singapore’s GovTech agency is following a similar approach and has developed a “Moments of Life” service.³

The UK government Service Standard (which all new government services must meet) includes the following requirement for teams designing services to work beyond the boundaries of an individual government agency:

“Work towards creating a service that solves one whole problem for users, collaborating across organizational boundaries where necessary”⁴

Also in the UK, the different steps needed to complete a task like ‘employing someone’ or ‘learning to drive’ organized in one place on the GOV.UK website, regardless of which government agency a user has to interact with.⁵

Take advantage of the opportunity of platforms design services to solve whole problems for people. Look for opportunities to make end-to-end service design part of official guidance and governance processes.

2. Think of services as built from many platforms

Just as platforms are part of many services, so services are made from many platforms. This means that a team designing the service can focus on the areas that are unique to the domain they are working in, and prototype a working service much faster.

A great example is the Christmas tree permitting service operated by the U.S. Forest Service that allows people to legally harvest a Christmas tree for their home from a national forest. The service uses pay.gov (to take payments), login.gov (for authentication), is hosted on cloud.gov, and uses a generic permits API.^{6 7}. The user interface is built using the U.S. Web Design system as a base.⁸

The other implication of this one-to-many principle is that a service team will not have control over the entire user journey, and this may take some adjustment for teams used to controlling the totality of the user experience.

When designing services that use platforms, understand what existing platforms you could use to develop your service. Work in the open and maintain good communications with teams operating platforms so you can ensure you understand any upcoming changes.

3. Allow for multiple, overlapping services, built on a common platform

Historically, policymakers have had a couple of clear, choices to make when it comes to the delivery of a service to the public. Should it be delivered centrally or locally? Should it be done by the private sector or the public sector? A healthy platform ecosystem could start to turn those choices into false choices.

That’s because it allows governments to follow both a retail approach to providing services (where government offers a public-facing service) and a wholesale one (where the charities and private companies also provide services).⁹

Because platforms do the “heavy lifting”, it becomes more feasible to build multiple services on top of them. These services could be provided by any layer of government, and by commercial or third sector organizations, in such a way that is ok if they overlap, complement or duplicate each other.

One recent example of this wholesale and retail approach is recreation.gov, which is a public-facing government service for finding and booking campsites and tours on federal land. It is built on an API that is also used by a commercial vacation website.¹⁰ These services overlap and to some extent compete with each other, but serve slightly different audiences.

It could also become much simpler to interact with multiple layers of government at once in a single service. Designing services that allow people to interact with central and local government within a single service.

4. Design real-time services (but be cautious of the risks)

One of the characteristics of modern digital services is that they operate in real-time. If you want to buy something on Amazon, you see if it’s out-of-stock immediately, and pricing on Uber responds to demand in real-time. The teams operating those services also benefit from real-time feedback loops so they can see where users are getting stuck and what’s not working as it should.

Registers, and shared APIs should make these things simpler for government services, so that, for example, users could track the exact point in the process their welfare application is at.

Real-time services will also come with new risks. For example, the Indian hotel chain Oyo plans to share guests check-in data with state governments in real-time (replacing an existing, manual process). The company’s motivation is to reduce errors and make things faster for hoteliers and guests. But it has also raised concerns from privacy campaigners about the affordances and unintended consequences of such as system.^{11 12 13}

When designing real-time services, a key decision for services designers is going to be where there should be a human in the loop.

Design services that take advantage of the real-time nature of platforms, but consider negative consequences as well as opportunities.

5. Design event-driven services

Lots of government services require people to report when things in their life change, and this places a lot of responsibility on the user - they need a good mental model of the service to know what to report when and how. (The UK’s Universal Credit benefits system requires people to internalize over 30 types of change-of-circumstance!)¹⁴

A different approach is to design services that both respond to events, and make use of data held elsewhere. Trust and identity systems, along with shared APIs and registers could make it simpler to design services that forgo the need for lots of secondary digital transactions (things like ‘update this’, ‘report that’, ‘change this’, ‘re-apply for that’.)

Rather than placing the burden on users, look for opportunities to use APIs and registers to design services that proactively meet the needs of users based on events.

Example: Building U.S. Forest Service Christmas tree permits service on-top of platforms

The Christmas tree permitting service operated by the U.S. Forest Service lets people to legally harvest a Christmas tree for their home from a national forest. It’s built on top off several platforms, including pay.gov and cloud.gov.

“Before Open Forest, there was no online purchasing option for these permits, limiting the public to buying permits at mostly remote USFS district offices or sometimes from local vendors during weekday business hours. From launch to the the end of the holiday season, Open Forest sold nearly 5,000 permits across the four pilot forests.”

“Though 18F has delivered many products to production since its founding in 2014, this is our first product to include payment functionality. Purchasers can use their credit card, debit card, or bank account number to pay for a permit through the U.S. Department of the Treasury’s Pay.gov. Leveraging this existing service helped us implement a modular approach; our product team focused on the unique Christmas tree sale process, rather than reinventing how to make a secure payment. For the Forest Service staff in the district offices, it minimized the administrative burden of processing large sums of cash.”

“Why did we design and build a print-at-home solution rather than a mobile one? With limited cellular service and temperatures dropping below freezing that can quickly drain a mobile phone battery, a digital solution might not be that durable.” — Laura Gerhardt, 18F (extract from a blog post) ¹⁵