Design System Hack Day: Solving discoverability across different design systems
In November, Register Dynamics went to the GOV.UK Design System's first ever hack day. Alaric and I joined over 100 other participants in a hybrid in-person/online event and spent the day exploring and prototyping ideas to help join up different design systems across the public sector.
This is a problem that's particularly topical for us. Since publishing the Data Upload Design Kit (which is a miniature design system just for spreadsheets) we've been looking for ways to make our work more discoverable by and accessible for more designers. We were really interested in contributing to this effort and offering our view as a small design system curator.
We've also done our own research with designers to understand how they discover new components and patterns and so we were keen to share what we'd found with the wider community. Having been users of the Design System since 2018, we thought it was time to give something back!
We started by focusing on the problems
Our day started with a review of problems – everyone was invited to add their own user needs when using design systems across the public sector. We contributed that it's important to know the user needs a component was designed to meet so it can be appraised for suitability in a new design. We also added that using design system components needs to be easy for developers as well as their design colleagues.
From there, the participants pitched ideas that might help. There were some fantastic ideas, and the four that came out as the ones we most wanted to explore were:
Improving searchability across design systems
Using more natural language within design systems
Recording decisions taken when designing patterns or components
A design system for non-citizen internal services (a much needed innovation!)
We thought we could help the most by joining the group that was looking at searchability across design systems!
We explored discoverability across design systems
Our group quickly settled on a core idea: what if we could present a single, searchable gallery of components and patterns from many different design systems? There's already some momentum behind this idea, as contributors like arindra from the X-GOVUK community have already demoed galleries that do this. There's still a lot of different designs to be realised inside this idea – so we split into a few sub-groups to look at different design approaches to this problem.
Alaric and I realised that there's a data infrastructure question at the heart of all of these ideas: how do we collect all the components and patterns to search and display? There are lots of answers, but they each have implications for adoption, maintenance and ultimately success of our ideas. We joined forces with Romaric and Ben to work out how to tackle this.
The thing that shapes our solution the most is working out who will be maintaining the data about components and patterns: will it be the person running the gallery (the consumer), the person maintaining the design system (the publisher), or a balance of both? Together we came up with three differently shaped ideas:
We could just start manually maintaining a set of data about each design system – this is the lowest effort way to get started, and is already being done elsewhere, but has an ongoing maintenance cost for the curator which might not be realistic
We could use a web service like JSONify to scrape design systems and collect data into a single place – this might allow us to scale out curation activity, but would come with reliance on an external service and some risk of inaccuracy or limits on what can be collected
We could allow people to publish their own metadata and have a harvester that collects from a bunch of URLs – the issue is that most publishers will need convincing of the value of doing this before adopting it
What's the correct answer? Of course, it's all of these! Their advantages and disadvantages are acceptable depending on the maturity of the service. They also potentially complement each other. For example, an automated AI-based solution might work well for publishers that aren't engaged, but it might be preferable to them to publish more finely controlled information when they are.
We defined a data standard for design system metadata
Next, we defined a data standard that all of these methods could work towards, when they are implemented. This means our downstream consumers (the search engine user interface, for one) can design and build against a common set of information without needing to know which method produced it. It also means that we can evolve data collection between these different methods in small and manageable ways, rather than requiring a huge system redesign.
By defining a standard we also allow people to build their own tools that work with it. We heard from some designers that it's often difficult to know what design system elements they are allowed to use, so we considered a use case where the department may want to show certain approved components alongside the official GOV.UK components. In this case, they could run the same design system gallery software but with only a few data sources, representing the design systems they've approved for use internally, and host it in a private, internal place.
We came up with a simple schema for data about design systems. We started with the work from the X-GOVUK community and combined the individual schemas for components and patterns to allow a single file of metadata to be published and harvested. We produced an example for the Data Upload Design Kit to show that our data standard is realistic.
There’s much more to do!
We're proud of what we achieved, but it's clear that this is only the beginning. There were multiple different ideas for how to present patterns and components from other design systems and some of the more involved ones require a lot more information than we collected in our example data standard.
For example, if you actually want to render and show all of the different components together, there at least needs to be some example code that can be used for that. Depending on how design systems are factored, that may require more implementation detail like stylesheets, Javascript includes and features to ensure cross-site security.
There's also a big opportunity here to do something really cool by combining this sort of Design System metadata with plugins from the GOV.UK Prototype Kit. Plugins are also currently defined using a lightweight data standard that needs some of the same information we've created above. What if design system publishers could write one simple metadata file and then automatically have all of their components and patterns visible in a central gallery whilst also making them all available as a plugin for Prototype Kit?! That seems like a really cool idea that I'm keen to explore further.
We really enjoyed the Hack Day and it got our creative juices flowing. It's clear that at the end of the day we'd completed our first cycle of iteration – we'd done just the first diamond of a double diamond design process. It would have been nice to have more time to develop some working code that could demonstrate what we'd learned, but that'll have to be saved for the next Hack Day! We collaborated with some great people and we're really looking forward to seeing how and if the GOV.UK Design System team takes any of these ideas forward. Many thanks to them for running an excellent and enjoyable hack day!
Author
Tags: