Currently there is a wide variety of articles that talk about different models used to create or adopt a Design System, regardless of the project we are working on.
Among the advantages of working with a Design System we can find that it provides consistency throughout the development of the project since we standardize elements and this at the same time allows us to reuse components through an orderly system. The purpose of implementing a Design System is that teams made up of several members can work with the same standards, at an acceptable pace and with the same elements, here we must make special emphasis since its correct use will save us a lot of time in revisions and corrections, but, is it always necessary to implement it?
Why should we implement a Design System?
First I would like to tell you why it is a good idea to consider it within the stages of a project, and for this I will rely on an example that many designers have experienced. I think most of us have experienced that after a few hours of work on several screens, we are ready to unify our work with the rest of the screens that were developed by other team members and to our surprise… the unification results in something like this:
For our purposes we can say that these images are equivalent, because far from looking like a joke we find a file with multiple styles and not only of buttons, but we discover that the same typography was used, but in different sizes or that the color is very similar but not identical … in short, a chaos within the file and many components without standardization.
At first, we could say that these are not serious errors and that the essence is maintained, but here is where we identify the second aspect of why implement a Design System and that is that designers, on many occasions, do not consider the developers and the “bomb” with which they have to deal, in addition to the ordeal that we pose to them with such messy files or inputs.
Which button color should I choose? or what is the right font size? These questions are just examples of what could happen in the best case scenario where developers become aware of these differences, but what if they don’t find out and just take as reference the first element they find? We could be carrying a problem that becomes increasingly complicated and tedious to correct and our technical debt as designers increases. This has an impact on the efficiency and productivity of the team, which brings us to a third point, the less we have to correct the more time we can spend on improving other relevant aspects or projects.
We are clear that it is not only a matter of execution but also of work methodologies implemented in the team, but that is a topic for another article.
Now that we are clearer about the benefits and what a Design System can bring us to our projects, we can look back and analyze if these features fit all of them, but have you thought about the effort required to generate these component systems? And more importantly, when to create them?
How and when we created our Design System?
This question is not easy to answer, there will be a lot of colleagues who will answer it from the theory that can be studied, but the practice in most cases is not one hundred percent faithful to what is written and from this perspective is that I will share our experience. Each project must be approached as a particular and specific case, due to its unique characteristics or the area of interest it covers.
If we see the development of the project as something linear and without variation it would be very difficult to locate at some point the implementation of the Design System, there are factors that can influence its creation such as the scope of the project; sometimes this is limited to the redesign or expansion of a specific functionality, it may also be that the client does not want this material for your project, so in these cases it is not possible to create the system and this does not mean that it is a poor or bad project.
On the other side, we could find a project that due to its complexity and the amount of equipment involved demands a system that helps to maintain order and control.
MVP vs Positioned Product
Let’s see a couple of examples to clarify this point, first let’s imagine that the company we work for develops its own digital products (such as Spotify, Airbnb or Netflix) and is about to make an improvement in any of its previously developed platforms, if it does not have a Design System we could face all the calamities we mentioned above, working with similar components but not the same as those in the platform, that the work between designers and developers is not fluid or even design patterns change.
This would directly affect the consistency and the perception of the brand that your users were counting on. The appropriate thing to do in this case is that if at this stage the library of components is not available, then the Design System should be generated prior to the new enhancement. At this point, the advantage is that by having a previous platform, the composition is simplified since the elements are standardized and the main task would be focused on the compilation of these and the generation of the library as input.
For many companies this work was an empirical learning over time, so probably its implementation was given in some advanced version of the platform, so the incremental improvement is notorious.
But now let’s look at the second scenario, does the same thing happen when working on an MVP or a totally new project? In many articles we have found that the ideal moment for the creation of the Design System is before starting the project, even in the previous example we could see it, but how do you generate a library of something that does not yet exist or whose design is not yet defined?
It does not make sense to invest time and resources in a library that will be constantly changing during the beginning of the project and could even generate confusion, in addition we have the need to generate products promptly for testing and this is where a decision must be made based on the context and characteristics of the project.
For a scenario like this we can find alternative solutions that are not necessarily a Design System as such, but they work in the same way, provide order and allow a team to coordinate in a better way.
There is also the possibility of working directly in the main file of the project and create the basic elements from there, here the recommendation or good practice would be to create and save them as symbols, for example a tool like Sketch allows us to do so, this ensures that when working with the file we find there the standardization and order necessary to work more smoothly, this option is recommended when it is a person who is developing the project and not a team, because when working locally the possibility of sharing the library and to update it is difficult.
The advantages of having a Design System are many and are notorious, but the reality is that beyond requiring teams that understand and make the most of these tools, it is necessary to understand that a Design System for each project developed can mean a workload and a focus of effort that at the beginning are not essential.
With positioned products all this work philosophy makes a lot of sense, but when working on such varied projects, of different scales, with different scopes and with different budgets, the reality is that other options may be more flexible, which eventually in the future will allow the creation of a Design System of its own.
We are a company that transforms your ideas into business opportunities, rely on Interfaz.