Transcript
(00:22)
Awesome, thank you everyone for coming to my talk this evening. I’ll give a brief intro of myself first of all. My name’s Nathan, I’m a software developer at Thinkmill. I’m also an Orange local, I was born and raised here. I left in 2015 to study design at Western Sydney Uni and then I joined Thinkmill in 2018 as a junior designer and then moved into the development track from there. I’ve been working from home since March of 2020 and working from Orange since 2022 as well. We’re back to start a family and here’s that family: my wife Carrie, my four-month-old Sienna and my 15-month-old Winnie.
(01:07)
Thinkmill is a software development and design consultancy based in Sydney, we have 40 plus team members across Australia and New Zealand, founded in 2013. It’s actually our 10th anniversary next week. We’ve been recognised nationally for our open source contributions. We also run popular tech meetups like React Sydney, sponsor SydJS as well. We’re a lot of speakers at local and international events, such as this one. Lovely to be here, thank you for having me.
(01:38)
I’m going to be speaking today about designing applications with scale. We’re going to talk about what I do for work, an overview of design systems. So first, I want to solve the question: How do large organisations with multiple products — work done by several design and development teams — achieve consistency and a great user experience at scale? The answer is design systems.
A design system is a suite of design elements, guidelines, and standards that ensure visual and functional consistency in the creation of products or services. They’re used by product managers, designers, developers, writers, and managers to promote a unified and user-friendly experience across multiple touchpoints. At Thinkmill, we’ve worked on a bunch of design systems from startups to Atlassian, to the Australian government. We’ve led, shaped, and contributed to over a dozen design systems in our 10 years.
(02:30)
I’m going to be explaining design systems today while discussing what I’ve been working for the last two years at the Australian Department of Agriculture, Fisheries, and Forestry.
The export service is a digital transformation initiative designed to replace inefficient paper-based systems with digital apps to help Aussie producers sell to overseas markets.
Several teams were created to build various aspects of the export service, and it was imperative that measures were in place to ensure each piece of the experience was consistent and met accessibility targets.
These teams worked on various aspects of multiple different products designed for farmers and producers who are exporting goods overseas, whether it be food, grain, or animals. On-the-ground inspectors might visit the boats or the establishments to ensure that everything met standards and also to the internal staff who are processing the applications in the back end as well. To enable the development of all these products, we created AgDS or the Agriculture Design System.
(03:38)
Our design system is comprised of a few elements: the design language, the principles, and the guidelines of what it looks like to build something for this organisation; a library of components, templates, and patterns; and a community of users and contributors to the design system. I’ll go through each of these points.
First one is the design language. You may have an idea about what I mean by design language. I’ll throw up this slide. This is a brand-new design language. You probably know who this is already. I don’t even have to point out the logo mark in the bottom right corner for you to know that that is definitely Optus. This is the visual feel of the organisation. Design language can also be seen in product design as well. I just want to throw this up there because I’m a massive car guy, but basically, a design language can contain elements that are consistent across multiple product lines, including industrial designs such as the double kidney grill in a BMW. And design language can be seen in software as well.
(04:36)
I’ll take a tangent off Agriculture for a moment. This is some work that we worked on with Reckon. Reckon, a financial software company, based in Sydney. They’ve been around for a long time. They’ve been around since the days where you’d procure your accounting software, and it would arrive to you on a disk, and you’d install that onto your computer, and that was the computer with your accounting software on it, and you had to keep that very, very safe. Since then, the cloud has come in, they have cloud solutions, but they brought in Thinkmill.
We came in to help them form the new generation of their product lines – a suite of apps built for the mobile businesses of today. This is the App Store screenshots for the invoicing app, Reckon Invoices. You create your invoices, send to customers, receive payments, etc. We also built a payroll app, Reckon Payroll. You can set up your employees, you can pay them, you can track their leave, it’s got all the government reporting built in. There’s also a web experience as well (web and mobile).
Now, if you forget about the vibrant colour backgrounds, these apps are built using the same components, the same toolkit – all the buttons and the icons, the badges, the typography – they’re all from the same library. We also used the same library to build an employee experience. If an employer did a pay run, and paid your employees, the employee could open up their app, Reckon Mate, and they can see their payslips, they can do their expenses and see their leave entitlements, etc. We built the design language, a design system for Reckon, called Balance, an accounting pun for you, to enable the building of the mobile applications as well as the web apps as well.
(06:40)
Now, the design language for the Export Service is very pared back. It’s simple and easy to understand. That’s by design. It’s built for a variety of experience levels with computers, as well as for a variety of usability needs. I’ll talk a bit more about that after.
(07:00)
Part two – a design system includes a component library.
The component library is kind of like the lego blocks to make up an application. You can assemble them in a design tool or in code. These are generic components for building things like forms and content pages. They are built in Figma, which is the tool of choice for UI designers, and also in React, which is a user interface library for code in JavaScript. It's built by Facebook actually, which means it’s the best thing to come out of Facebook.
A couple of practical examples of what implementing the components looks like. The developer would import this into their file. This is a button component. This button was designed with a few different variants. This is the primary button. It has an icon, it has a label. That’s probably the most simple version of a component we’ve got.
Here’s a slightly more complex version. Here’s a composition with a form stack, which ensures consistent spacing between each of the different elements. We have a text input with a few different props on that. We have a button group with a primary and a secondary button.
Up from the micro layer of the components, we also have a suite of templates as well. Here’s a multi-step form. If you’re registering for a business with the government, or if you’re processing an intent to export some livestock, you’ll probably see our multi-step form templates. We have a timeline of progress indicator on the left that shows you where you are in the process of building a form, and each of the pages are very simple. There’s only ever a couple of inputs on each page. And we have a suite of templates, some for forms, some for content pages.
We also are working on some for more dense dashboards for the internal staff who are reviewing the applications, etc. And then we have some design patterns as well.
So, what does it look like when a table is loading? If that was a gif, that’d be pulsing, but you get the idea. Or, what it looks like to filter data. So, we have a few patterns for table filtering as well.
(09:28)
Now, briefly on accessibility. Accessibility is something that’s really at the heart for not only Thinkmill, but also with the Department of Agriculture. You know, it’s not like, if your customer at Optus has a bad experience, they could like to go elsewhere. But unless you want to move the country, you don’t really have a choice of provider with the government. Typically when you’re interacting with the government, it’s always for something important. It’s something that you have to do. So, we want to make sure that people, no matter what their needs are, are able to achieve what they need to.
For instance, we’ve provided experiences or we’ve tested for people who have partial or full vision impairment, people who are colourblind or deaf, have a physical or motor skill impairment, cognitively divergent, or just have a different experience level with computers as well.
When we design anything, whether it be a component or a template, we ensure that screen readers can describe it clearly. Screen readers are software that’s built into your computer. You can turn it on if you have vision difficulties, and it will audibly describe what it’s seeing as you tab around the screen. We ensure that screen reader support is right up there. We ensure that we build everything with valid HTML, and we use the right properties to describe the elements as well. So, every element has correct colour contrast, anyone with low vision can discern text and foreground elements from backgrounds. And also, not using colour alone to convey meaning. If you imagine a red banner or a green banner to denote some sort of error state, we ensure that we use more than just colour because if you’re colourblind, you won’t be able to see the intent from that message.
One of the highlights of this project has been an accessibility audit. We engaged with a third-party consultant, Intopia. They’re an accessibility expert to audit our component library and also to enable user testing. We were able to observe people who were totally vision impaired or people who couldn’t use their arms at all and were actually looking at a camera and using facial expressions to move a cursor around. It was pretty amazing to see. We had that audit and we’re very proud that they noted us as an exemplary example of an accessible component library, which was great. With their other clients, they actually use us as an example, because it’s open source, they use us as an example to say, this is how you do it right with building for accessibility.
(12:28)
A design system includes a community of users.
Design systems are effectively products of their own, but they’re built to serve other products. Like any product, you want to understand your users’ needs and foster relationships with them. So, it’s important to create a dialogue with your users and get feedback or encourage contributions to the system. A good design team regularly engages in discussion with consumers to build a picture of their needs so they can be building valuable enhancements to the design system, creating value that way.
The individual product teams in the organisation could be siloed from each other, so they have their own backlogs, plans, goals for sprints or for quarters. What a design system does is it centralises design practices, enables collaboration, and overall raises the standard of design for the whole department.
A design system enables collaboration in a few ways. We have internal chat channels, so if people are having design problems they can get in contact with a designer or developer in the design system team to get feedback on how to solve design problems. We also have fortnightly shareback sessions called “guilds”. There’s Design Guild and Tech Guild, and people can share back what they’ve been working on. We also have design system office hours as well. Every week, there’ll be a session, people can just drop in to ask their design questions and drop out as they need. That’s been really valuable to build that community and get people excited about the design system and using it and get feedback that way.
(14:15)
Like I said before, a key part of the community-building aspect of the design system is the fact that it’s all open source. All the code for the component library and documentation site is all open source, it’s all published on GitHub, it’s all public access. That allows people to contribute to the design system, and it actually also enables other government departments to share their codes. We’ve had other government departments get in contact to use the design system as well.
Q: Are you telling me that I could go and regenerate an exactness like the Department of Agriculture website, the look, the feel, the design language, using all AGDS?
A: Yeah, in theory, depending on your skill level. But yes
Q: Let’s assume I’m extremely skilled. Surely there are intellectual property issues. The government would not police its entire IP for someone to create an incredible looking phishing site that looks just like the genuine. Isn’t there an issue there?
A: Short answer is no. I can try and answer that for you afterwards. Yeah, I’ve some [time for] questions at the end, but effectively, there’s no business domain logic in the design system, there’s nothing related to applications [with] important, sensitive information. There’s no data being stored in the design system. It’s purely the lego blocks used to assemble these websites. You can create a pretty credible-looking phishing scam without doing any of this as well.
(16:12)
With that, I might just show a quick demo of the documentation site. I’m just going to Google "Agriculture Design System" so you can play along at home. We got pretty good SEO as well, which we’re very proud of. Right, so this is the design system website. All of the internal teams use this.
As you’ve seen, it’s very accessible to get into it. A couple of notes that I’ll show you.
We have a schema of design tokens. For instance, how we use colour is very well thought out in the system. We describe what the text colours are and how they’re used. The different types of background colours. We don’t have red or green or blue. We have success, error and info because that denotes the intent of the colours and how they’re used in the system. This is always very fun to play with, there is a dark mode as well, and people really get excited by pressing stuff like that, usually.
Right, what else have I got there? You’ve seen the component library, so I’ll just show a page, if I can type, "page alert" as an example. Each of the components are thoroughly documented. We have do’s and don’ts on each of the components. We describe, for instance, the toned-alerts, when you should see something like this. Notice we have the different icons as well as talking about using colour alone before, so if you’re colourblind, you would see the difference between an error and a success state.
I won’t labor on this for too long but we do have, patterns for filtering, loading and empty states. There’s a gif I was promising here before. There are live examples as well, so they’re being rendered in this space and a developer could copy the code as well. Error states – we’ve thought about it and explained here, how to do those.
And there’s our suite of templates as well. So, yeah, feel free to take a look around it through that. You know how to Google it now. I’ll stop sharing. Now I’m back to my slides.
(19:40)
All right, quick word on who built the design system. The DS team, the A-Team, just not quite as jacked. A design system team requires a mix of unique skill sets. So, we have a product manager, we have interaction designers, front-end developers, and my personal favourite, design-engineers who kind of bridge both the design and the development space. We have a mix of full and part-time practitioners, so some people might be part-time on product teams as well. They fulfil a variety of responsibilities, like designing or building components, writing documentation, accessibility testing, providing design support, running the community engagement initiatives, surveying users for needs, or generally planning our sprints and running, the maintaining, the managing, a backlog of work.
(20:33)
All right, so I just wanted to end on some key success points. First of all, AGDS is already powering the export service portal. If you go to exports of agriculture, you actually see it being used in the real world. It’s also been used by other government partners around Australia as well, which is great. Home affairs, I believe, and the Northern Territory government also express interest as well.
We’ve also enabled collaboration across siloed teams, which we’re very proud of. A lot of teams who don’t have their own backlogs and planning and generally don’t talk to each other, the design system works to enable that collaboration.
We also enabled a departmental rebrand. So, interesting story, when the Labor government came into power, before the election, we were actually the Department of Agriculture, Water and the Environment; and then when Labor came in, we became Agriculture, Forestry, and Fisheries. And then there was Environment, they got split off. There was Department of Climate Change created as well. The teams that were already using the design system, that was just a software update, effectively, to ingest that new logo, and actually prompted other teams to start using the design system as well. So, that was good.
Like I said before, the biggest highlight for us was to have someone else, who is a real expert in the accessibility space, call us an exemplary accessible component library and they told all their friends about us.
All righty, that just about does it for me. Is there any other questions?
Audience Q&A
Q: Is it just a component library or is it built on a UI framework? Specifically, do you have support for flexbox or CSS grid to automatically resize? Now, I work with component libraries before, it’s just a library and you still need to go and use Bootstrap.
(22:42)
The primary touchpoint is the component library it’s built using React.js. It’s all CSS as well, so there’s flexbox and all those things that you mentioned as well, that’s all part of the system. But on top of that, there’s all the design principles, which I didn’t show in my demo, but we’ve got extensive documentation about what it looks like to build something with AGDS.
Q: I assume you have a core library and then you fork it or branch it for other clients, but do you keep that up to date and push revisions to change the core library?
(23:32)
A: Thinkmill doesn’t have a core library that all these other design systems are based off. They’re all independently built and ran. We actually make some open-source libraries that layers some of the foundation of them, but each of the libraries we’ve worked on, for the most part, independent of each other. We’ll share our ideas. A lot of the design systems we’ve worked on are open source. And the web development 10 years ago, it’s very different to what it is now. So, there’s always new things, and it would be more of a hindrance to have one central Thinkmill library that is always kept up to date. Frankly, we’re always fiddling with stuff, and we’re always wanting to try the new thing.
Q: Are these components just for web or mobile too?
(24:36)
A: In the case of Agriculture, there’s just web. For Reckon, which I spoke about before, there’s a core design language, of which we call Balance, and Balance has a React implementation as well as a React Native. Writing React Native is very similar to running regular React, but you run it through a different compiler, and it spits out an Android app and an iOS app.
Q: Have you done any design for wearables like an Apple Watch?
(25:11)
A: Not personally, but I think I’ve fiddled with a couple of apps just for fun before. Actually one of our guys, a couple weeks ago, was building a service that we use to basically build Lego characters inspired by each of the team members. And the website wasn’t very great. So he actually did a concept for building a new version where it was a 3D model in the browser. And it was like, what if I took that and put into the Apple Vision Pro headset and to Oculus, and he actually got a working prototype. We didn’t have the headset yet, but it was doing it in the simulator. Those libraries in the code were able to be shared between, web, iPhone, and VR systems.
Q: You were talking about the design language there. Is it actually is a language that helps to create the design elements that gets compiled down into other frameworks?
(26:20)
A: Essentially, yes. I didn’t labor on that part too much, but a really great thing about design systems is the shared handoff between designers and developers. What tends to happen without design systems is a designer will draw boxes and shapes, and developers have to translate that. As I showed a moment ago, the button with the variant primary and secondary, the same components effectively are built in Figma. A developer also calls that same thing a primary button as well. So, that makes the handoff a lot smoother.
Q: With Reckon, you created a language called Balance. Do you actually make a specific language for each product?
(27:12)
A: Not a coding language per se. The language is effectively what things are called. So, what do we call a badge or a button? It’s creating a shared vocabulary in all those elements between design and development. In terms of coding language, it’s all JavaScript, React and HTML.
Q: Can component libraries be integrated into online reporting and business analytics systems such as Power BI?
(28:30)
A: In theory, yes. That depends on the capabilities of things like Power BI. I have heard of people spending a bunch of time creating really nice Power BI dashboards. They’re not necessarily compatible with React, but they might be compatible with CSS and different styling frameworks as well.
Q: You mentioned Figma at the start. Assume you know that Adobe is buying them out, and that seems to be moving to two trains of thought - either Adobe is going to ruin the software, or pump it full of AI and all their own stuff. Any thoughts, concerns?
(29:42)
A: I guess when we originally read on the merger or the buyout, there were a few jokes like that being thrown around. I will say that recently, with the investment, they’ve developed a lot of really cool features like the design tokens. I don’t pay for the licenses, so I don’t think they’ve necessarily upped the price or anything like that yet or forced you to have a Creative Cloud subscription. I think if they did that, they would destroy their business and their customers, but so far, so good.
Q: Just in terms of the AI technology [...] what’s Thinkmill going to do in the future?
(31:18)
A: Thinkmill is really open-minded on AI. We have people that are experimenting with it, like what it could look like to integrate something like that into various products or systems, but nothing tangible at this point. We’re definitely remaining open-minded, and I’m sure we’ll have customers and clients who are interested in that space as well. That’s all I can say at this point.
Q: Around generative AI, you’ve already made a lot of these very deliberate design decisions about these components and you could feed that into AI and say, go and build me a website and that would go and automate something [...]
(32:10)
A: I guess I can say that the majority of problems that, as consultants, we’re there to solve most the time are more organisational or people problems than technology. Technology is certainly a factor of it, and there’s plenty of white label component libraries out there that people can adopt but rarely for large organisations. Those white label systems are great for startups or for getting something up and running, but for large organisations, typically, they need elements that are more opinionated, or templates that solve problems for their specific business needs. So we’re not too worried about our jobs at the moment.
Q: The components you shared with us are largely static. Do you have any more interactive ones like sliders and date pickers?
(33:15)
A: I can show you if you’d like. We have a date picker that when you click on the little icon, it has a little fly out. And there’s a calendar, accordions and modals as well. The accessibility challenges of modals in particular are really interesting and complex, and so we spend a bunch of time labouring over what an accessible implementation of a modal looks like.
Q: The experience on mobile is completely different because you can’t click, right?
(33:55)
A: There’s some components that, such as a tooltip, you hover over something, and then that a little fly out comes out. You can’t hover anything on a mobile device, so our design system team on top of building value and building components, you also need to have an idea of what not to do as well, and develop those design principles to inform direction.
Q: What trade-offs you’ve seen with having a design system [like a government service] that enables you to move to high fidelity so quickly?
(34:55)
A:There are certainly growing pains. I’ll answer the question I think you’re asking. Once you’ve got the critical mass of a design system and you’ve got templates that are tried and tested, then product teams are able to use those templates or contribute new ones. At the initial stage where you’re building a design system, you need to be informed by products and understand their needs to build something like that. If you’re building those things in parallel, there are trade-offs in terms of velocity to build and design something right, and making sure that it’s done in a systematic way rather than building a one-off prototype or a standalone product that doesn’t necessarily need a design system.
Q: In contrast, the trade-offs that I’ve seen is that going to high fidelity really quickly means that the feedback that you get, whether it’s from users or other stakeholders in your organisation, ends up just kind of fiddling around the edges. Where the feedback that you’re after, whether this is meeting the needs as opposed to does this look right, and the trade-offs around going to high fidelity very quickly, whether it’s stakeholders or customers, they quickly go to, does this look right, yes, or I’ll just kind of adjust things on the page a little bit, as opposed to thinking about, does this actually meet my needs? It’s an interesting challenge that the benefits that you have of being able to move to high fidelity quickly versus stripping that back and making sure that the service is actually as effective as it needs to be. Probably less of a question and more of a comment.
A: I guess our core clientele at the moment is large corporate entities that have a suite of existing products or existing systems as well. A lot of the time, you’re not just finding design and what looks right, but also, you know, we’ve got tech debt of a 30-year-old accounting software or something like that as well.
Q: Is it the staff at the Department of AG using your design system and building their pages, or does Thinkmill also do that?
(37:45)
A: In the case of AG, they are the staff of Agriculture, and Agriculture have a mix of contractors and full-time staff. But our work at Thinkmill is just on the design system front.
Q: Have you had any external contributors to your open-source repos yet?
(38:06)
A: We’ve had a lot of interest. The design language I was speaking about was actually very inspired by the former Australian government design system that was run by the DTA. That got defunded and turned to a community-driven model. It was also a 10-year-old tech stack so we wanted to take what that stood for – the design language, the thinking and the investment behind that – but re-implement it in modern React. We’ve had some really good feedback from people that used to work on that system as well.
