 Alright, thanks everyone for joining today. I know I said 1110, but we'll just let people trickle in and get started But thank you for coming. You know, this is my first Drupal console nervous. Also. I'm a UX designer, so Don't know that much about Drupal, but I'll try to teach you anyways So my session today is Drupal for designers speaking each other's language Kind of a kind of a back story. This is more of my origin story into Drupal I didn't know anything about Drupal and I was working on Drupal projects And so that kind of is what the the catalyst for me presenting this today is, you know, for anyone that's insecure Maybe doesn't feel part of the conversation You know, we want you to be heard and we want to hear you and then also have a conversation centered around that So again, my name is Maida. I'm a UX designer at face to technology You've probably saw our booth. It has a big tree. We got swings. We got all of that That's where we're located So accessibility advocate just like our whole agency We really, you know, highly value that as well as a noodle enthusiast and for anyone that's wondering Fah is my favorite Noodle bowl. So again, we're face to you'll see us in our light blue shirts located at booth 3 3 3 We are a full-service digital product agency So we span across multiple industries. You can hear more at our booth or even just hear more about our design system outline So we're gonna do things a little differently today Again, you know, this is really about striking a conversation So the expectation here is that we'll be talking to each other So I'll start off at the presentation with an overview Just kind of going through challenges that we face between different teams that we work with whether it's designers developers content strategists Talk about the discovery and design process from a face to standpoint how we've structured ourselves just to provide insight But then I'm opening gonna open up the floor and present some questions to everyone here Just to kind of hear thoughts and experiences. You've had working with cross-functional teams so that you know, again, we can learn from each other It's not just about me talking to you, but it's about talking everyone Everyone that sound good everyone okay talking. Okay All right. So why are we here again, you know We want to make sure that we're keeping all aspects of development as part of the conversation when we talk about Drupal development So here's a quote that I heard from an anonymous UX designer who said that I don't have much experience with Drupal And not to be a snitch, but that UX designer was me That was me about three or four years ago I was working on solely Drupal projects and I remember sitting in a client meeting and a Software architect was talking to me and he was talking about panels blocks layout builder. I had no idea what he was talking about Yet. I was making the designs That really struck a chord in me in terms of understanding what I'm doing You know a lot of times we tend to silo ourselves and the work we're doing and we feel that it doesn't necessarily apply to us Especially as designers We create no pretty solutions intuitive solutions, but then we don't think about the back end. That's making it work But that being said I'm not an expert so don't hold me to it So designers and developers play a fundamental role through the process But there's a lot of mystery surrounding the work we do we like to say that we really align ourselves to be cross-collaborative But you know on a day-to-day basis, we do get siloed with the work We're doing either whether it's deadlines a bunch of meetings We so we want to make sure that we're talking to each other But also understanding what we're doing at every phase of work And then we just genuinely want a better understanding of a Drupal project from a designer standpoint So just from a show of hands. Who is a developer here? I thought so and who's a designer Okay, a lot more than I thought 30 So wanted to just kind of shed light on what processes from our standpoint on when we're working on a Drupal project You know whether it's working with content strategy wire frames user research and how that applies to a full team And then again that we want to open a dialogue centered around designers within the Drupal community I was actually talking to someone earlier in this room at times It can feel like there is you know the sense of gatekeeping that happens Whether it's intentional or unintentional or maybe it's just something that I feel myself because I can be insecure about you know My expertise in Drupal is you know opening the conversation so that we can talk to each other and understand where we can meet each other halfway And so again, you know, why should designers know Drupal? You know for effective communication between teams We don't want to you know be starting a project and not know what we're doing And the ability to create designs are on Drupal frameworks I think this is probably the most important takeaway is understanding the design systems in place And then templates that are being used so that we can work around them as opposed to creating Designs from scratch that may need to be hard-coded a later time And then time and cost effectiveness again making sure if we can work with the system We will save time and money at the end of the day And then why should developers know design? So developers should know does the design process not necessarily design itself But just so that they can start you know early planning and development But also early input on concepts and ideation not every Developer has to be a designer not every designer has to be a developer by any means but designers You know we that's our job But there's always great input that we can get from other people So making sure we include designers and developers early on in the project And then just generally creating more synergy early on between design and development teams and the other teams that we work with Again, we all want to be friends. We all want to make sure that we're aligned on any decision We make so just making sure that we involve everyone early on in the process So we want to work with the system and not against it. I'm not sure if anyone else has experienced this I've experienced this numerous times where I've created wireframes You know taking them to a developer software architect, and they're like we can't do this And I'm always like why can't you do it and you can do it your coder just do it and you know for them You know, it's really about staying within scope of budget and timing So just understanding level of effort early on in the process saves all everyone heartache I'm just gonna dive into you know what our collaborative process looks like at phase two I'm sure a lot of the designers here are familiar We just wanted to give insight into specifically how we work and some of kind of the deliverables and artifacts that come out of it So the people that we work with as designers we work with clients So we are heavily client-facing individuals So we're always answering to the clients our internal teams and I would say a third group up here are the users We are the user advocates so making sure that we can also you know include them any conversation we have outside of business needs And then understanding the line is always open. So because we work with so many teams We're constantly having to communicate and that's probably the biggest Asset that you need to have as a designer is being able to listen as you go through the process and I think my calendar can also attest to that as well And the challenges we face when we don't talk to each other again lack of understanding between teams and clients So playing a lot of Chinese telephone just trying to you know go from one person to the other You hear one thing you hear another thing and then at the end day you deliver something that no one's aligned on And then also making sure that there's a single source of truth whatever that means to you whether it's you know a change Management document and maybe it's a Miro board where everyone throws all their ideas together in one place I know during remote work That's become something that I've valued a lot is setting up just kind of literally a brain dump folder or a brain dump Template on Miro a Miro where everyone just kind of throws all their thoughts in there and works off of one document for any sort of research work planning everything And then again missing out on optimizing time and cost when we don't talk to each other and we don't understand each other We lose money And then feasibility understanding what's possible early on as opposed to finding out later down the road when we go into actual development and planning So the solution again is just involving all teams at the beginning of a project. So I know We're talking about development and designers, but we want to also talk about the other groups in place We have strategy. We have content strategists. We have data and insights teams You may have other teams on you know at your agency's companies that you interact with These are just some examples of teams that I work with on a daily basis So again, you know when we when we don't work with each other and we don't work with each other's deliverables We very much fall into a waterfall approach. This is not a real sprint plan at all So don't don't look at the numbers on the top But we really want to take a look at, you know, kind of the waterfall approach and we end up taking when we Do design siloed and we don't necessarily start involving other teams early on in the process However, something that we're doing at phase two is actually getting that started early Outline our web design system full of web components. We get started on that during the UX and design process So any sort of designs that are built out or immediately send to the developers to start building on their end And I think at vice versa we utilize the design system as we create our wireframes So there's constantly some sort of so single source of truth and template that we're working off of And that just allows to Create more time and budget for any sort of complex items So if there's any efficiencies what we can take away from we use the design system So I wanted to break down the design process from a phase two standpoint in terms of the different types of work We do again, you know starting from discovery We go into user research user research is an ongoing process, although it's placed here as kind of that second bubble It's something that we're constantly doing and thinking about again You know budget and client needs can sometimes dictate how much user research we can do You know, I'm sure many of you are familiar with you know, especially designers You want to do usability testing at every round of designs. You can't always do that So just understanding that we want to fit this in as many times as we can wherever possible with the budget and time We have and then actual design work. So actual design work, you know includes wireframes UI design information architecture just kind of really, you know setting root for what we're gonna build moving forward And then design handoff is also a big part of what we do So we do work with our in-house development team. So it is a little easier in terms of doing handoff I've worked with offshore developers Where it's very different where we have to actually write out functional specifications So that may look different for you, but just kind of give insight into how we do it here and then design QA So designers job is never finished. We're working through the full life cycle of the product even after we've completed our designs We're still checking designs. So we're still playing a passive role towards the end So discovery the purpose here is to define the problem to be solved So again, you know, this is the foundation of all the work we do As you can see on the right hand side these are just examples of some of the kickoff activities will complete during this process the one on top is you know The one on top is more client-facing where we get them together and want to learn about just where they see themselves in a couple of Years what their vision and vision is for the product that we're creating just to kind of get them excited about what we're talking about The one below is actually a more complex So we'll start doing empathy mapping with them to identify what their users are looking for as well as You know value prop canvases that we use to understand, you know, what how they see this product benefiting their users And then we end up with strategic recommendations. They're usually in like a discovery findings deck that will create And then project plan and roadmap that we create with our product managers So key players here we have our developers. So again, you know, we bring in developers early on in the process The people you see here are you know, you'll see them throughout the process discovery process as well as design process We have strategy new acts kind of taking the lead in terms of all the discovery Deliverables that we're creating conducting workshops interviews with stakeholders as well as users And then we also have content strategists that start early on the content strategist is so one thing working with several different clients You can't anticipate how big their content team is or how much content they have So it's best to get content strategists involved early on so you can start talking about the brand voice and tone right then and there And then we have data and insights. So data and insights is really you know The team that's providing areas of improvement through analytics audit So they're giving me pointers on terms of what different things I should hit on as I'm talking to our stakeholders and users And the user research. This is my favorite part. I love talking to people So this you know doing user interviews is probably the most important part of my job I feel just understanding who the end users are and what their needs are, you know, typically in any sort of project It's usually our role to play that it's also usually our responsibility to play that role So just making sure I can take that kind of give the due diligence there So user research just helps us outline what our users needs are who our users are in fact And then how they're perceived the product or service. So a result of that is, you know persona segmentation journey mapping user interview service design blueprints just depending on what kind of project you're working on And then key players here content strategist again We involve content strategist during the user research part as well having them sit in just hear what we have to say Content strategy is really important at the agency in the sense that we want them to understand what Users are looking for so that they can speak to those users one instance is, you know working on a children's hospital Children's hospital versus a you know a regular adults hospital your content's going to look different It's going to sound different and you have to understand that early on So involving user interview involving content strategist during that come during that part of work really helps in terms of unearthing all that information for them Data insights. They'll start tracking metrics engagement to kind of give insight into what we need to focus on Again strategy new acts working together to conduct user interviews and any sort of other research. We need at that time and So design so does that during design we call We involve you IA and sitemap being into design. That's one big Phrase we use there. So it's kind of an overarching term We identify information architecture during this time based off of the user research so that that could include, you know Tree testing any sort of card sorting we need to do and then validate it there And then moving into wireframes from there and then during this time. We're also working on content again So one deliverable that really feeds into the work we're doing is MRA mapping, which I'll talk about in the next slide And again, the result of this is an IA built out wireframes basic CMS set up on the back end with the developers Feasibility matrix. So this is where we start talking about what's possible We start bringing up, you know features. We start bringing up design build to understand, you know How we can we move forward in the most efficient way? So key players again developers So developers are the ones that are really identifying that matrix for us feasibility matrix content strategist So content strategist actually start writing content at this point key content I would say the headlines just so that the client can start visualizing their pages in a way That's more meaningful to them And translating wireframes into design mockups and then validating so strategy will validate designs based off of their proposed strategy So strategist stay on board Maybe more in a passive role, but they're still providing input and then again UX creating wireframes and IA So this is an example of an MRA map, it's not the full MRA map I couldn't include that in here because the client reasons But what we start off with is an analytics audit and site crawls that really dictate what Different websites we should be looking at especially if it's a big enterprise website again right now I'm working on a healthcare system. They have about an app about I think 33 websites Marshall in there 33 33 websites that they're utilizing So we had our data insights team go in there and try to take out any redundant links any sort of broken pages and try To consolidate so that we can identify what websites we should be looking at for our content MRA map The content MRA map is basically a spreadsheet We create that identifies content that needs to be migrated or rewritten or archived And this really helps to find the IA when we know what kind of contents available to us We can start visualizing pages in a more meaningful way So to remove any sort of redundancies and identify moments of consolidation And then again that defines the IA that we move forward with based off of the content that's created in the MRA map MRA maps can be very long and tedious work However, I do believe they're very much worth it at the end especially for a content strategist kind of lays a foundation for what they're doing And then here is an example of a feasibility matrix that we've created in the past Identifying features we need to build for a platform we were creating so think of this as a basically Point estimation that you would be doing in any sort of scrum project that you most likely is happening in JIRA Except this is happening on a mirror board and you have multiple teams present for this So you'll have your content strategist You'll have UX you'll have your developers or software architect and they also have project managers and product managers The idea here is to understand not only feasibility from a level of effort standpoint and budgetary standpoint But also for people like us designers who you know want to understand You know really want have user input that we want to bring up to the table So allows us to create a feasibility matrix based off of all those different players We have in all the different clients we're working with And then you'll see just the the color dots are really just to identify Big smaller large it's very broad how we do this But it's really just to start the litling the foundation of any sort of sprint planning We have to do moving forward and it also includes design So it may not just be developments also design components content everything included in there And then we have design handoff. So this can be different amongst teams I know everyone does this differently based off of where you are what agency company you're working for However, because we have a great in-house team. We don't have to do too much explaining again Because we talk to each other all day So we create prototypes and sometimes functional specifications So just annotations on Figma files when we deliver So it's never anything too thorough because again, we're working closely throughout the full scale of the process Designers and developers are working from the very beginning So again developers are validating designs for us for feasibility and function content strategist deliver content Framework and new content. So we're placing an actual content into our designs At every moment that we deliver design so that again clients can start visualizing and we get a lot of comments about that You know it how about if we add an extra paragraph how would this page look so in order to just kind of Mitigate a lot of those questions. We start early on And then UX UX did QA's design work insurance It aligns with wireframes and then you eyes creating the prototypes based on the existing wireframes And then design QA so you know again our job is never done We're still doing looking at designs after the handoff It's our responsibility as the creators of the pages and the design on website to make sure that it functions the way we intended So we have quality assurance identifying errors and bugs developers Remediating that we have UX ensuring website functions as needed and then UI making sure it looks as intended And then one other thing I wanted to hit on is you know clients are also part of the conversation You know we we talk about it We're talking about you know having conversation with each other as an internal team But we also want to include clients as a stakeholder and as you know a product owner So this actually came from an experience I had myself in the past is you know trying to talk to clients about highly technical things They don't understand and when they don't understand they often just stop listening and then when they stop listening They don't think you're doing the right thing So making sure we can talk to them in a way that makes sense to them So there's just a couple of phrases that you know to keep in mind as you're talking to a client about the work You're doing Nodes pieces of content views page displays and honestly this was really helpful for me too because I would talk to developers And I had no idea what they were talking about half the time So I think this is helpful for everyone to just kind of have a basic understanding of terminology And then not overwhelming the client so understanding, you know making sure that we provide logical groups and chunks when we present to clients as opposed to a full build or full design and Then showing bits of functionality So maybe starting with a mega menu and then you know a footer as opposed to showing a full scale website and Then identifying and using real content for content types again This has probably been the biggest takeaway for me working with content strategy is Using real content and getting them involved early on the process so they can start building that content for my wire frames So I don't even wait for you know mock-ups I start placing in content in our wire frames and if we don't have full content We create frameworks around it so we can place in content have at least sort of placeholder text for that All right, so, you know, this is colonel, but why is this important? Hopefully you understood why it's important right now, but if not I have some summary slides So client and editors are also end users of the products we create so And I mean this in a sense that we should understand how to talk to them But we should also understand how to create a back-end experience that makes sense to them So understanding the CMS, you know understanding how we need to create workflows for them Understanding, you know if there's any sort of help text we need to create for them where we need to place it So we're not just working on the front-end experiences. We're also working on the back-end experiences, which is something honestly, you know I haven't seen as much it's something that I'm also working on is making sure I'm making conscious effort to think about the back-end experience for them from an editor experience and Then again in order to work efficiently, we have to collaborate early on we have to make sure we're talking to each other We have to make sure that we understand the nuances of the work We're doing early on so that we can help each other out A lot of times, you know deliverables can be seen as more just client-facing artifacts that we send over But they should be tools that we use to help each other Those deliverables we send to clients should also be deliverables that we're utilizing internally to maybe you know help the work that we're doing And again, designers should be thinking about the end product and the back-end experience that makes it work It just makes us better designers at the end of the day. It makes us, you know It helps us understand the people around us. It makes us have better conversations And then it just you know gives us an understanding of how to be more efficient in the work that we're doing All right, so I did my piece. I talked for a couple of minutes, but I did want to hear from the floor I know we have a good, you know ratio of designers and developers here And I know many of you probably come from different industries agencies So I wanted to hear some of you know the issues that everyone in the room has had in the past working with groups Go ahead So we've used air table in the past but kind of to your point I think the biggest issue isn't necessarily finding the right tool. It's finding a tool that clients find accessible We've done comments and Figma files in the past But you know, they sometimes just don't know how to access the Figma files There's always kind of that learning curve that's associated with it So something that I've consciously been trying to do is actually provide trainings on how to comment So when we deliver any sort of you know wireframe or IA actually recently delivered in IA I actually had to include slides on how to provide feedback And we kind of just reuse reuse those slides amongst each other within the UX team So we created a couple and we've created documents specifically for those comments So again to your point, you know, I don't think there's the best tool that I found But I think there's practices around making it easier for people, you know Just providing for the sitemap we had to literally lay out for them You know, you're commenting on the relationship of different pages You need a comment on if the naming structure makes sense to you like even small things like that I think really go a long way for them And if anyone else has any suggestions, too, go ahead Yeah, that's interesting. So it's more of like a feedback survey that you provide them and oh, okay And then you collect that on the back end and you do it for every single Deliverable you're sending out or page or who can you repeat that the last part? Sorry Yeah, and so I've come across that issue in the past where we've had multiple changes Or there was a work order in the middle of a project and they're like actually want to pivot and do something else Can you add these things? So we just go back to that feasibility matrix again We kind of get our heads back and start creating features again and placing them on a matrix And there have been times where we've actually gotten clients involved in that so that they understand How much of a budgetary concern it could be or timing concern it can be so that there's full transparency there for them But from for the first part of your question about bringing value to design I think the most important part for me is really valuing the data and insights team. I work with You can't you can't argue with numbers As much as you know Clients want to but when you kind of put it to them or put it, you know in front of their faces That's something that they can't deny and also just being able to do a b testing That's something I Would like to be a bigger advocate for as well as you know putting more money towards a b testing so that we can validate that way It just happens to be that some projects you don't have much budget to actually validate in certain ways So I really believe heavily lean on the data and insights team when we do that So making sure that we include them in any sort of presentation work we do Bring in facts and figures from them. So basically the deliverables we have are very much Collaborative with the data and insights team whenever whenever we deliver. It's not just solely ux Yeah, um, so I this is probably not the perfect answer because I think I'm actually struggling with that race right now I have a client and the client is the technically the product owner, but he also has About 12 people working above him that he has to answer to and he isn't the most assertive person and though I think you know what I'm talking about And um, so working with him has been interesting. So I feel like I think that question that you asked is something that I'm actually struggling with myself You know, one thing that we've had to do is actually more design work to get the point across Making sure that they're involved and actually doing more presentations that we need to so creating micro presentations for their leadership Something that we've been doing is so that if he isn't necessarily the best of translators, at least we can be And I am very wary of ever sending designs to a product owner that has 10 people that he's answering to And just handing it over to him or her or they whoever it is So for me, it's you know, I want to be part of that conversation at all times when I'm managing A group of clients is making sure that my voice is part of that conversation Or my team's voice is part of that conversation during every point of the engagement But yeah, to your point there have been many times where we've had a client that we thought was just one product owner and ended up being You know 30 people So it is it's hard to manage so you have to have really good account directors, too Yeah And the blue shirt in the back Yeah, and it's also in-house teams that they have, you know, we we have a client right now that has our own design team Yet we're doing design for them So there's also a sense of management that we're experiencing there as you know How can we leverage just a design team that currently exist for Our benefit but also without overstepping and then them overstepping us So they are also a sense a client that we're working with as well within that same group of clients So it's been a lot of dodging calls but also making sure that we're planning extra calls We also include ourselves in their weekly syncs design sprint syncs So that we at least know what's going on on their end or we can hear something we can flag it early Yeah, so the data and insights team we have a lot of it centered around google analytics We have you know hotjar that we utilize like qualitative measures And we utilize them throughout the process of the work we're doing So they create data measurement models for the client or whoever we're working with to understand how they should be properly targeting Creating metrics for them But they also help me in terms of understanding You know what pages I should be focusing on while there is drop-off. Maybe it's you know a high bounce rate So basic analytics work is what how we utilize them from a ux perspective Making sure to validate any sort of design work we're doing or maybe if clients pushing back on you know Some maybe want to create a blog for them and they're like well, we don't want to blog And yet we see you know majority of their users going through articles on their website In order to make that argument we we utilize our data and insights team So the ux designers under a team including myself. I am well versed in analytics, but however, they kind of take a deeper dive They do it on a daily basis. I don't have to do that work I can just go to them and they'll provide me some numbers plug it in and then present it to client No, and do you mean um front end design on the back end like the cms? Yeah, so I don't have much experience, but that's something I've actually been working on recently as understanding how I can How I can test that and conduct user research on the back end for clients Um, so I don't have much experience, but I'd be open to hearing more if you have any suggestions Okay Yeah, so for the specific project again, um, the biggest takeaway there was I actually put content in front of users During my usability testing my first round of usability testing And I actually recorded it and showed it to the clients. Um, they were saying, you know, this doesn't make sense A lot of the information is redundant Um, so I think that kind of nailed the point across for them in terms of how they see themselves moving forward But from more of like a revising and editing standpoint I think it's I think the easiest way to Prioritize is what aligns with your users at the end of the day, you know What information isn't kind of your MVP and then everything else you can build around that? Issues that we've come across are, you know, clients may not have a content team So we're making all these suggestions and recommendations and they're like, oh, this is great, but we need to hire people now Um, so that's an issue that we've come across in the past is, you know We make all these suggestions and yet they don't have resourcing for it So something that we have to offer is, you know, maybe providing a content framework for them so that they can work on it slowly Creating placeholder text that would be similar to what they would be using on their final site Even if they can't agree on it, at least there is, you know, certain topics that we can talk about within that Even if it's like certain headlines So focusing on as much as we can at that time may not maybe it's not all the body copy, but we're talking about headlines Um, and again aligning it with users that what users have said I work in I work extensively in healthcare So for me, you know, it's really centered around making sure that if someone's coming onto a website They're looking for for financial assistance information. That's the content. We're going to focus on right then in there I mean, that's the case for most patients when they come on a website They're looking for financial assistance and bill pay So just aligning it with the motivations of the user is kind of how we move forward in terms of prioritizing content frameworks Yeah, so I'm not too sure about what our content strategists use We do kind of create content content outlines. Oh, Felicia, go ahead. Yeah Yeah, and I think to that point the framework is also delivered multiple times So the first framework is more just a governance tool about like this is how you should be writing your information This is what the expectations are. This is these are the resources and you need in order to complete it And then we go into more of like the mra mapping and the governance kind of that spreadsheet the snippet of it I couldn't show you the whole thing But just in terms of you know identifying level of effort needed for each piece of content each page each website on Each each page on each website And that's delivered to them with the url as well associated with it So it's it's quite a dense document if you were to take a look at it Yeah Um, and it takes a long time But I think it really helps them in terms of going back in there and identifying and Especially just putting the urls in there. I think is the most helpful thing they just click on and they're like Oh, this is where it is because a lot of times product owners don't even know their own product that thoroughly Yeah, a hundred percent. That's something we've actually been talking about internally is you know productizing that You know, that's something that's a selling point. It's not necessarily about the front end experience You're providing but it's also the back end editing experience and how easy it is to use One thing I've heard from clients are you know, we couldn't use this. Um, so we went to another vendor You literally change vendors because you couldn't use this cms and that's a pretty easily Solvable solution that you could have made. Um, yeah, so we've definitely been thinking about that And I think that's a great suggestion is including in the feasibility matrix and start thinking about that early on Because typically we don't focus on that until later when we're delivering the website and then we have to do trainings associated to it Um, so something we've been thinking about is productizing it but also understanding what kind of help texts they may need Meeting them halfway in terms of their tech literacy. Some some clients tend to be very tech literate Some aren't um, so understanding that early on so we can provide that experience So I've definitely been consciously trying to make that a part of my process as of lately Just understanding how clients come back to us with so many questions and we could just alleviate that early on Yeah Yeah, so I mean for language, it's a little hard. Actually, I mean, I don't know if anyone's here from that company There is a company represented here at Drupal con lingo tech that's um working on creating an add-on on Drupal That accommodates to that. Um, so that's an issue. I've also experienced as multilingual design It can vary depending on just kind of the type of characters that are being used Um, also if you're reading from right to left versus left to right is also a big thing Um, so I think really for that is just honestly the way I perceive it if anyone has any suggestions more than happy To say whatever you want, but I just try to leave as much space as possible I don't make the assumption that the content here is a true content, right? So making sure that you can design for probably the widest amount of content and then work your way back So it's the opposite of doing mobile first design You're actually doing like a wide desktop version and then trying to figure out how it fits from there Um, so that's kind of my approach, but you know if anyone else has any suggestions Yeah, um, that's definitely part of the process. I think we have to sit down with them and understand who we're working with And I think it's also about not using that terminology. Um, you know You have to really just kind of use layman's terms when you're talking Because again, if you're trying to teach them constantly, you're not doing your job, right? So I think it's really about just making sure that we're using their terminology that they're familiar with I was on a call kind of recently and I was talking about an mvp Which I everyone here probably is like, oh mvp They didn't know what an mvp was and I kept saying it and then I think throughout like probably towards the end of the call They were like, I'm sorry. Can you um explain what an mvp is And so in that moment I was like this whole this whole conversation we had was just null and void. It went nowhere Um, so I think it's really just you know making sure that we meet them halfway where they are But again to the point earlier even about the information architecture. I delivered include slides You know talk to them. Um, these are these are the things that you should know This is maybe if maybe if you can't necessarily fully do everything in layman's terms provide them You know some sort of glossary I actually included a glossary at the end of this deck Um, I was just basic Drupal terminology. Um that I've had to pick up in the past. Um, I don't know if I can share this deck or not But yeah, if you want to take pictures But just you know as a way to kind of level set with them is just really something I've had to experience just a lot of teaching Yeah, that's a great question. Um, I think the kind of the easiest way to do that is making your files accessible at all times Just making an active, you know conscious decision to share things early on is really kind of I mean all of our figma files are kind Of that are open source. We open them to everyone. So the expectations if you're on a project team, you should be looking at them And providing active feedback. So I think the setting expectations early on where we're not just siloed This is you know, this is the phase of work you're responsible for this is the phase of work you're responsible for It's constant everyone's active on the project at all times And then also the feasibility matrix making sure everyone's included in that so there's never, you know That doesn't happen just with a couple of people to everyone that's involved in the team and making sure you resource that team early on Um, so you know who's involved on that team. You don't bring on, you know a site builder or you know back end developer later in the project Thank god Yeah, I mean I'm not that still not that comfortable honestly, I'm standing up here because I was told I wanted I was to do it Because I can talk But I'm still not that comfortable and I think that's fine, right? I think the reason why a lot of people don't even engage with it is because they're just like, well, I don't even know where to start So for me, honestly, I at my previous agency. I had a software architect that actually sat down with me He literally helped like this glossary you see here was a result of the work He did with me and it was me being genuinely curious about it Again, one thing I've noticed on design teams is that we're just not actively curious about these things because we're never told to learn it So I think that's really kind of the gist of it is just making sure there's actually a couple of books from oriley as well That are pretty good. They're a little outdated. I would say but I think that's a great starting point It's called Drupal for designers too Yeah, I mean just get back in cms access and you'll see kind of like what fields look like things like that And I'll kind of bring more insight into what everyone's talking about every day Yeah, yeah, that's completely valid I mean I used to hear the word wizzy wig on all the time and I was like what the hell is a wizzy wig? I was like it makes no sense to me And I remember you know creating wireframes where I would have like all these elaborate like Spots for media types and then they just weren't supported on the back end So I think that's how I learned was when I got a lot of nose Like you can't do this and that's when I was like, let me figure it out The end of our time if there are any other questions Feel free to come up. I'll be at the booth Our tree booth so you can find me there if you have any other questions or just comments But thank you for joining everyone