How we improved the workflow between product designers and frontends
Written by: Francisco Gileno Oliveira and Bruno Perruci
At Inloco, one of our fundamental goals is speed. However, we need to be fast without sacrificing consistency between projects. This is a challenge with building complex products, and the frontend and design teams face it every day.
Not so long ago, there was a lack of visual consistency among our products, meaning each project followed its own design concepts and implementation.
An obscure past
During these dark times of our journey, there was no one set of clear design guidelines meaning each designer had to define their own interface rules. There were no clear guidelines on colors, spacing, fonts, borders, etc.
The frontend team used to work on a very outdated and limited UI library, not accessible, hard to maintain, and scale. Besides, not every project used it.
In this scenario, it is quite easy to imagine how poor the user experience among our products, making designers, developers, and mainly our users unhappy.
The light at the end of the tunnel
We gradually discovered these problems and realized that, in addition to hindering the end-user experience, we were also hampering the performance of our teams, given the amount of duplicate work between our squads.
We knew that we needed a single visual identity, design system, and robust component library, but one question arose:
How were we going to convince Inloco to free up resources to build all this?
That is where another essential company value comes in: autonomy. With obvious benefits and the right framing, it was easy to convince the team to contribute to this initiative. We called it Orion.
Orion
Orion consists of:
- Component library specification
- Frontend library implementation
In addition to all the positive points already mentioned, Orion made the design and frontend teams work more closely than ever. After several definition meetings, we had aligned design and frontend and were working towards a common goal. Our attunement became clear to the end of becoming fans of each other.
Component library specification
For the creation and maintenance of the components, we used Atomic Design logic created by Brad Frost back in 2013. This helped us to maintain consistency between components, in addition to facilitating maintenance within the prototyping app file, in our case, Sketch.
If you want to learn more about Atomic Design, I recommend reading this post in which Brad Frost explains the logic behind it.
With the strategy for creating the components defined, some additional questions arose:
How do we share the library within the design team to make sure everyone has the latest version?
We researched several platforms, such as Abstract and Kactus, and after implementing some tests and evaluating budget and speed, we chose to start using Kactus for version control and sharing. However, shortly after we made this decision, Sketch launched the native Libraries functionality, and we migrated to it.
With the atoms, molecules and organisms created and already being used by the design team, we now needed to move on to templates and pages.
However, we faced another challenge:
In a startup with products that have entirely different needs, how do you create these patterns without limiting other designers?
To solve this, we bet on not creating templates and pages that can be reused, but rather, we created guides of good practices that must be followed when prototyping a solution using Orion. This guide (guide in PT-BR) contains recommendations for organizing files and folders inside Sketch, base sizes for floating components and spacing, and grid creation logic, among other details. Today, almost a year after the launch of these guides, we are able to give flexibility to our designers, allowing them to propose new solutions while maintaining consistency in the UI of our products.
Frontend Library
We use React on all projects which facilitate our development. But another question came up:
Is it worth building a library from scratch?
After researching a bit, it was clear to us that starting a library from scratch would be a mistake. Today, several component libraries can be used as a base, which contains useful abstractions, good accessibility, and is easy to extend.
After testing and doing proofs of concept, we decided to use the Semantic UI as our base library.
Semantic UI is a widely used and very well tested library. Its components are very solid and allow a level of abstraction that is difficult to find in other libraries.
We adopted some core components like input, dropdown, button, etc. from Semantic, and we created more specific components from scratch following the guidelines of the design team.
But there was a big challenge:
How were we going to add our visual identity to an existing library?
In the React version of Semantic UI, the components are entirely independent of the CSS, meaning that the components only set the class attribute.
So we decided to rewrite CSS from scratch using our beloved Tailwind CSS.
Tailwind CSS
We are fascinated with Tailwind, as it fits perfectly with our idea of standardizing style.
After a few meetings, we customized our tailwind config file, which allowed us without repetition and exceptions, to standardize:
- Colors of our palette
- Spacing (width, height, margin, padding, etc.)
- Shadows and opacity
- Typography
- z-indexes
The CSS file generated from Tailwind is ~35k (gzipped), containing 99% of all the rules we need.
Documentation
We document all our components using Storybook which help us to:
- Know which components are available
- Test all component variations
- Validate the component with the designers
Design ❤️ Frontend
Since this project began, we have managed to evolve both the communication process we used to construct the library components and how we use them to build products. To do so, we created some dynamics and points of contact. Let’s talk a little bit about them.
Feature review
After creating a solution, be it a large or small feature, the designer always does a review of what was delivered by the frontend team. This review covers both the visual, interaction, and behavior of the UI.
To make this communication fluid and efficient, we created a document shared on Notion with a table in which we freely describe the problem (it can be GIF, written explanation, image, video …) and some columns for internal control (such as the name of the developer responsible, the person who reported the problem, whether it has already been fixed and deployed, and the expected solution).
#Orion
For library issues, we created a channel on Slack where anyone can raise questions about the library, such as questions about how to use it or feedback on components that may be missing. We also use the channel to inform the team about new versions, changelogs, and, lately, whenever a new version is made available, we create a thread to discuss possible solutions in the front-end implementation.
Tech grooming
At Inloco, the design team is always involved in discovering new features for the product. It is common to work with a Product Manager in this exploratory phase. Right after that, our workflow is to create a draft of the possible solution, and, after validation, we meet with the frontend team to:
- Check for potential implementation problems due to web limitations
- Align and define alternative flows, such as loading, error states, etc.
- Define what is a priority, establishing what we need to deliver in versions 1, 2, etc.
This meeting is essential for aligning teams before the implementation phase, ensuring that there are fewer surprises.
Conclusion
Today, we are more productive than ever at building complex UI for our products without losing consistency.
For us, there is no way to build proper tooling without collaboration between designers and the frontend team. We are delighted to work together.
Of course, there is always room for improvement, but today we are proud to have matured as a team and built a reliable workflow. We hope this post helps you to develop your own.
Thanks for revisors and colaborators: Luiz Caúla, Thalles Cezar and Morgan Grandi.
