How we improved the workflow between product designers and frontends

Bruno Perruci
Aug 24, 2020 · 6 min read

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).

You can get the Notion table template here

#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.

Inloco Tech Blog

Find out about Inloco’s tech team: product development…

Thanks to Gileno Oliveira

Bruno Perruci

Written by

Product designer, sci-fi fan, coffee geek and punk listener.

Inloco Tech Blog

Find out about Inloco’s tech team: product development, tools, architectures, operations, and more. https://inloco.ai

Bruno Perruci

Written by

Product designer, sci-fi fan, coffee geek and punk listener.

Inloco Tech Blog

Find out about Inloco’s tech team: product development, tools, architectures, operations, and more. https://inloco.ai

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store