DEV Community: Zvonimir Perkovic

Promoting teamwork while improving production process in 5 easy steps

Zvonimir Perkovic — Thu, 18 Feb 2021 18:36:17 +0000

Steps:

Get the support you need first.
Make stakeholders engaged by adding value.
Promote it within the team.
Learn to let go (pass the ownership, support oncoming leadership initiatives)
Keep growing it.

Get the support you need first

Before starting this task, get the backing you need from your manager and peers. I can't emphasize this enough. Support from your boss comes packed with credibility, authority, valuable feedback, and it will force you to collect your thoughts and think about the problem concisely. If you can't communicate your ideas out loud in a clear and meaningful way, they are probably not worth pursuing at the moment.

The main three reasons I like to talk with my manager before going the extra mile are:

Making sure my thoughts are in line with the greater vision and plans.
Making sure to get approval before doing any major work.
Getting practical advice from someone who genuinely wants the process to improve.

Make stakeholders engaged by adding value

Get out of the idea generation and research as soon as possible.

My strategy for nailing this step consists of:

Defining the key players - people I need to make this work.
Including them early, getting the feedback, and making them a part of the solution.
Doing the job for them by solving an existing problem or a part of it.

I look for quick victories that will add the most value (when stacked together) in the long run. It has to be something people (including myself) care about or something that's bothering them. Then I put extra time into building a working solution. A working solution is not a finished version, but it is robust enough to be used right away and recognized for its potential.

I realized that some people could take it offensively if I take the liberty of solving a problem. Most people will appreciate it, as long as it makes their jobs easier and adds value. That's one more reason to make alliances with your boss and key stakeholders early in the process.

Here are some ideas on making critical stakeholders (people whose work will be affected by the change) interested by adding value?

Choose a tool that will solve the problem. You can build your solution from scratch if you have time and skills, but more often than not, choosing the right tool is a better option.
Start and do the work but leave room to grow. Remember, starting something is the hardest part of any activity, so it is very likely no one on your team will begin solving accumulated problems. You have to start, but also, you need to leave some skin in the game, so when people join, they can leave their mark on the project.
Make your solutions so great that it's hard to refuse them, and their potential is obvious.

Promote it within the team

Once key stakeholders are excited and contributing, it's time to use our marketing skills and promote our solution to the general audience. These are product managers, developers, product owners, and others whose workflow won't need to change.

Promotion is an essential step in making our new way official and getting more people on board. Once we have a critical mass of people on board (that recognize the value), even the minor contributions will ensure the project keeps growing and getting better.

More contributors indicate we can step back, which leads us to our next move - letting it go.

Learn to let go

Here is where the teamwork should kick in and swipe your ego away. Are you a team player? Can you walk away from the project or a workflow you started and set the groundwork? If you care about your team's success, you will have no problem letting your colleagues take ownership. If you are not, you should be because there is no personal success without the team. The same applies to the process.

Here are two ideas that can make this inner conflict manageable:

Empathy - put yourself in other people's shoes. Most people want to help, contribute, and show their value.
Create a new mental model based on opportunities. Mental models are like templates for thoughts that shape them according to the situation. Here are some that can help: a.When [Nikki and John] contribute to [this], I will be able to start [that]. b. The next problem I can work on now is [building a weather app]. c. Because [Sue] is contributing, I have time to learn [C#].

When I say "learn to let go," I don't mean "walk away." Keep growing it as described in the next section.

Keep growing it

Whenever we stop evolving, the opposite takes place. The same happens with processes, workflows, and work rules. They get out of date, out of use, and eventually, they die.

To prevent this from happening, I like to keep track of all the process improvements I've started and worked on (that do not have a manager who keeps track). To prevent the "Too many cooks in the kitchen" problem, I take a step back to make room for someone else to step in and lead. Taking a break is also necessary from a testing perspective. I need to change my mindset from someone who owns to someone who is using to discriminate against what works and what does not. If a process is helpful and makes us better, we will follow it. If it's not, we will discard or change it.

I like to follow this flow to keep a system alive and well:
"Stepping out > Using and observing > Stepping back in > Fixing and improving > Stepping back out > Repeat"

Considering this system improvement initiative came from within, and there is no external business owner that is tracking results, there is a big possibility that our process will get stale after a while. Since I'm expecting that to happen, I'm ready to jump back in when it happens.

Keep growing. Keep improving.

5 ways to do a code review

Zvonimir Perkovic — Sat, 13 Feb 2021 14:44:25 +0000

How to keep high coding standards without losing speed?

Code review ideas covered in this article:

A formal code critique with the demo
An informal code critique with the demo
Review based on the GitHub request
Approach with one designated reviewer
Pair programming, an informal code discussion between two developers

Formal code critique with the demo

I have joined the "team" in April of 2019. The same month I've experienced my first formal code review. And I was terrified.

The meeting started at 9:15, after a daily standup, and one by one, developers walked into the small room with the big square table. There were only six chairs around the table, and with me joining the team, seven developers. Space started to feel crowded. There was no facilitator; the developer whose card was the first in the "Code review" column was the first to begin.

To say: "the engagement was high" was indeed an understatement, and the fact they called it "code review" instead of "code critique" is what additionally caught me off guard.

The first developer would take the lead, and others would patiently wait, eyes wide open. With the Trello card visible, devs would compare requirements with whatever was on the screen. The purpose of the demo was to find any flaws in the working solution. Then, a GitHub pull request followed. If a dev could have written a line in another way, well, the team would let him know it. If a prototype did not fully match the requirements, well, he would quickly learn to read those specs to the letter. And if something were so apparent that two or more team members would notice it at the same time, they would ecstatically yell at him, pointing to the problem. It was indeed a blood bath with only one purpose: to find something, anything.

The system indeed had some pros:

Transparency of every pull request ensured that every new line followed established coding standards.
Since we were reviewing code every day, this meeting worked like a twisted version of team building.
Fresh employees would get directly educated in the expected means of writing software.
An effective way to get into other people's code and understand the reasons behind decisions and different coding styles.
Making sure managers get what they wrote in requirements and that software is working according to the specs even before getting to QA.

Cons were also plentiful:

Seven developers would sit on a meeting every day, even if they could not add anything to the discussion.
Long code reviews made it hard to stay focused and fully pay attention to the end.
More devs in the room meant more questions and requested changes, frequently basing those requests on personal preferences.
Slowing down the whole production process.

It was "the more, the merrier" type of a problem, where the more developers were in a room, the more updates they requested. Our highest number was nine developers on the daily review. The good thing about that period was clarity on what we need to change. Over time the number of developers decreased, and we started to rationalize how we use our time and what changes we are requesting. Once our team fell to only three devs, the detailed critique started working a lot better.

Let me fast forward to the present day.

Almost two years later, we still have a formal code review preceded by a demo. It's still happening at 9:15, but the team is smaller, there is less nitpicking, and we are more focused on functionality. We all work remotely and use Slack for reviews. We are still going through pull requests line by line, or at the very least, section by section. It is always a challenge to see the big picture, but keeping the pull requests small helps a lot. To summarize, we kept all the reasons for formal code reviews and cut off most of the reasons against it.

Conclusion

The detailed daily demo followed by line-by-line critique can work well in a smaller well-coordinated team. If done appropriately, this meeting functions as a daily check-in, an opportunity to ask questions, and the primary mechanism to keep your work in sync with others.

An informal code critique

Another meeting we use to keep our coding standards high is an informal code critique. In its form, this review is the same as a standard version. The main difference is in its ad-hoc nature.

This meeting comes in handy when:

Team member needs approvals, before starting a new, related task on the same day.
There is a pressuring deadline.
Another assignment depends on this solution and can't move forward until this code is approved.

We are using Slack "@codereviewers" mention in our GitHub channel to assemble the team. It's a good practice to leave some room and schedule a call 15 - 30 minutes in advance. The last difference worth noting is; while for the formal code critique, we wait for the whole team to assemble, for the informal one, we only wait for the two developers that make a quorum.

Review based on the GitHub request

One of my favorite ways of getting and giving feedback is through GitHub or Bitbucket. It arrives in a written form attached to the pull request, followed by a quick call when needed. Both applications made this process easy, with features explicitly built for this purpose.

There are a couple of ways we can make this work.

Option A:
A developer creates a pull request and asks for a review. Other devs examine the code before starting with their day and leave comments behind. A face-to-face meeting follows if a discussion is needed. Otherwise, she makes changes, and reviewers approve her work.

Option B:
A slightly different than option A, option B starts in the same way, with a pull request. Other devs on the team get automatically notified. The ones whose opinions are relevant for a specific task will inspect, leave comments, or give their approvals.

The difference between these two options is in the review request. In the first case, a developer is actively asking for a review from specific experts. In the second case, stakeholders will review and comment on their own. Both options provide a straightforward and efficient way of keeping the codebase clean. A downside is minimal in-person communication only when developers can't agree on something and make a point through short comments.

Who should be a "reviewer" is a question to answer? I found that the best combination of efficiency while keeping quality happens when peers with similar skillsets and levels of expertise review each other's code. Here are some examples:
A full-stack developer reviews a request from a junior front-end developer (FED from now on).
Two junior back-end developers could check a senior BED code.
Two BED's could review each other's pull requests.

There might be a situation where the beforementioned examples won't work. For instance, I'm a FED but not proficient in React. Another FED writes all React code on our team, and she is fantastic at it. It would be expected from me to review her code in the normal circumstances, but since my understanding is limited, a senior full-stack developer jumps in, which brings us to the next option.

One designated reviewer

Scenario when a senior developer examines and approves all pull requests

Most teams out there have that one teammate who has been with the company for eternity. And for a good reason. He understands business needs better than anyone and is well-versed in many different fields. This individual is well known and respected as a problem solver and leader. Even though he is a great coder, he spends more time examining, debugging, and approving others' work. He might be a team-lead, where interpreting business requirements falls on his shoulders together with other managerial duties. Of course, the actual responsibilities of an employee of this caliber will vary based on many factors, some of which might be the team's size, the number of projects, career plans, and aspirations.

As it might sound, this approach is very straightforward. Junior and mid-level developers write the code, and a senior developer reads, debugs, and approves the work. As with everything else, there are some reasons for and against assigning extra work to a designated developer.

Pros:

Competence. The most competent developer gets to decide what fits and what does not fit in the code standards. If there is a bug, this person will find it.
Hierarchy. There is a clear hierarchy between devs doing the work and the authority that approves it. The primary outcome should be a product of higher quality.
Time management. One meeting less for other devs on the team.

Cons:

A large workload might prevent the best developer from coding. * The most complex problems need the brightest brains working on them, and with this approach, that might not be possible.
Not fun. Inspecting other people's code for extended periods is not for everyone.
Learning opportunities. Reading code is one of the best ways of learning how to write code. If younger developers are not doing it, we are taking that opportunity away from them.

Worth noting is that a lighter and possibly better version of this method would involve two or more senior developers effectively sharing the workload.

Pair programming

Two sets of eyes will always catch more details, spot more obstacles, and find better solutions faster than one set of eyes would. The most common use of the term is in the phase of "solutioning." I found the same concept very useful and practical for code reviews, so I'm adding it to the list.

Developers can collaborate directly through tools such as Visual Studio Professional or Microsoft Teams. I found that even a screen share without giving control works. On our team, we usually do it through Slack or Teams. We are both problem-solving or presenting a solution. I find it useful to show a solution and get feedback before an official code review.

On its own, this type of code review is embedded in the workflow more than other options. Since the observer still needs to take a break from his work, it is convenient to append this after another meeting or schedule it in advance. Due to its informal structure and a lack of urgency, it still breaks the workflow less than other code review types.

Talking exclusively about front-end development CodeSandbox is a new tool that takes pair programming to another level. CodeSandbox works in the same way as the Codepen, with a couple of extra features in the free plan. The most important one is the live pair programming mode, which runs smoothly, and so far, it has been very stable. Another option that I love is the ability to assemble a team. In that case, pair programming is given and a part of a regular workflow.

I believe this type has more pros than cons, but let's try to define some of them.

Pros:

The informal nature of the meeting improves teamwork by making the connection between developers stronger.
Developers are explaining, reviewing, and problem-solving at the same time.
It is easier to see the bigger picture in this environment than during the formal code review.

Cons:

Time management. Working in pairs on the same stuff can get lengthy and exhausting.

I would love to learn how other teams are reviewing their code, products, and designs. Please reach out with your ideas or leave a comment.

Bridging the gap between design and development. ⚔️ How to use Figma's projects as process sections. 🥁

Zvonimir Perkovic — Sat, 06 Feb 2021 15:50:55 +0000

No time to read? Here is the summary of the most common reasons that create the gap between designers and developers:

The "red tape" problem. Lack of collaboration between the design and development team.
Excessive planning meetings, follow-ups, and reviews that happen due to inefficient processes. The main reason and the ways to avoid them.
Changes in requirements result in different looks between the finished product and the original mockups. Which then lead to more meetings and revisions.
Removing the middle man and bringing stakeholders together. Finding ways to make each contributor self-sustainable and independent.
Recommendations on how to use Figma's projects as process sections to organize, collaborate and document our work.

Step 1: Define the problem

A problem that I faced recently is a puzzle that bureaucrats call "red tape." Red tape is the existence of complex rules and procedures that must be followed to get something done¹. In this case, the red tape is extended to the requirements to get things done in a certain way instead of getting things done most efficiently. To the request to have multiple people approve or comment on work before it's called done, and much more.

Where checks and balances are needed in every large entity to ensure the quality of work and to prevent any side from growing too much or becoming rogue, they should not get in the way of doing what is needed to get things done. Our version of the red tape resulted in a lack of cross-team collaboration and a slow process that affected our delivery.

We approached the problem with two goals in mind:

To create a process that will keep us in check but also improve collaboration. People had to become excited to work with each other.
To create a process that will make the end-to-end process faster and a final product better.

Step 2: Removing the first obstacle - The Middleman.

Facilitators are useful in many different aspects of life. When developers are busy discussing the best way to solve a problem, but deadlines keep crawling, we need a manager to put us back on track. When designers can't agree on which art direction to take, they need a facilitator to help them decide. When middle management creates to-do lists for the year but can't agree on which one is the most important, they need a manager to prioritize, kill the dreams, and leave only one idea alive. Ideally, intermediaries remove obstacles and make us better at what we do.

However, facilitating or managing can become a purpose for itself, and then, we have a problem. Traditionally, in other fields such as open market economy, the middlemen are useful when both consumers and manufacturers benefit from their services. They are an obstacle if they are not adding any additional benefits nor solving any existing problems.

One way to solve the middleman problem is to ask yourself three different questions. Those questions are: Who is the owner? Who decides on the business logic and requirements? And who gives a final approval?

Who is the owner?

The answer looks relatively simple. The assigned project owner owns a project. However, what happens when an owner is a manager and not a contributor. Wouldn't it be fair to expect that people doing the work are owning the results? The theory of ownership tells us that an owner does not necessarily have to be the one doing the work. I can own something and hire someone to do the work for me. However, in the design and development teams, everyone is employed, and we cannot apply this theory fully here. So what do we do? Should a product owner be the main contributor? Or should an owner be an employee that communicates with the business owners? A simple question turns out not to be so simple. We can turn our question around and ask: if contributors don't own their work, why would they care for the result? The search for answers seems never-ending, but it drills down to that the owner is the most responsible for the project's success and should bring the most to the table.

Who decides on the business logic and requirements?

I'll be honest; every team I worked on answered differently on this question. However, patterns are evident. In smaller groups, the senior developer or designer is responsible for understanding the business logic and is writing requirements. In the larger teams, that is the domain of the project owner or manager.

The product development process is streamlined the most if the business owner takes care of the business logic and passes it on to the design and development teams. It's even better if it's written and shared in Confluence, Figma, Trello, or another tool of choice, as long as everything is in one place, accessible, easy to find, and reference.

It is best, however, if the requirements themselves are part of the working files. For example, the stakeholders can use Figma, XD or Avocode for documentation, communication, versioning, and much more. We can assemble the whole team in some of those apps with all assets ready and available. It is the easiest and fastest way to keep everyone on the same page.

Who gives a final approval?

The bigger the team, the harder it is to answer this question. Formally, the QA department. Informally, it can be any combination of a project lead, designer, developer, or manager. In reality, the client or a customer! So before launching, we have to get at least three approvals, oftentimes much more.

Once we answered those questions, it easier to make adjustments and remove 'the middleman" (process blockers). Then, we can replace those blockers with an automated system.

Step 3: Change often, change early, but stay on track.

Change is part of every process. Stakeholders should not stop their work when the change happens. Every update should be an integral part of the process, and ideally, only the most complex ones will need in-person meetings. Those ideas represent, of course, an ideal process.

More often than not, changes in requirements lead to more meetings, opinions, and missed deadlines.

The best route I found to deal with changes in requirements is a live collaboration with a stakeholder in the tools that bring us together. Suppose we have access to the same files or a demo website ready and continuously (automatically) updated every time a requirement changes on one side; the other side is aware of it.

A simple workflow could look something like this:

Trello for project management.
Figma for idea generation, design, prototyping, collaboration, style guide, and more.
CodeSandbox for front-end development, collaboration, and UI library.
Slack for communication.

A simple workflow for designers and developers with just four apps.

We can connect these apps together, for example, by installing Figma plugin in Trello or Slack. And to expand our reach and with apps outside this workflow, for instance, CodeSandbox with GitHub.

Step 4: Putting the product first - product based collaboration.

Organize your work and the work of your team around products, not rigid groups. That means accepting rules that will drive product development instead of slowing it down. It also means we should look for the added value, and if something is not adding value, eliminate it from the process.

A practical example of that approach is a team collaboration in Figma and Storybook. Designers and developers can work together and compare each other's work. Since they work on the same files, they will have to figure out version control. They will not have to figure out who is in which team or navigate through versions of office politics. GitHub makes it easy for developers, and Figma easy for designers. From the start, the product is front and center, and the contributors organize workflow around it.

It might sound that product-driven collaboration takes away individuality and opportunities for individual contributions. That diminishes chances for standing out for all non-technical team members. I like to believe that it makes everyone self-sustainable and independent.

Self-sustainable individuals can do their job without asking for guidance, instructions, passwords, assets, links, examples, which is all part of the workflow and accessible from the apps mentioned above. There is no fishing for files or scratching the head when reading through the requirements. If something should be self-evident, for example, how a component should transition from one state to another, we should not need a meeting to find it out. Independence becomes a by-product of the ability to provide for yourself.

Step 5: Using Figma's projects as process sections

When talking about collaboration between product teams, there is no question about which app to use. Two features that make Figma stand out from the competition are teams and projects.

How to create a team and a project in Figma.

One small adjustment our team had to make when using Figma's free plan was to use projects as process sections. We can apply the same idea within the paid plans with many projects on hand.

The starter plan has a top cap of three projects with an unlimited number of files and artboards within them. With that in mind, we organized those three projects as process sections, namely: playground, features and projects, and specs and patterns.

Figma's projects used as process sections.

The first section - Playground

The playground is open for everyone to experiment and try out new ideas. If you can imagine it, you can test it here and get feedback. This section is the home for all undefined or conceptual work. Teammates can follow each other's ideas and build on top of them.

If it grows and becomes an official project, the owner will move her idea into the "Features and Projects" section.

We are also trying to use the playground for wireframes as a first step in the design process. More yet to come.

The second section - Features and Projects

A project or a feature can find its way to the Features section in two ways:

Directly - when assigned through the Trello card.
Coming from the playground. Here we work on all active projects. They are passing through iterations and, once done, will end up in the specifications section.

This process section is the right place where developers can get acquainted with the new ideas and components and where they should join and start asking questions at the same time designers are designing.

The third section - Specifications and patterns

On top of our process are specifications and patterns. Here we store all established and tested designs, and we use them as a single source of truth in all projects. You can find all the assets and design tokens in the files that are stored here. Specs and patterns are also the section developers, and QA testers will reference the most for all work that is not going through the design process.

Some examples of referencing this section are:

When building a simple widget that will not end up in the design system.
When making sure spacing fit the established patterns.
When refactoring a component.

I highly recommend having all completed designs in one place. The main reasons are:

Speed; it's easy and fast to find the source of truth.
Documentation; it's easy to reference and know what the final versions are.
Order; it becomes natural to create new designs only when you really can't use the current ones. And when a designer creates a fresh piece, it is evident if that piece is in check with established rules.

That's it. In this article, I went to the conclusion through the back door. I hope it was fun and useful to read. Please let me know what you think or share your experience below.

http://www.socialstudieshelp.com/APGOV_The_Bureaucracy.htm

Component driven design in 5 steps 🚀

Zvonimir Perkovic — Tue, 26 Jan 2021 12:52:05 +0000

Great front-end development starts with great design. How to structure Figma components developers will love.

No time to read? Here is the summary:

Front-end developers use pre-processors that enable them to reuse their code. When designers follow the same patterns and reuse their styles, it's easier to transform them into code and keep the codebase lean.
Set up your patterns and style libraries first. Then take advantage of Figma's auto layout and nesting features to ensure consistency.
To design a component in the same way it will be developed, start with the master component.
Begin with assigning core styles to the master component. Then use the master component to build the modifier. Finally, use the modified version to create its state.
The result is a mirroring effect between the code base and design style guide. Components have the same names, rules, and architecture in Figma as they will have in code.

Before we begin, I want to disclaim that the examples I'm going to write about are not the only nor the best methods of organizing design files or writing code in a component-driven way. The best structure will be decided base on circumstances, needs, and personal preferences.

Component driven design.

Front-end developers have superpowers. One of them is to keep the stylesheets organized, maintainable, and lean. That job got a lot easier since the arrival of pre-processors like SCSS and LESS. Repetition and lack of readability became less common. Unfortunately, other problems emerged. Somehow our stylesheets kept growing, and lines of unused code got out of control. It was not always the FED's fault.

The problem here is that with every new mock, a developer will reuse what is obvious, scope the rest, and move on. Not knowing the bigger picture, the next developer will do the same. From that day on, stylesheets will become unmaintainable.

Meantime, the designer will create something new based on the latest business requirement. Let's take a new sign-up button as an example. She might reuse and reference what is useful from an old button. Brand colors, typography, or primary styles rarely change. They might as well be a starting point for a new button. From here, she might tweak a property that needs adjustment or swap icons. What she should do instead is extending the main button component and adding a new style to it. Designing this way, we are creating a new modified instance, not a new version of an old element. What is more important is the relationship between the two that is visible and obvious.

The more the system grows more important component-driven design becomes. It is a system where front-end development starts with the design and where every new element is unique or based on its parent. There is a clear hierarchy between components. A developer can see the bigger picture, and the designer sets up the path for development. The result is resolved problem of style inheritance and bloated stylesheets even before opening a code editor.

How to keep consistency while scaling? Create your patterns and style libraries first.

Before starting any work on the component architecture, we should define our patterns.

What is a pattern? A pattern is any property used to build a CSS framework or design a set of components. I like to start with spacing, typography, colors, and grids. Some familiar, easy to follow pattern would look like this:

Once we add patterns to our local style library in the Figma file, they will serve as a base for any design work. Then when development work begins, the developer will set up pattern libraries first.

There are two more things. Make sure to understand Figma's auto layout and nesting features before starting your work. Working with them is almost like building UI with code. Auto-layout makes it possible to control spacing, and the behavior of the component is Figma like it is an HTML element in the browser. Nesting a layout frame is much like nesting tags in HTML.

Master components. A new way of designing like a developer.

To set yourself for success and design a component in the same way that will be developed, start with the master. The master component is a template that controls all other elements made from it. That means thinking in advance how many variations of this element we will have and which styles we will reuse.

One possibility is to create a separate master template that stands alone. That component is not used for the actual design process. I use this standalone piece when I want to design other elements of the same type.

Let's look at our button example again. Place a picture of the button here:

I created three master buttons based on their sizes. Each one has all the pieces and properties any other button can have. The differences between them are padding, font sizes, line-height, and icon thickness. Their children will, however, inherit all the properties they have. For example, all large primary buttons are going to have a font-size defined here.

It's open for debate, but properties I don't want to set at this level are background and border colors. I will arrange those at the child levels. I'm also not creating any states here. They are going to be placed later on primary and secondary button levels.

Pro tip: it's a good practice to leave notes and guidelines others can reference when working with your file.

Looking at this design, SCSS I want to write without much thinking would look something like this:

%btn-m {
  font-size: 1rem;
  line-height: 1.2;
  border: 1px solid;
  border-radius: 8px;
  padding: 1rem 2rem;
}

(I would handle icons in separate placeholders as well.)

Easy enough! Since the designer already thought this through, I know I will extend these styles and not use them independently. I can plan my code accordingly and put them in SCSS placeholder "%." The result of this approach is going to be a cleaner and leaner code.

With that, we finished the most critical step. We know how many master components we need and which CSS properties we need to share. Let's move on.

Creating modifiers and states

Modifiers are nothing more than versions of the master component.

We can use our master button to create primary, secondary, and other buttons in their respective sizes in our example. The process would be as easy as drag and drop from the component library or direct copy and paste.

Detaching a copied instance is the next step. Detaching is like moving away from your parent's house. You are still under the influence, but you can change some things in your life. For example, you can paint the walls of your home bright-green.

Once the color (or any other property) changes, you can create a new component and save it in the library. All styles specific for the version would get set here — for example, background, border, and font colors. And the process would repeat for every new instance.

The last step here is to create states. Our button has five. Those states are normal or base, out of which we created active, hover, focus, and disabled states. The process of creating those states is the same as creating a version. Drag and drop our primary button modifier, detach, make a change, and create a new Figma component.

We can repeat this process as many times as needed, keeping in mind that extending too much will make our design and CSS files hard to follow. Another thing to keep in mind is Figma's autosave feature. By default, it will nest all related components, so make sure your naming convention makes sense and it's easy to follow.

Things change. Our buttons will change. When that happens, we will have a couple of options. Updating a master component will update all modifiers and their states. Updating a modifier will update its instances and states. Lastly, updating a state will update every instance of that state.

To make a change in the CSS file, we would follow the same pattern. Updating the main placeholder class will update all the elements. Updating an element will update its states, and so on.

The mirroring effect: Design styles == front-end code.

When components are using styles defined in local and global asset libraries, they are naturally using predefined colors, typography, and effects. Styles that are not in the libraries will be stored in the master components and extended to their modified versions. Modified versions will have their own set of unique styles, and the same is applied to their states.

Writing the front-end code based on the described component structure is a dream come true for every developer. The main selling points are:
Patterns are clear and easy to implement because a developer can see both the big picture and all the used styles.
Clear patterns will make a lean codebase. One-offs should be rare and planned.
Improved collaboration between designers and developers. This one is priceless, as it will enhance both process and the end product.

Finally, our SCSS code could look something like this:

%btn-m {
  padding: 10px 20px;
  font-size: 1rem;
  line-height: 1.2;
  border-radius: 4px;
}
.btn--primary {
  @extend%btn-m;
  background-color: $primary;
  border-color: $primary;
  color: $white;

  &:hover {
    background-color: $primary--hover;
    border-color: $primary--hover;
  }
}
.btn--secondary {
  @extend %btn-m;
  background-color: $secondary;
  border-color: $secondary;
  color: $primary;

  &:hover {
    background-color: $primary;
    border-color: $primary;
  }
}

Conclusion

As mentioned at the beginning of this article, the best way to structure your components will depend on your environment, front-end architecture, and design habits. It's always a good idea, before jumping into design, to start collaborating early and talk about different solutions with your team.

Let me know what you think and how you do it. I would love to get feedback and improve our process where possible. Thanks!