From the beginning of the project we understood the need for a design system. I believe that, however minimal it is, every project needs a component library. Component libraries make developers' lives much easier, and for us (products, ui, ux or any other acronym...) gives us a good macro view of the project and with a certain systemic bias , we leave aesthetics aside and focus on the pure function of a component.
It was not easy.
Our first clash was the project itself. If you search for design system on Google, you will find the following sentence: "The design system is a product that serves other products." but what to do when the product to be served is not understood? And when we don't have time? And when our priority is o discovery, ux and screen delivery?
At first I used Material Design as the basis for our design system, this is the smartest approach to take when we don't have time or resources in our favor.
I started with ready-made components from a small library we had and of course I didn't get very far. Making something from scratch is not easy, making decisions about functions that will work in different contexts, preparing a legacy for future teams is not just building a project, it is building a concept. Before talking about components I need to solidify a base, like in a house I need a foundation.
First, I stipulated the principles of the design system, I find it interesting to give it an identity so that any professional who enters the project is already in the its essence.
And those are: Metaphor, Intuition and Personal Design.
"Fun.da.ment: Set of works necessary to solidly lay a construction: start the foundations of a building."
O fundamento é tudo aquilo que serve de base para a cosntrução de um componente .
See the examples below:
We have two states of the same component, how am I going to speculate that state if it doesn't assign any function to the colors? Colors are not components, but in a project they have a systemic and semiotic function.
Mapear elementos e não são componentes mas fazem parte essencial deles é como dar um passo pra traz para enquadrar uma photo, Atomic design explains this in a very clear way: inside a structure there are molecules and atoms, here I called these molecules fundamentals.
About processes
According to Nathan Curtis, “A Design System is not a design. It is a product that serves a other products" and this is how it should be treated. At the beginning of the project, we tried to fit the construction of components into our delivery routine and the results were just a compilation with a little more than half a dozen components without any technical specification. When we looked at the design system as a separate project, I was able to devote time to further research and thus build a much more solid document.
Dado beginning a construction of the design system the expectations were of a linear process, something similar to a classic production mat: ideation homologation and development but it is not.
How we imagine the process of creating a component: a tangle of discussions and tests. after. delivery for development.
But in fact it is like this: the creative process of a component depends on other components, as well as depends on the fundamentals and, at the same time, it must be functional and consistent. This generates a round trip natural. It is necessary to test because there are situations where the component works in one context and not in another.
Establishing a creative process that is not a linear treadmill does not mean a messy process, I established a simple kanban for my personal control, with some very useful topics so I managed to keep the creation process focused on agile and I didn't get lost in these day-to-day comings and goings.
Component mapping: in this first step we mepe all the screens looking for the components to be made, here our intention is to raise not only how much this component is used but how it suffers "breaks", that is, how many times it is (or can be ) modified.
For example: How many titles do we have? What's the difference between them? What is the function of each one?
Research: Here we do a deep research on this component, what it is, what is its use, nomenclatures and derivations, this helps a lot when it comes to achieving a universal language for System design, we work with many terms in English on a daily basis and some elements may contain nomenclatures or regional terms it is always important to research.
Component discussion: With this information and with the components mapped, I can open a discussion with other designers or not, this depends on the complexity of the component and how much it is used in the project, in general we discuss its usability , possible failures and developments.
Refinement: Here some fine adjustments are made to the components, we adjust it to the library and create variations (component state).
Homologation with Devs: A technical validation aimed at development.
Structure of a component
A behavior has the structure:
Cor
Type
icon/image
Spacing
Margin
Form
Occupation
All these details must be chosen very carefully, as they must work in any context.
When a component is structurally done, I write a text explaining what it is, why it was made that way and how to use it. I also explain rules and spacing and margins, exceptions and derivations. So I keep the System design independent, anyone can create a new component or even modify an existing one.
Doing a System design is not easy, it requires dealing with the very notion of rhythm and productivity, looking at the macro and the micro simultaneously, being flexible and maintaining focus. It's something really crazy, it's almost philosophical, whenever people ask me what I've learned, I think my answer doesn't meet the expectations of the curious, my answer is always the following - "I learned to let go, nothing is perfect. Sometimes The best thing you can do is stop being a perfectionist. Focus on delivery. These minutiae that we are so attached to are always put to proof once the Design System. " - And it's true, I have a pretty long list of technical details about UI and UX that I've learned, but this is the biggest lesson.