Date: 8 Mar 2018
Nick: We currently have a similar setup to you guys, with multiple packages for multiple components. Why did you decide to take this approach?
Dominik: We come from a monolithic CSS (Bootstrap), and the reason for us moving to individual components was that it reduces ‘upgrade anxiety’ and helps with adoption. Answers to a lot of questions that you never had.
When we have individual modules we can version separately and those changes will affect only the ones using them. It comes with a lot of work, managing versions, dependencies, etc, but it’s up to us to do the hard work to make things simple. Everything should work out of the box.
Nick: We were thinking about how people consume individual components if there’s loads of shared globals. If you have multiple versions of a component in a projects how do you manage to avoid conflicts?
Dominik: We created Pancake to deal with that. It runs on the install and tells you when you have a clash so you know what's causing the error and what dependency to use.
Nick: You mentioned that you ruled out Bootstrap, making a custom build instead. Why did you decide to do that, and what are the limitations for that?
Dominik: If you’re still creating one version for the entire thing, then when you fix an accessibility bug in one component everyone will have to update the entire thing.
Design System is all about adoption and community, so we have to do as much as possible to make it a good experience for developers.
Alice: What are your plans for taking contributions from another people?
Trevor: To begin with, we’re just seeing how it grows organically.
The Design System isn’t strictly brand new. Other departments are already contributing components, and we’re relying on those early adopters to get things going.
We want to make sure that we’re listening and responding when people engage with us.
We're using a forum called Discourse to engage general conversations, for people like designers, accessibility experts, user researchers etc who might find GitHub a potential barrier.
Some people - developers especially - like to just get straight into the code and they can still use GitHub for that, but we're monitoring both.
Our team decides what goes into the Design System, but we try to be fairly open about that.
Patrick: Another thing is that we're doing a lot of meet-ups. At the last one, we had around 100 people. We discussed challenges with other teams, including one of the big banks in Australia. We had an encouraging discussion with them after the meetup. They have a really well-developed Design System but have a lot of the same struggles as us. We found lots of areas to collaborate on.
We made a decision early on to try and make our Design System as open as possible. GitHub was a big part of that, and Discourse is also open to anybody. We have a meetup later this month in Canberra. There are actually more private sector organisations coming than public. We want to involve the whole community and be completely open to the public; we want anyone to join, including the private sector.
Being a team of only 4 people we need the federated model to pay off. We need to outline a pathway for people to become core contributors.
Amy: I've been working quite closely with our service designer on how we create a federated model, so people become quite engaged with you. We've been doing a lot of work on how to review the proposed stuff, in a way that's fair. We created a design system working group, and did a lot of work (including a set of criteria) to give them the confidence to make the decisions. At this point we're trying to recruit for the working group, try it for 3 months and then try to rotate.
Patrick: Once people actually saw our Design System thing they got more engaged. They can understand why you’d contribute to it.
Dominik: We've done a lot of research after we've done our first version on how to get together on a thing. Branding is a big issue, ownership is another one. For us is really about explaining that we won't be able to do it alone, and try to give equal powers to them; improve documentation and treat them as equal partners, explain whys and the last thing what really helped was making very clear that we put a lot of work on it that no one wants to put in (as accessibility). A lot of people don't want to deal with that.
Alex J: Any findings around building technology-agnostic framework?
Dominik: We only have one component using JavaScript so wasn't that hard. But digital transformation is all about getting departments to a higher level. You can’t force them and it takes time. We even support IE8. You can’t do it all at once, you need to take them on a journey.
Trevor: We also looked at the current tech landscape to learn what people were using at the time (jQuery was very popular), Vanilla JS (plain JavaScript) is the simple way to cover most projects, and React helps us reach the modern developers.
Ollie: We had people only copying and pasting code... developers that assume that the only thing they need to take are the classes. Have you seen examples of people making assumptions, too? And how have you got around this?
Alex P: Yes, we had the exact same problem. One of the ways we’re tackling it is to provide templates. So, a whole HTML page that contains things like fallbacks for IE, no JS in HTML tags etc. Things that we know are needed, but devs may not.
Dominik: I believe React shines exactly for these things. You can have Aria roles, you can warn people about certain things that are missing etc.
Trevor: We’ve also got a slightly different environment from you guys. For example WCAG has been a requirement for some time in Australia. Developers are aware of it so will be more likely to check the semantics and use ARIA roles etc.
Alice: Have you seen anything surprising during user research?
Trevor: We’ve found we have 2 types of users:
There’s the ‘fly-in, fly-out’ users who just want to go in and get what they need. Designers here might browse, and look at examples, but just take what they need. Devs just want the code - they might not even use the Design System, and just go straight to GitHub.
Other users are interested in actually reading the docs. They want to know why we’ve done something. That’s why we’ve added the rationale section to most of our components, that links through to further docs. It’s almost inline, but not disrupting the journeys of the ‘fly-in, fly-out’ users.
Amy: Have you had any issues with duplicated content across the Design System and GitHub? We're trying to make sure people have everything they need where they look for it, but also trying to avoid too much duplication.
Trevor: Ideally we would try and customise the content to the use case. Because we’re a small team, we're trying to pull in that content, we're trying to avoid duplicating that (npm, GitHub and the DS).
Dominik: It’s crucial to have READMEs for each component, not just the main README. Each one should have a changelog and a version history explaining why things have changed. If we want people to update, we need to explain why.
Pat: We aim to have one source of truth, and link to it from the other places where it’s relevant. That’s generally GitHub for change logs and versioning, and the Design System links to that. Some docs are just repeated, though.
Jani: Single component vs All components consumption
Dominik: Sometimes we make updates to a number of components at a time, and they’ll all get breaking changes.
The ability to upgrade a single component is a very important tool in selling it to teams that have a lot of deadlines. We can say ‘there’s new stuff here, but go at your own pace’.
Alex P: Some of our partners said: "We're not ready to use all the stuff, but we really want to use the grid".
Jani: I guess that's why you have Pancake.
Ollie: What's actually a breaking change?
Dominik: We use patch to fix, minor is for adding a new feature, and major is if you make a change to the HTML (e.g. aria attributes).
Trevor: It’s difficult to do usability and tasked based testing on individual components, so we rely heavily on getting feedback from the teams implementing the Design System. We want to give you a component so that you can do research with it. We’re planning work on whole page templates, and hope that once we have those it will be easier to do our own tasked based tests to see how components are performing.
Alex P: People share their User Research with us.