Week #23 at the Digital Service: Notes for 4–7 October

Veröffentlicht am
A group of about 20 people of different ethnicities sitting on chairs and looking towards the right but outside of the photo

The week came and went fast. German Unity Day as a public holiday made it a short one, too.

For the second time in 2 weeks, a team member presented at a Berlin design meetup. After I approached the organiser in late May for the first time, my colleague Nadine grabbed the mic at the Berlin Product Designers meetup on Thursday. She spoke about designing public services that work for their users. It’s still a relatively new event series and is mainly run and attended by non-German speakers. Hosted at the AI Campus in Wedding, about 70 people showed up and had plenty of questions following Nadine’s presentation.

Attendees were interested in how to overcome practical challenges when working with bureaucratic public sector organisations, dealing with compliance when compensating user research participants, and thinking about data and long-term infrastructure.

The slides from Nadine’s talk are on GitHub, and we recorded the talk, so it should be on YouTube shortly.

Reflecting on the role of brands in public services

How should we approach branding in the context of public services and end-to-end service design? What role should brands play? And how might the approach be different to the private sector? I spent some hours contemplating these questions in the past few days.

When design should get in the way’ is an excellent articulation on the matter by my former colleague and friend Stephen. In the blog post, Stephen talks about the various products and service components developed by GDS and how they are visible when users interact with them as part of their service journey.

Logos of GOV.UK and its sub brands Pay, Sign In and Notify

There are various GOV.UK product brands, like GOV.UK Pay, GOV.UK Sign In or GOV.UK Notify. But they only matter for internal users – for civil servants but not citizens and other end users. So these brands only exist behind the curtain that’s never pulled for the users.

A person’s hand holding a smartphone showing two text messages, the most recent one saying: ‘Your new passport is being sent to the address you gave us. You should receive it within 2 days. Track you application at www.passport.service.gov.uk/track’

Users might receive a text message, email or letter from a service they interacted with – sent via the GOV.UK Notify component. However, from a brand perspective, only the service and GOV.UK as the home of the service are visible. The behind-the-scenes branding of the infrastructure remains hidden because there is no need to expose it.

Two screenshots of software interfaces with GOV.UK branding. On the left is a form asking for credit card details for a payment of £150, an end-user-facing interface with general GOV.UK branding.

On the right is a more detailed multi-field search dialogue with various fields and a table list below, a civil service-facing interface with dedicated GOV.UK Pay branding

The same happens in the interface: End-users only see the general GOV.UK brand when interacting with the GOV.UK Pay component integrated into a service. But civil servants managing payments for their service have a custom interface for this task. So specific branding only appears where it needs to be and for whom needs to see it.

Brands should give users orientation, lead them the right way and instruct where necessary. They should only exist where they help get users closer to their goal or desired outcome. Brands shouldn’t be in the way. Too many of them make recognition more difficult and reduce trust.

There are occasions when the user’s journey needs to leave the web-based service or transaction. GOVUK’s ID Check app is such a point that needs to be marked and branded. The user jumps from browser to app and back to the browser. The branding is as clearly related as possible. The sub brand’s name is a pragmatic description – saying what the app does: ID checks.

A screenshot from the Apple AppStore showing the GOV.UK ID Check app for iPhone with its branding and crown in the app icon and 4 illustrations of sample screens.

This pragmatic approach follows what others like Rebekah Barry and Tom Hewitson have proposed. In Rebekah’s words:

Good service names:

  • use the words users use
  • are based on analytics and user research
  • describe a task, not a technology
  • don’t need to change when policy or technology changes
  • are verbs, not nouns
  • don’t include government department or agency names
  • aren’t brand-driven or focused on marketing

Considering this, brands in the context of public services follow different rules and logic than their siblings in the private sector. Commercial organisations and companies need to cut through the noise of their competitors. They rely on brands and brand names that stand out from other products and services doing the same or a similar thing. They count on people to remember them, value them and return to them for spending more with them.

Public sector brands do not have to follow that logic as their ‘market’ conditions differ. There might still be different organisations providing products and parts of a service, but they can appear as one.

For the user, such a unified brand approach – as modelled by GOV.UK – reduces cognitive load and helps build trust.

In Germany, the current approach is still a little different. There are several vastly different brands and competing offerings when using public services online. They don’t follow a clear and coherent naming logic or even use the Federal government’s established style guide.

It requires a multi-actor coalition with senior backing to change that. But I am hopeful we can sort some things in the coming months and years.

What’s next

Next week, I’ll be in Freiburg in southwest Germany to help co-run Public Service Lab Day, co-present a short input, and co-deliver 2 workshops with my colleague Katja. There’s quite a bit of prep that still needs to be done.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert