 Hey everybody, how's it going? This is painless designs handoffs and I first want to say that like I am so excited to be in person For me virtual conferences don't quite do it. So thank you all for being here Who are you so my name is Jen wick house key I'm an associate design director I currently live in Buffalo, New York and right now the weather is kind of the same So we've had 70 degrees and now we just dropped down to 30 I got photos of snow from my parents and my sister. So Kind of happy to be here in rainy Portland where the weather is kind of nice But I like things Anything doing with the outdoors. So I love camping hiking. I love bonfires. I love gardening And because I'm a designer. I also like all things pretty where you Mike So I am my car show I live in Gainesville, Florida I also like being outside and I am a senior friend and developer We also We are two of the guilty parties and doing the Olivero theme for Drupal 10 Gentlemen was the primary designer and I'm the primary dev on that. So we've we've done a bit of work We're former co-workers, but now we're not co-workers Yeah So I I still currently work for Lullabot and if you're not familiar with Lullabot Basically, we're a company that specializes in creating websites for clients that need that have large content needs And now to who do you work for Mike? I work for AVB digital AVB digital is an organization and we do federal websites So right now I'm working on the small business administration's website So in this talk, we are going to talk about friend and pain points This is like the airing of grievances for me. Like if you know like the whole Seinfeld reference Jen's going to talk about some solutions for those. We're going to talk about documentation and tooling to kind of help us out with that So here is my time to shine. This is the these are the things that Kind of drive me a little bit bonkers as I'm doing as I'm doing work So the biggest by far the thing as a friend and developer that I run into that kind of kind of makes me not happy is lack of consistency so this particular screenshot right here is we have some documentation and then we have a design and Like if you were to look closely at this, you're going to see that the documentation and the design have two different things You know the font is one thing and there's a couple a couple different issues right here And so like when I get this as a developer, I have to think through there You know, I think like is this a mistake, you know because designers are people too and And You know people people make mistakes or I think of this if this is is if this is intentional Do I abstract this? You know, is this a variation on a heading? That I need to do it or do I just kind of create a one-off do it like when I'm writing my styles Do I just like say like this is this font size and I add a little comment and that says this is a one-off Or do I just go in and modify the design or modify the documentation? you know like It takes a lot of effort for me to kind of go through there and Something else that I see is what I call like to Willie nillies and that's where where designers will just kind of eyeball stuff You know and and I get the cases where like the spacing spacing is Inconsistent does this need to be 43 pixels does this need to be 59 pixels is the line height correct? You know I go through all these things and At the end of that I'm kind of like well, you know, how do I do this? What do I do and and we're going to talk about solutions on this But I'm going to have a couple more. I have a couple more grievances for you Jen So something that I I see pretty often is when designs create like have optimal content in there And you know that when your designs will look beautiful because they have optimal content But as soon as your content editors get in there, what do they do? they immediately try to screw stuff up so like as a developer it is up to me to make sure whatever they do and Needs to it needs to work, you know, so so in this particular case you can see the design on the Left-hand side has a very nice short name on the right-hand side We see a name that could be a little bit more realistic, you know, and so I have to I have to think things through I have to say like there's a grid there. It does does this name need to be in the grid. Can it just wrap? We can we can enforce a character limit, you know, can you imagine if you're typing your name? It says no your name's too long, but but we can do that You know, I could also like do the little ellipsis and do like a little CSS clamp there And in different situations that might be appropriate, you know So yeah, so it makes me have to think Something else that I kind of run into fairly often is multiple or unknown font providers so for y'all that don't know like when your website pulls down a font it takes a little bit of time it can slow down your website and when you Use a third-party license font Sometimes they make you run like a little bit of JavaScript to like track maybe your page counters and stuff like that that also takes a little bit of time and It can it can slow down your website in addition to that Like it costs a little bit of money and I've had literally I've had cases before where we're designers will They'll give me design and it has this font and I said well How are we gonna pay for this font this font costs money? It should not be up to the developer to research where should I buy this font? What license should I get for this font? You know In my mind I also think like can I just swap this font out for another similar font? And I've done this before I've talked to a designer and said hey This font is very similar to this font and then we can do it and I won't have these issues But once again All of this stuff kind of takes time and takes effort, you know And you all know like time is money like if the if the development process is smooth and goes straightforward It goes quicker that saves everybody money documentation Like a show of hands here if you're creating designs who here creates documentation with the designs So for any like record recordings right here that was a very pitiful showing So what I love to see When when when I have a design is I want to see a list of the headings I want to see I want to see how things fit together Because let me tell you if there is no documentation, you know who's creating the documentation. I am Because I need to abstract these things out. I need to look at the headings I need to figure out how many variations are there of h2's and where are they used? You know and at the end of it It involves spreadsheets You know and I'm a front-end developer and I don't mind working with spreadsheets But at the same time like we all want to save our clients time and money, you know And I might be doing something wrong, you know all together it makes me feel like that guy that guy He was a former co-worker of mine who didn't have documentations with a design so Jen what the hell I am so sorry Mike We definitely don't want Mike hurting himself Snacky's head against the wall and we definitely don't want him breaking his computer because we need Mike to build out our designs So we want to make sure that we're trying to make his job as easy as possible In the past we've we've learned together on how to do this So, you know, we've made all of these mistakes and it came through like sat slack messages And sometimes I got to the point with Mike would ping me and I'd be like I don't want to answer this right now because I know I had done I hadn't done a proper Documentation or he had a question or he ran across a content entry issue where the design wasn't fitting to the content So I'm gonna talk a little bit about solutions The first thing I'm gonna tackle is creating consistency a lot of what Mike had mentioned has to do with creating Consistency within the designs that we create and this is also followed up with documentation because documentation is very important Because we don't want Mike also working in spreadsheets spreadsheets are not fun so Before I get into design consistency or creating design consistency. I did want to point this out Basically design consistency It's harder to maintain as your team grows So smaller teams it's pretty easy to create consistent designs because you only have one or two designers Creating those designs, but as you have like five or ten designers jumping into a project Maybe it's a fairly large project again It takes more people are touching the designs in consistency. It can happen pretty quickly So I have this quote by Jeff Bezos if a team cannot be fed by two pizzas then that team is too large I can eat a whole pizza. So I don't know how true this quote is, but I thought it Kind of communicated the fact that the larger the team the more time you may have to put into creating a process For designers for creating consistency So I'm gonna talk about creating consistency a lot of this is gonna have to do with setting up a design system But this isn't a design system talk So I'm not gonna get deep into the weeds, but you are gonna hear some terms that are related to design system I'm gonna talk about naming systems and how naming systems can help create Design consistency, especially when naming things between designs and components and I'm passing that along to front-end developers I'm also gonna talk a little bit about design tokens. These are fairly new When I say new like the past like three four years they become a little bit more popular and design tools have incorporated plugins for designers to be able to use these I'm gonna talk a little bit about grid systems and how we can be more consistent in setting up our grid systems and also our type systems and Creating components symbols styles and shared libraries within the tools that we use to create our designs So I'm gonna start off with naming systems Naming systems as I mentioned can apply to both how we as designers name things in our designs So components or colors or our type systems But it also can be passed down to front-end developers and how they name things in the front-end code so I am going to Just mention that naming things is very very difficult It'll take some time to do this I was talking with a designer a few weeks ago and basically we had come to the conclusion that naming things is really hard Designing things is the easy part, but coming up with a consistent naming system can be pretty difficult So you might want to reserve some time to do this and it's okay if it takes a little bit longer than what you had originally planned You also want to make sure that it's a shared vocabulary with everybody on your team But especially the developers and the designers because they're gonna be going back and forth a lot with the naming system You also want to create and document some way How these components or styles are being named? So in the past we have kind of set up like a Google doc like a design dictionary that has these names Incorporated in it. I may know what a CTA is because I've been on the project for a while But if you're onboarding a new designer on they may not know what a CTA means And by the way CTA means called action So if you're using words or naming that not everybody on the team knows they can go ahead and reference this design Dictionary to get the names that they that they need The best approach is obviously to come up with a naming system before you start designing However, your naming system will probably change as the design evolves because you'll find some gaps and that's absolutely Okay, it's okay to change things because you know as you're building out multiple pages You may find gaps in the naming system and may have to change them You just make sure when that the changes happen that everybody on the team is aware of those changes So the naming can be continued in a consistent manner So I'm gonna have Mike kind of start off start us off an example We recently went through this process With Olivero and updating the naming system for colors in Olivero, and I'm gonna have Mike take this off Yeah, I'm really excited about this because I think it's like something that has kind of solved some of our naming woes and past projects and like we started this with Olivero and I've taken it to various different projects. So Basically, the gist of this is you'll have you'll have a list of colors, right? And so people might start with like, you know a blue and then they might say blue light and then they say Blue dark and then before you know it there's a blue lighter and then there might be a blue lightest and then there might be blue lightester and and y'all y'all like know how this goes blue lighter dash one and Who here has a blue lighter dash one? more people than do documentation and so This is a very common problem like everybody runs into this So what we ended up doing is we ended up kind of doing like a rough map of the name to the To the The luminosity in in the value so like if y'all don't like know you'll have a color, right? You'll have you know, whatever hex value, but there's another format called HSL Which stands for a huge saturation luminosity and you can go online type in like HSL converter or something like that And it converts it and it's three values for the hue the luminosity or saturation than luminosity The luminosity is really how bright it is so What what we're what we do is we name the color Based on how bright it is, you know kind of roughly so if you have a blue You will name it and it has a luminosity of say 62 you can name that thing blue six blue 60 don't name it 62 because the luminosity might roughly change and This is really interesting because in addition to like providing some standardization and a way to do this You will find out like hey, I have two color blues here One is a luminosity of 61 the others is 62 I wonder if I can just consolidate these and I can tell you when we did when we did this with Olivero we did consolidate this and That that kind of makes the code base like a lot nicer. You know, it's less variables it's less things for you to mentally comprehend and Anything any time that we can do that is a big win in my opinion and and it also like gives it gives the consistency for us Like if you see blues if you blue 60 you have an idea in your head What that's gonna look like without even like trying it out So yeah, once we had once Mike had changed all of the color names in the front end code And we had found the ones which there were multiple I was surprised on how many were so close and Mike was like hey can we just consolidate these and I was like Oh, yeah, and made our color system like I think we dropped like seven colors a lot of them were grays too Because with grays we had grays that we were just pulling out to make more a more accessible grave because as the design system Kind of grew and we're using grays against different colors We needed to have more accessible grays to create that contrast ratio And so we consolidated a lot of colors and then we went back into our Figma document And we updated all of our naming system to match what Mike had done in the front end So that way it was more consistent And that way what Mike was using in the front end. We were also using in our design system Another way to do this is using something called design tokens now I'm not super well versed in design tokens. So please do not ask me questions You know troubleshooting design tokens. I'm still learning to but design tokens are basically a way to create that Consistency between the design files and the front end code when it comes to naming and so basically definition of design tokens is it's a way to store values of a design So think about your colors the values of your typography your spacing values all of that is basically aggregated into a JSON file and I'll have Mike explain what a JSON file is because I'm pretty sure you can do it better than I can But they basically allow teams to better collaborate So then what you do is you take this JSON file you pass it along to your front end developer Or you can sync it up to GitHub and I know that Figma has a couple of plugins That export this JSON file with the naming system and all the values And I know scotch recently also I think they either natively or have a plugin that also Export design tokens and Mike can you um? Can you talk to us about what a JSON file is? So the so developers in this crowd already know this but a JSON file is basically a text file that could be read and by computers So so you could like you could you could define like these are colors And this is a name of a color and then this is the value of that and stuff like that And it's you can you can read it and computers can read it and that's that's kind of the value of that Awesome, so yeah, if you haven't used design tokens again great great tool to use I'm still experimenting in Figma and how to set these up correctly But grid systems is another way that designers can create consistency for Mike And when we think about grid systems most people or designers think about grid systems as like the horizontal grid So that is your columns going across. This is the most common that you see but in one of my examples there was some odd spacing in between components as They were as they were being stacked on the page and we want to make sure that that spacing is also very consistent and so We call this vertical rhythm, which is basically How things are spaced going down the page and how the user scrolls down the page and you want to use a consistent consistent spacing for that and a Past co-worker of mine Maggie Griner who used to work at Lullabop since his left She wrote this amazing article on techniques on how to do this Designing with rhythm and proportion put a link there highly recommend to check it out. She has some great tips and techniques You also want to think about with your grid. What is the width and max width? This is something that sometimes I even forget and Mike used to ping me all the time about But what is the max width of your grid? Where do things stop scaling and width or are there specific components that actually take up the full width of the grid system? And break out of that grid system and actually become the full width of the browser You also want to set up your grid system for multiple breakpoints because they will change from desktop down to mobile and so If you're new to grid systems The best grid systems are multiplied by two 12 and 16 are the most column grid systems because they are the most flexible when it comes to desktop grid systems You also want to think about your typography So a technique that we use with setting up our type systems is we just come up with a bunch of typography and type scales And then we at the very beginning of the project and then we revise as we go along because your type system and your type Scale is going to change as you find the gaps And as the design system grows Really cool tool that we use it's something called module scale. I put a link here and What it is is module scale is a way to set up a type scale system pretty quickly using ratios So you can pretty quickly Based on the ratio that you put in and your base font size like you can put in a base font size of 1m And it'll give you different options for your type scale You also want to think about the margins around the typography Specifically if you have like two paragraphs, what are the margins or the padding in between those two paragraphs? What happens if you take a paragraph out and you stack it on top of an image, you know Does the padding stay the same? Is it different? Mike is going to ask these questions if he doesn't know Now let's talk a little bit about components styles and shared libraries These are things that you are going to create in the design tools that you use So just a little FYI Figma calls calls these components Sketch calls them symbols. I'm going to use components for the sake of this talk But it means the same thing So basically you in your sketch or your Figma documents or your design tools that you're using you can usually set up a design Library or component library or a style library And basically what you do is you can create these libraries and create reusable components and then you can take those components and Pull them directly from the library for designers to use You can also create the spoke components, which means that these one-off components that aren't really Reused in the design system there might be just like show up in the about us page or on the home page But when you do create those bespoke components make sure you add some documentation for Mike because He will want to know that those are not mistakes So components the great thing about components is that they create the central source of truth for all designers So if you update a master components, so you change off the background color and save it it'll those Changes will push down to all of the pages and all of the files that are linked to that style or component library You can also create overrides pretty easily So if you know you have a component that use a black background, but on a specific page You want to use a gray background? You can go ahead and do that pretty easily again document that for Mike. So he knows it's not a mistake And again the great thing about components is they help create more consistency in our designs So instead of copying and pasting copying and pasting you can just pull right from the component library And updates are stay pretty consistent because you just change the master component With style libraries you can set these up early on too So start at the very beginning. So there is a library for all designers to pull from again, this will probably change as the design evolves as in the past We've had our colors change pretty quickly in the design process because we find accessibility issues with them But that's absolutely okay because they work similarly to components. So does typography So you set up your colors and typography of shared styles kind of works like the same thing with a master component Where you change out the master color and it updates across the board wherever that color is being used And again, I cannot stress enough about how much I love shared libraries I share them all the time, you know, it's very easy to share them with designers because designers can link directly to the component library You can put links in your documentation to these libraries and anything that we hand off to Mike we usually Add links to the shared libraries for Mike to access And we also sometimes share them with stakeholders and other adopters that are outside of the project team So when it comes to documentation, there may be specific things that Mike might not Might Mike might not know and so we're gonna create like that extra layer of documentation for him And so with our documentation, I'm just gonna go back here because this fast-forwarded way too quickly for me We're gonna document our style guide patterns and additional functionality because if he's jumping into a figma file He might not know like things are supposed to be sticky or how Animation is supposed to work within the design system And so we're gonna add that extra layer for him to hand that off to him So he pings pings us last so when it comes to asking questions So I love the photo that Mike pulled for ice cube, but I found this quote Truth is the ultimate power when the truth comes around all the lies have to run and hide So basically when Mike finds any inconsistencies in the designs He can go to the documentation to figure out if those inconsistencies are part of the design system Or if they are mistakes pretty easily so So in our style guide We typically document our type systems grid systems colors and spacing and the reason why is because it's basically a Document that we can just hand off the mic and he can really quickly scan and set up all of the type systems And all of this basically without clicking around the designs to kind of get those values. Oh One other thing too is we often include our design principles and personas in here because a lot of times We'll hand the style guide off to higher stakeholders And it's nice to have those personas and design principles in there because it creates a nice reference for how these styles and spacing and everything kind of came about This is just an example of a style guide we often use Google Docs for this because several designers can jump in and create and Create the style guide, but as you can see here we document our type system We document our grid system and we also add handy links at the end For our front-end developers to kind of jump into anything like for instance typography You know, you want to make sure Mike has those links to where he is where we're grabbing our funds from And so a lot of times what will happen is Designers will actually if we have to purchase the fonts we'll purchase the fonts ahead of time And we'll put them in a drop box folder or box folder for him to access those fonts We're also want to document our patterns and components separately And when it comes to our patterns and components, this includes our colors our layouts and our type treatments And here's an example that we've done for Olivero On the right-hand side is Some extra documentation that we added for the header just because there's lots that happens in the header You know, we have if we have a sticky header. What does it happen on scroll down? How does the design change? You know, what did drop-downs look like a navigation on the right-hand side or on the left-hand side? We have a documentation for input labels and these are super important because I found in the past that several designers Don't even like don't know all of the states that Input labels could have so a lot of times Mike would ping me and be like so like what is the focus state supposed to be and I was like Oh, this seems a hover state. He's like, no, no, no Let's let's happen a flat call and talk And so, you know, we document basically our error messages, you know, what is a checkbox look like when it's checked What does it look like when it's disabled? All of this Mike can get really quickly and just scanning down to make sure that everything's included And if there's something missing, he'll reach out to me We also have functionality and this we want to document us separately So we have prototypes that we can do this with but those take some extra time sometimes the prototyping can be too complex for Figma and You know, sometimes designers don't know front-end code and they can't do this pretty quickly In that case in the past we've used comments and envision in Figma What we found is most popular though is creating a functionality spec document and basically this is an annotated design that kind of links up to a spreadsheet, so yes designers sometimes have to work in spreadsheets but basically The numbers match up to functionality that is supposed to happen. So you can document your click functionality your skull functionality or any animation that's supposed to happen and then this one I actually just added in last second because There are a lot of gripes about file Organization on developers and other designers even are gonna hop into your files at one point and so it's great if everything's organized and I am totally a Person who kind of works messy at the very beginning and then works backwards and cleans cleans up their files But basically try and name your layers In a way that is meaningful You also want to set up a system to let developers or other designers know like what's still in progress versus what has been approved in The design files. So we've used an emoji system in the past So anything that has a green check mark has been approved Anything that has a red X is still no being worked on or has to still go through the approval process and finally it's Good to leave any other notes for Things that might need to might might need to know when it comes to extra context with the design. So So Mike's gonna talk a little bit about communication Yep So communication is is obviously Very very important probably the most important thing that the way that we're gonna collaborate, right? So this is this is traditional here and we've all been there Where a designer will do a whole bunch of work and they just kind of throw it over and then they're done I've been in situations with this especially with external design agencies We overly communicate like and I highly encourage you to overly communicate to Communicate during the design process with regular check ins that includes wireframe check ins and things like that that can identify some issues Like for example does Drupal give this to you give you this functionality, but slightly different for free most recently I had a case where Our designer was putting together a form You know and it was kind of a filter form and they had an idea and I said well if you use views expose filters It will kind of look like this with this work and they were like that's wonderful. Yes, and that saved several hours of Development work for us to have to configure those expose filters to do a different format and and that Time is money. You know that that that saves our that saves our client that much money So bring your developers in for review and during the development process to we're constantly We're constantly talking. There's always gaps and that's totally fine Like I expect gaps and to tell you the truth like I kind of look forward to these gaps because it gives me like A little personally it gives me the opportunity to flex that muscle what I typically do and not everybody works this way if I see like For example a state like a focus state or an active state that was not documented I will say I will I will do it Make a best effort and at that point I'll say hey Jen What do you think about this and she will say well Mike? There's a reason you're not a designer or she will say Hey, that's really good Done, you know and and more often it's the latter and and and I I like to I like to find that you know There's also all types of pushback. There's always going to be pushback, you know designers have a tendency to create a Text that might not meet Accessibility criteria, you know like you like to make a website Properly accessible text has to have a certain contrast ratio above the background color So when we do design or when Jen does designs when I when I co-designs I do my best to make sure it does that because I want our websites to I want everybody to be able to use our website So so there's things like that. We talked about similar components You know there are cases where like right now I am I am working on a project and we have a whole bunch of different card variations is this a card is that a Card can we combine these cards? That's a conversation that I've scheduled for when I get back from a Drupal con here and as I mentioned earlier can similar functionality be provided by Drupal that's not quite the same is that okay a Lot of times the answer is like heck Yeah, and then there might be some minor design elements that impact the timeline and I don't know Like think of like maybe a menu that flies out or or that does something a little Untraditional is that important is this the type of thing that you and the client 100% want and if so that is fine, but keep in mind that might take you know Three four hours of development time to put together You want to talk about tools? Sure, so I'm just kind of really quickly go over some of the tools that I had mentioned a little bit earlier that can help with the handoff When it comes to handing off your designs, but I don't want to call it a handoff It's not handoff like we're communicating all the time Mike's brought in super early into the design process to ask questions to help us with timelines You know some of our ideas are really blue-skiled, but they may not meet the deadlines that we have So we want to make sure that we're communicating all of that So that's why I don't want to say handoff because it typically is not a handoff. It's more like um We're not really done yet, but we At the point where Mike can start development So a few years back our design team had moved to Figma Figma is a really great design tool because You don't have to download the program in order to use it and we always we had run across this with several developers In the past sketch was only Mac based so they couldn't access any of the design files so we had to use another tool called envision and Create a link based system where we would send sync our designs to Envision Sun that link over to Mike Mike would get that link and then he could go in and Turn on something called the inspect tool where he could kind of click around the designs to get all the values He needed for the front-end design Figma eliminates that extra step. So Figma is basically a design tool if you haven't heard of it similar to scotch But it is also web-based so you can download the program or you can use it web-based It allows everybody to collaborate at once in the file, which is kind of cool But kind of creepy at the same time you can see cursors moving this morning I went in to check on the progress of a design file that I've been working on I had three other cursors moving in the design file and I felt I felt like I was kind of creeping in on them so but I can send Mike a Figma link and he can really quickly just go in and Click on everything and get all the values that he needs to start the front-end code There are other couple tools that do something similar that you may have heard of These used to be pretty popular, but I feel like because of Envision and Figma. They're they're less popular But there's Zeppelin and Avacode which does the same thing that Envision does so you can basically sync your files to These programs and then send a link to Mike and then Mike can go in and click around to get the values that he needs to start the front-end We also use Google Docs and Dropbox paper which took a second to show up here The reason why we use Dropbox paper in Google Docs for all of our design documentation is there's more likely going to be more than one designer creating these and so we often have several designers going in to Finish off the design documentation around the design system that we're going to hand off to Mike also to The documentation might change as the design system evolves So it's pretty easy to just go ahead and change it in the Google Doc Look let Mike know But we don't have to like keep exporting PDFs and uploading them or emailing them So it helps create more of a living document So we are near the end of our presentation All of the resources that we have mentioned are at the end of our presentation here We aggregated this nice slide for everybody so they don't have to go seeking through the presentation looking for all the links But if you're curious the link to this presentation is also down at the bottom here and um I think do we have time for q&a? Yeah, we have uh, we have about 10 minutes if y'all have any questions We will do our best So first of all, thank you you had your hand up first Yeah So the question the question this is for the recording is how do the designers deal with nested grid systems? Do you want to answer that? I can try um So typically we try and avoid nested grid systems because in the end there's going to be only one grid system that Like hat can start up. Is that correct like when you're doing your? Yeah from a front end perspective. Um nested grid systems can be tricky Because like like there's there's some css techniques coming out that are going going to allow us to deal with that a little bit easier But right now Right now there's not that doesn't mean it never happens But coming from gen and and the designers that I worked with typically they avoid those But when they happen they happen and I deal with it You and then you next Yeah, so the question is uh, should a style guide be publicly accessible on your website? And I I kind of have thoughts if you want to have thoughts Uh, so my personal opinion is yes And the reason why is because there's no I mean unless you have some proprietary information in there that you don't want to share out I don't see a reason why Not to publish it. Um, I know some companies in the past were afraid like People might actually like duplicate the look and feel of their website And so they wanted to keep all of the style guide and all that pretty private But I'm I'm more for sharing like I I I love personally I love looking at other style guides and design systems and documentation that other companies have set up As inspiration for how we can make ours better When it comes to documentation so I just want to add I think it would probably keep you more honest too, you know, so they don't go out of sync Yeah Yeah Yeah, yeah, so that's that's another grape that I could probably put into the slides at some point So the question is is in regards to the max width like how Like a lot of times like it's not documented like how that's going to look And is the is that hero is the hero image going to like say like expand to the whole The whole width of the site no matter how wide it is, you know, am I am I understanding that correctly? So What I typically do is I'll like like for me I'm I'll typically just Kind of do it, you know, I'll I'll I'll let it expand even if it's going to be like kind of like very low resolution, but I guess it really depends on the design and things like this might be a Situation where I reach out to gen like because there's a couple different options. You could do a repeat you could do You could you could have a Color back there or something like that And I think I think that would be a question for design where I would I would ping you in slack and say hey Let me show you this and what do you think? Yeah, and um, so at Very early on in my design career, I Would always be like, oh no, it's just it should just be the max width of the browser Like it should never stop scaling, uh, but I learned a couple of things number one The image would have to be fairly large because you know a lot of Dust hop screens are getting larger and larger And so especially if you're showing a website on you know a screen like this It'll get pretty Pretty blown out and so I've had in the past developers just go out on a call with me and show me what the image looks like Or send me a link to see what the image looks like at full width and you can See pretty quickly that the image is pixelated And then I'd ask that well Why can't we just upload a larger image and the reason why is obviously for performance reasons because you know the larger the image It'll float on the website and so I've come to the conclusion that Basically, there is going to be a point where things just stop scaling And so it might not be apparent on my laptop or on my screen But there is going to be a max width that i'm going to have to uphold in order to help create some To create more clear images and so nobody sees like a blown out image when it comes to the website so So i'm going to repeat the question the question is are there any references or guides for designers to kind of For print designers to learn web design and all the things that they have to design for Huh, there's a lot that's out there. I do know that there's a bunch of articles that I could That I could reference, but I don't know the links to them right away I do know there are some books too. So in the past I've taught some web design classes where I've actually used a book because the book is actually pretty good and I've noticed that when you point students to To you know links, they just don't read them like Go ahead So the question is how do we approach ADA? It starts with design. I will tell you that so all the colors that you choose the type system that you set up We often run through Contrast checker, which is plugins that you can use with figma with accessibility. It'll tell you if the type is too small And if it is too small you have to bump up the contrast with the color And then that also gets passed on to mike who also has to do a lot of accessibility A lot of accessibility in the front end Sometimes he'll come back to me and he'll find stuff that I had missed Which is great. He'll be like, oh, you know, this doesn't pass the contrast ratio And it's like a grade that I had missed and I was like, okay, we have to go ahead and we have to update this color Yeah, pretty much what jen said I created this cool grid that if the internet was working it would it would work It's called contrast grid here it comes and it allows you to quickly evaluate Large color systems and I I did this Because I was a lot of fun because it was a lot of fun And what you can do is you can paste in your css variables or sass variables And you hit a button and it will show you the grid right here and This helps you This can help you like Really quickly evaluate your colors And and and how it looks and stuff like that. And so that's at contrast grid dot com So so the answer is like it's a lot of it's on me about keeping the website accessible I strongly believe in accessibility But there is it starts with design One more question in person with the green shirt Yeah, yeah, yeah, all right totally I guess one more question too while I pull that up Uh the one in the back there with the plat Yeah So how do the question is how is the project set up? So we have that much so we have access to our front end developers and front end developers have access to our designers, correct? Yeah, yeah So in the past at lullabot when we had worked together, uh, they basically overlap In those in the in the process they basically overlap The developers with the designers so there isn't a point where designers actually roll off the project Where there isn't a front end developer that they're communicating with so usually it was what like three four weeks We've also since learned that it's also advantageous to have a front end developer embedded in the design team at the very beginning So we're actually experience experimenting with using something called a front end designer is what we're calling it And basically it's a front end developer who also knows design Embedded at the very beginning with uh the design team to kind of help with that communication and to help with feedback I also want to kind of talk about people skills Like I have worked with designers before that I don't personally know and they have honestly not made the most optimal designs and but Because I don't know them that well. I don't want to go to them and kind of trash on their designs So you like you have to know how to gently push you have to you have to Uh, you have to have that feedback. I like to do video calls So you can hear the people's voice inflection and and stuff like that But that's that's a whole another talk and that's honestly probably the most complicated thing ever is just being able to do that Um, we don't have time but like we can hang out out there if y'all have questions and uh Like thank you. Thank you for being in person