My Dear Friends of Figma in Today’s session is in the file from design to code scaling design with collaboration and documentation i’m very excited i haven’t seen too much of the presentation but i know that the wix team have been doing some awesome awesome work and i can’t wait to see what they’ve been up to today speaker is thomas he is the ux lead at wix.com he’s.
A great guy he’s really talented he’s also an expert figma and i can’t wait to see what he’s up to so i’m gonna hand over the dumbass to get started please feel free to go and share your screen right so okay before i share my screen let me get just introduce myself a little bit more so.
I work at wix already for six years and i’m based in vilnius lithuania uh this is where i’m streaming this from and yeah i’ll be talking mostly about the handoff uh our work files to developers so let me share a screen this is really nice by the way like it.
Helped me out to test some uh unexpected things just because like once i clicked to take a photo it crashed my figma so i’m really glad that it happened before starting this presentation.
Not now so okay so what we agreed on today to to speak about is mainly three things a collaboration nuances about when we start from a small team and then scale to large team unfortunately my colleague couldn’t join me so i’ll be touching only on a high level this point today but i promise i’ll touch on the.
Product side and then show how different teams work at wix because everyone is individual in our company another thing is uh important aspect that how we communicate to the teams about the changes in design systems and about the braking changes that we.
Make in the library and how they have to deal with this and the last thing is just handing out the products to developers in two stages first once we design a component in the library and the second thing when we design a product and then we want we want to launch a product so this is just a brief agenda about it.
So i don’t have slides specifically for today but i have a bunch of files and then i have this just a timeline it’s a oversimplified it’s more details in one area where i focus more and i think it’s important for today there are fewer and missing some.
Steps so please don’t judge it uh too hard uh it’s it’s yeah it shouldn’t be um part of today’s uh focus either way on that but i just highlighted the points that matches our work together with figma tool and if i zoom out so i’m not really sure how well uh you.
Can read the text but i’ll let me read it for you i split it into two zones so the first path is when the new component is born in a design system library and then when we have this design system library which is in the middle here then product teams takes these assets.
Into their product and then they build their own product and they just do they user flows and then they do some handoff files then follows the development product ui launch and etc right so let me start from the beginning so we are here at the start this is.
Where i work i work in design systems team and my um my interaction together with the product teams usually happens at this stage that there is some kind of a reason to make a change in the library so it’s a either it’s a.
Strategic move or it’s a product need that for example product design something and they say hey this library doesn’t support this kind of a button or we just say that we have way too many buttons we just need to optimize it and then refactor the library and then just drop to some features maybe.
Rethink them different way so what we usually do um we have like long process in between just to try to find the real solution um but the the outcome itself is communicated in the uh design specs this is how we call it but like it’s a specification file explaining how.
The component should look like and then it should be clear to read for developers so this is the the main outcome so what i’m going to share today i’m going to share what we have already most of the files i must say they were imported from sketch this is where we used to work in the past.
So they might um they show like this one it’s a i’ll i’ll explain what this is it what it is um but it shares a lot of information but it’s built not using any of uh figma.
Features while the next example it will show you know how we adjusted this one and the future changes right now actually are reflected with all the figma benefits all right so what what this file contains um it’s a component that it’s a atomic item this is like what we used to call.
Ic which is called the internal component it’s not meant for the end user but it’s usually used for building other components such as table lists and also nestable list which allows to drag and drop and nest items within itself just on these components here i noticed.
On the introductory page you had table list as one word um i think it was using camel casing or pascal casing or something on the intro page is that a naming convention that you use for your components yes so yeah so this like.
I see it even doesn’t have any spaces so we just decided to it’s very interesting um and then maybe i can even tell how one of the figma features helped uh out at least for us to get rid of our past workflow so in the past we used to index all of our components so 1.2 1.7.
For example the first number means which failing family it belongs to whether it’s form elements table lists buttons etc um and and then we had the library um of actual components and then we have a mapping where you know developers can go look and then find based on this index.
File the downside of this indexing is that it’s not intuitive like numbers they don’t mean anything you know when we just read them so somebody has to memorize it and and then we used some plugins some that you know once you click it so then you can inspect it also zeppelin supports some solutions we use that as.
Well uh but that you know came right just after we introduced this this uh index file like we used it for a long time and what we do right now so i can just go back a little bit here and then show.
Maybe an input file which will have wow sorry i cannot click on this url because both of these they are too close i’m sorry i have to do this um i’m very sorry if we have graphic designers here that who are really picky about kerning and then.
Bleeding leading but yeah i just have to make the light height higher to click this so okay input it’s uh it’s also like you see on the left it shares the all spec that was imported from sketch and then the right one is using a template that we built inside of figma.
And then right now we are rebuilding sometimes once we need to update and introduce a new feature so then we introduce this new feature in this new template and then also we take some time to rebuild all the past examples so just for storing so most of these examples if i drill in.
They contain the actual component like we don’t detach it here and if i go into the inspect mode it should be that at the still thinking at which level oh no it does detached okay so let me think okay so no worries i’ll just what i’m going to do yeah this one exactly.
So how we share the information with developers right now instead of these index names we do two things first we use the area for the description to share the snippets of the actual code and another thing is.
This component url is also very handful that once you click on it it opens our documentation which is public or ebook oh yeah and it is broken there is a reason like we’re fixing it um yeah i’m not going to go to the.
Details why it is but it was leading a while ago and it worked here um and then yeah a developer can just go into this and then read about all the properties that we share and just go into the api area and then read about the available.
Properties right i’ve got a few questions on this process so the field where you paste the code snippet who who is responsible for updating that description field um you mean that once we change the api or just when you’re building components.
Who oh the design systems team specifically that adds the snippet or is it an engineer who is responsible for this yeah so it is the designer who does this um so we have some designers who cross discipline uh professionals i would call them like that.
And so you know they feel comfortable with the code and also with the design so they can do this job um and uh and the downside right now is just that it’s all manual so you know if we change the api so we have manually to update it.
And then we’re still playing around like this is quite recent i must say because we migrated to um the figma platform and all the library migrated only this the last summer so we’re still in the experimenting mode.
So i’m jumping through many topics but yeah i can lead to another thing that if we want to continue on this what we learned about this because we run a usability test with some developers just to understand how they interpreted it the storybook library is that a designer maintained or is it developer.
Maintained both yeah so um this is yeah where we contain basically all of our components um so it’s primarily developer oriented but we just noticed across the time and.
Usability testing that bunch of and then through interviews that a lot of our designers just prefer to go there either way because they want to see the end result so then what we started doing like we started combining this one so it’s still like for a long time it wasn’t maintained.
Because it was purely engineered for engineers and nobody cared that much as as as of a representation object but right now as we take care of more of it so the whole form family for example it’s it’s very well.
Documented and then we have a format for this that everything comes in the same structure and then we just have the rules how we define things so every example it talks about a specific property which is meant for developers uh sometimes maybe it’s even too simple.
For developers because it shows just in this example it talks only about this small segment um but it makes it very clear to understand like how it works and and then on the top of it like what we had we just add a very small uh designer guide that.
Where each parameter should be used so usually it’s valuable both for a designer and the developer because the designers they’re looking for these questions and developers usually as just a gatekeepers because developers who care about design they usually say hey i read this in our documentation and then you.
Shouldn’t do that and then it backfires to designers as well which is a win-win situation right thank you i know i derailed you a little bit there from the original file so feel free to jump back yeah that’s true okay so continuing on um on the inspect.
Area um let me short just share share with you just two slides um here in the later step where i added it just i called it a holy bucket of components which is just a design system library.
Um yeah so just recently i think yeah just it was just the last quarter we were testing multiple things but including also the figma and understanding how um.
How developers manage uh to can i zoom it in it’s uh the slideshow top right yeah so let’s hope we see this so the experiment was like this it was a usability test that we gave this sigma.
File where we’re like very clear areas this this and this component then on the top there were examples that you know what we expect from a developer to respond and then we ask like could you just identify you know what snippet should be inserted here and in here just.
To get the right result and then we checked how they perform so they performed you know they achieved their results in some or other way but what we learned that everything that we um let’s zoom it out again um everything that we expected for this.
Site snippet and then view documentation area that will be super beneficial for them they didn’t use it at all at least these six people like why that happens we don’t know yet probably because like this is a new tool so they’re not used to it.
And all of them they assumed it’s meant for designers and but not for developers to view documentation uh so it’s part of a communication i guess and then just overall just involvement in our company um and and yeah we learned some some things that uh like as we saw that we assumed that this will be that the.
Number one feature to help out to solve this apparently it isn’t um and it’s it’s not it’s i’m not you know phrasing it as a bad thing i’m just trying to phrase it as a fact because in the end like all products.
Are still developed and then they’re performed well so it means that people still manage to achieve their things i really liked how you basically done a small research program to analyze the handoff process and its effectiveness it’s really nice approach yeah thank you um okay so.
Where i should talk next so i guess looking at that that situation there where we had a proposal by the design systems team um and it didn’t maybe didn’t quite work out is there something you do frequently where you test ideas out between design development the handoff process to understand its effectiveness.
So yeah we do it not too often but we try to do on some areas uh at least like once a quarter or at least half once in a half a year and sometimes like we don’t have these recurring things that okay we’re going to test this exact feature every quarter let’s.
Say but what we do instead that we usually we just uh identify some pain points and then just before right jumping into solving these pain points we try to just zoom out a bit and then try to really understand the full context like um maybe you know the cause is not what we assume but.
There may be way more reasons so then we usually take uh slightly broader research which includes this area like in this example and then we learn even new things that we were not aware of what does the future look like for this particular stage of that handoff cycle that you have been testing.
Oh the future that we are working on oh future um okay so it’s uh we’re not planning to abandon this uh this this uh url button and then also description i still believe like it’s a great feature.
It’s uh we’re still trying to identify and then probably will test it again and check whether people get familiar with it and then if it changes over time so then we gather more data and then in meanwhile like during this usability test we learned other things where we can act now and then it’s very clear like what.
We need to fix to improve so it touches the storybook that we use other parts and we’re focusing on that part for now with regards to the collaboration between design and development on the figma side do you encourage people to invite developers into the files to to inspect things and get the assets and.
That sort of thing out of the file or is that handled slightly differently i know you’ve got the storybook installation for components how does that translate to things like user flows and even testing our design systems yeah so so this is this depends uh per team so i can share a few files and then i think hopefully it will answer this question.
Um let me jump back a little bit to this file where i started at so this is how we hand off design files for developers who are making new components and then this all file it’s segmented like this is very complex file by the way uh.
Sometimes like we have way smaller ones but it all of them they share the same structure at first like we just share the main properties it might be not all the properties that components have but they are all related to layout and functional changes for example if allows to control number of columns.
If allows to control the width of the columns and then what controllability would give alignment of the columns uh in this case if it has a draggable or or not feature so then in this case it enables this icon and then once we scroll down like we.
Usually communicate if it’s we’re using some other components inside of it so we just highlight with these annotations and the most important part is this constraints area where we just showcase according like what parameter is turned on or off how.
Its layout changes and this is like what we learned over time that highlighting with these zones that i must say um i took it from chrome and then you know once you inspect code in chrome and then it highlights the areas.
This format it seemed to work best for developers to interpret uh how component needs to build needs to be built um and then it takes the fewest steps in the qa stage so yeah so this is like this is how we work in in design systems team but.
Let’s see you know how we work in uh product teams so once product teams they take uh our components i have two examples yeah let’s start with the simple one and i split them into two stages that product flows and then the handoff but basically.
What i learned that teams they they usually contain both of these handoff and then flows in the same file and then in this particular file there is just a handoff because it’s a very very simple product but it still shares some interesting stuff um yeah so in this one the end result is just this settings page.
Um let me zoom it in a little bit yeah um let’s just hide the side panels um yeah so you can see a better view it has multiple cards and then controls in each card.
So what forum team does and how they work and what i really like about this um they take our components and out of these components they build their own blocks usually the features that they repeat in the flows so they don’t have to recreate them all the time and they just have these small buckets of features where they usually.
Align them with the ux writers just finalize then they have this one one large component that contains everything in cards and then in this particular case i think they used a template of page layout so they just inserted all this large component.
Into this one maybe we can even see um so okay page moderation and p row um it seems like it yeah it’s replaced i’m not really sure like in this particular case i’m not really sure you know why why this stage is created in.
Their case but i see that this is a detached template of our of our page so they just adjusted it and then inserted that one so it’s a very simple example but it shows the basics how we work in the products together with the.
For the design systems well i’ve got a couple of questions on this one actually sure if you zoom back up to the components part of the file um into into this one or the moderation settings file yeah back up to the components there so it would be great to get some.
At least your perspective i think i know the answer but why you think why you encourage people to create components in a local file instead of having these components in the system oh yeah so i cannot answer probably for all the teams but i had this specific conversation with some.
Of them and what i learned is that you know majority of the teams they have design systems file in their project i mean just for their product which is irrelevant for.
Global just assets design system that i work with um but usually they they post a and and publish new components in there only when new features are published and and developed already while in this file it’s usually the features that they’re planning to be planning to develop.
And it still it still doesn’t exist and it might change in there just in the middle of it so what they do instead at the beginning they they host all of their components locally for this file means that this project and then once this project is finished and the feature is published so then they just copy paste it into their main design.
System library basics create components ship the feature move the components to the library right yeah exactly perfect and on these components as well they’re i’ve cut their nested components there’s i guess we’re looking at organism level.
Structures here how does a designer know that it needs to be 24 pixels spacing in there yeah good question so we communicate this one through design guidelines design guidelines are just written documents which designers have to.
Read so at the moment like we rely on just trust and then professionalism so just people know that okay we have six pixel grid just in our case and then we use the spacing right um i think trust is is super important in all stages of product releasing and i think um we can all.
Learn a lot from that simple phrase is that that’s true a lot of the time we we hesitate to trust that the developers will implement the right thing but as long as you’re all on board as long as we have the documentation somewhere that somebody needs to be reading and i think we can all place that trust in our team and secondly to this one.
Um when it does come to the library handoff i guess process to you how is that communicated um could you repeat the question so this component for example let’s say that ultimately it needs to be in the design system it’s the process going from local file.
Local component publishing and then you need to implement it oh yeah so in this case uh we have a pipeline of our process that we have a dedicated request form where people can submit their product reviews so.
Usually like all these new feature requests they occur from new product features um so once they work on this they submit through the form and then every morning we do the just reviews like whether we have new requests or not if we have so then we assign one of our team members just to meet with them and talk with.
Them about their product maybe sometimes we can even suggest some alternatives that they don’t even need new component in some cases once we understand so we do in a contribution way that means that a design system in our team um in our company.
Acts more as an assistant and then the owner of all the effort needs to put in including design and the development uh is uh responsibility of the product team meaning that i’m assisting designers to define their uh feature in this spec format as as we have.
Um and so i usually do the reviews introduce them on board them and then once this is ready so we have a common meeting with our developers and and and product developers together we hand off the files and then our developers do the same with their devs that we on board on the api that on the whole.
Repository that we have how they should work they usually make a change we create approve it and then only the documentation is the part that we take only by ourselves and then figma components as well so we don’t ask them to create special figma components by them because sometimes it’s very.
Um like we because we share the these components to over 200 designers so we want it to be top-notch quality um and then we have some standards so at this moment like it’s faster for us to work at this place so i can share briefly like how our design system library looks like in figma.
Um like whilst we’re whilst we’re talking about sort of transitioning of components from files to files how that linting process also works between the or even your design systems team and that sort of the code side of that regards to things like 24 pixels padding.
Between things is that a manual process that you go through um yeah i’d love to know a little bit more about that oh um you mean that if if we defined uh one spacing but in the product there is a different one so how we act in this case or or even when the in the ideation.
Phase of the let’s take the moderation settings page somebody doesn’t abide by your six grid system six pixel grid system when is that caught and how do you manage that or is everyone perfect and everybody always does the right thing so.
Like i i must say i don’t uh yeah i don’t check on that of a low level usually when doing product reviews on the on this basic like if it’s generally seeing that something is off so then of course i usually just try to react and then and leave a comment.
Um but in the most cases even if this if a designer makes something a little bit not 100 correct as in production our components exist developer can implement it in a higher.
Quality than it was designed just because like we have very um defined api which is mean that we provide layout component with which has default values so in the most cases developers just need to use default values and then if they notice that if it doesn’t match.
In a designer’s work usually they escalate this try to communicate and then they understand that oh it was just an issue you know a human mistake but yeah but if it’s something um made intentionally so yeah in most of the cases just people talk with our team and then try we try to solve it together.
Right okay so we hear a few few examples of our design system library of the components so i think i will not go into the details how our components are built just because today’s topic is more about the handoff and then collaborating with.
Developers uh but just briefly yeah because we try to combine and and reflect as much as possible the api level of the real component therefore like it requires a lot of understanding about the real component as it’s developed.
And then also it requires a lot of understanding about how figma works and also what we just learned recently that that it’s very very easy to run out of its memory working in this and and managed way so uh yeah taking all these things into effect so.
Therefore we are the owners right now of uh uh figma female assets know what let’s uh let’s see more examples of how different teams they hand off their work files.
To developers so this is a more complex example i gathered it’s from promote team they were working on a email marketing uh editor solution which allowed to change.
The paddings of components so how this theme works they they have this template where they have this overview page at the beginning beginning then they define their flows let’s wait until it loads yeah so yeah and what i really liked it that they.
Even built this uh template for themselves just to stack everything into these rows and usually they take all these flows based by the case if it’s like happy path um some edge cases in this case it just based their component because each component it has its own padding controls.
Uh so let me just scroll a bit about the contents what is going on here so this is an editor where a consumer can just drag and drop a button to create a newsletter and then once it’s clicked in the design section.
There’s this new control which allows to set the paddings on the top on the bottom left right um yeah so all of this uh it has a content area as well so so they just copy paste the flow after their design.
Work is finished so they hand off this one for content writers so they can just read it and make it sure that it’s a high quality text so it can also be passed to localization team as i understand in their team the um the writer prefers to even sometimes.
Leave some sticky notes and add and until it’s finalized and and then once the text are finished then this also once it’s once more it’s copy pasted for dev specifications and then it has few extra areas so as you see like at the bottom there’s the same flows that.
Developer can just get somewhere with it then at the top they have this area which is explaining just the exact area that a new layout that occurred explaining that what they actually need to develop in a visual way.
Um this is done by this is done by the designer on the project not the design systems team right exactly yeah cool and is this uh the stan i know you said the doctor teams do it differently but is this kind of thing the standard way of working as.
A product team yeah many teams work like that um and uh a person who had yeah how i was supposed to to run this so actually they started this way as as at least i learned because they used sigma already for a couple of years at least.
You know so yeah so i know that he could tell a story how they came to this um stage i’m sorry i cannot but it seems like this is this frame work really works because what they do here they just write down all the relevant people that should be involved in this project.
So for a developer sometimes it’s important to understand who they should approach um if they have questions of course every time and every team uh in our company we just we don’t send this by email we usually schedule a 15-minute meeting just to go over it and then just make.
Sure that nobody has any questions so this is i think like just because of this meeting i think nobody missed these features that we learned during the usability test that the description than the url exists here just because they these questions were already answered in person.
Um yeah and then they show even these stages so in some cases uh yeah i see that it has content so it’s important to know whether the content is done or not so then sometimes if the content was adjusted so a developer has to know about it so this is why they use these tags.
Uh and then some annotations are put what’s interesting that some annotations they even share the links to the storybook but does this require every designer to at least know storybook exists and how to use it how to navigate it yeah um what is happening here let’s see.
No none of my stories work no it’s just that url has been changed recently and they are static links so right so this is the downside we’re working on it and yeah so it was supposed to lead to test components.
Yeah so the education of this um i guess the technical side of that do you host office hour sessions with the designers do you have like an open avenue for communication how how do designers understand that that stepper component existed for.
Example so yeah what’s interesting that if we um i need to open the file that i can edit it would be this one let’s just jump right in to intro if i go into assets and if i go to wick style right library.
So all the families that we see here um icons layout lists forms actions they all use the same structure as is this area and then also if i drill into actions i have this amount of buttons if i go here inside of it these are the same buttons so for them it’s very easy to relate um.
Because we try to use the same language and then the the exact same names even if the names they don’t make sense we still keep keep up to them because then it’s easy to find um and.
Yeah and then usually they just insert this component they scroll a bit here read a bit and then just understand you know what they can control and what not and also the button themselves usually once we add them here the properties that we communicate in.
In these controls we talk we try as well to be the same you know and use the same naming as all these descriptions this is where you start to link back to that api that you were talking about before yeah exactly.
Great um so with the rest of the api um i know it’s it’s quite a technical term but it does relate very well to how you’re structuring figma components is that something you had to push quite hard for when you’re thinking about this as an approach or is it just something that naturally landed at how are you going to.
Work as a team um i think it’s an evolution it’s just at the beginning we had totally separated areas that developers they had their own environment and designers they had their own and it caused a lot of frustration in between because.
Nobody understood each other you know a lot of mistakes happening and then yeah we understood that okay we need to collaborate on this you know so we’re not expecting from designers to be developers and from designers to be i mean opposite so um.
But we just want to care about you know that about each field that not to be ignorant you know um and uh and also at the same level like uh i had the chance to have a conversation with nathan curtis also about the same subject like what.
You know should do in this case and as we see example in google for example they they have separate areas in material design and but we have some other design systems as well that they use only one area and it just the reality is it’s very hard to keep in sync when we have.
Multiple locations to synchronize and make a seamless pipeline it’s a hell of a job so for us it’s it’s way more efficient just to sacrifice maybe a little bit of some things from developers that they have to see designer stuff that is relevant for them and then designers have to.
See a little bit of a technical stuff in the same place but just because like it’s all contained in the same place but in the end they both then speak in the same language and for us it’s user maintenance so it’s like we see benefit of it and so far nobody has been complaining.
I’ve got a couple of questions in i’d love to answer ask you from the audience and the first one i’m going to run in with questions from dermot and they’d love to know what process or plugins you have for checking accessibility on your components oh yeah so accessibility is a it’s a painful topic for us because we.
Really care about it we’re working on it we’re not there yet um it’s just there’s nothing to hide because you can you know test us um yeah so right what right now right now we every new product and every new.
Component we make we make them accessible so once teams develop their products they make them accessible whatever is on their level of responsibility so what i say what i mean.
That if they make a product that uses our components and our components are inaccessible they’re not fixing that we’re just logging it and then we have right now backlog of issues uh which we’re aware of and then we’re prioritizing or fixing them but the whole process how it how it goes.
We have a dedicated accessibility team um where where people just there are professionals who usually review these products including our components and they just give our guidance you know how the com the whole product should behave.
So in a nutshell what product teams they have this dedicated area and every uh every our product you find in in figma these they have this accessibility area where once they hand off the the work files to developers.
Um they show you know what the tab index should be and if they have some landmarks some specific zones that also that responds on this so they show in here as well this example it just shows you know it’s just a small feature that is is not the whole product.
Therefore it touches only this area but for the whole product it would touch the landmarks of the the whole interface and then yeah it would have this definition in our component accessibility so i can give you a demo with the component that we recently improved.
We call it a popover menu technically what it is it’s a list menu that appears once some kind of a button is clicked and then as i explained like we have all the structure in this spec template right below the constraints area we have.
Few areas that are dedicated to accessibility so the first one is a tab index so this is kind of silly and simple uh just because like it’s just one trigger action and then you know you focus on it.
Um but in some cases it has many areas where you have to focus in and then another area is we show the keyboard controls so a user would just keyboard without using a screen reader how that person controls it so usually we show it in a simple flow that in this initial focus is here once you hit the enter it opens and then you.
Use up and down arrow keys uh to navigate between it and then to close it as well like we just specify that it’s enter or escape closes um so why we chose this way is because designers they’re not developers and we don’t expect them to show the dom level explanation.
What i mean don’t it’s it’s a technical term how html is written anyways um so what we ask just to show the experience like what the experience should be so it shows the keyboard experience and also if we scroll down the screen reader control experience so we just show that.
Okay once you focus on this screen reader will tell these words yes that is awesome thank you the next question is in from francis and they’d love to know about the staffing that you have so ratio of designers to developers the amount the size of the giant systems.
Team could you share some about that um yeah of course so the ratio depends per team um and each team has i think its own ratio but in most cases it’s uh more more developers uh than designers in the team uh obviously.
Um i’m trying to make a number and not to make a lie so i’m sorry struggling we can maybe start with the design systems team yeah so and.
In design systems team it’s a little bit opposite just because we have a lot of uh assistance work with a lot of teams and we have a couple of hundreds of designers so so our ratio in the past time it was 101 so it means that we have four developers and four designers.
And and uh yeah and it’s it seems like it’s a little bit unusual uh but we still find it work because a lot of our time like we cannot dedicate 100 percent of our time to work on new features we have spent half of our time assist different teams and this is you know just how this.
Ratio changes but in the most cases they’re like two developers one designer um in the most cases as i know or it can be slightly different that maybe slightly more developers for one designer or if the need is similar to our teams will maybe increase the slightly larger.
Thank you we’ve got a question in from suraj about the padding rules that you have and they want to know about your padding rules are they in increments of eight or ten do you have any preference i know you think you mentioned earlier about six so it’d be great to get insight into the decision around that.
Yeah um so we use six pixel grid due to the historical reasons like it’s uh it’s very pricey to move from one grid system to another appropriate system and it doesn’t bring that much of value for us right now so we’re happy with that like well my personal opinion for pixel grid it is.
Easier to use and better just because um it’s more flexible like you have more um steps to choose from you know it’s uh proportionally you can make it nicer looking areas but yeah we stick we stick only two to these values so in our case it’s 6 12 18.
24 and so on in some very edgy cases we have to make excuses so like what we do we introduce a size of three so it means that we need something smaller than six so what we do we just make three pixel paddings from top and bottom and then.
The sum is still six so it falls nicely on the grid the reason why we um why we used to you know why we are strict onto this it’s easier for us to count but also in the past once we didn’t have these sophisticated auto.
Layout features just to make sure that we’re not off with the spacing all of us used to use just a grid and you know if you are not on the grid so then you just see it and that that something is not right so.
Then you just fix it and this is why we always stick to this six pixels cool and then the last question uh is very important from francesco is how much time do designers typically spend on documentation because it looks like there’s a lot of documentation that happens in all stages of your design process from product to design system um.
So we’d love to get some insight about the realistic i guess of that yeah um so it depends per component because the more complex the more time it will take but on average uh like we already like we haven’t documented all.
Of the components but over a hundred we already did so we know that on the average is around one day for a full documentation of a component plus some development work because developers they have their own roles how to write snippets for examples so.
If we go into this and you yeah click to show code so all of this is written by a developer and this is not a designer’s work obviously and just to they have their own rules how to make it very simple to show only what’s important in here so that takes.
Additional time i cannot give the exact number on that but it’s roughly one day for for all of this for a designer to write content and then additional time for a developer once only a future change so it’s just you know small amount of time just half a day.
Uh maybe hour or two tops great thank you i think that’s a really nice place to finish up effectively staging the claim for the importance of taking the time to spend on the documentation because in the long run it will save you time ultimately to save you money give you better return.
Investment for your components thank you so much thomas thank you everybody for attending i hope that was fun and we’ll see you all next time thank you
Join to hear from Domas Markevičius UX Lead, Wix.com about how they embed a culture of collaboration and communication …
Figma Official Channel,design,the,from,figma, design, product design, tips, tricks, UI design, ux design, app design, figma design, design for figma, product:figma_design, audience:designer, language:english, format:standard, produced_by:marketing, theme:other, event:none, series:in_the_file, type:other, level:intermediate, primary_feature:, secondary_feature:,