Encouraging a community to contribute to a design system
This is co-authored by Henry Cookson (User Research) and Tosin Balogun (Interaction Design), both user centred design (UCD) trainees who worked on the service manual team at NHS Digital.
A design system is a library where disassembled parts of a website or a mobile app are stored. This allows teams to assemble a website or mobile app quickly and consistently, with the goal being to save time, effort and money.
When the NHS design system was created, it was meant to help spin up healthcare digital services rapidly and at reduced cost, but how do you keep the system up to date?
There are 3 pillars which make or break a design system:
- the product
- the support and maintenance of the product
- the community using it
The first 2 can be controlled in terms of risk, the last 1 cannot.
The problem we had with the NHS design system was that the product worked, the support service was reliable, but the community was not feeding back into the system enough. This meant that the team had little insight into how the system was performing, a major risk when you consider how fast things change in the digital world. The question then becomes “Why are people in the community not contributing back into the system”
To figure out why, the team embarked on a journey which took us through mapping our assumptions, conducting user research, making sense of the findings, brainstorming ideas and testing these ideas.
Assembling our assumptions
The team gathered together and looked at all the assumptions we had for why people didn’t share back into the system. Everyone shared what they thought was causing the issues on a collaborative board. These ranged from observations, feedback or data trends. We then mapped the assumptions on a known/unknown and high risk/low risk chart to identify which ones we needed research for.
Once we finished, a research plan was formed to prove or disprove these assumptions.
Validating our assumptions with research
At the time of researching, the 5 most commented backlog issues had at most, 12 people contributing. This helped us set a clear research question to focus on:
Why don’t people share their findings back to the service manual?
We began our research by looking at how other design system communities worked. Our findings showed that many online communities only had a small percentage of people contributing, compared to everyone who benefitted from the community, therefore expecting a large proportion of users to consistently share feedback was unrealistic.
User survey
We ran a survey which provided extra insights about contributing to the design system. 24 people who responded worked at NHS Digital and 15 people worked elsewhere. We learnt that most people did not know what to do if they wanted to contribute. This is a barrier to contributing because people have a lack of knowledge about the process.
User interviews
After running the survey, a series of interviews were conducted to add further depth to the research. These were with 11 people from NHS Digital or other NHS bodies. Speaking with people from a variety of professional backgrounds provided different perspectives as to why individuals or teams don’t contribute to the design system. An important finding from this research activity was that managers were not fully aware if their teams were using or contributing back to the design system. Contributing seemed to be done inconsistently within teams, often led by individuals.
Usability testing
To conclude our initial research, we ran some usability tests for 3 contribution scenarios based on the current process with 13 people from a range of job roles. We observed that most people didn’t recognise there was a process and didn’t know if they could change code for styles, components, patterns or guidance. Another significant observation was that most people were likely to contact the service manual team before contributing. They would either contact an individual they know or the team more broadly if they didn’t know anyone in the team.
Making sense of the research findings
Once we gathered all our evidence, we needed to break it down into a digestible form. We mapped some of our initial assumptions to the evidence we gathered and identified 7 behaviour patterns or groups, which our users fell into. On a spectrum from experienced (like co-developers) users to inexperienced users (like lurkers), each user group was represented by an animal.
We added details from our evidence into each behaviour group and this helped us isolate problem hotspots in the process.
The problems clustered around 3 user needs:
- users being unaware they could contribute and how to go about it
- users not having enough confidence or motivation to contribute
- users not feeling permitted to contribute
We broke down these user need clusters into 14 problem statements which formed a base from which we could brainstorm ideas. The team is working on 6 of these which are
How might we (HMW):
- help users understand the benefits of contributing
- make GitHub (where the backlog lives) less intimidating
- create clear calls to action to contribute
- show users where help is most needed
- show what work is in progress
- create a positive experience so users want to do it again
Brainstorming how to solve the problems
The team followed up with a series of workshops to brainstorm how we might solve these 6 issues. We worked in 3 groups made up of 3 people, with cross disciplinary skill sets in each. The goal was to come up with solutions for each problem we had.
At the end of the workshop series, we were able to generate 19 well defined hypotheses, along with measurement criteria to know if they worked. We then prioritised them based on our current capacity and created a delivery plan of how to roll them out.
An example from our hypotheses is:
Problem: How might we make clear calls to action to contribute.
Hypothesis: If we change the ‘Community’ header to ‘Community and contribution’ on the navigation of the service manual website, then users will know how to enter the process. We will know this has worked when we see an increase in people clicking the header compared to now.
For more on design hypothesis, see the short blog by Andrew Duckworth.
Where we are now
For each of the 6 hypotheses, the team is benchmarking the analytics and evidence of how things are now, making a prototype and then testing to see if it improves.
So far, we have changed the navigation header from ‘Community’ to ‘Community and contribution’. We have also added an action link to contribute in the respective sections people often use (based on page analytics).
We have seen some preliminary evidence to suggest our hypotheses are on the right track, so the team feels encouraged.
The team learned 3 main things from doing this work.
- Even though we make our GitHub backlog open to the public, we need to show people how it works.
- We need to engage with the wider communities, such as those building digital health services who are not NHS staff. We also need to engage with the leaders of those teams to make sure sharing back is integrated as part of their planning.
- We need to refine the contribution process end to end.
We also want to run co-design sessions with the community to help generate more rich ideas of how we could solve these issues. After all, the product depends on the community and vice versa.
Closing
The team are on a journey that isn’t completed and are interested in hearing from others who might have been on a similar journey to share what they learned.
You can reach the NHS service manual team by messaging us on Slack or contacting us by email.
