In the File: Building a Design System for designers

all right hello everyone thank you so much for joining us today for our figment in the file series today's session is going to be uh building a design system for designers my name is chad i am a designer advocate here at figma means i get to work with all of you out there in the community i'm sharing tips best practices um content and material around figma as well as learning from all of you on how you're using figma and today i'm joined by lauren duxbury and julie lee both from honeywell and they are right here on the screen as well i'm going to pass it to each of them to say hello real quick here and tell you a little bit about themselves hi yeah hi everybody i'm lauren duxbury i was born in south africa and i grew up there and now i live in atlanta georgia uh we're honey uh where i work at honeywell and i've been there for two years i am working as a ux designer and a product manager on their ford ui design system team and uh now passes to julie yeah hello i'm julie um i didn't know we were sharing where we're from i'm from korea um i've been with honeywell for two years we started about like the same day um i'm a product designer on the design system team awesome thank you so much so lauren and julie they're going to share more of their story today on creating a design system for designers and before we pass it off to them to share all of their awesome content with you today i just want to let everyone know that today's session it is being recorded and we'll have this available on the figma youtube channel um if you have questions throughout please use the q a button um we will answer some of those questions as we go some of the questions we may save until the end where we will do a bit of a dedicated q a time if you have questions in the chat want to say hello now give a shout out on a great point that really resonates with you please use the chat to make sure it's set to chat with everyone and most importantly you know we ask that you please be kind you know we're all about um just being kind and inclusive here at figma if you have questions please check out figma.com code of conduct and with that i am excited to pass it over to lauren and julie to share a bit more about their design system at honeywell great thank you yeah i've really been enjoying reading where everybody is from i saw somebody was from portugal i went there a couple of years ago and i had the most amazing time i want to go back so shout out to the person from portugal yeah before julie and i get started i really wanted to get into the details about uh you know before we get into the details about the design system i really wanted to introduce you to what honeywell is and kind of what industry you're working in so a lot of you who've heard of honeywell might think about thermostats or air conditioning filters but honeywell is actually a really massive company and they serve us a vast array of industries uh everything from aerospace to healthcare to manufacturing and they're doing amazing things they work on flying cars they're creating quantum computers and if you think about your house and some of the smart devices you might have in your home like you might have a nice doorbell or a samsung smart fridge and think about how you can manage that through your phone or through your alexa device um and think about all these smart appliances honeywell's actually doing the same thing they're creating industrial hardware that's smart and it's connected and over the years all of these different divisions of honeywell whether it be in the industrial space or an aero have been creating software for their customers so that they can manage all these smart devices and this software as it's been getting built over the years has started to look and act and feel like it was from all different brands so back in like 2018 honeywell for honeywell connected enterprise also known as hce and the main goal of this organization was to bring honeywell's software products together under one brand so it can start producing cohesive customer experiences and drive innovation in the industrial software space um to achieve this main goal and this vision honeymoon connected enterprise needed consistent and modern ui while incorporating global standards in inclusive and accessible design and the only way to achieve that goal was to revamp or almost re-establish a new design and brand guidelines yeah so if you think about the whole goal of hce was to just take all these softwares and bring them together and so we had an engineering uh director and our ux director eric breyer and they they conceived of this idea of creating a whole brand new design system that could cater to this and so they got the budget for a small dedicated team of five designers two desert devs and one researcher so that included julie and i and we were all hired and we eagerly embarked on the journey of creating this new design system for this extremely complex global product space and this design system has to serve as multiple product teams all over the world and they're producing software that manages everything from maintaining the tallest building in the world to monitoring the parts inside an airplane and so like we said when hce was formed in 2018 we inherited some uh actually some legacy design systems and the problem was that some of the legacy design systems they didn't always deliver in certain areas and they didn't have meaningful timely releases so basically their releases didn't really meet the complexity of the needs that the product teams had and they weren't always on time um they didn't really cater to a healthy cross-functional collaboration between ux and engineering because the tools weren't really providing the way the way in which to speak the same language and then there wasn't really reliable collaboration between the core teams so the team building the design system and then the partner product team so those teams consuming the design system and so we heard a lot of negative feedback about those legacy design systems and what we really found from that feedback was it was kind of a result of two main things there was a lack of a core design system team so because there were these transient designers and engineers they didn't have a good rapport and then because they weren't all working together on the same products at the same time they didn't always have a shared goal and then this lack of attention and their transience also lead to the fact that they couldn't focus on their product and if they couldn't focus on that product they couldn't focus on their customer and that lead to poor customer service and so that means that their customers weren't really happy and so when we set out to build this new design system we knew we're not just building a ui library we're not just building some components and releasing them this isn't just about improving aesthetics and creating rules around icons and color styles you know we needed to make more meaningful promises to our customers and really start to gain their trust again and so some of those promises were making sure we had a dedicated cross-functional team making sure we were transparent making sure we had fast uh releases and that contribution was easy and just yeah healthy collaboration overall amongst everybody so if you look at this diagram it actually shows the complexity of honeywell and how many users we have as the 4g ui design system team so on our first layer of users that's the product teams who work on platform products so these are teams that build things like admin services and then in our second layer of users we have consumers of those platform products as well as our design system and they're the teams that work in industrial and warehouse and cyber and buildings and they're the ones who are building custo building the products for our end users honeywell's customers and one of our main goals is to offer superior service to all labels of users not just our end users and so whenever julie and i interview somebody to join the design system team or we talk about what it's like to to be on a design system team we like to make sure that people are eager to take on all the roles that go along with being on a design system because if you look at this you have to realize you're no longer just a designer you're actually a service designer you're in sales you're in marketing and you're in customer support and so those other roles require a certain attitude and willingness that not everyone is always thrilled to embrace when you embark on such a scalable and extensible projects you really need to understand the service aspects that feed into assistance success like what we've said before a design system isn't just a product it is a service as well because a design system only works when other teams actually adopt it so if we were to achieve this healthy strong ecosystem we needed a smart method and a solid set of tools so when we were planning to revamp our design system we looked to other popular approaches to help us get started um we ran with brad frost atomic design methodology because it made the most sense at the time and it also allowed us to break down this monstrous ginormous design system down to like a digestible and manageable bite size and we started with our foundational elements like typography shadows and colors then those elements go into each small component like a button then those small components are combined to form molecules like drop down larger components are called like organisms such as headers and they are built with those smaller components like atoms and molecules the idea is that all of the components can then be compiled like like lego blocks to create pre-built templates and or um even like entire experiences like login flows or notification workflows yeah and you know when you look back on this now we became a little too attached to this approach and a little too obsessed with this methodology and we started letting this methodology run our entire process and we started to try and explain everything through this lens and it it didn't click with everybody not a lot of people understood the analogy we had to explain it a lot and we pushed it way too hard and we actually started selling atomic design rather than our system yeah and it got to a point where we lost our track and started to confuse our own customers like our designers and developers and pms because we were breaking things down and said things like a helper text where input field label was also a component to fit into this atomic design model yeah so you know needless to say i mean you can all look back in hindsight now and say that wasn't the best approach but it did help us break down what we were doing and it didn't help us plan and so nyx came the tooling discussion so um like i said we had some legacy design systems and they were built in sketch and so our designers were hesitant uh to say the least to try a new tool you know they were really used to the sketch ecosystem they liked the plugins they liked you know how it was working for them and so also when you work in a big company like honeywell you also have to realize how hard it is to get new tools it can sometimes take months to get new tools approved and so the problem with sketch though when you're thinking about a design system and libraries you're publishing out to multiple people across the world and you're trying to have them all have the same files at the same time is that it didn't offer any cloud services and sketch at the time didn't have skit cloud and so on its own it didn't allow us to deliver on our promises you know which included that cross-functional collaboration with divs so inspect tools things like that and smoother governance and so then we introduced abstract and so in order to collaborate with our designers on a global scale because we had designers in israel we had designers as india china we had designers on the west coast australia we needed to introduce this functionality um through a plug-in or an additional tool and for that purpose we used abstract and abstract promise to deliver collaboration elements versioning inspect tools and all these amazing cloud services and we were like okay cool this is awesome this is all we need um this is going to be super easy and voila you know we don't have to we don't have to do anything else it was it was almost too good to be true and then once we began to actually build our stuff we encountered some weaknesses in the tools and it first started out with prototyping um since we were using sketch micro animations and any prototyping work had to be done in envision along with third-party plugins to be used between sketch and vision then envision had its limits on prototyping so some of the designers from the core team and designers consuming the system began seeking out other tools to create more realistic and extensive prototypes like adobe xd then we kind of really started to diverge and had design files all over the place and we had to make sure we provide multiple links in the confluence for documentation or in like jared tickets um also in teams when we're in group chats to make sure we were directing our cross-functional teams to quote-unquote right places then mira was introduced to us for like brainstorming like research purposes and things just got worse yeah so uh as you can imagine the result of all of this was a little bit stressful because um now you don't have any single source of truth and that's kind of the whole point of a design system so designers on the core team and product teams were using and managing designs across multiple softwares and multiple files then it ended up having designers recreating their own instances of design systems such as in like adobe xd to achieve the level of prototyping and collaboration they desired and this completely negated the concept of having the design system because now they were no longer linked to like a centralized library yeah and then you can just imagine you know we've got pms and engineers and designers all coming to these different tools so now there's these steep learning curves because everyone's having to learn multiple different tools and become adept and master you know at least five different tools just to create and share deliverables and because there were so many unique component instances when the design system team made a small change in the system it had massive downstream impact and made it harder for the design system team to manage and communicate all the changes but even if sketch and abstract had been our only tools we would still be like struggling because the branching and merging functionality was imperfect that we lost some branches with our most recent work and the files began to slow down a lot and we found out that the larger the design files got the slower the software became and we even tried separating out this like ginormous design system file into different smaller files but that didn't really resolve our issue then on top of that when a designer was on a different version of sketch or a different version of abstract all hell broke loose designer began losing hours worth of work missing sprint deadlines we were pulling all nighters while biting down our nails and watch this sink loader just like spin and spin and spin on our screens yeah and you know earlier i talked about one of our promises being visibility we were actually now really struggling to deliver on our promises because apart from anything else we couldn't communicate properly and our tools didn't allow us to communicate effectively we couldn't communicate things through sketch and abstract and so we were trying to send out emails and send out things on team channels and these posts were often overlooked and then things just couldn't get any better because when covet hit we were all separated working from home like everyone else the sprint velocity and deadlines became very crucial and bad tooling definitely exasperated the issue with the quality of design while the quality of design and suffering so we were no longer able to collaborate as a team like when we were in the office together meaning that our design reviews were a bit more challenging than before and our designers all right our designs were anything but harmonious and systematic so to kind of put you in our headspace at the time um if you go to the doctor and give you one of those pain scales i like to say you hurt your ankle or something you're supposed to tell them where you're at you were at sevilla you were at the crying league face like really angry place and um you know it was around this time that uh julie really got fond of these uh angry panda gifts they were kind of on repeat on a daily basis and um they kept us chipper but yeah we had some we had some bad moments i specifically remember a design review with my design director and i'm trying to get sign off from you know friday evening at 6 pm and monday you know next tuesday i've got a sprint deadline coming up and it's you know i've got a ton of work to get reviewed and and all i saw during this review with my director was this spinning wheel of death and it just kept going and going yeah i i definitely remember that because i was in the review as well and my hands were getting really sweaty as the wheel was spinning so um i was just like wondering like how you felt about that yeah about the situation yeah it was embarrassing um it was really frustrating and it was frustrating for him you know and i just i just remember feeling really angry because it was so not worth it because our tools weren't even amazing so like what are we even doing here this is the golden era of ux this is our time to shine and there must be something better out there for us and so the following week i thought i'm not going to complain about this anymore you know it's going on these years i need to actually show numbers and so what i did was i started measuring my time on a tool called toggle and then i would measure how much time was spent on downtime like waiting on abstract to load a file which would take an hour um redoing work because abstract had lost a branch um all these kinds of things how how much am i troubleshooting and helping people just use sketch and abstract and then i sent these charts to my manager and my director and that's kind of when things really clicked like okay the designers aren't just complaining here this is actually costing us a lot of money and so that's when they said okay let's let's start the bleeding and then i think after some time passed um after we've adjusted to this new work from home situation the team conducted some interviews with the product designers to gather insights into their preferences for the design tools because we just you know couldn't take this any longer we were literally like ripping our hairs out so we also started chatting to other ux friends outside of honeywell and other big companies to like talk about like what they were using at the time so the core team and the product teams worked together to create this list of features that were important in our next tool for consideration adobe xd was already being heavily utilized and was well liked amongst the bangalore team our india team their biggest concern was having a tool that didn't offer an offline mode because they often had this internet connectivity issue and we also had a group of designers in the states that had previously used bigma and were very very very passionate about it and sometimes they would get in trouble for using figma because we were trying to make designers use just sketch and abstracts and then we also had another group of designers who were seeking a faster advanced prototyping tool so they were really loving actuar so after a lot of discussions and consideration two contenders rose to the top figma and adobe xd xd was very popular with design leadership because it was already accounted for in the budget and included in our adobe licensing this was a huge consideration during this pandemic because budgets were being slashed if we were to sell a new tool to leadership we needed to ensure it really really was bringing extra value and the core team also needed um the real-time collaboration because the work stream of design system were so co-dependent and tightly knitted yeah so so after the core team completed an evaluation of those two tools um that was followed by an evaluation by the external team so we picked people in the external teams to actually go in and create trial products in each tool and then they could taste things like creating vectors and the collaboration and the sharing and then some of the advanced prototyping features and i would say figma really went out here because they did a really great job of supporting this whole evaluation process and they helped us think through the more complicated scenarios and and things like how do you set up specifically for a design system file and how do you really taste the capabilities of this tool versus just kind of doing a very basic case and then the secondary layer of this as the core team is what we needed to do was really evaluate how learnable is this tool and i would say we quickly saw that teams were able to adapt to the figma environment much more easily than the xd environment i think people that came from graphic design backgrounds and were really used to the adobe environment preferred xd but yeah the thing that was common amongst amongst both of them was that they supported both platforms you know windows and ios operating systems which was big um because honeywell has a lot of people that use windows and so we can't always rely on something that only caters to mac users um i'd say where xd1 out at the time was with its prototyping and interactions they had states and autoanimate and all of that obviously figma's brought that in now and once again figment did an amazing job of communicating that was on the roadblock so we weren't really worried about it because we knew it was coming and then figma totally went out on the inspect and the dev hand off tools that totally surprised xd in that area uh one thing i will say if you are in a big enterprise organization like ours and you cater to really really complex products that are really data heavy and rely on a lot of logic this is something where we're not really seeing um a great advancement in either xd or figma we're we're still struggling with that because a lot of our products are very daughter heavy and we actually need those kinds of advanced prototyping tools so we're hoping figma delivers that in the future um so yeah so another part of the evaluation we did was an actual evaluation of migration so how long is it going to take for us to to to move our files over and how how long will it take to migrate from sketch specifically to a new tool um what's it going to be like to manually fix the components once they're migrated over what happens to the vectors and the shadows do they come over correctly no they didn't they did not um you know what's going to happen with things that are connected to a central library like our colors and our type styles are they going to still be linked no they did not come overlinked and so what we realized was that um in this migration evaluation is that it helped us create a timeline for how long this was actually going to take and it also helped us realize it's not a migration it's more of a recreation of the libraries and i think this was where our management started to step back and then get a little bit recent again and then they saw because they saw costs associated with the time and effort it was going to take and it was really a tough pull to swallow for all the teams as well because we had literally just asked them to all move over to our new sketch libraries and now we were asking them to move again so it was a hard sell uh but yeah it's migration's a misnomer it's it's a recreation if you really want to take advantage of figma and really immerse yourself in the whole sigma environment um and something you really do need to factor into your cost and and figure out how long it will really take for you to do it properly and to chime in um migrating a whole design system and migrating product design file can be a little bit different um a design system may require multiple layers of work such as like making colors styles typography and depending on like how big your design system it can get even bigger and you can also have like one component affecting the another or having one component being nested into another and this can lead to having quite a bit of design files in order for this design system to work as a whole ecosystem um while a product design file can have its own little world per file so you can have like a page dedicated to uh master components without having to create multiple files like design system and just like linking them linking them together within one file and this is just like purely out of its my experience because i also had a time when i was working on a cloud service product so that's just two cents for that thanks to me yeah sorry so for the last part of the tool evaluation uh we had to consider the new tool at scale and we learned it in a hard way um in the past with other tools we had so many frequent incidents where we were losing our work like we've stated before and i mean at first like we did not expect this to happen i don't think anyone would um second we also never tested out tools beforehand with larger files and larger teams and i mean larger teams as in a lot of people and also having teams in different locations so as we were having some publishing glitches and while we were losing our work our product teams were getting impatient with us and i'm sure they were sending angry panda gifts to each other whenever this happened and when they're getting notifications on design system file about any updates and changes they were a little bit confused because there was no clarity on these updates so we knew we needed to test any new tools at scale and ensure teams from all over the world to test it out in their own environments and also test out if it can better our communication between teams yeah so you know once you do your own evaluation if this is something you're embarking on um i'm sure you'll find your own things unique to you but if you're ready and if you're looking to make the switch and you just need to kind of make the business pitch i think we can help you a little bit about how to think about it so the first thing for us that was totally easy sell um our our ceo loves design and so cute her name's q and she's she she already knew about fredman so that was great that was first easy solve for us but not everybody has that right so you really need to start talking business and the easy thing for us was the cost cutting so like i said we had over five design specific tools per designer and we were now able to cut that down to one so that was around a cost savings of 500 per designer annually so if you have a team of about 40 designers that's going to be around 20 000 per year your design team is saving just on the designers licensing and that's not even thinking about the view only or the limited access licenses you also have to provide for people to view your files the other way you're saving on cost is because you're actually reducing time spent because you're not using multiple tools and having to replicate work across multiple tools and then the other way you're saving is because um the cost of labor is is really expensive and when you have four different design tools that you're all having you're having to use that's that's a lot of training um on all these different tools and then for us we made the argument that we could stay in one tool for all collaboration and peer review the design system designers could collaborate more easily with other product designers and the designers consuming the system had greater visibility into our files so we were able to follow through with comments and resolve issues and bugs way faster we even uh started chatting inside the files so we were cutting out teams and multiple designers could seamlessly work on the same file with no lags as if we were in the office together so this and this collaboration was not only just amongst designers but also with our pms our developers and our researchers they were all able to come to one file that had all the wireframes and prototypes and everything and allow them to leave comments directly yeah and you know i also think back i think about you know some of the problems at the time of using sketch when you know i said when you work at a big company like honeywell they often have these procurement teams to get your licenses and so our sketch and envision licenses were very very heavily controlled by the procurement teams and at one stage all like four four or four or five design systems designers all lost their licenses at the same time without warning and one of our designers without a sketch license for over a month and so there i was sending emails to the procurement people and haggling about you know this you get to say she's 40 an hour and now she's wasting time and she's not designing that's already the cost in one day of one stitch license and you can't get these sketch licenses and so now i'm having arguments with procurement people and that's like not my job you know my job is to worry about honeywell's customers my job is to enjoy being a designer enjoy using my tools and loving what i do and by alleviating all these roadblocks and by taking away those conversations with us with a tool like uh with a tool like figma where you control the licensing and you control the access and everything's under one roof and it's so simple um you're making just the whole environment for your designers beta and when your designers are happy you retain your designers and i think we all know at this moment in time it's really important to to think about retention in your teams and how you can keep your teams happy um yeah so i just kind of want to show you just a snapshot of our live scene here you know this is not everything of course we've got a couple of themes we've got a huge structure but really what i want to end with um you know before we get into questions is just to say you know thanks to figma our design libraries have have really evolved and matured this year we uh have a trusted controlled set of plugins versus all these weird plugins that are updating at different times and we've been able to improve things like accessibility they've got these amazing accessibility plugins to test for things like color blindness and the collaboration features you know commenting and live viewing like i said have given us that greater visibility and helping our teams communicate better and they've just allowed us to share more easily with our partners and we're conducting way healthier critiques and way healthier peer reviews and another feature that has really impacted us is the ability to publish assets individually um even just like couple days ago we wanted to fix a small thing on the component from the design system file or uh we wanted to restructure tooltip components and we were able to make our changes and publish parts of the design system instead of republishing the whole file over and over and controlling publishing on that level has been a game changer and we actually plan to replicate that model with our engineering versioning and publishing so that's another area we see maturity where design thinking tools and design processes are impacting our engineering team yeah and you know if you're at a point where you're still deciding on what tools to use i really want to emphasize that you need to think about not just what's important for your core contributors so the people on your design system team but think about how the tool is going to impact all level of all levels of your users and all types of users and figma might not have some of those advanced prototyping features we talked about but where they lack there we really feel like they're making up for in a sense of community and and the sense of community their tool fosters and figma has really allowed us to do so many more things so much more easily inviting contributors and reviewers training ux's even training non-ux people like pms and researcher you know non-designers and figma has been instrumental in driving our enhancements because of all of this transparency and how easy it is to contribute we're now making enhancements so much faster and for your design system to be healthy you need to make enhancements quicker and so yeah we're just creating this really solid environment and that ecosystem we're talking about and able to mature our team as well and so yeah as you embark on this journey if you're if you're thinking about it right now just think about how your tool no matter what you pick even if it's not figma think about how it's going to impact all of your users all those levels of users we talked about yeah so uh that's kind of everything we have to say about our journey and how we chose figma and [Music] thank thank you so much for listening and we're we're happy to dive into any questions or actually dive into the files if you all would like any final thoughts from you julie that was it great thank you so much lauren and julie you know a lot of uh a lot of great content there and yeah i know a lot of folks are excited about some of the learnings there um you know one thing that you said that i think is a really really great point is that um even in the beginning when you were setting out to define your promises to teams you know recognizing that building your design system it wasn't just about creating components and rules that it's really about that entire ecosystem on you know how to better enable designers across a worldwide company right um so we actually had a question come in that i think really ties into that around um as you're defining those promises you know which piece of that was the hardest to deliver on and you know how did you work through finding a solution for you know the biggest challenge as a part of that sorry i have two little dogs in the back i tried my best i closed all the house they still um for me it's still hard we haven't overcome it i think it's a constant challenge and i think if you're speaking to anybody in a design system and they're saying that isn't a challenge i don't know how honest they're being with you because everybody i've spoken to says governance is the most difficult part um i think it's like we say communication is so big and we're still struggling with that a little bit i mean not every designer is tapped in all the time and seeing what's going you know they've got their own stuff going on so even when we make up we publish something we can write notes we can tell them exactly what's happened they're not necessarily going to read it they're sometimes just going to click out so you still definitely want to try and have those multiple channels of communication to tell people what's changed um something that we've that i've learned really helps us having a lot of one-on-ones so i have one-on-ones with all the designers um and they invite me to their reviews so something that's really worked well is we can kind of spot patterns or spot things we need to work on before they've even asked for it because we're invited to all their reviews and so it does take time um and you really have to invest in in that kind of one-on-one with them but it's been really helpful and it's really helped us mature and once again that's how figma's helped us because we can kind of just get quick access into all these files and they can allow us in and kind of we can maneuver around in the air and comment and it's been it's it's really makes it seamless but i think contribution is the hardest part um teaching people how to to design for a design system is a different way of thinking but it's been really fun because when you invite people in to design for your design system you help them think in a totally different way and when they click it's really cool because at first they're like oh this is so easy i'm just going to create this component and like i don't know why you guys take so long and blah blah blah blah be like okay okay and then when they start they realize oh this is quite complicated you know i have to think about all these little things and how i structured this so it's nice to use and then you also have to kind of retrain the brain a little bit because like we said it's service minded so people are like oh well i'm going to create it this way because that's easy for me or i'm going to create it this way because it's easier to update in the future for me um but it's a balance you also have to make sure that that component works really well for someone and how is it going to be the best theme how are they not going to break it how are they just going to be able to use it without you having to teach them how to use it all the time so i don't know what about you judy what do you think what's what's been the hardest thing for you to deliver on um i think yeah i would i would agree um it's about teaching them how components are supposed to be used but at the same time for the design system team we need to make sure that we give them enough flexibility but also some guidelines or like rules around components so i would agree with that sorry lauren we have two but that's why i'm so used to calling our thoughts you know i i love that um you know it's really when you get into building for a design system it really does challenge you to think more holistically you know you're not thinking about your singular you know product feature or product area demo you really do think about that impact as it goes across you know all areas um you know and even as you have the underline on your slide here you know your design system it's a product and a service yes i think that that's you know it's fantastic to think about it's how you can help others through your promises elevate and just become more familiar with creating a design system for all that's a really good point and i just want to say don't be scared to get involved in other people's products i mean sometimes i definitely get overwhelmed because our products are so different and solving such tough problems it's very complex um but you really need to get in there with your designers and trust that they understand their problem space and trust that they're going to communicate it to you so you can really deliver to them yeah now and the communication piece you know saying that that's a huge part of it um you know another question i think really ties in to that is around you know keeping folks who are in the cross-functional teams you know how are you keeping them on the same page with the design system team as updates are happening um you know just so they know what's going on perhaps they are also making contributions to the system you know what does that communication tend to look like yeah it's tricky um once again if you're being service minded you're kind of doing whatever they want um so it's a bit of a balancing act some designers want to hear about things on teams some designers don't want to hear from you at all they just want to get their updates and see what happens um some designers want to have a lot of one-on-ones i had some designers who didn't want to go and learn finger on their own they wanted kind of to be hand held so i started doing like figma fridays or um these sessions and so it really just depends on the individual i'd say and you need to be flexible with that because everybody learns differently everybody learns at a different pace and everybody consumes information differently and we can't say it's a one size fits all you could have a perfect communication strategy which we don't uh i'll be the first to admit that we're figuring that one out uh but it doesn't mean it's gonna work for everybody you know just like some people like to consume their news through twitter and other people like to consume their news through bbc and everybody's different yeah awesome so another question um i love that you talked about how when you were first building everything out you know really following a lot of the atomic design um methodology and you know we see that with lots and lots of different teams you know everyone really will reference that with their initial approaches and we had a question come in and i thought it was really you started to touch on it where you got to a point of realizing that you were selling more of atomic design than you really were your process and how you were looking to build your governance model and you know you drive your adoption you know how long was it really until you kind of backtracked you know did it cause you to have to um can restructure redirect any of your goals or promises along the way yes um it kind of dawned on me that we were becoming too obsessed when we were trying to look at the information architecture of our documentation one of the pms in our company had asked us to help her better understand this again to restructure our components under molecules organisms templates and atoms and this other designer and i was like what what what why would we put our components in that structure that makes mistakes and she's like oh but this is the way you guys are talking about it shouldn't you make everything seamless so we can understand and then that's when i realized we've gone way too deep with us we've been talking about this atomic design way too much and then the other way we realized was that when we started bringing everything together like julie talked about we're all working apart it's hard to communicate with everybody at home during covert we started bringing everything together and it all looked discordant because we were working in sprints and working on these neatly separated components and then they weren't coming together well and that's yeah that's when we realized oh this has been kind of detrimental and then the other thing we did was we were actually having dev build in this order versus the way that maybe they would have liked to build and that's kind of more of a waterfall approach and it wasn't giving our other product teams what they wanted fast enough they didn't want things in this order they wanted things in bigger chunks so that they could start using the design system you just spoke to a great point there you know around the how it's built out on the code side of things and you know as you're doing your migrations and you know wonder if you could share a little bit about what that collaboration looked like with the engineering teams as your assets were being created yeah so we have a pretty unique situation just to be completely transparent we actually i would say this atomic design approach was so harmful that our engineers got taken away because we weren't building fast enough and we weren't delivering to teams fast enough so what happened was is they put a hold on the engineering side of things we got up to molecules and then they put a hold on it and so now what we're doing is um re-skinning one of our old design system components sorry not components the library we're re-skinning it with our new design system and so what's been hard there um as as we were migrating the engineers don't know where to look should we go to figma should we go to confluence with the documentation should we go back to abstract and sketch that was tricky because we also had a product team that was really heavily relying on us and so we were trying to migrate and really partner with them at the same time while they were re-skinning this old design system so it was that was that was tough um i wouldn't say that was an easy process but the engineers are really really enjoying figma and the inspect tools there we're finding that before engineers preferred going to confluence which designers hated using and then they might also have preferred going and getting really really fleshed out documentation in uh nero and now they don't feel like they need those tools anymore they just go to figma so as we've kind of neatened things up and streamline things they've been enjoying the inspect tools a lot awesome so another piece that we touched on there's a question that folks had around you know honeywell obviously a large very global organization you know any lessons that you've learned about how to build localization into your design system assets to provide for that global audience you know any any tips or best practices that you've identified that's that's a great question and really timely so we um i wouldn't say we're very advanced they were trying very hard to be because it was kind of one of the tenants of our system so we do think about how a component might resize so definitely using order layout so that say for instance a language ran from right to left or the words in the language were longer you're making sure that those components can work um in different directions and for longer strings so that's kind of one of the more basic things we thought about and then just recently i spoke to somebody um in honeywell and he was telling me how amazing figma's been for him and his team because what they're doing is is they're they're creating with with the design system they've created another kind of theme on top of that which is all in mandarin and they're switching out libraries seamlessly using the library switcher which i haven't actually tried yet using it he was just telling me about it the other day so that i thought was really cool i haven't actually watched the full demo of it but it's really tiny that you asked about that and if anybody wants to know who that is i can i can forge you his information and he'll be able to show you his demo awesome and i think also going along with the internationalization side you briefly touched on some of your plugins some of the accessibility side of things now i think that that's a question that you know we hear a lot from folks who are building out their design systems and how can they factor in elements of accessibility um into their assets and you know whether that's just the library assets used it's in their documentation et cetera you know really how have you approached the accessibility side i know we've had a couple of questions come up around that i think that's really timely around you know even with internationalization and how um accessibility is worldwide yeah i don't know can you all see this file yeah sure so the great thing about um figma which i really love and we touched on in our talk was that um you can set up these approved plugins if you're in a big organization like honeywell where there's um like i said they're quite strict about security and procurement especially when it comes to intellectual property and so you can set up these approved plugins and so what we have is these really cool ones like colorblind and what you can do with a with a plug-in like that is take a whole component or a design and then actually render it to see people's different um what people with different types of colorblindness would see and so that's an added layer of how we're trying to cater to um people with with different types of needs it's not necessarily part of wicca guidelines or something that we have to do but we are being really careful about that um julie i don't know if you want to add to that at all about how we're catering to accessibility through figma if you have anything uh through figma i don't really know anything other than plugins um but we did we have we have like our dedicated accessibility researcher so she's our basically our guidance and accessibility so outside of figma it's more like working with her and doing her own research before creating components such as like checking color contrast or like size font sizes and things like that yeah one thing i will say is we don't really rely they give us kind of a starting point but we don't rely on plugins because there's things that are technically accessible and then you when you actually do the usability testing we saw this a lot like we had a red and an orange and the orange was this really dark amber not necessarily something that we liked but it was technically accessible it had enough contrast and it was fine and the colorblind checker that i used the plugin everything was fine but when we actually tasted it with the these users even people that didn't have types of color blindness they couldn't tell the difference between the red and the orange and that might seem really silly to some designers like say if you're just designing a music app or something like that but at a company like honeywell if you're a pilot and you've got an ipad strapped to your leg and it's going red there's red stuff it means something really bad is about to go down and so you have to be really careful about how you use color and obviously your pilot's not going to be color blind but there are there are other people in our in our user community that could be like somebody that manages a factory um or a large building and if something's red and something severe they need to know and they need to know now and they can't think it's just orange or green because you know it's important awesome well lauren and julie i really want to thank you so much for sharing you know more about your process and you know how you were able to take your design system and you know better tailor this for designers you know that entire process you know really you know really speaks to how you know design systems have so many different pieces to it you know it's really that iceberg right there's so much underneath the surface there and you know it's really really great to hear about how you approach that thank you yeah great so much awesome so thank you all so much for joining us today um please check out uh figma.com events where you can see um any future live streams that we have coming up and if you have some suggestions or ideas future content where you would love to see um please feel free to reach out to us at community figma.com once again lauren and julie thank you so so much for being with us today and for sharing thank you so much for having us this was really fun and goodbye to everybody awesome goodbye everyone thank you

Channel: Figma

Views: 3,500

Rating: 4.7852349 out of 5

Keywords: figma, design, product design, tips, tricks, UI design, ux design, app design, figma design, design for figma, Honeywell, Design System, Design Systems, In the File, Atomic Design

Id: 3FzKsA7e2Rs

Length: 55min 32sec (3332 seconds)

Published: Tue Oct 05 2021