Imran  Hussain 

Next step we have Imran Hussain.

[APPLAUSE] >> IMRAN: You can tell there are some colleagues in the room. [LAUGHTER] Lovely to be here and thank you for joining me to talk about how we can co-design as a community. I am Imran Hussain, a community designer with Government Digital Service, part of the cabinet office. A community designer is a role I made up. [LAUGHTER] Pretty much every role I made up and when I land in a role I see what they need so I do a bit of everything. So it is constant engagement.

If I spot any themes and problems I will solidify those in my mind, I will take them back to the team, pose them as problems and then discover the problems through user research. I will work with the team to service design solutions and deliver that and be there for aftercare as well from the start to the finish, and it's just constantly happening with small problems, larger problems. So yeah, I kind of love it as it does involve building a better future, as Nat has just touched on in her talk.  

So, I’m gonna fit my talk into three chapters. Number 1 chapter is setting the scene, fitting everything together. Chapter 2 is what I like to call ‘obstacles schmobstacle’. And chapter 3 is talking about the kind of learnings from whole process, how we iterate it, and how we improve things.

So chapter one. So before GOV.UK the UK government kind of looked like this. There were websites everywhere, hundreds of websites, campaigns, transactions different things floating around. There were sometimes things that were contradicting each other and it created broken usage opinions, something by the way I'm going to tell you a little bit about the design system because I don't want to assume any knowledge, but that would be brief. In 2012 Government Digital Service overhaul worked to take all that disparate information, which is about 700 websites at the time, and put them all in one place which is now GOV.UK, which is how it currently sits. So it's a central place that citizens can go and interact with government and it's much better user experience.

As part of that, the community I work with and the product I work with, the GOV.UK design system, is a suite of tools, and it helps people quickly build usable accessible services that sit on that website GOV.UK.

So you can go onto the website and it provides styles, components and patterns, to help design and build those user-centred services. So yeah, quite helpful. There's more than 900 live services using the GOV.UK design system and it's found in more than - I think that number's updated since I was doing the slides - it's more than 2 000 repos on GitHub.

So that's like, you can't track everyone who uses it, but that's just like a finger in the air of how many repos are officially using it. Year to date, so starting from January to June, it’s saved the UK taxpayer 22 million pounds, and that's just in the UK. There's many countries, states kind of prefectures, that use our Design Systems and think across the world it's probably saving many more millions as well. Okay, so that's kind of background done about the design system. Contribution is a key part of keeping our design system going, and that's because of the open-source kind of design system. And if you want to scale and we want to provide the things that all the designers need, we need people to help us make them because they're a fairly small sized team.

So just want to give a shout out to the original innovators. So this is Ignacia Orellan and Amy Hupe, and they are two people who are based in our team who created this contribution process, and that's no mean feat because now anyone from government or the wider public sector can actually contribute to our design system. Everything is open source on GitHub. And coralling all that together and finding a system for it was not easy to do, and essentially our design system has been doing co-design for over four years because of the work that they've got in early on. So the way that it was set up, was we did a public open backlog where people can go, they can share their ideas, research works in progress. And it was on GitHub, and and there's no access limitations to that which can often be a challenge for government. But it can be a bit hard for people to use when they’re not familiar with it, so developers usually use this kind of tool a lot but other roles maybe not so much. But yes all of our work that we're kind of doing is really visible on there, which is important for open source. What we also created were some like contribution criteria. So we developed these in conjunction with experts across government, designers and developers,  and this gives people an idea of what kind of standards they need to be or what it needs to do if they want to contribute something.

We also set up a working group. So it's got 11 representatives, they're currently from nine different organisations and five different disciplines. And this is just to make sure any decision making is kind of fair and representative. Essentially like the final decision making and standard setting goes out to this group, so it just means we're not marking our own homework right. So if something's great they'll let us know, if something's not great we have to act on their feedback, which is a really great setup and probably the best thing about a design system contribution process.

So this is around the time that I entered the organisation…happy world, everything was going so well. Everything’s great right - sector-wide design system contributions coming in, should be perfect. No obviously things change, things happen. And one of the things that happened was like our team shrunk to four people which was smaller than the small team that was already kind of running it. Ignacia and Amy who've doing all that fantastic work with setting up the contribution process moved on to work their magic on other products at GDS and other design systems. Which kind of meant that the engagement that they've been doing, the kind of reaching out to everyone across government and getting them involved kind of disappeared.

And it disappeared for a decent amount of time, nine to 12 months so that's a big kind of gap. I think this is a really nice tweet that sums up a lot of the problems that you get with Design Systems and other kind of products that you set up. It's like creating it is great, but getting an organisation to adopt it and to maintain it over time, that is the work.

And you know, we'd stopped being the shiny new thing after a year and a half. Other things start to be worked on. That's what leadership start to focus on all of a sudden. Also business needs kind of got in the way.Sso there was a lot of things that we needed to create for the main site at GOV.UK, but then there were a lot of emergencies as well like Brexit and Covid kind of happened. Which obviously GOV.UK is the portal for information for all those kind of things, so a lot of the results from our team kind of got focused on dealing with these urgent issues that are happening in government.

So when I came in I wanted to kind of speak to the community and find out what was happening. I thought yeah they'll really be up for speaking to me but when I kind of got in there, absolutely nothing, no one wanted to speak to me. And I was just a little bit confused and it took a while and nitpicking and just kind of keeping asking people. And I kind of found out or got the impression that we’d lost the trust that we’d built up, right. I thought I was starting from zero. Right I'll start fresh and I’ll build it up, but we were below zero, you know. Because we built up this trust and then the engagement had just stopped, so it was we've taken a step backwards. So we had to build back up to zero so that we could kind of start. So yeah that that was the challenge that was before me and so some of the first things I did, I spoke to some of the designers and developers building these services in government. So we did our user research and we gathered some of their thoughts including those on the contribution process and just engaging with people on the team and the design system in general.

So some of the problems that kind of came about were, users were concerned that they didn't have enough expertise to contribute. They saw the people that were contributing right at the top of their game as someone who was like a complete expert and they were really intimidated to speak about things or offer their suggestions or create things. Even things that they've created that would be really useful they were really intimidated to suggest a contribution. They would also worry that they would ask something like silly on Slack, like oh has someone asked this before, should I know this already.

So they're even intimidated to reach out to the community or the team for help. And they also thought that the decision-making process that we use for the design system was not really clear. So that was like team priorities, but also even someone who's doing a contribution. Sometimes they handed something over and they kind of felt like it's gone into the ether for a bit until the team gets back to them a couple of months later. Some users didn't know how to formally contribute but they assumed that'd be guidance on it somewhere and if they needed it they'd go up and kind of find it, but they didn't know off the top of their head which probably wasn't a good sign. Some users also mentioned that they struggled to keep up to date with the changes on the design system and what the team were working on. And just to clarify when we're talking about users here, we mean designers and developers in government, because they're the ones who use the design system.

Overall, especially with the contribution, everything had become a little bit disjointed. And that was especially because the team had got a lot smaller. We had like kind of like four people at one point in 2020. So the contributor was doing some work handing it over, it went missing for a while, we were doing some work we were handling it back. And it kind of felt like you know those folded children's stories, where you write one line and pass it on to the next person, and then you open it and it doesn't make any sense whatsoever. It was kind of like that it really disjointed, it didn't feel how we wanted it to feel.

So clearly we needed to make some changes, but the team it was quite small they were kind of at capacity working on components, buttons, trying and support to people dealing with tech as well. So as a community designer it kind of came down to me, which was intimidating to try and move the needle on these kind of issues. And there was a lot of work to do. It was really intimidating. Much of the work was kind of like service design shaped, like you needed to create things. And that wasn't really my role. I kind of dabbled in it as far from a kind of expert, and it was a community of experts which made it even more kind of intimidating.

So some of the best designers and developers in the country, and having to sort all their problems out. So I kind of started to understand that feeling that community members had of being intimidated by to deal with this community. Luckily I had an awesome mentor. So this is my design mentor Clara Greo - if you don't know her, follow her Twitter because she's a brilliant lady. And I kind of had some conversations with her because I was like, am I qualified to lead this? Some of the stuff I want to do I'm not sure it should be me that's kind of doing it. And through some conversations I actually flicked the idea on it’s head right, so I changed my perspective completely. And it was that that lack of expertise, not being completely at the top of the game, can actually be my superpower because if I can lead this community and I'm not even a designer, then anyone can take part, right. So it's the key kind of takeaways that I had, like through this one or two conversations in my assignment, to always work to your strengths. And my strength is in convening people, getting them excited about work and bringing them together. And that's what I did from there on out. So we've got crisis of confidence kind of averted, I set about kind of dealing with these problems.

Obstacles, schmobstacles. Okay, so I spoke to some people across government in follow-up conversations just to really dig into the issues and do further research. And then I kind of came up with a bit of a community strategy. And what we aimed to do was to build some trust obviously, we need to prepare it. And just demonstrate some consistency. So I wanted to show them I'm not going to do this for a little bit and then just disappear after a couple of months, because that's what happened before. We wanted to create safe space and approachability, because people kind of felt intimidated it in the space. We want to run exciting events, but also they should add value for someone who attends them, it can't just be exciting and then no one really thinks on it. Let's be a bit more open about the roadmap and the decisions and actively invite feedback and act on it. And the last thing was, let's make the most of that expertise in the community. So we've got lots of experts, let's try some structures and sessions to that make the most of that.

So to start off with I create some kind of like principles for how our team will engage with the communities. In all our interactions I wanted everything to feel the same, whether you spoke to me whether you spoke to one of the developers or one of the designers on the team. And whatever channel this was… if it was am online conversation or just something on Slack, we wanted to have the same kind of feel, to build that consistency.

So I created four principles.Tthe first one was being open, like transparent about our work, our processes, our decision-making, how much feedback we can take on. Inviting. This sounds similar to open, but quite often what happens is people working their open, they'll broadcast what they're doing but they don't often take feedback in. And one thing I really wanted us to do was actively encourage people to get involved with our team. So we should be actively encouraging people, inviting their feedback, getring them involved in sessions, getting them involved in conversations.

And those decision-making opportunities should be there for our users. Third was transfer of power. Currently people felt like they were on the outside looking in, right. They couldn't affect this design system and as a contribution-based design system we should be serving their needs a little bit more. So transferring some of the decision-making powers and people feeling like they've got more skin in the game was absolutely vital. And the last thing was to be a little bit educational. So it's one thing to build something, but if you don't want to teach people how to use it properly, or develop some training then you're not going to fulfil people using it properly.

So we wanted to make sure people have the right skills and taking some of the skills that we have especially if our team was taking something that works in one context, so someone will develop something for the DWPm they'll bring it to our team and then now we have to make it apply to every single department whether it's a small service, large service. And whether it's all different types of public sector organisations, and that's one thing that was a bit of a bottleneck for our team. Only we could do that and no one else do that in government so if you could start to spread those skills and reduce that kind of bottleneck that is stopping our team from achieving more.

So we started off putting those principles into practice with kind of like face-to-face interactions and interesting events. And so I created some spaces where you could kind of engage with the community and allow them to discuss other challenges. And luckily at this point our team started to grow so we had more people on the team that can jump on board, so we were a bit more open about our work. This is a regular fortnightly chat that we have around the design system and design systems in general. Anyone is free to kind of take part, and after the session we share anonymised notes. So we take notes, we don't put anyone's names or departments or the service they're working on in it so that people are free to share their opinion, and we'll share those great views after the session in case people miss it.

We started to get the community more involved in our decisions. So this is a cross-Gov crit that we ran before we launched one of our patterns on the design system, which was asking for quality information. Normally what we’d do before this was we'd launch it, we'd look out for feedback and then we'd rapidly just have to like fix anything. And it just made sense to go out to people and get that feedback before we launch a thing, be able to take those opinions, and attitudes, and gaps that we've got into account before we launch a final thing.

We also run an annual conference to celebrate the design system's birthday. So we usually announce it on our birthday in June and then we'll do it a couple of months later. It's happening in October this year, and this is just like a focal point. So over summer, usually you get a bit of a lull. People go on holiday, and you know when you're doing collaboration type of work this is a really real chance after summer to kind of like pick people up get them interested in a kind of work again and just engage them again. So it's really serving the community.

In our first session, first design system day, we had like some really interesting workshops like this one on contrast modes. Taking components through accessibility, we had a loads of breakout rooms on different types of discussions around design systems, and we had a great keynote talk from Sarah Drummond.

We've also thought about comms because the way we communicate is really really important for the cabinet design system. What does this have to do with co-design? If people don't know you’re doing co-design, there’s no actual way they can kind of take part, so actually communicating was absolutely vital. And one of the things we kind of realised was different people interact with the design system in different ways.

So we have different personas that there were people who were like super users that interacted with us all the time and for those kind of people we had weekly engagements. So this fortnightly call was weekly at one point and now we've got many events so we've amended to fortnightly. And we also have constant engagement on Slack and our support offers on Slack, so if people want to engage more often they can. For people who just want to keep a loose eye on the design system we've got like a mailing list so rather than have to chase this up and find out what's going on they get a ping to their inbox. For people who just want a loose idea of what's going on we kind of blog on the design notes block which is a government block, and it kind of lets people know what direction we're headed in.

If we're making any major changes and then a thing that increasingly starting to do is add a bit of personality because like we're central government and it's quite dry. But our team our team is absolutely amazing, and there's loads of work that kind of goes on behind the scenes that people don't get to see. Like there's members of our team that will contact Mozilla and Google and try and change the way they use their browsers so our components work better, and that's the kind of thing you never get to find out. So we're encouraging our team to write like more personal blogs even if it's two to three paragraphs, just to kind of let you know, some of the extent that we go to. And some of that work that you never get to see. So this is kind of behind the scenes stories which leads me on to a co-design project. Okay so I've been talking for a while so at this point I thought I'd take a short break and give you a chance to speak to someone next to you or around you or behind you, so I'm going to give you a minute or two and just give you this question… what does co-design or co-creation mean to you?

Does anyone wanna come in on what they kind of discussed?

Audience: Yeah we've talked a bit about review time and there was quite a bit about service design, we talked about earlier about designing for the 20 percent, so it's really bringing users together and working with them to deliver services. What did we also spoke about in the design aspect is bringing lots of developers together from different areas and different views like you've done to try and learn something a bit more substantial, that’s going to last a bit longer.

Imran: Right that's fantastic, yeah bringing more bringing users into the fold, bringing more designers and more perspectives in. Fantastic answer, anyone else want to come in?

Audience: Not necessarily just designers, people that might not think of themselves as designers. Sessions where we co-created content, not just as a design session, there’s people who might be experts in products.

Imran: Yeah absolutely. So getting more people involved and different perspectives. And it's kind of what we try to do with our working group actually, because our community is more designers and developers, but the next iteration of our working group we've got you know like digital leaders involved, content professionals. And it brings that different perspective, so yeah I completely agree.

Co-design, you can find definitions online. I think everyone roughly knows what it feels like, but it definitely can be a spectrum, right. You can have co-design in one instance and your limitations can be based on your organisation and the service that you're working with. It might be the chance that you get is just to run a few extra user research sessions, or you can go right to the other end of the spectrum which is where the users are actually designing for you. And that really depends on what context you're working in, okay.

Now with me it was a community, right. There's no budget here, I was in the budget. My kind of role there's no money at stake. I have a bunch of experts so the idea was to let's push this thing as far as we can go along that spectrum, and see what happens. Yeah I didn't know if it would work, it was definitely an experiment, but this is what kind of happened.

So generally I wanted the community to have more of a say, more of a say of what's going on, and it's definitely stepping out of my comfort zone. And as you know I'm a community person, I'm not a designer, and leading that community was already intimidating. But when you're leading something that's online, open-source, collaborative co-design during the pandemic that's kind of seems really implausible. And there was a lot of kind of complexity and I was definitely feeling it.

But what we wanted to do was create an alternative way for people to get something into the design system, because currently what was happening at the time was the team decided what went into the design system. So we did have this backlog that we've done, two-three years ago.

But there were also those kind of business needs coming in, and you know Covid was happening so a lot of resource was kind of taken to making sure GOV.UK is doing it’s job, which is obviously really important, but then this community that's contributing to it is not being served. So this was the opportunity to address that concern and balance things out a little bit. And we created something where we could cut the team out as much as possible, so the team is not a blocker to us doing this kind of collaboration.

It just meant that it doesn't matter what's happening within the team, the community can focus on doing what it is that they want to do. So this was the component that we worked on. It was called the task list. It's a component that people use when a citizen can't complete a transaction in one sitting. So if you go to a service and it's going to be really long, you might see section one, section two, section three, section four. That's the task list component. And that's just to let the citizen know, hey this is going to be a long process, this is where you are in the journey, and this is how much more you've got kind of left to do.

And maybe you can take a break in between the sections if you need to. So the community decides to make this a priority themselves. I did not choose it, this came up in conversation several times. And I pitched it like shall we do something about this? And people were like ‘yeahhh’. I kind of helped bring them together, that's what I saw as my role. Overall like 400 designers, developers, digital people, people who are just interested in this kind of collaboration came together. There were over 150 organisations that are being put into this and we're very grateful.

And we've all designed these kind of components. The work for this happened mostly in workshops and that was a conscious decision because not everyone's available inbetween these workshop times, and we want them to be inclusive and wanted as many perspectives as we could kind of get. And we didn't want to cut people out. And so I ran two workshops. And the first two workshops were kind of like scene setting. So we talked about what people's interest was in task list in the first one and as a community we kind of gathered our needs, like what are our usability needs, what other accessibility needs from this kind of component, what are the needs of the end users that they're trying to serve in the community? And then the community affinity mapped all those needs and kind of put them into groups which you see a picture of in that fold. In the second workshop as a community we were kind of like deciding the scope of the component, and what we're going to kind of build as our minimum viable product. So what features go into it what features do we kind of cut out so it doesn't get too much complaints?

So there was a lot of challenges to overcome and each workshop was bespoke. It has it’s own kind of set of goals, its own kind of challenges. So we have to design together, we have to be online. There were people from all around the world that joined that it, was super chuffed, and it was during a pandemic. And everyone uses different platforms in their organisations, so how do we tend to deal with that? So I wanted to remain open, accessible, collaborative, but it wasn't that easy to be agnostic of all those things.

After those sessions I did probably the most complicated session, which was a four-hour design-a- thon. So it's kind of a bit like a hackathon where we're kind of coming up with design ideas and wireframes. And it was online and so logistically it took a bit of work through different platforms, but what we ended up doing was pitching for time and voting on the most useful ideas and groups, and then we created ideas for prototypes based on the ideas that got the most votes.

It was a lot of mental work and I was definitely still kind of feeling the pressure as a non-designer, especially using design sessions. So we set up a steering group to help make decisions. So they started to help decide what went into those sessions. I kind of tried to coach them over time to take more control of the project and that was purposeful because I wanted the community to be making the decisions and not really for me to be kind of driving it.

So they ended up presenting part of the sessions as well, they ran breakout groups and they kept work and the momentum going in between these sessions. You've got Steve from Nexer, apart of that steering group. But it did a thoroughly good job. So in this context the idea for me was I'm just kind of facilitating this collaboration and handing over as much control as I can as possible, to the kind of community to run it. We did have an early success from that design as well, as one of the ideas we updated some guidance on the task list as it stood on the design system, so before we even built anything we'd updated and added intersections to the guidance so it was a really good early win from all these people that were kind of getting together and pitching in their ideas.

So hopes and reality. What were my hopes and what actually happened? Okay, so I thought that the interesting events kept the community engaged and we’d draw a wider audience because we're doing exciting online things that people don't do. Also such a large group from different organisations as we go through designing this thing, people start to understand our contributions, process and that encourages them to contribute more often we also about things. We also thought if we can do this more often, more contributions will go into the design system. So you've got the team over there pottering away on day-to-day work, and you've got the community over here like building the stuff that they want.

This particular task list, by the way ,was number 72 out of 100 on the list, so this wouldn’t have happened probably for a couple of years if the community didn't step up and decide to do this. And obviously I wanted people to learn from each other. So like you've got all these experts in the room working together they're starting to pick up on each other’s skills.

And by the way all of this did happen, so I was really really happy. But there were some other things as well, and in reality it was really difficult. So I was treading new grounds. I tried to speak to a lot of people but I didn't know anyone who'd done this before. So like literally everything is bespoke, you have to create a new way of doing things. So it's like inventing the Double Diamond every time you want to design a service or run a workshop. So yeah it took a lot of mental energy to organise and that's why we created that steering group to help. We wanted to invite new views all the time so I didn't block anyone from attending the sessions, anyone could turn up even halfway through the collaboration. But then it took up time in workshops to get these people up to speed. Here's what's happened so far, here's what we're looking to do in this session, and a lot needed to happen in that workshop because it's been two months since the last one. So it's time, how do you balance catching people up with making sure I'm getting this work done?

As I said, had to get through a lot of work, and they’re 90-minute workshops so there's a lot of pressure on that kind of time. And as time kind of grew on I was coaching that steering group and they were getting more and more involved, but increasingly I kind of felt like I was teaching them collaboration skills and giving them more control but I'm not using them to their potential. We've got some of the most expert designers probably in the world with this kind of stuff, and I'm getting them to do admin - it just it didn't sit right with me. And then I remembered my mentor’s advice like work to your strengths, right. I should be getting this steering group, this expert panel to be working to their strengths. And I should be working to mine. I did take on a lot throughout this. I became a community lead, a project manager for this particular component, the delivery manager and the workshop lead during the collaboration. So there's a lot of things kind of going on. I really enjoyed it, I probably wouldn't do it exactly the same again.

I became a singular point of contact for more information. So it was like ‘hey I want to join the co-design’,  ‘Go to speak to Imran’. More than happy to get you knowm people want to get involved. Try doing that 300 time,s it takes its toll and it takes up a lot of time when you want to be planning your next workshop design project. I’m also bad at saying no to exciting work, and so I created another co-design project. And it's because people so exciting work happening and they wanted to do other stuff. And this is not the remit of the design system, but it's not the remit of other things either. There was no one working on this and there are people passionate, willing to pour their time into it. So I was like f___ it, sorry that was literally it, so we kept hearing about it we decided to do something about it. What we're trying to do as part of this collaboration which is a lot less of our own, is make maps more consistent for the public sector.

In the first workshop we had over 90 people from across the public sector. A lot of them are like map experts. We had like a show and tell from Defra about the maps work that they've done, and then we collected some kind of user needs from the group in terms of what do you want from this collaboration. I put together a steering group for that to plan the next steps. That steering group’s grown to over 20 people now, which is amazing. They're all different map experts.

We then ran a fun session where we looked for lots of examples and maps best practice, and we started to analyse it. What can we get from the way maps are done well in other places? That’s something from that session. It has such a wide remit, ‘making maps better’. It's intimidating but it was also an open goal. So we set a short-term goal which for us is we're going to create a set of map design principles. So once we create these principles and kind of spread them across the public sector then we can build specific things that people use that align with these principles that we've kind of set.

Again there's no real best practice. How do you create a set of design principles for an entire sector? I don't know. I tried to speak to people because very few people have kind of done it. So fail fast, trial it, test it, iterate it, and hope we do well. And if we don't, let's make it better next time around. So the whole process – learning, iterating and improving, here's how we refine those code design projects.

So we designed a community landing page so instead of people just coming to me, they can get information about the project and what's happening through here. They can get straight onto the slack channels, ask people what's going on. There's no blocker by having this single point of contact that is in-room and I created a briefing for each co-design project as well, so when people enter those channels or start asking they can read this they get a bit of an update on what happened in each workshop, and it's got all the links to all the boards so if we collected user needs they can go have a look at what people came up with and even add their own things to that board.

We did some more targeted work as well in between those workshops. So we had these like big workshops where the whole community took part, but then the steering group did smaller workshops. So here we developed a prototype and we've writing some guidance. So the first chapter of the guidance was written by the smaller group but then we'll take it to the larger community to read through it and see if they agree to see if anything needs adding.

So in doing so we started to use the skills of those collaborators to the full extent, and one of the things we did was create a prototype so the designers and developers create a prototype which is now being tested with users in a few different departments. It's also been through our governance process, and will be added to the design system anytime now. The collaborations had a knock-on effect on some other components as well. So this kind of status that we use, which they worked on, ended up having a knock-on impact because when the working group saw it they said that's better than the current design so we've ended up actually updating the second component. So the collaboration is carried on and ended up working on the tag component and updating that as well.

There's lots of kind of work that went into the colour contrast, making it more accessible, using a sentence case that's more accessible to people with neurodiversity as well. And this is also having like an impact on some other things like this is a phase banner that we use at the top of our service. And because it's got a tag in it the visual change is going to be reflected in several places across different services, and this will be rolled out soon. So we created one component but actually we made several components better throughout this collaboration, and that will end up going out to kind of like millions of users pretty soon.

So what did I learn from the process? First of all co-design is community work. So if you're doing co-design you need to be building community. You need to show that you care about people's needs and you need to build that trusting relationship if you really want them to contribute in a meaningful way. And you'll build that trust over time by being there, being consistent and I kind of feel personally there's a responsibility if you're doing co-design as well. It's not about using people while you need them and then just dropping them. There needs to be an ongoing relationship once you've completed that first phase of work because you want to maintain that trust and you want to keep making whatever you've created together better.

You can definitely try to do too much. So this collaboration took two years and that's because we were trying to do education, we were trying to make it fun, we were trying to have like a steering group that I kind of coached and helped them make decisions and deliver part of the sessions. Like I could have delivered this quicker. We had no budget we had no strict time frame, that's the reason that we did it, to that kind of extension. And yweachieved all our goals but if I was to do it again I think I'd restrict the scope and definitely try and deliver it in a more timely manner.

I’ve said this several times, use the people that you have. Go to their friends to find out what they're good at and try and get them involved at doing those things that are within their area of comfort, and it will benefit the whole collaboration. And also kind of stick to a set of core volumes. So like everything we did was values-based. Like how do we want the design system and its community to feel? And that permeated throughout every workshop, through every interaction that we had with thousands of people across these two years.

So what is the team taking away? It's kind of affected our team and our team culture because if you want to have like an open source mentality, you kind of need the people that are also going to deliver it. So we start to do things slightly differently in our team. So we're more open about our work. We've got like a backlog of all these blogs that we’re writing, and we've been trying to blog more frequently even if it is there's like three or four paragraphs. We engage more on Slack as well, we share our roadmap more openly. You can just go on to our site and check that out and find out what we've shaped and what's coming up. We've also designed the page to encourage discussion around what's coming up. So before you went on to GitHub there's like 100 things and you were a bit lost, so here it's like here's our next three things we're working on, get involved in the discussion. I do want to kind of be involved when we start building this and that's your opportunity to let us know.

We're also updating our regular contribution process based on what we learned from the co-design. And it's not doing engagement for engagement sake, it's what parts of that co-design really added value to our regular kind of contribution process. So everything's quite pragmatic, so the principles are to work on things that are valuable to lots of teams and will involve a larger, more diverse group of people. Contributors will be clearer about what's happening and hopefully by getting people involved we’ll spot problems earlier. So yeah we've got many more touch-points with our users, this is going to be an expedited process. So we're hoping this takes like between six and nine months rather than the kind of two years and all the bits that I did as well. And and my colleague Chris Valentine actually wrote a blog about this, and he created a video to explain the contribution process. So we're trying to get that communication out there and put it into different formats so people can understand our contribution process more easily. So the next step will be choosing one of our prioritised things and trialling the model.

That's it for me, thank you.