While designing for self service is probably the most important thing you can do to encourage people to use a platform, it is not the only factor. At different stages you may need to employ additional approaches including ensuring that early adopters become evangelists, learning to say ‘no’, and the smart use of mandates.

1. Use early adopters to demonstrate capability and build trust

While the aim should be to design for self-service and a broad user base, there will always be a first user. You will probably find more enthusiasm for teams looking to be the second or third adopter (once they can point to the fact someone else is using it). Give the 1st user ‘VIP treatment’, co-locating with them if necessary. Map out how you will make your team available to support and address their concerns.

Once a platform has been adopted by one team in an agency, it is likely that others will adopt it too. This is partly because of trust, and partly because any contractual problems will likely have been solved. Blog and talk about your work so other teams know this. Be open about what you are learning through user research and observed usage. If you are able to, publish your roadmap in the open.

2. Do ‘sales’

Explain to potential users across government and beyond how it will make their lives easier, as well as the lives of citizens. Be clear and confident about the value that you are delivering in terms of savings and usage. E.g. It’s going to ‘save this much time’ or ‘it’s going to be this much more valuable in terms of marginal costs’ or ‘your integration costs are going to be lower’.

Be open and transparent about costs to the users of your platform. Help them understand the unit costs and how those will reduce as more services use the platform. Do this even if they are not directly paying for the service (as it will help them understand the cost if that becomes nessesary in the future).

Inviting potential users to try the platform out, or showing a working prototype that uses it, is worth a million slick presentations.

3. Understand the risks of high-volume users early on in development

There are risks and opportunities around trying to get a platform adopted by high profile services, especially early on in its development. While it might lend credibility, it can also risk the platform becoming tightly coupled with the demands of one use-case. They may also have demands around scale and robustness that it might be hard to satisfy early on in development.

Don’t be afraid to say no to feature requests, even from big users, especially if it is unlikely to meet a common need that other users have.

4. Mandate the right thing (and only once it works)

While the aim should always be to design platforms that meet the needs of users and are so good they want to use it, there is a role for mandates. The key appears to be getting the level of the mandate or principles right.

At Google, for example, things that are mandated are high-level, rather than day-to-day - everything rolls-up to a higher objective.¹ In Estonia, the interoperability between different government agencies using the X-Road platform is not mandated by law, it is the product of a set of guiding principles. ²

Be careful about mandating the use of any particular platform and only consider it once you have proved it is useful.