oi
Maintenance of the mobile section of Kyte's design system
Kyte's Design System was made by designers who were no longer with the company, but most components no longer served the company because they were created in an extremely complex way, and the design team no longer felt comfortable using them.
Because the documentation is not clear, the Design System instead of being a support for designers it has become a bottleneck. That's when the team made the decision to completely update it, going from the fundamentals to the page templates.
The main challenge of this project was to carry out a complete inspection of this legacy to try to reuse elements that could still be useful, conciliate the task of rebuilding a design system with the frenetic demands of a Startup's day-to-day and clearly communicate the changes for Dev. Team to be able to keep the component repository up to date.
It was essential to create an inventory to inspect, catalog and categorize all existing material to separate what would be reused and what would be discarded. To be able to handle all the work, we divided it into Mobile and Web and created a backlog with all the tasks. The Mobile part of the DS was under my responsibility. To create a bridge with the development team, we made an alignment with the Front-End tech-leads, and decided that to implement the updates we would elect (in order of impact) a component for each sprint to be refactored.
After the construction of the new components, the friction that existed in the workflow reduced considerably, because in addition to being simpler components to be used, their naming logic made the construction of navigation flows much easier.
It was clear to see the benefits reaped from the project with the reduction of the delivery time of new features and in addition the process of maintenance and adaptation of the proposals under development became more agile.
The main lesson I learned from this project is how important detailed and timeless documentation is, as knowledge about a company's processes and guidelines needs to be available not only to today's designers but also to designers to come.
One of the main steps in this process was the creation of the legacy inventory, as this way we obtained a macro view of all the material we had and thus managed to avoid rework. In addition, at that moment we realized that there were some components that were being used in many different screens and flows, including in projects that were already in the hands of the Dev. Team, and that any minor change we made could break the layout and perhaps create a bottleneck in the development flow. So we decided to keep using the legacy for a while until the teams were able to build a good buffer of tasks to reduce maintenance risks.
To optimize the use in figma, we taxonomy of the components so that they are organized “by folders”, in this way, in addition to facilitating maintenance when necessary, it also facilitates their use in the files. It was also necessary to rework the style and component libraries to make sense with the new information architecture we were developing. This process was watered with tests and iterations until arriving at an ideal model that made sense. We also reviewed the styles that had already been created in order to give more versatility and freedom when creating.
Em determinado momento percebemos que a biblioteca de componentes (Storybook) que estava sendo utilizada pelos desenvolvedores estava completamente diferente do que estava sendo utilizado no Figma, então antes de prosseguir fizemos um alinhamento com os desenvolvedores para ficar na mesma página. Apresentamos todo o trabalho que estávamos fazendo e as motivações para fazer a atualização, e eles compartilharam conosco todos os componentes existentes no storybook e também nos trouxeram os design tokens já existentes para que pudéssemos reaproveitar o que dava também no figma. Eles se foram bastante solicitos e falaram que essa lacuna de documentação também os prejudicava. Após esse alinhamento ficou decidido que o tech lead iria eleger um desenvolvedor para acompanhar de perto e colaborar com a atualização e também seria responsável pela construção dos componentes em react e atualização do stotybook.
