![\"\"\/](\"https:\/\/lh4.googleusercontent.com\/T-GEfIXP_Z6N9y5-e1dqijO-lwueIu3J-kgXzD3g2bfW17-4MB-n5htFMEZv-h0XHezIINlzCs0Wk5JIToBNNEnwmkmWZQLojPNr7DuFAAuBkSmhcQr8VqIVbko8Xl5uXplc_f3b\")
<\/figure>\n\n\n\nReasoning<\/strong><\/p>\n\n\n\n When we started building our Design System at ORFIUM, I was hard-pressed to gather information from other companies that had gone through the process or colleagues with this kind of experience. I hope that you will find answers in our story to some of the questions you\u2019ll face when you go about creating a design system of your own.<\/p>\n\n\n\n Start of everything and the big Q<\/strong><\/p>\n\n\n\n Big Bang\u200a\u2014\u200aThe start of everything<\/strong><\/p>\n\n\n\n Over the past couple of years, we\u2019ve seen more and more companies adopt the idea of a Design System into their core business. Creating and using a design system can help to solve a number of problems for design and frontend teams collaborating. As the design system handbook<\/a> defines, it helps teams to:<\/p>\n\n\n\n But what happens when you want to sync those two departments together and have that system stand as middleware? This is the point in our research where we had a hard time finding information. Turns out, it\u2019s pretty challenging to find a one-solution-fits-all kind of answer.<\/p>\n\n\n\n At ORFIUM<\/a>, the need for a DS came up as our products grew and we had to work on different projects that focused on different user flows. Furthermore, the nice problem of rapidly growing two departments (front-end and design) led us to the need for centralized information about our user journey and a more rapid and solid solution for building components. This is where the Design System<\/strong> comes in. <\/p>\n\n\n\n To do that we decided to implement two different tools<\/strong>. <\/p>\n\n\n\n Our Design System <\/em><\/p>\n\n\n\n The first step was to identify what we were about to build. One of our primary considerations was to not waste resources, to ensure that no extra work would be put in for unnecessary outcomes. So the first question on the team\u2019s mind was\u200a \u201c\u200ado we really need<\/em> to make everything from scratch\u201d?<\/p>\n\n\n\n There are many well-known, well-structured, and open-source design systems out there, such as Material Design or Ant Design. So, why don\u2019t we use that kind of a tool? We spent a decent amount of time considering our v1 designs of all the products. This exercise led us to the conclusion that we couldn\u2019t use any other system. Here\u2019s why:<\/p>\n\n\n\n Furthermore, it was time to establish how it was going to be used within the team. As we don\u2019t currently use any sort of monorepos, we wanted to make sure that this library would have its own roadmap. We chose the use of npm and made it a public package. This way the team would have to use it as a public package contribution and we have to stick with many good processes. This move allowed us to pull Request labeling and procedures, automate our changelog and release system, and, importantly, to show our work to the world and be proud of what we deliver. <\/p>\n\n\n\n Our implementation was broken up into 3 steps. <\/p>\n\n\n\n Team Arrangement<\/strong><\/p>\n\n\n\n We defined several ways of communication between the Product, Design, and Frontend teams to provide a solution that will be built once and will help all products in the way.<\/p>\n\n\n\n It is important to note here that we see the design system team as a non-product team and our two teams (design and frontend) maintain it.<\/p>\n\n\n\n Each product has its team. This team consists of people from all departments: Frontend, Backend, Design, Product, and QA. The need usually comes from the Product team and grows there. The flow of requests, from request to implementation and release.<\/em><\/p>\n\n\n\n So if there is a new feature, let\u2019s just say a select input that does only filtering, it is the responsibility of the frontend engineers and designers to raise that need of a new component to the DS moderators to discuss.<\/p>\n\n\n\n You can learn more about team structures and dynamics in a great article here<\/a>. Federated team flow based on <\/em>Nathan Curtis<\/em><\/a> article.<\/em><\/p>\n\n\n\n This way we built it once and use it when there is a need. We always have a \u201cDesign System First\u201d rule.<\/p>\n\n\n\n We have two roles defined to smooth out our communication.<\/p>\n\n\n\n Moderators <\/strong>make document decisions, provide guidelines, do the technical review, and communicate updates. They also create space for doers to get the job done.<\/p>\n\n\n\n As our DS consists of two departments, Frontend and Design, there are two moderators: a technical mod and a designer.<\/p>\n\n\n\n <\/em>Moderators communication between teams<\/em><\/p>\n\n\n\n Doers <\/strong>are the system contributors\u200a and builders. They execute on proposals or requests, and set priorities based on the design\u2019s needs.<\/p>\n\n\n\n Yeah, it’s not what you think it is. Or maybe it is. The DS is not a product, so we don\u2019t have scheduled events, velocity, or retros. But we an agreed meeting every two weeks. This is mainly driven by the moderators to discuss new requests. They are the main members who need to attend, but both teams can join optionally as their input is important. This meeting is also where we vote on story points. Remember when we said that Product Managers who serve requests first are going to have them built? Well, story points help here for the team to know what it can create for the Design System. <\/p>\n\n\n\n Problems we encounter<\/p>\n\n\n\n Of course, all the above didn\u2019t work out of the box from day one! The first version was in beta mode. All the communication between us was unshaped. Let\u2019s take a look at the issues we faced while setting up our Design System and its processes. <\/p>\n\n\n\n As we have many products and different roadmaps, we need to keep different versions for breaking changes. Having different versions allowed us to run at different speeds. So if we had 3 products that had 3 different roadmaps, we didn\u2019t need to force anyone to always be up to date with the latest design system changes. Representation of versioning<\/em><\/p>\n\n\n\n At first, we were manually fixing versions and keeping track of everyone. This took a lot of time and energy and, as we try to keep our DevOps mentality, we had to automate it. If we have a version for our library, the design team has to do the same. <\/p>\n\n\n\n Now the system has automated releases (semantic) that we track. We introduce branches for the next release (major \u2014 breaking change release) that we have in the roadmap and we also have different versions in Figma, which match what we have and what is in the next<\/strong> version. Design and Frontend teams must be fully aligned with these versions, otherwise QA will fail.<\/p>\n\n\n\n We also needed to find the perfect tool for the job. We tried a couple until we found Figma<\/a> \u2764. <\/p>\n\n\n\n We started out with Zeplin<\/a>, where we had all of our design screens. But it didn\u2019t help our design team to keep track of their changes as their team grew. So we moved to Abstract<\/a>. That tool solved the problem of version tracking, kinda. But that was right when our design system took off, and the point where we needed to split all of our product designs into smaller components. So the key that changed everything was this word, \u201ccomponents\u201d. That\u2019s when Figma comes in. With Figma, we now had the power for different versions and component-based designs. Our teams need to understand each other. Figma gave us this in a simple way.<\/p>\n\n\n\n Pro Tip: we went through 3 tools to end up at Figma because we only discovered the growing needs as we used the Design System. Learn from our experience and use Figma for Design\/Frontend collaboration. <\/p>\n\n\n\n Oh boy, two different worlds under the same roof, you can imagine. We had (and we still have) miscommunication. It\u2019s one of the main ingredients of teams with different worldviews working together, we know it. The first and main problem was the main responsibility at the two ends. As the teams were working on the Design System, we were all questions like:<\/p>\n\n\n\n We discovered that we were tripping over our shoelaces! Thus, we assigned what we call \u201cthe Gatekeeper\u201d a.k.a the Moderator<\/strong> on each team. The Moderator is the go-to person for all of these questions. That person is not responsible to run all the tickets, is a member of the team but has to align with both teams to solve any problems and communicate with the other moderators for issues and features.<\/p>\n\n\n\n These two people now held the single source of truth, but we also have to make our decision-making more transparent. The solution was pretty simple: we started a Slack group where we shared our decision-making while we wrote it down on documentation.<\/p>\n\n\n\n As these things started to work well and we gained a good speed, we had to plan ahead. Our tasks, according to our federated system, must be visible to everyone to handle. We came to a place also when we wanted to have a rough calculation of how this affects all the other products. We know that we do well and all, but wouldn\u2019t it be awesome if we could say that we spent 10 hours building one thing that we used in 5 places? That\u2019s 40 hours saved! <\/p>\n\n\n\n For this, we agreed that we had to create a \u201cplanning\u201d event where the moderators will attend and all other members optionally can join. At this event, we are voting for each task and creating rough planning for the upcoming weeks. On the completion of each task, we also count the hours that it took to complete. This way we know what we planned and how long it took. Sounds familiar, agile people?<\/p>\n\n\n\n Lastly, as our process of doing things was<\/p>\n\n\n\n planning -> coding -> code review -> QA -> completion<\/em><\/p>\n\n\n\n We decided that we need to change things a bit to avoid doing code reviews on the wrong things. So for this case and only we switched to<\/p>\n\n\n\n planning -> coding -> Design QA -> code review -> QA -> completion<\/em><\/p>\n\n\n\n This way we give developers the sanity to review a finished solution.<\/p>\n\n\n\n So, the solutions that are in place:<\/p>\n\n\n\n Enough with the past. What does the Orfium Design System, Ictinus, have in its future?<\/p>\n\n\n\n Every decision we make is based on a need. Also, any change in previous decisions we make is for the same reason, a new need. Right now there are 2 of them that we need to solve.<\/p>\n\n\n\n Lately, we see that our two documentations (technical + design) need to be compared or be visually linked. This will help us develop, as we could visually compare in real-time with the design itself. Also, it can help any QA or viewer compare the actual outcome which adds extra value. <\/p>\n\n\n\n The planned solution for this is to link the storybook with Figma in two-way communication. <\/p>\n\n\n\n We have much room to expand here as we only scratched the surface. The plan is to add more QA to UX and UI. Also, as per our DevOps nature, we can add a solution to automate in any release to check if something changed as per documentation from any side and show exactly what changed.<\/p>\n\n\n\n Building a design system is challenging, literally. It will challenge the way the teams work and communicate, collaborate with each other and how the org as a whole thinks about more abstract solutions. It\u2019s a long road that requires constant fixes in both tech and processes. But it will pay off all the hard work when you see it in action. When one small UI or UX change suddenly affects 5 products and their users. <\/p>\n\n\n\n Of course, your design system doesn\u2019t have to match our story, because every company\u2019s DS may be bigger. Even a standalone product.<\/p>\n\n\n\n If you wanna have a glance at our project check it at npm<\/a> or Github<\/a>.<\/p>\n\n\n\n *Credit<\/strong> for all of this hard work must go to both of the teams, Frontend and Design. Plus, thanks for all the assets for this article!<\/p>\n\n\n\n Team Models for Scaling a Design System<\/strong><\/a><\/p>\n\n\n\n Evolving Past Overlords to Centralize or Federate Design Decision-Making Across Platforms<\/em>medium.com<\/a><\/p>\n\n\n\n Defining Design System Contributions<\/strong><\/a><\/p>\n\n\n\n Time to Separate the Small-and-Quick from Larger Things<\/em>medium.com<\/a><\/p>\n\n\n\n <\/p>\n<\/div>\n<\/div>\n\n\n\n Panagiotis Vourtsis<\/strong><\/p>\n\n\n\n Head of Front End Engineering @ ORFIUM<\/p>\n\n\n\n https:\/\/www.linkedin.com\/in\/panvourtsis<\/a><\/p>\n\n\n\n https:\/\/github.com\/panvourtsis<\/a><\/p>\n<\/div>\n<\/div>\n\n\n\n Katerina MIliaraki<\/strong><\/p>\n\n\n\n Product Design Lead @ ORFIUM<\/p>\n\n\n\n https:\/\/www.linkedin.com\/in\/katerinamiliaraki\/<\/a> <\/p>\n\n\n\n![\"\"\/](\"https:\/\/lh6.googleusercontent.com\/bFsQxHyJ-BeObxZ1fYA9EiTpKnXn7YWuUEesTNzhKZ4ukRiNutQwuY1LBPpAPs4UJXzt_9L8HBrnqBGelCQVNqBVokEGU7zjpI8YydtX22NKgziJZ8C0wIMzHW0AlfFqIhAyKfVG\")
![](\"https:\/\/lh3.googleusercontent.com\/JRMpnrQwFq5BXmYkj1ibxpmo3mKaogMs736eeGQYS34SU6YIWWIFqNvqcgIQfkoyzLhLvu_krmxy_nZJy1-Ri8SB-xz2WyArrSf8IUR11HoYrpXz_a6eaV-JBySEjGrd6RokViJB\")
How we did it\u200a\u2014\u200aFront-End <\/strong><\/h3>\n\n\n\n
Initial analysis<\/strong><\/h4>\n\n\n\n
First Baby Steps<\/strong><\/h4>\n\n\n\n
![](\"https:\/\/lh5.googleusercontent.com\/H2kdSDfjYZ8R9nJNGSkBsfq2enXd4e8JsLVuVQcOSJWWWZAGJqLte1lh5wuB3VsSx1Q0x5NhnvN6VkgTUl1GqddkXP-lPFtcTaGUksgdbYqpH7PUENoEAYH97RtY3izjLRb-Mwtp\")
Pro Tip:<\/strong> I suggest that you do that early and define it with the team.<\/li>
Pro Tip:<\/strong> A visual comparison of any external tool doesn\u2019t hurt.<\/li><\/ol>\n\n\n\nUse of a Federated team<\/strong><\/h4>\n\n\n\n
<\/p>\n\n\n\n![](\"https:\/\/lh3.googleusercontent.com\/Jn37rxe-Nq8pkn5nwvM9olLe-Y1x9-DY9mOfXnjPkKHQQ4ZOrK6oNmKScoL0x6blVLlX3mpGWolEFaWYBVCN7yMp4T_ujg2oPhmZ9iv3Bp6KNEyaSSirZDnjhmDwt6iTi_6HTHiN\")
<\/p>\n\n\n\n![](\"https:\/\/lh5.googleusercontent.com\/E0aT0rQWd_JJ2esSO0jRtsVKAB9cvv_8NnQUSvrU5ipv0-FyRabmYr6psNbCCUY5bV0K1J2afI0DeAR6oJJnqHHNJ_LSiBMi_-WFOudm54KrkPSw8xqoJh7-lybwD0Sd21sMedaZ\")
Furthermore, because there is no specific team for the design system, the request will be created as a task and can be handled by either the first developer available or the first product team member that needs to serve this in their roadmap.<\/p>\n\n\n\nRoles<\/strong><\/h4>\n\n\n\n
Planning<\/strong><\/h4>\n\n\n\n
Versioning<\/strong><\/h4>\n\n\n\n
<\/p>\n\n\n\n![](\"https:\/\/lh4.googleusercontent.com\/0g2HLRevVf7pLPpEgAi7SwcbG9R5vNk1NZgV_Y7Yg3jPgnj1Y0wi7PFGfp8WTp2BnO0nzHHl9YP0KkZB1op01IxKxE6Yh23r-z4HpvYciicTLwUO14D0mvb1jukd5SwWdooEA7wb\")
Wrong tools for the job<\/strong><\/h4>\n\n\n\n
Lack of communication <\/strong><\/h4>\n\n\n\n
What\u2019s next<\/strong><\/h3>\n\n\n\n
Documentations link<\/strong><\/h4>\n\n\n\n
Enhanced QA<\/strong><\/h4>\n\n\n\n
Conclusion<\/strong><\/h3>\n\n\n\n
References<\/strong><\/h3>\n\n\n\n
![\"\"](\"http:\/\/52.91.248.125\/wp-content\/uploads\/2023\/02\/pan-grayscale-scaled.jpeg\")
<\/figure>\n<\/div>\n\n\n\n![\"\"](\"http:\/\/52.91.248.125\/wp-content\/uploads\/2023\/02\/katerina_milliaraki.png\")
<\/figure>\n<\/div>\n\n\n\n