 Thank you, everyone, just to clarify, so there was a presentation in Canberra around GovCMS and Civic Theme, but today's presentation will be slightly different. It's actually a variation of one I did at the Drupal South in Wellington, so this is a more advanced version of that one. So just to clarify that. So welcome to the session, we'll be talking about Figma, designing in Figma and deploying a pixel-perfect Drupal website in days, not weeks. So firstly, I need to converse that I'm providing you a warning up front now that I'll be making two controversial statements. May upset some of you and not aiming to offend anyone, but let's see what happens. And that's one of the disclaimers out of the way right now. So let's just begin. So just a quick intro or covering what we're agenda, what we're covering today. We've got just a quick intro, how a web development typically happens, how a true design system can help Drupal builds, introducing Civic Theme and open source true design system, and showing the magic of kind of how this works and what it is and what it isn't. And then some questions. Hello. An intro to me quickly. My name is Achille, I was living in Australia, so we're here. 22 years in the tech industry, started kind of in product sales and with the web software company, then I ended up having my own agency looking after graphic design, web design, front end development and website development. So I did all the coding in the olden days, when it was just HTML, basic kind of UI market stuff. And then I did a lot of user experience and designs worked in the last decade or so worked with the Department of Communications and the arts, specifically in the web services team. And then moved into the communications team where I was in both of those was looking after the external websites for the corporate sites and the internal internet as well. And then I think I had another arts when we got marked with arts, so joined with another department. And I also looked at the arts website as well for about the seven of the years that was there. And then lastly last few for a few years, four years especially, I've worked with Solstice Digital where I am now. And as a digital engagement manager, marketing business development lead and kind of UX and product development with our teams internally here. So I'm going to skip usual. This is a bit more of an interactive session, it's a bit harder when it's a bit online, but I'm expecting people to wave and do whatever they can to interact with me if they like to. So I'm going to skip the usual. Who's the designer? Who's the developer? Question. You all know who you are. But I'm going to ask you all a couple of questions here. And hopefully if you can put your hand up it's fine. So who here starts with an actual visual design when they're actually building a website? And there's a lot of developers around for anyone. I'm actually quickly looking at the screen there. Anyone want to confess? Yes? Okay. Anyone want to? Cool. And then who actually wings it? So, you know, you might use some low fire wireframes or something else and kind of have an idea of what you're going to do. It just goes into building. I'm guessing it's a lot of the developers here. Let's just say if you are you, okay, cool. So typically what happens on a web design and build process is that you'll have, you know, stages where you'll have the design and discovery and the builds and then a couple of stages towards the end to kind of finalize and test everything off before it's launched. It's more like a relay race. There's a bit of a batten pass between the phases, you know, it's a very sequential process. Even though it's agile development, there is kind of distinct phases within this. And normally the first phase is in the design phase where it's followed by build unless you have those developers who just wing it and they'll just jump straight into the build phase there. And then often the design team is either an internal team or most often an external agency that's engaged to do the designs responsible for the SOS component where it may also include, you know, user testing and any kind of user validation and work there for HCD designs. So just running through kind of the diagram there, we've got the requirements, discovery, lo-fi, wireframe development, et cetera, in that first phase. Sorry. Can I, are you trying to share your screen or not? Yes, yeah, I was. Ah, I have not. Maybe, maybe it's not coming through, try again. You have not shared your screen yet. Any of it. Oh, wow. I did try. Something didn't work. It looks like it bounced off. The reason I came in late because I had an update with NVIDIA, so I think something just knocked up. Let me give it a second. Do you want me to start again? Is it sharing now? Yes. Okay, cool. Great. Thank you. Oh, good now. Okay. That was fun. Okay, so I'm going to skip through. Now you can imagine what I was showing you. You can actually see what it looks like. That's me. So this is what I was explaining. Yes. So thank you. So just running through the diagram there. And these are kind of the high level things that you'd include. It's kind of the requirements, discovery, some life, lo-fi, wireframe development potentially. Then you would validate those with some user research activities. And then there'd be some design iterations within there. And you could have one or two sprints or many sprints depending on how long you understood the designs and how detailed you wanted to do those. And then you finally have your final designs, which are then to be signed off. So that kind of marker there. Then depending on a project, there's some kind of handover. Often this is done with, you know, the design team potentially to the next phase, either the files are just handed over, or sometimes there's some kind of exchange there to explain what's going on. Does that make sense with everyone? That's everyone pretty much agrees. That's generally how it works. Yes. People are nodding. At least they can see what they're nodding to. Thank you. So any idea how long I was going to ask, actually, any idea how long the first phase typically would take, that's saying about right, you know, three to eight weeks, depending on the range of activities you put in there. Anyone want to nod or... Yes. Cool. Yes. We'll just go with yes. And then the second phase can take anywhere between four to 16 weeks or more, depending on the size of complexity of the website. So, you know, overall it's roughly, you know, 24 weeks to do a project could be less, could be anything from like, you know, the four to seven, so four weeks plus three, two to three. And then that would be the range of your project there. So that's kind of the general approach. It could be less. Screen to change. So there's common issues with this approach. So as I mentioned before, there's a kind of warm or cold handover of the design files. So the pressure is on now. Exactly the question. The project started and the project design is about to, you know, the design team are about to start another project while the build team is waiting for the designs to be handed over to start their project. So what happens generally the handover is either cold or warm, you either just get the files as is, or you have some kind of transition meeting to say, hey, here are the files, here are the things we'll count for, et cetera, some kind of knowledge transfer, but often that's the one time deal, you know, that's normally done at the end of that design phase, that first phase that we showed and that's kind of it. And if you're lucky, you might have access to the design team internally to ask questions. So those questions that may come up further down the track, really just working off the designs you have, you know, and if things come up like, you know, how does that promo card work? Or, you know, how does that, one of my favourites is how is this going to work on a touch device? Well, it's really up to the developers and the build team to kind of figure that out or kind of fill in the gaps on their own accord. The other things that the, is that lost in translation. So the coding can take time. Obviously you're building everything from scratch and naturally there's a process to go through of tidying up and fixing and going through testing and then the multiple rounds of testing can take time itself as well. So usually that development cycle can be time consuming, but also kind of has its own overhead and issues that it comes up with. The last one there is a degradation of the design vision and the user experience. So in that first phase, whether it's two, three, seven, eight, 12 weeks, there's a high investment cost there generally done with a design team, especially if there's user research and kind of more thorough approach to kind of going out into the market or going out to users and seeing what they're saying and all that feedback and intelligence and insights needs to come back into the designs, which it does. Now that's often only used in that one phase. So it's all done in that design phase and that cost is quite high or can be quite high. So there's a lot of investment up front and those key findings are poured into the final designs. Now this is used for that initial build only. Often during the build, there's technical variations creep in, there may be variations of the designs and that's towards the end of the project or during the project itself. But down the track, a new feature needs to be developed and that's based only on the live site. It's rare that anyone will look back at the original designs at all and so all that investment is kind of just almost a once-off type of sunk cost. So I just kind of quickly validate is that the case is anyone used original design files from a project, say a year or two later? Anyone? Yeah, yeah, one or two. Yep. Okay, good. So I wouldn't say it's very common, but there is, yeah, there's a chance that you could look at that. But again, it's kind of a one-off sunk cost and that's a process because of the way that it's set up, the way that it's done. So now how can a true design system help Drupal builds? So I'm going to ask a question here, but I think most people would know this one who's worked with the design system here and anyone use them regularly in their projects. A bit of a loaded question in this group here, so I'm going to skip that question. So what do I mean by a true design system? So maybe let's just quickly define what a design system is. So we've got a definition from the Nielsen-Norman group, which you might have seen. What needs research user experience. And their definition is a design system of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels. So it may resonate with some people, but that's what it actually is versus what they may understand. And I'll just go through some of the components there because I think there's some kind of common misconception about what a design system is and what it actually consists of and what it's supposed to be for. But the design, a design system consists of visual guides of how to actually build or visually place things on the page or any kind of digital asset. The usage guidelines of how those assets are actually used and interact with other assets. The components that make up a user interface kit or pattern library, which is probably the most common bit that people actually understand or assume is part of what is a design system. It's usually what they think of as either a UI kit or a pattern library. And a design system is often quite static. It's created potentially at a point in time and sometimes used as a kind of one-off reference. This is different to a true design system where with a true design system, in addition to the above, you have this ability that it's a dynamic document. It matures. It's a living thing that gets updated as new features are added. So that example I gave about, hey, who's looked at something a year ago? Well, if there are new features, they actually get fed back into the system itself and are part of the system. So that's more of a true design system. It's a living document that matures with the product or the sites or assets that is used within that design system. There are coding standards specifically that you can include code snippets or other more sophisticated cases, which would actually include a library of codified components. So those are actual functional components that are actually part of the design system rather than this. These are the visual designs within a tool. These are actually the functional components that are coded and the standards to use those. And lastly is the documentation. Quite often there is a comprehensive documentation about the decisions made and the component usage usage and how to modify them if you're going to continue or extend the design system to make those extra new components that makes it grow. So a true design system is definitely what you want to use over a design system. So the other thing we're going to talk about is Figma. So I'm just going to quickly cover what Figma is. So Figma is a collaborative tool. It's used for UX design, UX prototyping and other kind of design activities, which is basically run online. Sorry, it runs through the cloud or via the cloud. It can create fully working apps and responsive websites within the Figma program itself. There's no coding required. It's all kind of interface and UI driven drag and drop and kind of similar to any kind of design interface that you might use on other products like the rearrange or other similar sketch or anything else. It's highly accessible. So you can learn to use this in days rather than doing long courses or short courses to figure out how it all works. It's fairly intuitive. Now I'm going to go through in-depth an expanded history of Drupal. I'm just kidding. We all know what Drupal is. So I'm going to go through now. So we've talked about what a design system is, what a true design system is in Figma, kind of just building up here. Now I'm just going to quickly talk about the benefits of using a true design system. So naturally, if you've got something that is like Figma, which is an online cloud based tool, which is collaborative, the key of having a design system with both the functional and the components that are built out codified are obviously what the developers would be looking at and can use and the design, visual design components of what the designers would use. But what is super useful now is that you've got this ability in one design system looking at both of these components from both ends. So the developers can actually see what the designs look like and the designers can actually see what the functional components look like. If I make a change here and I want to do something, it might impact the interactivity of or the interaction spec of particular components. So this kind of ability to bridge the gap between designers and developers is kind of the biggest thing around having a true design system. The other one is that everyone has a common understanding of what the language is, reducing the time going back and forth when you have definitions of what each element component is. The consistency that this produces so a design system allows you to have a range of components over websites or other platforms or a group of websites with a unified brand voice and feel across all the platforms. All the buttons look the same. All the interfaces look the same. The scroll bars are on the right spot. I've seen a recently looked at a wireframe and it had multiple pages and there was the same component with a scroller button at the top and the scroller button at the bottom of the different page and it was all a little bit different for some reason even though it's the same component it was not that consistency that should have been there from a UX point of view. It also eliminates design discrepancies and that enhances user trust when using these systems. You kind of know that there's been some thought behind that. And then it also creates efficiencies so this is what we're talking about today is the acceleration to move from design to development very quickly and it also avoids redundant work. So rebuilding or redesigning or even multiple teams trying to work out what these different components could look like. The example I had earlier about the handing over the design files and kind of working out what something is supposed to do or look like when say the design team have already worked all that out but it just wasn't very clear. So having a design system where the developers and all the team can look at the one source of truth makes that much more efficient. So now introducing Civic Theme which is an open source true design system. So you may remember I mentioned there will be two controversial statements earlier. Well here they are. What if I said to the developers you don't need to rely on designers anymore at all? Is that controversial? Are there any designers in the room? Are there any designers in the room? I'm just trying to see if there is anyone else. Well let's make it fair. What if I said designers you don't need developers anymore? Is that even more controversial? There are a lot of developers here. Lots of. You'll believe. Well how about we compromise and what if designers and developers could both build high quality visual engaging websites on their own so individually right? Developers can build and design the part as well as designers can actually build websites. Or even just working more efficiently together. So Civic Theme is an open source inclusive component based design system that's created for governments and organizations can rapidly assemble modern, consistent and compliant digital experiences for its audiences. So out of the box it's an atomic based design system. So just to define an atomic based design it was developed by Brad Frost where the designs were made up of individual elements and they build up to create larger elements and larger components. So basically there are base elements atoms and then there are molecules which are a formation of atoms then there are organisms and then templates and the whole pages and I'll cover some of these a little bit later potentially so. Design and those kind of building blocks is one of the key parts here to how this is set up. With Civic Theme there are also 60 included components in Sigma and also codified in Storybook which is what the tool that we use for the codified components in the design system for the designers to see and use and there's also a Drupal 10 theme. So all the components are created into the Drupal theme components as well and there are also low to no code assembly of site that allows web admins and even content authors to build and manage their own pages layouts and designs. It is also WCAG 2.1AA compliant and includes an accessibility compliance report for every development release to ensure that this is maintained through the product lifecycle. It's highly extensible. The design system and Drupal theme is architected to be highly extendable to allow more sophisticated design patterns, integrations and modifications and visual themes to be added and integrated into the base design system itself. And it's visually stunning. It won the Drupal Slash Awards this year for the best Drupal UX design and project early this year at the Drupal South Awards. It is recommended by government. So in Australia here we've got the Australian Government Architecture website which is managed by the Digital Transformation Agency, DTA and Civic Theme is recommended by the DTA and this website, the AGA website for new government websites to use on their projects. The Civic Theme is the recommended theme to use. And lastly it's technology agnostic. So currently we've built a Drupal 10 theme. However the design system, which is the Figma designs and the functional components are technology agnostic. They don't have to be connected to Drupal 10. They can be used with Vue.js or other technologies which still use the design system framework at the moment which just happened to build the Drupal 10 theme itself. So how can we do this in days not weeks? So how can we build a site in days and design a site in days rather than weeks? So we did talk about the number of weeks that it took to design and the number of weeks that it took to build. Well these three parts of the site are the visual design library which gives us the design UI library of components. It's built in Figma. It uses the atomic design architecture. It's cloud collaborative and the 60 design components are available in this design library. The codified UI components are the functional UI library of components of the actual design components but actually working with HTML and JavaScript and other technologies there. It uses Storybook to actually show these in isolation. So each of these components can actually be interacted with without having to run a website. So these can actually work and you can see each of the components actually functioning under variations and changes that you can do to each of those components. And again there are the 60 functional components. It also is made up of a visual theme. So as I mentioned before there's a Drupal 10 UI library of components. There's a roadmap that includes other technologies potentially and decoupling the system as well and it also allows for the low code, no code, management of page layouts and designs. And again there's the 60 Drupal components that are made. So with these three things in particular we can now do things in days not weeks. Now the key here is that both the designers and developers can actually use all parts of this. And the bottom there you can see the 60 design components, function components and triple components. Those fixed components are in 100% sync all time. Well they're almost in sync all the time, most of the time. About 99% of the time. That depends on the lifecycle of the design library. Changes and contributions and changes as they flow through but they're pretty much in sync. So if you pick up the designs you can actually build everything that is available in the designs and in the Drupal side you can actually build everything that is available in Figma. So how can a true design system benefit projects? Well it can rapidly help with functional prototyping. You can get rich feedback from interactions of the functional designs rather than just low-fi wireframes which people click through. So in a process where you can actually interact with elements instead of just getting a feedback on the page you may actually get additional insights into the buttons and functions within the design and the actual components themselves which would have potentially been a process that included a second or third iteration of more wireframes as they matured in low-fi to high-fi. Getting user detail, detailed user feedback earlier in the process so instead of as I mentioned maturing the wireframes from multiple stages the higher fidelity interactive product types will allow this feedback to be done in an earlier process within that design also reducing the number of rounds of design iterations that you need in the project itself in that sprint plan that we showed earlier. So this also allows the projects to focus more on improving UX like user journeys users finding key information or completing key tasks rather than designing and building buttons or menus for every single project. So the focus becomes more on how the designs can improve user experience not about how you build a button for every website that you start with. There is minimal development out of the box. There's no load and no code side assembly so all the components are pre-built and use the Drupal admin to basically configure within the content type the different variations of what you can see on the front end. It's highly accessible so it feels more sophisticated website projects as well as the very simple ones and very fast to deploy can quickly deploy small campaign websites which then use the same consistent high quality digital experience that the main website or the brand design system that exists. Okay so we've talked about the process from Figma to build and you want to know how it actually works and what the magic is. We've talked about the two different stages of the multiple process here that we do so if you have a true design system and a cohesive design system like Civic Theme with a comprehensive UI kit and codified component library you can move from Figma to Drupal very very fast. Designers can be rapidly built and prototyped to deliver that high failure design very quickly while developers can assemble and build sites quickly as well. The real magic is really how we architected Figma and the design system and the key ingredient is the atomic based design system and the companion codified component library so those are the visual designs and the codified functional parts and that's what makes the Civic Theme design system possible. We've also built the Drupal 10 theme however today it doesn't connect from Figma to Drupal so I'm just going to quickly press these so you can now do things in days and weeks not in the traditional months that it normally takes. Although we don't have a connection from Figma to Drupal right now it is a process of either using the Figma visual design library and then using the Drupal build there's no way to change anything in Figma and have that kind of spit out code that doesn't work that way at the moment but maybe one day it could be potentially looking at ways that could potentially happen. So an example in real life so the Climate Change Authority this was a project that we completed with Civic Theme in four weeks from design to assembly. It included migration as well of 250 pages and almost a thousand media files all done in four weeks. There was an extended time afterwards that we kind of did a little bit more UAT and other work with it but they took really just around the four weeks to build out this site which was very very fast. So how would you start your open source Drupal project? So you could use what's in the box so you can adopt the Civic Theme design system as it is. So you can use either the Figma out of the box design and visual library with minor styling and branding applied to your site where you can extend the Figma designs to create kind of new modified components. You can make the box bigger, you can adapt to Civic Theme you can use the atomic design elements to reassemble, modify or completely create new components using what's already there that's changing the atoms and molecules and rearranging those. You can also then just change the visual spacing and other things to create new components while maintaining the codified elements and wiring that Drupal might have in the theme itself to make that easier. Or you could kind of just throw out the box inside your own Drupal build instead of having to start with Figma you can just start building with the site directly again it's low to no code after it's set up. Civic Theme resources, we have quite a few resources. It's an open source project so the URL's up there but there are plenty of elements here that you can kind of work with whether it's on the Figma side or on the Drupal side you can work with any of these things here. Let's give her that. So with a true design system you can really build design and build a Drupal site at scale at a very very short period of time. For now is there any questions? Good. Thank you. I do have a question, I'm sorry. I was just trying to compose it in my mind right and yeah hopefully I can do this just in time. Part of the premise no designer developer can assemble the components and they've got enough of a kickstart to produce a really great website and I'm sure that is the case in certain contexts particularly in simple contexts. What about complicated journeys UX is a discipline itself and people are sort of formally trained as UX people and engineers are sort of technical by nature and I imagine there's a bit of a blurriness there as to what's practical what's not can you talk a little bit to that and your experience there? I may have kind of skipped over this bottom one a little bit quickly but at the bottom there you can see the design there the one to three days is really just building out that base design or the base build from a design point of view in stigma naturally whatever UX you'd want to do on top of that happens on top of that. The other part is that with any of these projects with any project really once you have additional feedback and iteration and changes then yes that would change and I guess from a non-developer from a designer point of view that needs to be potentially familiar with Figma itself and basic kind of design principles to modify those designs but the way that it works that it's fairly modular in those components and those can be updated then that would have to be updated on the development side so yes would need code depending on what those changes are they may need some code updates on the on the Drupal theme side for sure so again it's difficult to kind of say without knowing what those are but yes UX with whether you use UX to redesign components or whether you use the UX to actually improve the user experience which would be user journeys and really those are based of having landing pages or home pages or any pages within the site where you can change the layout of the page itself the design and those components which can get shifted around or moved within any page since the page is a fluid in this case in Civic Theme the user experience phase is really more around what components are best suited to achieve a particular goal for the user are they trying to find something are they trying to understand something how do we get that information across basic UX stuff and therefore it doesn't really need to change the designs that we're typing and then changing componentry around the page or even having multiple pages or different steps in how the user journey is taken that answer yeah cool anyone else anyone else have a question alright thanks a lot I'll stop recording now thank you