Now more than ever, we need fast, accurate and contextual information from the public sector. Governments like the UK and US have invested in creating strong design systems that help achieve this. Check out https://design-system.service.gov.uk and https://designsystem.digital.gov. We think these are awesome. We also think much more can be done.
Public sector design systems are atomic, but they should be pattern based.
Government design systems (GDS) break web content down to the smallest practical units. If you review https://design-system.service.gov.uk/components you can see the base building blocks like buttons, panels, date input. There are really good reasons to do this: the GDS is used across many different technical platforms for many different purposes. GDS needs to supply the most flexible and adaptable toolkit for a whole range of outcomes.
The problem is, people (users and content editors) don't communicate at the atomic level - communication is a bundle of stuff grouped together as a task. Sarah Richards captures this neatly in Content Design. Users (and public sector content designers) communicate in user stories and job stories. So while atomic design helps technologists with a toolkit to build a technical system, it's limited help to content designers needing to communicate in job stories.
We can help content designers communicate more readily by combining atomic elements into common groupings useful for typical communication tasks. So for example, while a button has limited communication use, it's great when combined in a design pattern that includes text, and images. Suddenly we have a teaser panel - a very common use case and much handier for a content designer. Re-use should occur at the pattern level as well as the atomic level.
Design systems need to be implemented.
Perhaps an obvious point, but bear with me. A GDS is only as good as the technology that activates it. It must be a tool for content designers as well as application developers. When we build a site, we benefit from the guidance the GDS provides. But when the site is live can content editors use and re-use design patterns with the same ease? A GDS should have simple, clear drag-and-drop editing capabilities so that content can be added, removed, and altered easily and without developer intervention. It should be a tool for publishing, and shaped to the communication tasks of the editor.
We use a combination of Drupal, Acquia Cohesion and Site Factory to achieve this.
Design systems need to be extendable.
Here's a classic implementation of the GDS: The UK Prime Minister's Office. This steers true to the system. However, consider these implementations from Brighton and Hove Local Authority and the Royal Marsden Hospital. We can see the GDS in there somewhere, but there has been extension - typography, colour palette, use of padding, bespoke styling elements.
GDS has core users and a hinterland of public sector, third sector, non-governmental, and charity users that also derive benefit while pushing the branding. We conducted an experiment to rebuild these three examples using a common implemented design system powered by Acquia Cohesion and were able to build very close replicas of these pages using a common implemented design system in differing configuration states. You can see the results of this experiment here. When they are implemented, design systems need configuration capabilities that allow them to be extended.
Design systems need to evolve.
User expectations, web standards and communication needs are changing all the time. An implemented GDS needs to have the ability to cascade improvements, updates, enhanced features. There needs to be a method to distribute these, with specifications and training, to the client applications that are using the system. Cohesion helps solve this problem through allowing the export of design patterns as configuration data between Drupal distributions. Site Factory helps with the management of Drupal distributions in multi-site estates.
Design systems should be for ever, not just for launch.
Public sector content designers lead an unpredictable life. Change in government, policy, events and public need mean that web sites will constantly need to publish content in ways we cannot predict. GDS can help us build more consistent and accessible applications with greater speed. But the GDS needs to remain active, re-usable, configurable within the application after launch, so that content editors can keep publishing, changing layout and structure, conducting page takeovers, refining messaging and so on. Again a tool like Cohesion helps us achieve this by exposing the design system as a set of re-usable patterns in a drag and drop editing environment.
Believe in standards, but don't worry about them.
Accessibility, user experience, performance, security and stability are at the heart of government driven design systems. But a content editor cannot run each communication through a checklist as long as your arm. Standards must be baked-in to the technology that renders the design system. They should be invisible, impossible to transgress and yet effortless to implement.
Fortunately, technologies like Drupal have very strong accessibility, security and performance credentials. In addition to this, a tool like Cohesion can embed standards into every publishing action without a dependency on the content editor.
Ultimately, we want content editors and designers to focus on the quality of the communication, and the needs of their audience.
See it in action at Acquia Engage on the 21st October
Dries Buytaert, Founder of Drupal and CTO of Acquia, will be presenting at 1pm on the 21st October. Joining him will be Acquia Product Manager Craig Hanna, and MD of Coherence Julian Tedstone.
It's free to attend so simply register here and see how you can bring major efficiencies to your organisation, and deliver the impacts your audience deserves. Hope to see you there.
