How to use Figma for Full Cycle Design: Aligning Stakeholders, Designers, Content Authors & Developers

CARLEY:
Alright. Thanks, everyone, for joining us for today's presentation. So we're all here today to talk about full cycle design and ways to leverage figma to align all of your internal teams. So before we get started, just a quick agenda for today. We're first going to begin with introduction, so a little bit about our team here, followed by explaining why we're all here, which is what is full cycle design and maybe some common problems within it. We're then going to talk about some solutions leveraging Figma to some of your common problems. We'll talk about maintenance and ways to scale your systems, and then we're gonna follow and end with a summary and then open up the floor for some questions. So here's the team here. So sorry. In case you didn't know, we are bounteous. We are a leading global digital experience consultancy that co innovates with the world's most ambitious brands. So here we have I'm Carley, we have Jen and Ainoa over here. Combined, we have over 15 years of experience within UI and UX design.

And we also have Canadian based rapper Drake. He will be making many appearances throughout this meeting today. This is his first mid camp appearance that we know of, though. So maybe he'll get an invite next year. So like we mentioned, we are bounteous. We are a digital consultancy. We co-innovate with the world's most ambitious brands. Our people, our clients and our partners are really will put the us in bounteous. We know that we're better together with work built on co-innovation principles and a culture that's rooted in belonging, boundless support and growth. So for more than 20 years, bounteous has elevated brand experiences through industry leading technology partnerships and an unparalleled platform expertise. We are here to help companies do better things and do things better. So I did say that Drake was gonna make a handful of appearances here. He quotes, my team good, we don't really need a mascot. So while bounteous doesn't actually have a physical mascot, our people and our teams are champions of creating creative solutions that deliver beautiful results.

As members of the experience design team, our culture has allowed us to build a team of talented and client focused problem solvers, design thinkers and educators. At bounteous we design experiences around the motivations, needs and challenges of the user. We also value the collaboration across disciplines in order to generate innovative ideas, and we thoughtfully apply those new technologies to create experiences that deliver on business goals. So bounteous is a global partner with a depth of expertise across the digital experience platform. Bounteous has over ten years of active involvement within the Drupal community. So we are earners of over 300 Drupal contribution credits. Bounteous has over 100 and plus developer certifications and we serve as an acquia global partner and an aquia DXP certified practice partner. So I actually wanna take a poll in the room here. I wanna get a sense of what everyone's roles are within their team or their organization. So please raise your hand if you're a designer.

Hey, we got a couple, more than I thought. Is there a product owner here? How many are developers? That's what we thought. What about on the content side? Are there any content authors in the room? We got one. Are there any representatives on the business side of their team or organization? Very cool. OK. And are there any rappers? That is one more than I thought. Yeah. Wow. Tomorrow's your night to shine. So we got one. That was way more than I thought we were gonna have. Alright, cool. So it's really nice to see, actually, that there is a pretty good mix of teams here today that's gonna be super valuable as we talk about cross team collaboration. So let's get into it. We're here today to talk about what does full cycle design and how we can leverage figma tools in order to basically create a more seamless work stream between design developers, content author, product owners and business stakeholders. So we've been talking about full cycle design, but what does that actually mean? So a full cycle design is a process to help properly create, document and launch a system of scalable components and page templates.

The goal of following an approach like this is that it helps ensure that your library of assets will align with business goals, the potential limitations of Drupal, the needs of the user and is accessible across all of your internal teams. So this is just a quick visualization of how a full cycle design can work. So when you're in this cycle, we first begin with the design system build. In this portion is where UI and UX teams begin to collaborate closely in order to translate business goals and objectives into a really cool set of components. The next phase is the execution phase. This is where we begin to take that wonderful library of components and begin to translate them into full page comps in order to facilitate stakeholder feedback and gather those approvals. After all your party is approve of your wonderful page designs, we then move into the delivery phase. This is where we ensure all of your documentation, rules and requirements are all captured so that page designs can be handed off to product owners to eventually translate our files into tickets for developers.

Once all of our beautiful pages have gone through all parties and are published in life, we then circle right back to the beginning of the process during our maintenance and as we begin to improve and build upon our library. So as Drake puts it, as of late, a lot of stuffs been going sideways. So while you're working with in full cycle design, like most things, common problems could appear. So one of the first type of problems we see while working within full cycle design is that you may find inconsistent source files. So depending on the design platform that you're using, your files could quickly become maybe a little messy, maybe a little unorganized. So maybe your layers are a little unorganized, like your naming convention isn't all there, maybe there's inconsistent padding and spacing between your elements. Your type sizes don't align with your global system. Or maybe there's an unclear translation with how your components scale between desktop, tablet and mobile. Depending on the platform you're using, in our case, FIGMA, which we'll talk about, our team at the beginning was often finding that we had to manually scale our components between desktop, tablet and mobile, which as you can imagine, is a very time consuming and redundant task.

The second type of problem we see and arguably might be the most important, is that your designs may not align to how it's actually built within your toolkit. If your design team is utilizing components based on certain assumptions of component functionality, but they don't actually align to how they're built within Drupal, as you can imagine, this can cause many blockers down the line when it comes to actually building out these pages. We also found that teams are working in silos, so between designers, developers, product owners. These teams are often running in parallel and not communicating strategies or work in progress files. This resulted in deliverables that didn't holistically capture the needs and requirements that each team needs. What a designer might be capturing may not be the same level of fidelity that a product owner needs to know in order to do their job and so on. So all of these problems can cause major blockers once you reach handoff to the production teams who are ultimately responsible for the page builds.

If other teams aren't clear on what's required and don't understand how they need to be built, how is everyone in each team supposed to understand? So, as Drake puts it, our solution is dubbed last name ever, first name greatest. There proved to be a need for... Sorry. It proved to be a need for a workflow and in need of digital assets to act and function as they do within Drupal. Components and pages that are truly 1 to 1 within your toolkit, truly responsive and contain all the necessary annotations and level of detail. So our solution was to build a design system and establish a workflow that can serve as that single source of truth for your entire team that's reflective of the capabilities and limitations of Drupal. By doing so, you'll speed up the full cycle design process, as we mentioned, and overall collaboration between teams. So here are just some deeper dives into some of our solutions here. As part of this, we created a structured library of complex components. So you may hear complex components being used a couple of times in this presentation, and is a term that our internal team had dubbed.

So a complex component is typically what's built in Figma or in our case, and it's built so that is responsive across all your breakpoints. It's flexible across your content length. It's scalable, so that's easier to build upon during your maintenance phase and then it's built with all the foundational elements that allow for quicker page builds. Once we create your structured library of complex components, we then... Sorry. OK, sorry. So after we create those complex components, we then make sure that we have specific documentation that's reflective of your toolkit. This documentation is intuitive and accessible enough across all your teams, regardless of their level of familiarity within Figma. So finally, you can incorporate all your rules and requirements and actually build them into your figma file through a series of what we're calling annotations. So these annotations will reflect what's available within your toolkit, and it will just aid in the translation of your designs and authoring intention for other teams.

SPEAKER:
(INAUDIBLE). Are you using complex components across your clients or are you making them specifically for every single. One

CARLEY:
In this instance that we're gonna go over, specific to the client. They're built with some of the foundational elements, which I'll show in a second that can easily be translated to other teams, let's say using a CMS. A lot of basic foundations, it's a layering system. And so you can certainly slice and dice based on your client's needs. And we're gonna go over that to you later in the presentation. Alright. So good break, actually. So who here, I wanna take a poll again, has either heard or have used Figma in the past? See. That's good, though. OK, well, maybe not good, but good into the Segway I'm about to go to. So it's clear that a lot of people have heard of this program, but wanted to touch on just some quick pointers and just a reminder refresh to everyone in the room as to what this program is. So Figma, as we all know or should know, is one of the leading design platforms for building and creating products. This platform, of course, like many products, has a robust library of tools and ways of simplifying workflow.

There's a lot of collaboration features that just make designing products faster and more efficient. It allows teams to have, again, that all in one source making it easier to collaborate. We utilize many of the built in tools within Figma, such as auto layout and variations. Figma also allows us to continuously test for accessibility, which is always useful during the design phase. And then like I mentioned and we continuously harp on is that it has all in one place for many different people to work on, which helps streamline version control. And of course there are dozens of other tools and resources within Figma that you can utilize, but these are just some of the core areas that we utilize when we're creating our scalable systems. So the best part about creating a robust library is that it can and should be custom built for your team. So some of these are some questions you wanna think about before you begin diving into your new system build. So you should think about your internal audience.

Think about the types of teams and your team who are going to be referencing your file and at what scale. Understanding your audience will be a driving factor in all the ways you can shape your Figma library. You should also think about the nature of the work. Well, all of the systems and ways of working benefit your product in the end. And finally, it's also to think about what comes after. So setting up the foundation can help you scale in the future, but only if it's clear to your teams how you foresee your systems evolving. Alright. So, Mr Drake, here goes, you only live demo once. So we've been talking about building a system. We've been talking about all the nuances of Figma, but we think it's important that we actually show you. So now I'm gonna hand it off to Ainoa who's gonna be walking us through the figma steps of building out a design system.

AINOA:
OK. Well, thank you. We're gonna start a demo. We're gonna jump into Figma to try a few things. So we're gonna follow that full cycle design process. So we're gonna start with step number one, which is the design system build. Inside of that, in this step, we're gonna have several teams working together. So we have the design team (INAUDIBLE), depending on your team and your product, and wanna make sure there's an alignment when we're building these components and these libraries to make sure that all the needs are met. So let's go through all the tools and properties, well, some of the tools and properties that Figma gives you when you're building those components. So we have a sample here. We have a component, it's a card. It's very simple. So if you select it and you go to the design tab, you can see all the properties that are applied to that component. So let's go through some of them. So the text property indicates which text can be edited. It allows edits within the property panel.

So you can see here to the side. (INAUDIBLE) to see, but you can see that title area and that body area, so that way the user understand what they can change and what they can edit and they can do so on this side as well. So if you have a text that will reflect in that component so the user doesn't have to go into layers or start clicking around, you can just pick all the options from that panel and also update your content in there as well. OK. So then if you scroll down, we have the outer layout which allows your frame to expand and shrink flexibly with their content based on constraints you've applied in the outer layer panel. So if you go to the panel here, you can define how the elements inside of that components are gonna align, how everything is gonna stack together and you can also set those values for different patterns which is within those elements. So it's very easy to update. If you wanna add some padding, everything will maintain that consistency with those values. And that is key when you're building responsiveness into it, because as you adjust that card, everything fits together and follows that logic.

So let's move into a bit of a more complex component. So we have this (INAUDIBLE) component. It has nested components inside of it. We have the same card that we were using before. Now it's inside of this component. So let's keep going through some properties. So again, in that design. Yeah. Under design tab, we can see the boolean property, which is property that helps you setting true and false values, so allows the user to toggle an attribute on and off. So for example, this area at the top with the section title and that little description is something that we wanna make sure the user understand that is optional so you can turn it on and off and it's very easy to do so here with the boolean property so you can turn it off and everything can rearranges and accommodates to that new content. So the same for the CTA. If it's something that is not required, we wanna make that option available for the user. The next one is the instant property swap, which indicates which is the instances in the main component or variant can be swapped.

For example, these cards that we have inside of this component, if we go here, this is the little symbol for instant property swap. So you can access that dropdown. Let me just make it larger and you have these four cards that you can choose from. So if you select that one, everything rearranges to that new layout and you can select which options you wanna give the user. So you can select if you have ten cards and you only want for this component to be able to have three options, then you can just select which ones you want to make available in it. And then we're gonna move into variant property, which is different versions of a component that share the same base properties but have different values for one or more properties. So for example, here we can group those properties as well. So we have the number of cards and inside of that option we have these variants. So we can go from three to six cards and the same for the type of device. You can go from desktop, tablet, mobile. So it's easy way to access different types of content.

(INAUDIBLE). So you'll see when we build a page, how this is very useful to translate these lines from two different breakpoints. The last one that we're gonna take a look at is the nested component property. So on this under design tab, we can see all the properties that applied to the component overall. And if you scroll down, we are able to also pick which properties from the nested components. For example, that card we wanna show in there as well so the user don't have to click and go into, like, deeper levels of the component. You can see all the options here. So for example, for card one, you can hide the image if it's something that you wanna give the user the power to do. You can update their copy everything from that main component panel. So yeah, so let's move down and see what Drake is saying. So auto-layout is too hard. How did we design it before auto-layout? So I think that when we're looking at these properties and how we build these components, everything is a bit daunting and it's like there's a lot that you need to do to make them work.

But once you apply this library of components is something that your team, it becomes indispensable for the team and it's such a time saving tool and it aligns everyone that needs to be touching that project. So yeah, so let's keep going. Sorry. Yes. So we have our little sample library. It's not complete. It's just something that we wanna put some of the elements that you are gonna be able to see in a library. So we have styles and atomic elements here on the side. So we can have buttons, we can have iconography, we have different CTAs, and then we have all our styles. So if you click outside, if you're not selecting anything, you can access those styles and those colors as well on the side and adjust those settings. So it's very easy to update all the styles that you gonna use through all your components. So those are the smallest elements in the library. And as you move here, you have some foundational components, for example, the card that we were looking at and we have several options for it.

We have different alignments. We have photography with iconography as well. So we have all the options for those type of cards. And then we move into components that are a bit more complex and they have different options that you can pick from. So this is the one that we were using before. And let's just zoom out and you would have more. So here we just have that one. We have the main navigation. We have the hero banner. So it's something that you start building your library to the components that you're gonna need. And yeah, here's a way, a great way to see what the variance came from. So this is a component set and all of these different options are the variants that we were selecting before. So we have the number of cards and we have the different devices and we have the annotations that we include with every component, and this is something that we'll touch on a bit later. So on the same here, we just dropped everything all together. We organize all this components into files, which is something that we're also gonna discuss, Jen is gonna go through that later.

If any change in Figma is very quick and easy to do, if you have a card and you wanna maybe increase the padding, that will translate through all the components that uses that card and then all the users, when you open the file, you will get a notification telling you what the changes are and you can accept that. So (INAUDIBLE) very good tool to understand if anything is updated. So there's a lot of clarity and alignment between the teams, which is what we're trying to do building this library. Yeah. So let's move on into what the benefits are for different users. So what are the benefits for designers or content authors? There's a clear understanding of all the options that you have for each component so you understand what you can do with them and (INAUDIBLE), there's only, like, there's one place where you have to go just to update your content. So it's very easy to just go through it as a form and just complete everything that you need to make sure that it fits your content. It allows to keep that aligned with everything that is done in Drupal as well.

So there's no surprises when you're gonna send that to development. Also that is very easy and quick to update if there's anything that needs to change. Everything is connected and it's just one button and everything is updated for everyone. Let's move into developers. So what does this mean for developers? It's easy to go into components and dive deeper and go to master components and see how their structure, how everything is built and how it works. The library in Figma is meant to mirror everything that is all the requirements and capabilities in Drupal. So less customization is needed unless you want to customize anything. And also again, if there's a change in Drupal, it's very easy to update it in Figma. And then again for the entire team is one source of truth to align team members and avoid discrepancies. So what can be accessed in Figma? So you can go into code and inspection, measuring and spacing, guides and grids, styles, prototypes and explore assets very quickly. So let's go through that just to show how fast it is.

So we have the three components in three different breakpoints. All the content is the same. So if you need to export, for example, let's just do like the first card, you select the three images that you need and you go to this panel again and you have that export section and you're able to pick the size that you need, format and adjust (INAUDIBLE). So if you wanna add more than one, you can add as many as you need and just click export and you'll get your folder with all the (INAUDIBLE) you need to download. So it's very easy to grab everything very quickly. And then again, if you select that component and go to inspect tab at the top, you have all the selections that you did on that component here as well as all the copy that you updated. You can copy that text, you can see all the images and their names. And as you scroll down, you can access property for the entire component, so the size of it and where it is located on the frame. If you select other items inside of the card of the component, you can also get those details.

And if you go to the code section at the bottom, that code panel offers an easy way to extract code information from a specific page element. So you can do it for the whole component or you can click into, for example, that button there and access that content. The code will be displayed by clicking on a layer. Currently, Figma supports CSS, iOS and Android, but notice that most of the code available involves only visual properties and spacing. So you can access here all those options. So now that we've talked about the library components and the benefits, let's keep going to that second step in the full cycle design. So execution. The teams that are gonna be involved, (INAUDIBLE) be design, development, content, product business and this is a really good tool to keep all those teams connected. As we're designing, development can come in. Comment if anything needs to be changed. Content also can take a look at what they need to provide. It's just something that brings everyone together to the latest.

So we have a frame here. Well, before that. We like to include this section at the top of the work that we're doing, just to keep that clarity because we have all those teams, we wanna make sure that all the information is clear around the page that we're building. So for example, we have the name of the page, we have some description below, we have some important links. If you have your project brief and you wanna include it there, it's just a place for easy access to anything that you would need. And we have the status bar at the top, which is great to really for any team to jump in and just understand what it is in the process. So let's build a wireframe using our components. So we can go to assets and here we can see all the components that we have available. So we can just drag and drop them into that frame. It's very easy to understand where you can use and where you have to play with. So I just drag and drop them. We have a frame that is gonna adjust to the length of all the components of (INAUDIBLE).

So it's very easy to just, you know, move things around once you have the components that you wanna use, then you can jump into your design panel and make selections and make decisions. So, for example, if we wanna turn off that CTA, if instead of that card in that section, we wanna add icons. Those is very easy to swap and kind understand what you can do and how you can build this experience. Once you have your wireframe for one of the great points, you can also just duplicate that frame, select each component and change your device to the variant that you need next. So for example, we're gonna go with mobile, we select all the components and switch to mobile and in second we have that ready to go. And all (INAUDIBLE) that we made in desktop, the icons, removing the CTA like everything flows into that new frame for this breakpoint. So it's just you don't have to adjust anything. You just have to do it once and it will translate to all the variants. So that's a great tool to save some time and get this ready very quickly.

And with that, we also add annotations with like something that we include as a variant to our device settings. So we are able to also include some information that is not on the component, but that is gonna be useful for that next team that is gonna take over. So for example, when this goes to the client, we would kind of customize this annotation to the content that the client would need. So we would just duplicate all the components to add a specific information for each of them. And that is ready to go. So your wireframe is ready and then it goes to your client, for example. You get approval. It goes to content. They generate the content. You can now turn that wireframe into a high (INAUDIBLE) just by duplicating that wireframe and adding content to it. So for example, we can select that (INAUDIBLE) and we place that background with an image maybe to just add a profile pic for the author. You can go through all these nested properties and add icons to those placeholders and then, yeah, and then maybe change that the title, your page or copy, midcamp 2023.

And yes, you're happy with it. All your content is updated. You can just again duplicate the frame, select all your components, change that to mobile and all that content that you updated and all those selections are gonna cascade into this new layout. So again, you make that effort only once and you are ready to go and you can add your annotations to the slide again. So very quick and easy. If you need to do tablet the same, just duplicate that and just switch to tablet mode and it's ready to go. So, yeah. So Let's see here. So we're gonna go into the last step of the cycle, which is delivery. So again, we have a few teams in there. We change that status to ready for development as we have our three break points. All the content is there, everything is embedded and then we added, bless you, we added all the annotations here the developers are gonna need. So that is ready to go. So, yes. So that's it for me. Now let's dive deeper into annotations with Jen.

JEN:
Thank you, Ainoa. So, yes, we're gonna get into the nerdy but exciting world of annotations. So we created a template for our annotations and within this template we had an overview which had the where and how this component was gonna be used. We included our authorable fields with details that are required versus optional along with our behavior and display. And then last, we also had our experience related accessibility behavior as well. And by having this template, it really helped ensure that we had the right level of detail and structure across all of our components. So we're not, you know, having some details in one component, but missing them in another.

SPEAKER:
So this isn't a part of FIgma. (INAUDIBLE) as atemplate.

JEN:
This is in Figma. Yeah. So this is actually applying the same principles that I know I just went through in terms of creating components. So, like in here we're using auto layout as well so that you can, you know, as you enter your details, everything won't shift along with that.

SPEAKER:
I'm sorry, but just to be clear. It's not something that it kinda creates for you. There's not like... (CROSSTALK)

JEN:
Oh, gotcha. Gotcha.

SPEAKER:
They created all of this tech like on their own. It's technically its own little design, essentially and then (INAUDIBLE).

JEN:
No, thank you. That's where I didn't catch was the question here. Yeah. No. Yeah. I thought it was a question of where it lives. Yeah, it's in Figma. But yeah, we created it. So we created this template and then we go ahead and make these edits as needed. Thank you for that clarification.

SPEAKER:
Which is coming first, are you writing up this sort of list of content requirements and then the designer is working from there, or (INAUDIBLE)?

JEN:
Yeah. So we usually go through design and actually I'll make sure to repeat the question in terms of, the question was when we incorporate these annotations as it relates to the design cycle. So we'll go through, we'll create components and we'll start to annotate. I mean, usually in the wireframe phase we are starting to think through those interactions 'cause we usually in our agile process, you know, start to have discussions with all collaborators, right? Designers don't just work in a silo on our own. So we'll work with all contributors as we are building these components and we'll start to outline some of those details. But, you know, as we move further along in the design cycle, usually there's more and more detail that we start to layer and add into it. Really good question. So in this instance here, you know, I know I was showing we had like wires and then our annotations as well as the comps and our annotations as well, side by side and presentations. So for example, we were redesigning a navigation.

And as you can imagine, we went through lots of rounds of reviews with various stakeholders, right? We had business product developers, content authors, everybody, you know, critical part of the site. We wanted to make sure that everyone was on board with our design solution. So given that, you know, we found that we were having to frequently modify our annotations for that specific audience, which is inefficient. So we built this template in mind to have all the details that anyone from our audience needs in this template. So let's say, for example, that, you know, we're presenting to our stakeholders, well, they really only want the overview. What's the overall goal of this component? They don't need all the nitty gritty details. But for content authors, you know, we would include our authorable fields and some of the details around best practice for usage of those components. And then for developers and our product teams, we would include all of the details, including accessibility.

So it was really great in terms of streamlining to make sure that we were consistent with our annotations and it was very quick on the go to just modify for our audience. And one of the things that I really like to kind of talked about in our, you know, that we just chat about with that question I liked as a UX designer, right, I'm responsible, largely responsible for making sure we capture all of that behavior and the interactions with this component and having that template made me think through all of the details that I needed to include. So it helped me make sure that, you know, they were comprehensive details to it. And then, yeah, and during those Agile ceremonies, I really encourage cross collaboration and make sure we weren't missing any details or maybe there was a detail that was confusing. So we were catching those things a little bit earlier in the process and not just waiting till the end with, you know, handoff to Dev. So let's say your team has worked endlessly to get this beautiful component library and now it's time to maintain it.

So how do you maintain it and how do you communicate continuous updates to your internal and external teams? So let's take, for example, that component that I know I just built. The page is now approved, and there's one new component that we're gonna add to our library that's coming out of it. So we're gonna walk through like a typical process of what that workflow is like once that design is approved. So first we'll go in here and we'll update this to be ready for Dev. Similar to that strip that you saw above her design file, we're also having it here in this cover to also indicate to everyone that this is approved and ready for development. Next, we'll go in here and we'll copy that new component and then we'll come in here to paste in that new component. So I'll take a step back here to note that. So this is a Figma team. This is the term that Figma uses that we're using for our project, and we divided that into two different figma projects, one for the component library and one for our working files.

So within the component library, because we had 60 components and that's a large amount to maintain, we actually divided our components into the way they functioned. So you can see here we broke it up by like general, interactive, global, heroes, et cetera, and then we used a cover that was a visual indicator of what contents were inside of this file. So in this instance, we had all of the components that were in this file. So you could have at a glance what's in there and not have to, you know, go in it to see and come back out. So that new component that I know I just built is a card. So we'll go in there and we'll add it to our library. Oops. But one second. But first, though, I will create a new branch. So we'll call this, let's say, Sprint 20 and we'll be extra helpful. And note that it's going live 530. And the reason that we're creating a branch here is so that we can have a clear distinction between what components are in production versus what's in development. So as you see here, going back to our component library here, on the thumbnail of the cards, you can see that there is a branch.

There's this little thumbnail and you can pick if you wanna go into the main branch or into our new branch. So we really like how it's a very clear indicator as you're looking through all of your components. Oh, that's great to know here there's a, you know, branch that's part of the cards. That means there's something that's in development. So we'll go into this new branch and now we'll paste our new component. And then in this branch, it's really like a safe place for designers to finalize and prep their files for development 'cause, you know, there's always some additional details, maybe some states or just our files are a little bit, you know, could be cleaner or, you know, those additional details that we need to include in our annotations here. So we'll go through and add that at this stage and then through our agile ceremonies as well as we have, you know, grooming and go through that process as we talk with developers and product and contenders, we make sure that everything is clear and we'll make those updates here without disrupting the main branch.

So let's say this component is now in production. Yay, super exciting. So now we can review and merge our changes to the main branch. And one thing that you can do here is actually add reviewers to the process. So before you merge it, you can have people go through and make sure that these are in fact the changes you wanna make before adding them or merging them into your main branch. And you can see here that there's even Figma tells you what things have been changed here. But we're happy with it, so we're gonna go ahead and merge it. So with all of that, now that you have this really great workflow, how do you make sure people know how to use it and they're using it correctly? So imagine here that you have, you know, your build of your pages or your new component. How do those flow into the component library and then how does it go into delivery? And then finally, how do you, you know, move those in to make sure it's in parity with Figma? So after that process going through that, we just walk through, you know, as things are changing in development, which they sometimes do, we'll go back through and make those updates into Figma as well.

And so with that, we also document our process to make sure we create an instruction and guidelines so that everyone knows how to use this new process. We have in here instructions, and this is in Figma as well. You know, how you actually turn on your libraries. How you can swap instances and browse your components and how you can maintain your library and make edits. And so with that, I'll now hand it off to Carley.

SPEAKER:
Can I ask you a question?

JEN:
Yeah.

SPEAKER:
After you merge, is it possible to automatically (INAUDIBLE)?

JEN:
That's a good question. I know you can view them and then version history within pages you can, I'm pretty sure you can roll back to you. I'd have to look into that, but you can see the previous version.

SPEAKER:
So there's built in version?

JEN:
Yeah. So yeah, even in the pages. Like I was showing like our design files were in pages too, you can see version history as well and you can definitely roll down on that as well, which is definitely come into handy at some points. Yeah. Good question.

CARLEY:
Alright. So thanks, Jen. Thanks, Ainoa, for those demonstrations. So after this whole presentation, you might still be asking yourself, is this whole system still a good fit for my team? Is all this upfront investment worth it at the end? And it's definitely a fair question. So we feel that this approach could be good for you and your teams. Truthfully, if you have a really large team structure, a large or even like a complex component library, or if there are cross-discipline contributors all referencing your design systems. This approach also works well when dealing with the maintenance and hand-off phases. It allows you just to be able to quickly iterate on your systems and for more quicker page builds. And then really the most important we feel is that you have the time and budget to support it. So you did see that there is a lot of different ways that you can build out your systems. You see that it might seem like a daunting task because of all the steps involved. And so while it might seem like a lot of steps, it's really intuitive and really valuable at the end and it can remain valuable as long as you have the proper team and the time and budget to help support the ongoing efforts of your Figma files.

Alright. So I jumped ahead. I ruined the joke. But I'll stay on this line. (LAUGHS) I got excited. I just love Drake. What else did I wanna talk about? Oh, the coolest part. OK. So like I keep saying, there's so many different ways you can establish your workflow. There's so many different ways you can organize your components. But like to your question earlier, you should honestly custom build this to your team. Even though there's many different ways you can split this, you should slice and dice it based on what works best for your team, your organizations and your workflows. You might not necessarily need everything from start to finish, but there are probably some good areas where you can grab and apply it to your clients and your clients needs. Alright, here's my joke. So we're gonna address the elephant in the room of why is Drake even here? What does he mean to this all? So let's say you have a team that's working with really large or complex systems. Let's say your teams are often finding blockers in handoff phases or just ways of communicating with your internal teams.

So maybe right now you're starting at the bottom. We also asked at the beginning of this presentation what everyone's roles were on their team and we asked because really the goal of full cycle design is to have that source of truth for all your teams to reference that can scale as your team grows and your business objectives change. So now that you're at the top, stakeholders, developers, product owners, we all now are able to understand how this process can improve not only our individual day to day, but again our cross collaboration across teams. So if you forgot everything we said in this presentation, don't worry, we have a slew of resources here for you. So we have very specific resources as far as some of the nuances of building within Figma from creating atomic components all the way to the best ways of utilizing variants. And then we also have some bigger picture references as well, like designing systems for Drupal specifically, and they're all in the PowerPoint that you guys can reference later.

We thank you so much for coming to our presentation. We'll open up the floor for some Q&A. But again, thanks so much. And you can be nice in the feedback, but we'll take questions. I'll go with you.

SPEAKER:
So I'm assuming using Figma in this way is a relatively new process for your organization. I was curious what kind of impact it had on like a project time and budget.

CARLEY:
So the question is, because Figma is relatively a newer program, how that's affected our time and budget utilizing the system.

SPEAKER:
Right. To do it in this way.

CARLEY:
Yes. So funny enough, I think I'm gonna bring up the instances the client brought came from. So the way this whole kind of system started was we kind of worked backwards. We were working with the client who had this very complex library, the translation between what was in our library versus how it was built. There's a large disconnect. And so we were finding that our timelines were much longer, which the client wasn't too happy with. They want pages updated, you know, yesterday. And so we implemented this process and through that it ended up cutting some of our scopes in the times that we would say we were turn things around immensely. So I don't have an exact like days and hours and things like that. But not only increased or decreased like the days it took, but also decrease like the size of the tickets that we're also going through, too. We noticed that if we were promoting or showing something in Figma and it didn't align to how it was built within their CMS, there was a lot of back and forth and then we were sizing tickets too high 'cause it wasn't clear that it needed to be like a lower sized ticket 'cause we were just referencing what was already built within the library.

I hope that helped answer your question.

JEN:
I'm just gonna add to it, yeah, 'cause for this project with this client, there was a lot of execution in terms of pages here. So we had a team that was focused on just the design system and another team that was focused on page execution. So yeah, given the number, again, we're talking about scaling on the number of pages that we had to keep producing. This is where we really saw the efficiencies and kind of goes back to what Carley was saying, you have to really think about the scale of your team's needs and your design system that you're gonna be maintaining to like make the call of, is this up front time worth it to see all the benefits that you get during execution? Yeah. And I feel like one last point. Like I feel there was a bit of a rotation of, like, people like, coming into the team as it grew. We got new designers and it was very time saving when it came to onboarding. And so it's something that you don't really have to go through like a lot of documentation of details, just everything is so intuitive that it caught the time of (INAUDIBLE).

Yeah, that's it.

CARLEY:
Does that answer your question? OK, cool. Yes.

SPEAKER:
So just to be clear, when you're doing your designs, are you doing everything before you hand it off to Dev or are you actually doing true agile where you're designing in every sprint?

CARLEY:
That's a good question. You know, we would go through our full design of whatever the component are pages and then we would actually hand it off to development. So it's not like we would be making small changes, but it was still a sprint structure. So, you know, working in the development, in their case it was actually four week sprints, but working within their cadence.

SPEAKER:
And you were designing in those sprints during those (INAUDIBLE).

CARLEY:
We were handing off in those sprints. So yeah, our actually designs...

SPEAKER:
You had already done it already.

CARLEY:
Exactly. Our design cycle was not exactly the same sprint that they have. Yes.

SPEAKER:
Do you have alternatives you'd recommend for like smaller teams alternatives to Figma?

CARLEY:
Alternatives to Figma or like some of the processes we've gone over?

SPEAKER:
Yeah, to figma 'cause you said you would only recommend it for like larger teams, like more complex.

CARLEY:
Well, figma in general, I feel like I recommend honestly, maybe it's biased. The program is just super intuitive. There's a lot of, like I said, built in tools that make things just working so much faster. I mean, I've worked with a sketch, I've worked with Adobe XD, I think and they're very similar, they're translatable. But really I think Figma is a really robust tool. So I don't think it matters necessarily how big your team is. I think anyone can benefit from the program, just more so like some of these like workflows and the time it takes to like build out a complex component.

JEN:
Like branch concept. The other ones don't have that the other certain features that Figma has that the others don't. But I mean, there's still some things you could carry over like that is the good thing about this. Like you don't have to take everything that we just recommended. You can pull in something. So like even how you label things with status, you know, could be helpful because that was one of the things we even found helpful because we had those two separate teams. Like for the production team, for example, because they weren't in the (INAUDIBLE), like the design system team was knowing when components were going live, knowing, Oh, this is gonna be enhanced, a new one is gonna be available at this time. You know, it was nice for them to very easily go in there and like know, OK, this is the status of this. I can expect this while I'm building my page design without like cross-referencing with Jira and, you know, that type of thing.

SPEAKER:
I'm not sure if your annotations have this, but I heard (INAUDIBLE) is that where you were documenting interactions also. So CSS transition, things like that?

JEN:
Yeah. I mean, anything that's really experience related we would handle there.

SPEAKER:
(INAUDIBLE)