Good digital services

Digital services rarely come about in one go. They come about in loops of observation, design, trial and correction. A considerable share of public IT projects misses its dates, its costs or its intended benefit.

The practices below describe an approach that lowers that risk. They are not a maturity model and not a standard. They are useful for taking stock, for preparing a procurement and for reaching an understanding between the specialist department, IT and external partners.

The checklist names actions that can be verified. The questions are for the conversation, not for sign-off.

Two notes first. One, the practices do not hold independently of each other. Several are in tension, for instance the call for small teams and the call for broad expertise. Those tensions are named where they occur. Two, no practice replaces checking the legal frame. Procurement law, data protection law and sector law set conditions that are not up for negotiation.

Start with the task people want to get done, and with the situation they are in when they do it. That holds whether the service addresses the public or the staff of your own organisation.

Administrative action is legally bound. The law lays down what a service has to do and what it may ask for. It does not usually lay down how the service is operated, in what order it asks and in what language it answers. That room is the subject of design. Organisational responsibilities are no argument for leaving it unused.

• Talk to people who will use the service, or who get the task done another way today, before the first draft.
• Combine qualitative and quantitative methods. Interviews explain causes, figures show how widespread something is.
• Test drafts in the environment the service will later be used in, wherever possible.
• Document goals, needs, behaviours and obstacles in a form later team members can read without asking.
• Put the findings to the management level, the uncomfortable ones included.
• Keep a prioritised list of the tasks users want to get done.
• Repeat the testing throughout development, not only at the start.

• Which groups use the service, and what task do they get done with it?
• Which groups will have the greatest difficulty, and why?
• Which research methods did you use, and why those?
• What were the findings that refuted your original assumption?
• Where is the documentation, and who has access to it?
• How often do you test with people outside the team?

A service does not end at the edge of the application. People move between form, telephone, counter, letter and application, often within a single case. A technically successful step helps little if the step before it creates a six-week wait.

Look at the chain of touchpoints, then, not at the single interface. The digital part should connect to the non-digital parts instead of duplicating them.

• Record every point at which people come into contact with the service, online and off.
• Name the places where cases break off or queries arise, and rank them by frequency and impact.
• Design the digital parts so that they connect to existing routes, to postal dispatch or appointment booking for instance.
• Define for each section how you will recognise that it works.
• Settle who is responsible for the transitions between sections. Experience says they fall between the organisational units.

• By what routes do people get the task done today?
• Where do cases break off, and what happens then?
• How does the project fit into the complete process?
• Which measures show whether the process works as a whole and not only the digital section?

A service should be usable without prior knowledge. That is a claim on the design, not a guarantee. Even a well-designed service needs help for cases that depart from the norm, and for people who need support.

Simplicity does not come from leaving information out but from ordering it. Language, sequence and feedback contribute more to it than the visual surface.

• Work with a short, binding design guide and with established web standards.
• Show at every point where in the process the user is and what still follows.
• Meet the recognised accessibility requirements and check them with assistive technology, not only with testing tools.
• Make it possible to interrupt a case and resume it later at the same place.
• Use the language of the users, not that of the statute. Where a legal term is needed, explain it on the spot.
• Keep language and design consistent across all touchpoints, the non-digital ones included.
• Keep a reachable route to help open, and measure which questions arrive there.

• Which tasks should the service carry, and which not?
• Is the language as undemanding as it can be without becoming imprecise?
• In which languages and in which versions is the service available?
• How do people get help, and how long do they wait for it?
• Which questions reach the help desk most often, and what does that say about the design?

Short development loops lower risk because they make wrong assumptions visible early. What matters is not the choice of a method but the ability to change software that has shipped.

Keep the team small. Small means the number of people making decisions every day, not the breadth of expertise available. Chapter 7 describes which competences have to be reachable. They do not all have to sit in the team permanently.

• Ship a first usable version that covers the main need. About three months is a workable guide, not a limit.
• Run usability tests at a fixed interval and derive the next steps of work from them.
• Keep the number of levels between team and decision low.
• Release changes several times a month.
• Keep prioritised lists for features and for defects.
• Use a version control system and give the whole team access to source code and issue tracking.
• Have changes reviewed by a second pair of eyes before they are merged.

• When was the first usable version shipped, and what delayed it?
• How long does a deployment to production take, from release to availability?
• How long is one iteration?
• What do you manage source code, defects and requirements with?
• How often do you review the prioritisation?
• How does feedback from use reach development, and how long does it take?
• Which gaps did the last usability tests show?

Contracts determine how much adjustment is possible during the term. A contract that lists features conclusively prevents exactly the corrections that make an iterative approach useful in the first place.

Procurement law requires a specification that is unambiguous and exhaustive. That does not rule out an iterative approach. It requires you to describe the procedure, the roles, the types of result and the acceptance criteria precisely instead of the single feature. Bring the procurement office in early, not only at the notice stage. Check which established contract templates for agile projects are available.

• Provide funds for research, exploration and prototyping, separately from the funds for implementation.
• Agree frequent, verifiable deliveries instead of a few large milestones.
• Define what delivery quality is measured by, and tie payment to it.
• Secure the right to change the order of implementation within the described frame.
• Require that open source software is examined during technology selection and that the reasons for the decision are documented.
• Regulate rights to source code, configuration, data and documentation so that passing them on and reusing them stays possible.
• Agree billing models that suit the usage pattern, consumption-based ones included.
• Agree a warranty period and a handover plan with named artefacts, not only with a date.

• What is the subject of the contract, and what are the deliverables?
• How often is delivery made, and what exactly is accepted?
• Which performance figures are agreed, response time, availability and fix deadlines for instance?
• What happens to source code, data and operational knowledge when the contract ends?
• Who decides on changes to the order, and within what deadline?

There has to be one person who decides on features and technical implementation and who stands behind the result. That person is answerable for whether the service covers the need that was established. That is what the service is measured by.

Shared responsibility slows decisions down and pushes them upwards. The name of the role is secondary. What matters is the actual authority to decide.

• Name a product owner in writing.
• Confirm among those involved that this person decides on features and implementation details.
• Look for a profile that combines professional steering with technical judgement. Without the latter, alternatives cannot be weighed.
• Equip the role with a work plan that states the funding needed and its sources.
• Provide a short route to the procurement office and to the management level.
• Record which decisions the role takes alone and which need approval.

• Who holds product responsibility, and since when?
• Which organisational changes were needed to make the role able to act?
• What steps are required to add or drop a feature, and how long do they take?
• What happens if the person is absent or changes?

Digital services need people who have already built and run comparable services. That holds for steering as much as for development and design.

Not every competence has to be permanently in the team. Security, data protection and law usually work in a supporting role. They still have to be reachable, from the start and not only at acceptance. Where external support is needed, you need a procurement office that can judge technical suitability.

• Look for experience with services that actually went into operation and carried load.
• Make sure experience with web and mobile applications is present in the team.
• Make sure automated testing is mastered.
• Make sure experience with continuous integration and delivery is present.
• Bring security expertise in before the design is settled.
• Bring the people responsible for data protection and law in as partners, not as an inspectorate at the end.
• Describe how knowledge is spread within the team, so that absence does not bring things to a halt.

• Which comparable services has the team already shipped and run?
• Which competences are in the team, which in the network, and how quickly are the latter reachable?
• How long does a new team member take to make a first productive contribution?
• How do you judge the technical suitability of suppliers, and who does it?

Technology decisions bind for a long time. They determine who can develop the service further, how fast that goes and what a change costs.

Popularity in the private sector is not a sufficient criterion for that. It says something about the labour market and little about suitability, operating life and replaceability. Decide instead on characteristics that can be checked: availability of expertise, state of maintenance and release rhythm, quality of the documentation, open interfaces, licence, and the question of what a replacement would look like.

• Record for every substantial decision which alternatives were examined and what the choice hung on.
• Examine open source software at every layer of the technology stack.
• Prefer components with open, documented interfaces and exportable data formats.
• Make sure the software can be run on common hardware and at more than one supplier.
• Keep instructions ready with which a local development environment comes about without asking.
• Assess the state of maintenance of every dependency before you take it on, and at a fixed interval afterwards.
• Describe for every tie to a supplier how a replacement would run and roughly what it would cost.

• What parts does the technology stack consist of, and why?
• Which data storage do you use, and which requirements has it met?
• Which dependencies would have to be rebuilt on a change of supplier?
• How long does a new team member take to reach a first working environment?

Services should run on infrastructure that carries load peaks without lead time. Where capacity is procured and installed by hand, waiting times arise that limit the development rhythm.

Adaptability and supplier independence pull in different directions. Managed services take operational effort away and increase the tie at the same time. Treat that as a trade-off with a documented outcome. Examine the place of processing, the legal basis of the data processing agreement, access by third parties, and the question of whether operation can be moved without a rebuild.

• Provide capacity on demand, without manual procurement steps.
• Let capacity follow actual demand, upwards as well as downwards.
• Procure and manage resources through an interface, not through forms.
• Fix the place of processing and check it against the data protection requirements before you add regions.
• Bill by actual consumption where that is cheaper for the load pattern.
• Deliver immutable content through a content delivery network.
• Run on standard hardware without particular requirements on individual parts.
• Keep configuration as versioned code, so the environment can be rebuilt.

• Where does the service run, and who processes which data in doing so?
• How does the service behave at a multiple of the usual load?
• How long does providing an additional instance take?
• How does operation bill, and how does that relate to the load pattern?
• Does the service run in more than one zone, and what speaks for or against that?
• How long does recovery after a data centre failure take, and has that been tried?
• What data redundancy is in place, and what would a complete data loss mean?
• How often do you have to contact the operator to solve a problem?

Automated tests lower the risk that a change damages existing behaviour. They replace neither manual checking nor professional acceptance. Their use lies in making frequent deployment defensible at all.

Automated deployment works in the same direction. Where a production release costs half a day of manual work, it is rarely done, and every deployment accordingly contains a great many changes.

• Cover the central paths of use with automated tests.
• Add integration tests for the interplay of the components.
• Run the tests on every build and stop the build on failure.
• Automate deployment, including the withdrawal of a faulty version.
• Run load and performance tests at a fixed interval, at least before the public launch.
• Record which areas are deliberately not tested automatically, and why.

• Which paths are covered, and which are not?
• How long does it take from the defect report to the fixed version in production?
• How long does the same take for a new feature?
• How often do builds run?
• Which tools do you use for testing, integration and deployment?
• How many concurrent accesses did the system carry in the last test?
• How does the service behave above that limit?

Security and data protection are not acceptance criteria at the end but a continuous task. Settle at the start of every larger change which data is collected, what for, how long it stays and who sees it.

Reuse lowers the effort. Components that have been checked and cleared once can be used in further services without repeating the check. That presupposes that check results are documented, versioned and findable.

• Determine together with the office responsible for data protection which data is collected, why, how it is stored and secured, and when it is deleted.
• Do not collect data that is not necessary for the purpose. Examine that question again with every new feature.
• Settle how users are informed about the processing and how they are notified in the event of a breach.
• Settle how users can see, correct and have their data deleted, and implement it.
• Keep a register of checked, reusable components with their clearance status and validity.
• Keep the configuration of the production environment as code, so that it stays traceable and restorable.
• Set up a public route for reporting security holes and describe how you respond to it.
• Have the service checked by third parties at a fixed interval.

• Which personal data does the service process, and on what legal basis?
• Does the service collect more than it needs? How did you check that?
• Can the data be used in a way users would not expect?
• Is data passed on to further bodies, and to which?
• How often and by what methods do you check for vulnerabilities?
• How does an outsider report a security problem, and how quickly do they get an answer?

Measure at every stage how well the service works. That concerns technical operation and use alike. Figures show where problems lie. They do not explain why. For the explanation you need the methods from chapter 1.

Add to the measurement a feedback route over which people can report problems directly. Before publishing any figures, check whether conclusions about individuals or about security properties can be drawn from them.

• Monitor load and performance of the system continuously, response time, throughput and error rate included.
• Set up alerts that go to a named on-call duty.
• Collect usage behaviour in aggregated form and to the extent needed for improvement.
• Publish central figures internally and, after checking, publicly as well.
• Keep a low-threshold route for defect reports open, and answer them.
• Define in advance for comparison tests which changes are permissible. For services there is a legal entitlement to, variants must not affect the outcome.
• Record an evaluation after incidents that names causes and derives measures.

• Which figures are the decisive ones for this service?
• How have they developed since the launch?
• Which mean response time do you aim for, and how are the values above it distributed?
• What volume do the most common cases have, and what share is completed?
• How high is availability, with and without planned maintenance?
• How does an alert reach the responsible person, and in what time?
• How do you measure satisfaction, and how sound is that method?

Openness concerns three things: the data of the service, its source code and the development process. It makes checking from outside easier, lowers the tie to individual suppliers and makes reuse possible.

Default does not mean without exception. Personal data, security-relevant configuration and third-party trade secrets stay out. What is required is that holding back is justified, not that publishing is.

• Provide data sets completely, both as a full dump and through an interface.
• Give data an open, internationally effective licence and name it unambiguously in one place. Datenlizenz Deutschland Zero 2.0 and Creative Commons Attribution 4.0 are widespread.
• Enter public data sets in the authority’s data register and in the relevant open data portal.
• Secure the rights to purpose-built software by contract, so that publishing stays possible.
• Publish source code under a recognised open source licence and keep the statement in repository, package metadata and documentation identical.
• Offer a documented interface if third parties are to integrate the service.
• Make the approach and the state of the work publicly visible, as far as that is possible without risk.
• Keep a route for defect reports open and respond to it traceably.
• Justify and document every decision against publishing.

• How do defect reports from the public reach you, and how do you answer them?
• Which interface exists, who uses it, and where is it documented?
• Under which licence do data and source code stand, and do all the statements agree?
• If the source code is not open: what is that decision based on?
• Which parts are already openly available, and which are to follow?