Darllenwch y blog hwn yn Gymraeg / Read this blog post in Welsh.
Following the Welsh Language Act 1993, all public services in Wales should be available in Welsh, and the language should be treated no less favourably than English. In practice, this often means services are designed in English then translated into Welsh - usually during the Beta phase. At this point, the design and journey is quite fixed, but what if it doesn’t work for Welsh users?
The Welsh Government has an ambition to achieve a million people speaking Welsh by 2050, and we need to support that.
During our discovery project to support the Welsh Government’s Council Tax reform programme, we wanted to bring Welsh language in from the beginning of the design process. This meant including Welsh at Discovery and Alpha phases rather than waiting until Beta and Live. Here are some reflections based on the things we’ve done so far.
While we’re fortunate to have two Welsh speakers in our team, we also included Welsh in the foundations of how we work. This has included:
Getting the whole service team – not just the design team – on the same page and understanding why it’s important has been essential. One of our developers has also started to learn Welsh!
We met with the Welsh Language Unit (WLU) to introduce ourselves and understand how we can work with them. We got to know the translation process and captured this in our documentation. We invited the WLU to our show and tells demonstrating our progress and learnings, and continue to meet with them regularly.
We also learnt about the history of the Welsh language and how people were told not to speak Welsh. This was known as Welsh Not. This increased our empathy for how important it is to Welsh people and their identity to be able to use Welsh.
We also met with people working on GOV.UK One Login to find out how we could help users carry their language choice across a whole service.
We recognise there are teams already doing great work on bilingual services already so we reached out to learn from their work.
We met with Osian Jones and Adrián Ortega at the Centre for Digital Public Services which partners with organisations to build public services across Wales. They talked about trio writing and how using this method, which includes a content designer, subject matter expert and a translator, had helped them write more natural sounding Welsh content and improved the clarity of the English content as a result.
We’ve been working closely with the WLU to propose a trial of working this way together and finding a compromise that considers their team capacity and merging existing ways of working to make this an option for us all. We’re hoping to trial trio writing with the WLU in Cardiff in 2024.
We also spoke with Nia Campbell, a Welsh speaking content designer at the Ministry of Justice, who is working with an English speaking user researcher to conduct research in Welsh, and who stressed how important it is to make sure if a participant is taking part in research as a Welsh speaker, all of their communication should be available in Welsh, including consent forms.
By reaching out to the wider design community we were introduced to new resources like Helo Blod, a free Welsh translation and advice service, invited to join the Designing Welsh language products and services online meetup (for an invite get in touch with Nia) and joined the Centre for Digital Public Services communities of practice.
A key part of this was being willing to meet people where they are. Our user researchers went to libraries in Wrexham and spoke to the public there, equipped with recruitment posters and conceptual mock ups in both Welsh and English.
Another benefit of reaching out to the wider communities was learning about Welsh cultural events like the annual Eisteddfod festival which celebrates the Welsh language. We’re now considering the Eisteddfod and similar events as an avenue for recruiting Welsh speaking research participants, pushing us beyond the standard recruitment channels.
Though our project focuses on the Welsh language, the principles listed here could be used to support the creation of other bilingual public services. For example, when the service is primarily for people who use English as a second language.
On our project, we’re fortunate to be given the space and directive to really focus on the language. Even if, as design teams, we’re not able to action all of these, showing positive intent and willingness to learn and adapt, even in small ways, has been essential for us.
Abbie Foxton, Dylunydd Cynnwys, Asiantaeth y Swyddfa Brisio
Darllenwch y blog hwn yn Saesneg / Read this blog post in English.
Yn dilyn Deddf yr Iaith Gymraeg 1993, dylai pob gwasanaeth cyhoeddus yng Nghymru fod ar gael yn Gymraeg, ac ni ddylid trin yr iaith yn llai ffafriol na’r Saesneg. Yn ymarferol, mae hyn yn aml yn golygu bod gwasanaethau’n cael eu dylunio yn Saesneg ac yna eu cyfieithu i’r Gymraeg – fel arfer yn ystod y cyfnod Beta. Bryd hynny, mae’r dyluniad a’r daith yn eithaf sefydlog, ond beth os nad ydyn nhw’n gweithio i ddefnyddwyr Cymraeg?
Mae gan Lywodraeth Cymru uchelgais i gyrraedd targed o filiwn o siaradwyr Cymraeg erbyn 2050, ac mae angen i ni gefnogi hynny.
Yn ystod ein prosiect darganfod i gefnogi rhaglen Llywodraeth Cymru er mwyn diwygio’r Dreth Gyngor, roedden ni am ystyried y Gymraeg o gychwyn cyntaf y broses ddylunio. Roedd hynny’n golygu cynnwys y Gymraeg yn ystod y cyfnodau Darganfod ac Alffa, yn hytrach nag aros tan y cyfnodau Beta a Byw. Dyma rai sylwadau yn seiliedig ar y pethau rydyn ni wedi’u gwneud hyd yn hyn.
Er ein bod ni’n ffodus o fod â dau siaradwr Cymraeg yn ein tîm, gwnaethon ni hefyd gynnwys y Gymraeg yn sylfeini’r ffordd rydyn ni’n gweithio. Mae hyn wedi cynnwys:
Mae sicrhau bod y tîm gwasanaeth cyfan – nid dim ond y tîm dylunio – ar yr un dudalen ac yn deall pam mae’r Gymraeg yn bwysig wedi bod yn hanfodol. Mae un o’n datblygwyr hefyd wedi dechrau dysgu Cymraeg!
Cawson ni gyfarfod gyda’r Uned Iaith Gymraeg (WLU) i gyflwyno ein hunain ac i ddeall sut y gallwn ni weithio gyda nhw. Daethon ni yn gyfarwydd â’r broses gyfieithu, a chofnodi hyn yn ein dogfennaeth. Gwnaethon ni wahodd yr Uned i’n sesiynau ‘dangos a dysgu’, i ddangos y cynnydd rydyn ni wedi’i wneud a’r pethau rydyn ni wedi’u dysgu, ac rydyn ni’n parhau i gwrdd â’r Uned yn rheolaidd.
Dysgon ni hefyd am hanes yr iaith Gymraeg a sut y dywedwyd wrth bobl am beidio â siarad Cymraeg. ‘Welsh Not’ oedd yr enw ar hyn. Gwnaeth hyn godi ein dealltwriaeth o ran pa mor bwysig yw hi i’r Cymry allu defnyddio’r Gymraeg, ac o ran ei phwysigrwydd i’w hunaniaeth.
Gwnaethon ni hefyd gwrdd â phobl sy’n gweithio ar y prosiect One Login ar GOV.UK i ddysgu sut y gallen ni helpu defnyddwyr i gadw eu dewis iaith ar draws gwasanaeth cyfan.
Rydyn ni’n cydnabod bod timau eisoes yn gwneud gwaith gwych ar wasanaethau dwyieithog, felly gwnaethon ni ymgysylltu â nhw i ddysgu o’u gwaith.
Gwnaethon ni gwrdd ag Osian Jones ac Adrián Ortega yn y Ganolfan Gwasanaethau Cyhoeddus Digidol, sy’n partneru gyda sefydliadau i adeiladu gwasanaethau cyhoeddus ledled Cymru. Roedden nhw’n siarad am ysgrifennu ar ffurf triawd, sy’n golygu bod dylunydd cynnwys, arbenigwr pwnc a chyfieithydd yn ysgrifennu cynnwys ar y cyd. Gwnaethon nhw sôn am sut roedd defnyddio’r dull hwn wedi eu helpu i ysgrifennu cynnwys sy’n swnio’n fwy naturiol yn y Gymraeg ac i wella eglurder y cynnwys Saesneg o ganlyniad.
Rydyn ni wedi bod yn gweithio’n agos gyda’r Uned Iaith Gymraeg i gynnig treial o weithio gyda’n gilydd fel hyn, ac i ddod o hyd i gyfaddawd sy’n ystyried capasiti’r Uned ac sy’n uno ffyrdd presennol o weithio i wneud hyn yn opsiwn i ni i gyd. Rydyn ni’n gobeithio treialu ysgrifennu ar ffurf triawd gyda’r Uned yng Nghaerdydd yn 2024.
Siaradon ni hefyd â Nia Campbell, dylunydd cynnwys yn y Weinyddiaeth Gyfiawnder sy’n siarad Cymraeg. Mae hi’n gweithio gydag ymchwilydd defnyddwyr Saesneg ei iaith i gynnal ymchwil yn y Gymraeg, a phwysleisiodd hi pa mor bwysig yw sicrhau bod yr holl gyfathrebiadau, gan gynnwys ffurflenni caniatâd, ar gael yn Gymraeg i’r sawl sy’n cymryd rhan mewn ymchwil fel siaradwyr Cymraeg.
Drwy ymgysylltu â’r gymuned ddylunio ehangach, daethon ni’n ymwybodol o adnoddau newydd fel Helo Blod, sef gwasanaeth cyfieithu a chyngor Cymraeg sy’n rhad ac am ddim, cawson ni wahoddiad i ymuno â’r cyfarfod ar-lein ynghylch dylunio cynnyrch a gwasanaethau Cymraeg (am wahoddiad, cysylltwch â Nia), a gwnaethon ni ymuno â chymunedau ymarfer y Ganolfan Gwasanaethau Cyhoeddus Digidol.
Rhan allweddol o hyn oedd bod yn barod i gwrdd â phobl lle maen nhw. Aeth ein hymchwilwyr defnyddwyr i lyfrgelloedd yn Wrecsam a siarad â’r cyhoedd yno, gyda phosteri recriwtio wrth law yn ogystal â chopïau yn Gymraeg ac yn Saesneg o gysyniadau drafft.
Mantais arall o ymgysylltu â’r cymunedau ehangach oedd dysgu am ddigwyddiadau diwylliannol Cymru fel gŵyl flynyddol yr Eisteddfod sy’n dathlu’r Gymraeg. Rydyn ni bellach yn ystyried defnyddio’r Eisteddfod a digwyddiadau tebyg fel ffordd o recriwtio cyfranogwyr ymchwil Cymraeg eu hiaith, sy’n mynd â ni y tu hwnt i’r sianeli recriwtio safonol.
Er bod ein prosiect yn canolbwyntio ar yr iaith Gymraeg, gellid defnyddio’r egwyddorion a restrir yma i gefnogi creu gwasanaethau cyhoeddus dwyieithog eraill – er enghraifft, pan fo’r gwasanaeth yn bennaf ar gyfer pobl sy’n defnyddio’r Saesneg fel ail iaith.
Ar ein prosiect, rydyn ni’n ffodus o gael y cyfle a’r cyfarwyddyd i ganolbwyntio go iawn ar yr iaith. Hyd yn oed os nad ydyn ni, fel timau dylunio, yn gallu gweithredu ar bob un o’r rhain, mae dangos bwriad cadarnhaol a pharodrwydd i ddysgu ac i addasu, hyd yn oed mewn ffyrdd bach, wedi bod yn hanfodol i ni.
]]>The International Design in Government community has been gathering for almost 7 years. This autumn, it found novel ways of convening globally – including in-person gatherings and the first-ever 24-hour remote conference.
Since our last update in August, the community has continued to grow through our events to over 4,000 members. We’ve welcomed hundreds of new colleagues, including from Central Asian and West African countries. This reflects our ambition of increasing global representation – and contributions beyond the Global North.
From 28 to 30 November 2023 we ran our first 24-hour remote conference. There were actually 24 sessions over 26 hours, so in the breaks participants could do speed networking. To co-create the most complete snapshot of public sector design in the world, we reached out to community members everywhere to express their interest in the format and submit topics they would like to contribute. We had over 550 registered attendees and 61 speakers representing 25 countries, nations and territories.
We created this new, inclusive 24-hour format for the community to reach everyone wherever they are and co-create a global snapshot of government design work. Since starting the community and running the first events, we have gathered for multi-day conferences, shared our work in remote calls, and collected the viewpoints of people in all parts of the world. For this event, we wanted to bring these three aspects together in a single format.
Over the day, we moved around the world – starting in Oceania, going through Asia to Africa and Europe and towards the Americas. The topics were broad – ranging from accessible services to co-created policies. We heard from vice ministers, chief design officers, accessibility specialists, content, service, UX designers, and user researchers. From city and state to federal and central government, we saw the broadest range of human-centred design practices: from visual to experience to service to policy design. In addition, several speakers emphasised the importance of building community and global collaboration; and dealing with disillusionment and celebrating small victories.
The event was open and free to attend for any community member. Participants spent just under five hours on average and gave a 9.6 out of 10 score for the event. Each talk has been recorded – as we didn’t expect anyone to stay awake for 24-hours – and is available only to the community on our YouTube.
It was a massive success and collective community effort to pull this event off—we are very proud of what we achieved and grateful to all of our speakers for volunteering their time!
In our last post we mentioned various community members attended and met at the Creative Bureaucracy Festival in Berlin in Summer 2023, where we hosted an open panel discussion on the challenges of transforming public services.
In September and October 2023, international colleagues came together again for service design conferences in Edinburgh and Berlin. Over the years, we had valuable exchanges with people at conferences in various countries. But often, those were unplanned and serendipitous. In October, complementing the Service Design Network (SDN) Global Conference in Berlin, we invited public servants in town for a community afternoon gathering ahead of the main event.
Hosted at the German Federal Government’s Digital Service, we spent half a day sharing work, discussing current topics, and getting to know each other. Around 20 people from four nations and seven organisations took part in the event with talks, breakout discussions and exchanges. Germany’s Digital Service shared some of their work on designing principles for digital-ready legislation and co-designing with federal court staff. In multiple breakout rounds, we discussed voted-on topics like the role of ‘delight’ in using public services, skills designers need in emerging areas, or how to play back experience from service to policy. All slides from the afternoon are available on GitHub.
Afterwards, attendees expressed gratitude for the intimate exchange of ideas and practices throughout the afternoon and evening. So, we want to explore how to hold similar events adjacent to big conferences in the future such as at the next SDN Global conference — see an update on this at the end of the post.
At both events, in Scotland and Germany, we gave a talk about the ‘long slog of public service design’. We addressed why designing public services can feel difficult, slow and frustrating. The talk was informed by research with 60 community members from eight countries and all levels of government – from central to local.
Linked to the questions from the Creative Bureaucracy panel discussion in the summer, we asked colleagues how they ensure others stay motivated, excited, empowered, and creative to work resiliently and sustainably towards more fundamental transformational change. We wanted to know what has been easy and what has been hard to change. Respondents took ample time to describe their work, setups and challenges.
In the talk, derived from the research findings, we talked about resilience on an individual level and organisational resilience at a system level. We then presented 5 recipes for people transforming end-to-end services. These respond to the notion that designing public services is not a sprint, but a baton relay ultramarathon. They recognise that services aren’t designed by one group of people, but by multiple generations of teams.
In the audience were public servants from abroad whom we had not met before and who had yet to hear of the community. Just weeks later, they had joined the community and were presenting their work at the 24-hour remote conference!
The talk was recorded and is available for rewatch.
In 2024, we will resume the regular community calls that took a break during this busy autumn. We want to discuss topics like building accessibility capability, co-designing with local communities, assuring service quality – and any other topic community members propose.
Although we had some representation from African, Latin American, and South Asian countries, we plan to increase our efforts by offering time for colleagues from currently underrepresented regions. We made many new contacts through the conferences we attended that will help us find exciting content and case studies.
In autumn 2024, we will team up with the Finnish Government design community Julkis-muotoilijat for an International Design in Government community event. It will be adjacent to the Service Design Global Conference that will happen in Helsinki from 2 to 4 October. We will share more information about the event in the coming months.
Join the community if you work in user-centred design in, for or with government anywhere in the world or are a design-minded public servant. You will get instant access to the recorded conference talks and community calls.
The user research and interaction design teams at HM Courts & Tribunals Service (HMCTS) spent a day together face to face, helping each other to grow their skills and tools. Interaction designers wanted to upskill in user needs and interpreting discovery research. User researchers wanted to expand capability in user journey mapping, designing questions and prototyping for testing. Both teams wanted to gain experience coaching colleagues outside their discipline. User research and interaction design are user-centred design (UCD) roles — you can find the skills required for these roles in the Government Digital and Data Profession Capability Framework.
A group of us facilitated the session, and we designed a challenge based on a fictional government initiative — to encourage pet owners to volunteer their animals to volunteer in the community. The teams used the provided discovery research, did their own desk research, and worked together to end the day with a prototype for the service.
This model can be replicated, both with these disciplines, as well as others.
We split the day into sections:
Throughout the day, we related activities back to the Service Manual and Service Standard.
The teams were given a brief alongside discovery research about an existing initiative for the public to register their pets as volunteers. The take up was low due to pet owners and organisations not knowing about the scheme.
The department wanted the teams to design a service to allow pet owners to register their animals through a registration form, however teams needed to think about the broader picture beyond the form. For example, how would organisations access the register? How might potential volunteers find the form?
You could use this problem, or design your own brief to focus on specific skills or methods your teams want to develop.
We began with a refresher on user needs versus user wants, looking at the Government Design Principle ‘Start with user needs’ and thinking about needs as being problem-centred and based on evidence and relevant research, rather than assumptions.
Task 1: The teams then broke off to write user needs on post-it notes. They conducted research online during the activity and then prioritised their user needs.
In the next activity, we looked at the guidance for naming a service.
Task 2: The teams worked together to workshop ideas for naming their services, applying the key principles of the guidance. This was an opportunity for the teams to think about the purpose of the service and how users will find it.
We then moved on to designing the registration form.
Before the teams started mapping their services, we reviewed some parts of the Service Manual. We prioritised areas which would help the teams develop a good service, including:
We looked at mapping styles, from low fidelity post-it notes describing steps in the journey, to high fidelity wireframes.
Task 3: The teams then broke down what they needed to capture from users and what the journey would be in phases, such as:
Before the service:
In the service:
After the service:
After creating a high-level map of the user journey, the teams began looking at questions in more detail.
At this point, we took a look at some of the Service Standard - particularly the points that would help the team design their questions:
We also introduced the GOV.UK Design System and the ‘Do’s and Dont’s on designing for accessibility’.
Task 4: Using the design system as a reference for components and patterns, the teams split up their journeys and everyone took the opportunity to create some low fidelity mockups to sketch out how to ask the questions. Then they discussed different pattern options in groups.
We then introduced different prototyping methods, including MOJ Forms, the GOV.UK Prototype Kit and using design tools like Figma, looking at the pros and cons of each method.
We worked through a step by step training exercise on how to create a screen in Figma using the design system. This involved giving a high level overview of how Figma works, how to install the GDS Transport font and how to activate the design system as an asset library.
Task 5: Once everyone had successfully created an example page, the teams split off again to continue developing their designs from sketches to screens in Figma.
The teams were also asked to think about how they might test these designs, with a focus on thinking about it from the angle of the other discipline.
For example:
Overall, both researchers and designers found the day really valuable as a development activity. Designing a service in a day provided opportunities for both disciplines to think more generally about users and the standards we design to, as well as gaining more practical skills like using the design system and Figma.
We hope to follow up this activity in the future — testing the forms the teams have designed and iterating based on that feedback.
We are keen to learn about how other teams use this type of session to upskill their teams, and if there are any other activities they include with other disciplines. If you would like to see the templates we used, email Ros.Boyes@justice.gov.uk.
I'm Ned, a service designer at the Department for the Environment, Food and Rural Affairs (Defra). In March, I wrote a blog post on why a group of designers and researchers in Defra had come together to discuss the topic of planet-centricity, and played back 10 initial high-level principles we had sketched for the design of greener services.
This blog post will first present the principles in their latest iteration, and then cover what’s next for 2024. The article will conclude by covering the collaborative process we followed, including gathering input from colleagues across government, in order to get the principles into their current state!
These eight principles focus on the roles involved in the delivery of services. They attempt to set aspirations for the direction of travel, helping us all become more aware of what the issues are from an environmental impact perspective, and what good practice might look like.
The principles were designed based on feedback gathered through workshops with colleagues across the public sector.
The first four principles relate to the work of the user-centred design roles. They are intended to help you to consider services holistically from a design point of view, including the online and offline impacts. The remaining four principles cover the other key disciplines involved in the design and delivery of services as well as the working practices of teams as a whole.
Each principle includes some guidelines for putting it into action, and there are links to further reading and guidance for most of these at the end of the blog post.
The principles we have sketched are very much a work in progress, and there is more work to do to continue to evolve them and provide opportunities for discussion and feedback in 2024. We hope to:
Following the blog post back in the spring, our planet-centred design working group caught the attention of the Digital Sustainability team at Defra, and they invited us to become a sub-working group of STAR (Sustainable Technology Assurance & Reporting), the cross-public sector group that they lead.
In July, with the help of Transform and Kin & Carta, we ran a cross-public sector workshop to gather feedback on how best to evolve and develop the principles with 25 participants interested in this work from government departments, local authorities and supplier partners. Particular themes emerged around simplifying our use of language, making environmental impacts clearer and widening the scope of the principles to include all disciplines involved at the delivery stage.
And in September, the principles and the rationale behind them were presented at a talk at Service Design in Government, facilitating another round of feedback and iteration.
Please get in touch with us, we would love to hear your ideas. Email ned.gartside@defra.gov.uk.
Want to keep up with the progress of the work? Follow the Defra blog.
For my guidance on each of the principles, see our guidance document.
There are three new features of the updated pattern:
Additionally, the code is now available within the GOV.UK Design System rather than just the GOV.UK Prototype Kit, making it easier for teams to use the pattern in production services.
The task list pattern was first published back in 2017, after being designed by the Government Digital Service (GDS) for more complicated application processes where users need to complete a set of different tasks.
Since then it has been used successfully in dozens of services across government.
However, it hasn’t always been implemented in a consistent way, and was for a long time still considered ‘experimental’.
Two years ago, we started some cross-government collaboration to understand how it was being used, and see what different teams had learnt from their research on it.
The most common recurring finding from this research was that teams observed users attempting to click on the status tag (for example ‘not yet started’) instead of the link text. Whilst users were generally able to recover quickly from this, it indicated to us that the status labels looked too similar to the standard button design.
In addition, we heard repeated concern from teams that the uppercase text on status tags may be harder to read than regular text, particularly for certain user groups or where longer text was used.
To improve both of these issues, we changed the design of the status tag so that it always uses a darker text colour on a lighter coloured background, and no longer uses uppercase text. This makes them more distinct from buttons, which use white text on a darker coloured background.
In case users still perceive the status tag as a button, we also made the whole row of the task clickable.
Finally, we also include a version of the status label which is just plain black text with no background colour at all. We recommend that teams use this for ‘Completed’ tasks, so that more visual attention is drawn to the tasks where users still need to take action.
This change was developed through a new collaborative cross-government contribution process.
We kicked off with an open call to join an online workshop, and had over 120 participants attend from dozens of government organisations. This helped us to understand the diversity of ways in which the task list pattern was being used, from application forms to case management systems, as well as collecting research findings, and user needs that the pattern was helping with.
From the workshops a smaller group, comprising designers and researchers from across different government departments, was formed to work on iterating the actual design.
Collaborating in this way wasn’t always fast – the work had to be fitted in around everyone’s main roles – but a dedicated Slack channel and semi-regular calls helped to maintain momentum.
Once we had a version we were all happy with, it was sent to the Design System working group for feedback. Their main feedback was that the design changes to the status tags within the task list should also be applied to the tag component more widely, such as within the ‘beta’ banner, or when used within tables. We were happy to do this, however this did cause the new component to become a ‘breaking change’, which meant waiting to release it with version 5 of GOV.UK Frontend.
We are still keen to learn from teams how they are using the task list pattern.
The new guidance pages for the pattern contain recommended wording and colours for status tags in task lists, but these are non-prescriptive and you can change them if your research shows different text is more suitable.
If you use the new design in a service and have any feedback, please let us know.
As designers working on the GOV.UK Forms team we help government services create accessible forms. Our team is working towards opening up the platform for more users to give them the autonomy to create accessible forms. That means we need to expand our knowledge of our users, think about the governance of our form creation service, and understand the potential risks that might emerge as a result of this growth.
Designers play an important role in helping the team see the important information in the journey and focus on improvements.This blog post is about how we used the consequence scanning design method to help us understand and plan to eliminate the most critical risks early in the design process, and what we learned from it.
Consequence scanning workshops can help teams to understand the risks in their product, and identify those that they can influence. These include risks to direct users, the general population, and the planet. The exercise means that different stakeholders can discuss these risks in the open.
From what we have learnt, some signs that your team may benefit from a consequence scanning exercise are:
The workshop had three main activities, and ran for an hour. We had two facilitators and participants from different disciplines within our product team. Prior to the workshop this group shared high level questions with the wider team, as prompts to help them prepare. We also created a working space on Mural with activity instructions and sections.This ensured that colleagues who wanted to participate but would not be available on the day could still contribute asynchronously.
On the day of the workshop we did the following:
We asked the team to individually reflect and post on the Mural space about what they imagined could go well or go wrong when Forms is open for all. We asked them to identify:
The aim of this activity was for the team to share honestly and openly and generate useful ideas.
Example prompt questions:
We encouraged the team to also think beyond these questions and bring other novel ideas they may have.
After the set time for individual contribution we encouraged the team to look at other’s contributions and if they sparked a new idea in them, they could note it down. We invited the team to raise questions and comments on ideas or a post that they found intriguing.
We noted the consequences in the Mural space and grouped similar ideas together to uncover themes.
We invited the team to sort the different notes into three categories to help us prioritise what we can work on.
This step helps to identify:
We then took the outcomes that we can act on and the outcomes we can influence, and further sorted them into:
This was an important step because intended consequences are not always positive, and unintended consequences are not always negative.
We came out of this step with clarity of the positive outcomes we want to focus on and negative outcomes we want to mitigate. There are some outcomes that were hard to place, those that were both positive and would still need solutions to mitigate. It was a great reminder that this activity is not a linear right or wrong process, just like many design activities.
We voted to agree on the riskiest outcomes that we need to mitigate first and reach a common understanding on how to reduce their negative impacts
At the end of the workshop we had a rich perspective of the risks, outcomes and consequences that can be expected from expanding our product to reach more users. An important final step was prioritisation.
After the workshop we mapped the relationship of the overall themes and prioritised what needs to be solved now, next or later.
We identified outcomes that pose the highest risk to other work in our roadmap, and how they fit with other current work in the team. We made sense of all the information shared and created action tickets. We put together a summary of the outcomes and shared this with the rest of the team, especially those not able to attend the workshop.
The exercise works best if the workshop has a clear, narrow focus, such as working on a very specific question or topic about your product. It works best with an idea that is well defined and when the team has a good understanding of the scope. The method is not that useful with new and undefined ideas.
We also learned that it’s important to create a safe team space where information can be shared freely and honestly. You should invite participants from different disciplines to get varied perspectives, share the workshop plan early with the team, and at the end thank them for contributing so they know their input was helpful.
You could also think about creating time for discussion as our workshop was very activity heavy. For example, you could break the session into a series of workshops as this can allow the team to explore points further. After the workshop, we also invited the wider team to give input on unexpected outcomes from the workshop that they wanted to look into or discuss further.
In the end, from this exercise we were able to clearly identify the potential risks that we needed to be aware of. We know that we are not able to eliminate all the risks that come from having our product open to all, but there are some risks that we can influence and mitigate.
Useful links:
Dot everyone have a consequence scanning template you can adapt to your team needs,
We would love to hear from you if you have used this method or similar methods in the past.
Sign up to our blog updates to find out more about what design in government looks like.
The International Design in Government continues to grow and convene — and we’re bigger than ever before. We have over 3,500 members on Slack and regularly have 40 to 50 people joining our calls. The last time we blogged, we talked about wanting to have more regular calls and to return to face-to-face events. We’ve done both! We’re excited to share what we’ve been up to…
Since our last blog post, we ran 8 community calls on topics the community prioritised. We had calls on end-to-end services, maturing and scaling up design, and designing for life events.
Contributions were from Finland, France, Germany, Italy, Israel, Korea, Netherlands, Sweden, Switzerland, the USA, and Wales. We record all of the calls and share them privately with the community. With a global membership, time zones and work priorities mean we cannot find a time that works for everyone. Our recordings help with this. The most recent 8 calls have had over 1,500 collective views – so the recordings have 4 times as many views as the live calls. People value the content, get in touch with presenters to follow up on specific topics, and return to recordings or share them with colleagues when relevant.
In June 2023, we got together in Berlin for the first time since the beginning of the pandemic and since our last in-person community activities in late 2019. We were thrilled to return to the Creative Bureaucracy Festival, which we first hosted a session at in 2019. This time, we ran an open panel discussion around the topic of the long slog of public service transformation – with participation of Estonia’s Ülly Enn, Italy’s Marco Maria Pedrazzo, and former GDS colleague Laurence Berry.
We had a fantastic session with input from the audience. The key takeaways were:
We also participated in a satellite event of the festival: Berlin’s local public sector innovation meetup ‘Öffentliches Gestalten’. With many international visitors in the city, the topic was ‘Borderless challenges, exponential opportunity’. We talked about digital transformation, the role of communities of practice and global design patterns. All of the meetup talks are on YouTube.
Next up, we will be speaking at the Service Design Network (SDN) Global Conference, which is the biggest service design conference in Europe. Our talk is on the long slog of public service design – and other international government speakers will be there, too.
Then later this year, on 29 November, we plan to run a 24-hour remote conference to bring together colleagues from all parts of the globe – not just the Global North, and co-create the most complete overview of the state of government innovation.
The idea is we’ll have 24 sessions – so, at least 24 countries, but not more than 1 contribution per country. We’ll work with regional community leaders to put together the content so we can get the best spread of representation possible.
Register your interest for the 24-hour remote conference.
If you work in user-centred design in, for or with government anywhere in the world or are a design-minded public servant, we’d love for you to join the community. We have a Slack group, monthly community calls, and remote and face-to-face events to get involved in.
Tell us what topics you want to discuss – and also if you want to share some work.
]]>The GOV.UK Design System team have released Exit this page, a component which helps users quickly leave a page or site. It was originally suggested by Rob King at the Ministry of Justice (MoJ) following a collaboration between MoJ, the Department for Work and Pensions and the Scottish Government (GOV.SCOT).
GDS's mission is to design and protect the user experience of government. This work supports that by helping vulnerable users.
Exit this page aims to reduce the risk for users when seeking information and using online services. This component addresses the crucial need for consistency of approach in design and functionality across government.
The team were aware of the potential for sensitive or dangerous situations, so they carefully navigated between making a simple, accessible feature and one that would not further endanger the user.
We started by building a prototype service of Exit this page using the GOV.UK Prototype Kit. We used this prototype to conduct research with people with a lived experience of domestic abuse and people with accessibility needs.
Building a component within the Design System always starts with the needs of the user. This is even more essential when the finished component is mainly for vulnerable people and by focussing our research on these groups we get more accurate data than if we only tested in a lab.
As researchers, we have a duty of care to participants. The priorities were to avoid re-traumatising participants, while also caring for our own mental health. Our researcher applied trauma informed practice principles to organise and conduct the research in a way which minimised the risks to participants.
Integral to this approach was a collaboration with Hyndburn and Ribble Valley (HARV) Domestic Abuse Moving On Team, which supports people with a lived experience of domestic abuse. HARV’s involvement was essential in recruiting psychologically resilient people to be participants and providing trusted support to those participants during research sessions.
Jenny H Winfield, Kate Every and Jax Weschler also write constructively on practical approaches and things to consider when researching and designing with trauma in mind.
Part of our research showed we needed to improve how we communicated to users what the component does and does not do, how it affects browsing history and what happens with the information a user puts into a service. We also discovered changes were needed to make Exit this page work better and more consistently for people who use assistive technology.
Exit this page already had substantive design when it came to us from MoJ. Our main aim was to work out how to visualise 'the button' within a user journey.
A significant debate for the team was how we could draw attention to the button without putting someone at more risk. This was especially challenging on a mobile device, as the button changed format to become a bar across the width of the screen. After testing whether to continue having the button at the top of the page to mirror the desktop experience, we decided it was too prominent on the smaller screen, potentially putting the user at risk. We also considered interoperability issues with other components within a service, such as the accessibility of drop down menus. As a result, we decided to place the button at the bottom of the page, where it was easy to access, did not impede other elements of the service and was more discrete.
For this component, some of our iterations included:
With Exit this page, we tried to achieve a balance between how the component functions and how it offers the user a way to obscure their online activity. We needed to clearly explain what the component does and how to use it, while keeping the information discreet. That meant efficiently explaining things where we could and reinforcing this through the design and text of the button.
Writing content to reinforce the user’s understanding of the component also comes with some constraints. For example, button text and screen reader announcements needed to concisely explain what happened when they pressed ‘Exit this page’.
User research showed us the user is likely to be in a stressful, time-sensitive situation and they often held assumptions about what would happen to their data and browsing history. To try and help with this, we decided this component and pattern needed to include a way to inform the user about online safety and privacy, so we’ve included guidance for service teams to add safety content as part of Exit this page.
While the Exit this page component appears to behave in a similar way to a normal hyperlink, we needed to make sure the component is accessible. Many of the component’s technical features will not be visible to users, but they are vital to ensure ease of use and user safety.
Users of assistive technology can press the shift key on their keyboard 3 times to activate the Exit this page component and navigate away from the page. We initially used the escape key for this feature which only needed to be pressed once. However, we made several detrimental discoveries while investigating this approach:
We re-designed the button and decided on pressing shift 3 times to activate functionality. This action is common across different keyboards, easy to carry out for users with motor difficulties and does not control any existing functionality when pressed on its own. To make this even more robust, we prevented activation when the shift key was pressed in combination with other keys or if another key was pressed between the 3 shift presses.
We additionally added visual “traffic light” indicators to the component to show how many times the user had pressed the shift key and how many presses remained before the component activated. We also added built-in screen reader announcements to the keypress functionality, so screen reader users know how many presses were left, when the keypress functionality had timed out and when the button was successfully activated.
An additional safety feature of the Exit this page component is making the web page go blank when the component is activated. This is to hide any content during the time between the user activating the component and the new page loading. This is to better protect users on slower internet connections.
This feature does two things. It hides the contents of the page body and creates a page width and height white block to cover the page. We do both these things because:
When making features in a website accessible, such as an Exit this page component, there are methods to simplify the work such as having:
For Exit this page though, we dealt with some unique challenges. There is tension between stating clearly what the Exit this page component does, and tailoring it to the sensitive or dangerous situations in which it will be used.
Looking at the first method above, we have text that explains what the feature will do. Directly on the button is the text “Exit this page”. Looking at the second method, that text decently explains what Exit this page does: it exits the page by navigating to a new page. However, looking at the third method, we also needed this feature to work for all kinds of device setups with various assistive technologies. It’s here that our straightforward ‘Exit this page’ text started to raise concerns, especially for people using voice command software tools to navigate.
If someone is using Dragon on a Windows computer, or Voice Control on a Mac, how could they discreetly activate the Exit this page component without audibly commanding their device to “Click exit this page”?
We explored adding a ‘disguised’ alternative name for the button, or adding another hidden button with a less conspicuous command name, such as “click BBC Weather”. But these options had two flaws. Having a ‘disguised’ name for the button would likely interfere with other assistive technologies that rely on descriptive and accurate labels. Additionally, we would need to write content specifically for people who use voice command tools, attempting to explain to them that the secret command exists.
We’ve determined that alternative navigation options like the ‘item numbers’ tool for Voice Control are an adequate way for people using voice command tools to discreetly activate the Exit this page component.
To make decisions about these challenges, we relied on user research, advice from experts, reports from users and manual tests of our prototypes. In particular, we had the component audited by the Digital Accessibility Centre, an organisation that tests services with real users with accessibility needs.
We have plans for future improvements, using more research and cross-departmental collaboration.
Making this component available is not the end of its journey. The team is keen to learn from others who use the component in the coming months so we can improve it.
If you’re in a service team and interested in being part of future research and improvements to this component, you can contact us on govuk-design-system-support@digital.cabinet-office.gov.uk.
Now that there are over 40+ people in “heads of design/ head of user-centred design (UCD)” roles in government, we want to leverage that to empower our community of practitioners. Our heads of design come from not just ministerial departments, but arms length bodies, agencies and the NHS, too. Currently this does not extend to local government design leaders, as this would be an extremely large group of people.
As part of this initiative, we would love to find out more about your world, and what you need from us, so please use the contact details below to get in touch. We’re starting small, aiming to publish a short blog each month with details of what we are actively working on, and who is doing it.
Recently we met in person for our cross government heads of design meeting! This meeting was well attended (not just by the 4 people in the photo!) and productive. We now have a Trello board with a backlog of activities and tasks that different heads are taking responsibility for. We encourage all heads of design across government to attend this meeting held on the first Tuesday of every month, and engage with some of the shared topics that we are all focussing on (and bring your own ones too).
Although we meet monthly online, our next in-person meeting will be in Autumn, if you are heading up a design team in government please get in touch below to be added to the invite.
In spring, heads of design across government met in London to formalise a number of things:
We got together to discuss a few initiatives in a lean coffee format — where people suggest topics and then vote on which they want to discuss. First up was to brainstorm all the shared initiatives we want to be working on. Now that we have grown the community of design leaders in government, the chance of duplicating our work is high so we want to avoid that where possible.
One of these areas of potential duplication is shared training, so we want to reduce the effort of producing courses and training across departments. Currently each department is producing its own training, for example: introduction to UCD, Figma training and so on, and we are not sharing or reusing it outside of our organisations which we want to change. We talked about how we can start to audit and log what training exists and which organisation has created it. We decided that an MVP (minimum viable product) could be to start matching learners to these organisations running the training rather than creating new training internally. The next phase would be whether we can start to centralise some of this training and how that might work.
Another hot topic was working out what tools the heads of design can and cannot access across government. If we want to collaborate, we need to know what tools are available to all to enable us to work together. This is ongoing, but an audit has been done and we are now setting up the ways to collaborate.
We meet to assess the progress on all these initiatives each month, and are looking forward to sharing more of our work with the design community going forward.
Since early on in its development, we've put a lot of focus on making the Design System open for contribution. It’s had some great successes — nowadays, most major additions to the Design System come from outside the team.
After facilitating lots of different contributions and bringing them into the Design System, we’re taking what we’ve learnt and making some changes to the contribution model.
A few recent bits of work feed into this. Over the last year or so, our community designer has been leading two large-scale collaborations with the community. These involve far more people than in the past, and use co-design approaches to make use of more people’s knowledge and skills. To hear more about this, listen to our podcast about the maps collaboration.
We’ve also been trying a new way of prioritising new work, to make sure we take on the community’s needs and prioritise the most valuable things. Those priorities are listed on our upcoming components and patterns page. Picking up one of these newly-prioritised things gives us an opportunity to trial a new model for contribution.
We’ve put together a quick video that gives an overview of how we plan to work:
It's intended as a loose model — each step has a range of possible activities we could run, depending on the thing we’re working on.
We’re not starting completely from scratch. A lot of the model is made of things we already do, rearranged a bit to reflect what we’ve learned over the last few years. For example, the importance of making clear scoping decisions earlier on in the process.
We’ve also left some existing steps untouched. For example, how the working group reviews work. This is so we’re not changing everything at once — we may revisit these things in the future.
If you want to see more detail than what’s in the video, have a look at the journey map we made whilst developing the model.
In the past, we often waited for teams to approach us for proposals for patterns and components, which did not always match with the community's needs. The new prioritisation process will change that dynamic: we'll communicate what the next focus is, then ask the community to get involved. Hopefully this means that people are able to share more relevant information, and that their efforts will bear fruit sooner.
We want to take the successes of the community collaborations and make them structurally part of how we work. This means being more intentional about how and when we involve the community. For example, some activities benefit from a larger group, some benefit from a smaller one.
We also want everyone involved to be clear about what’s going on at each point in the process, and how they can contribute. So we’re adding a bit more structure and planning to improve how we communicate.
We’ll trial the model when we kick off one of the 3 priorities in the near future. When that happens, we’ll blog about it and let people know via our mailing list.
Facilitating contributions to design systems is hard. Not everything will work. We’ll be taking feedback and iterating as we go.