Positive impact on teams approach to digital products.
That design systems are an unavoidable topic in the product design industry these days will certainly not be news to anyone. Studies such as the Map of Design Systems in Portugal 2022 and other similar ones at an international level, show that it is almost impossible to work on product design without the topic somehow being part of the teams’ daily lives.
On the other hand, we also see that it is increasingly simpler to find content on the subject online. Articles, webinars, podcasts, practical guides, checklists, among many other hypotheses, are part of the extraordinary offer that we have available. All of this is amazing and helps the industry to grow and evolve in many ways. The public and online sharing of the experiences of many teams is a fantastic contribution to the evolutionary process of other teams.
As we look at this whole scenario, there are some patterns that jump out at us very easily. There is a great concern (and good) with the technical part of design systems. A lot also because, especially on the design side, of the theme’s association with software companies like Figma or Zeroheight. The perspective of how to build design systems and the impact that software has on this instrument is a topic that occupies a large part of the community’s discussion.
Excellent execution is halfway to success. A good idea (or good intention) with poor execution or that does not use the best tools to do so, will always have a result below expectations. How to build component libraries, what are the best tools to liaise between design and development teams, how to document components, are all very relevant questions, but they are only part of the equation when it comes to design systems.
Working with design systems goes far beyond all the associated technical component. This is all a fundamental part of the process for sure, but at the end of the day it’s only part of the equation. Working with design systems is much more than building and maintaining libraries. Working with design systems, truly in the broadest sense of the concept, has much more to do with the mindset we want to work on, more than with the artifacts we want to work with.
The way we look at the design (and development) process, more than the component design tasks. The perspective through which we are going to look at each problem and the fundamental principles that will guide everything that happens in each sprint, whatever the objective may be, this is the design systems mindset.
Concepts such as simplicity, iteration, modularity, scalability or sharing are probably the easiest to come up in a conversation when the subject is design systems. As it turns out, none of these concepts play easily with the idea of a design system confined simply within a Figma library or a codebase in any Storybook.
The application of these and many other concepts that we usually see associated with the topic of design systems, has its true application, when we look at design systems more as a work mindset to support the construction and maintenance of digital products, than as a creation and management of drawing or code libraries.
1. Simplicity
Simplicity is a concept dear to design systems. No one will say they want to build a complex design system, but the truth is that it’s not hard to find design systems with extra stuff. Components with too many variations or with similar functions and with merely visual differences, color palettes with so many shades of color that most of them will never be used in the product or, just to give some examples, rules and more rules that would take much more time to understand them than the one we have in each sprint to work with the design system itself.
All this can look fantastic in one or several Figma files, super well organized, with emojis and everything in the mix, but the truth is that when this happens, it is the concept of simplicity within the design system that is harmed. The process of truly understanding what we really need to have within the design system and how this will have a concrete application in the digital product we are building is a fundamental part of the design systems mindset.
2. Iteration
Nothing is closed. This is one of the phrases we say most often in digital product teams, be they design or development. But the truth is that we are, in most cases, permanently in sprints to “close” things. It is that component that has to be “closed” because someone is in need of it quickly. All those tasks where we say let’s close the first version to move fast and then we go back there, but we rarely go back there.
Iteration is not just a nice word that looks good in any presentation. It is a very strong (and very valuable) concept that allows us to grow the digital product (and the design system) as if it were a living organism. A comfort with the permanent discomfort that nothing is written in stone and everything is a result of current needs that may change in the future.
3. Modularity
We’ve all been there when someone on our team tells us “this is just a simple thing”. I’m afraid there’s bad news to deliver at this point. Nothing in a digital product is simple. Let’s think about the complexity of the digital products we use (and help build) every day. In everything that’s behind. The complexity of business and technology. All variables that have a big impact on the interaction between people and systems. None of this is simple, none of this is easy to make happen. But this is our mission.
All of this means, among many other things, that none of this is going to happen all at once. It is fundamental to be able to break down problems into parts and this in a digital product (and in design systems), that is, to understand how we will build a whole, using and recycling small parts as much as possible. Combining parts that we didn’t even imagine could be combined but that in certain contexts might make perfect sense to be used together. Thinking that we are always building parts, rather than finished works, can be halfway to bringing the concept of modularity into the true mindset of design systems.
4. Scalability
Design systems do not always make sense in an organization. Especially in smaller contexts, building digital products using design systems can be more work than it is worth. The natural habitat of design systems (or if they weren’t living organisms) are large organizations with one or more digital products. This means that in organizations of this type, economies of scale are not an asset, they are imperative. How many times do we not see different departments of the same organization investing money to do exactly the same things (who never?).
Economies of scale, whatever it may be within large organizations, are a difficult path, but a mindset that when rooted can bring fantastic benefits to the organization. Imagining for everything we do, inside and outside the context of the design system, that that solution may not be confined only to that initial context, but how it could be used in other contexts of the organization, can be an extraordinary exercise of “imagination”. Always having as a background thought, how each solution can be expanded to other needs, is a trick that can gradually help us to create very interesting economies of scale in any organization.
5. Sharing
Working in a team, or as it often happens in the context of design systems, in very large organizations is a difficult mission. Large organizations means many people. Many people, I mean many different perspectives, often different from our own perspectives. This is a wealth that in some cases can have a perverse effect. People may be afraid to share what they are doing, a little of their work, for fear of exposing themselves to criticism from colleagues or even superiors. It is true that in many organizations this is not quite the case, but in many others this is day to day.
This type of context is very challenging when we talk about design systems. When it comes to digital products, the lack of sharing the good solutions but also the failures of the teams, can mean a huge waste of money for the organization. In large organizations, “ownership” must necessarily be collective. There cannot be “my solutions” but “our solutions”. Shared and available to anyone who may be useful. Be it processes, customer survey models, design system components (of course), templates, everything can and should be shared within the organization. After all, aren’t we all in the organization headed in the same direction?
The next time you are going to work on the design system of the digital product you have in your hands, try the following exercise. Stop 5 minutes. Put down the computer mouse and keyboard and ask yourself: “in addition to libraries, what other benefits has the design system brought to our digital product, what benefits has the design system brought to our organization?”. If the answer is something like “now we have more components to use”, maybe this could mean that the design system in the organization is still just a library and not a mindset.
The day you realize that in an organization that has a fantastic design system (not because it’s a design system with many things), the teams manage to do a serious exercise in always looking for the simplest solutions. Who look at everything more as an iterative process and less as a “closed” task in Jira. Who build solutions building recyclable modular pieces in different contexts. That the economies of scale of scalable solutions are a recurring reality. And that there is a true open-source policy of transversal sharing throughout the organization. So this could very well be the day that the design system stopped being a library and became a mindset. And this day should be very celebrated.
Read and share more about at www.dxd.pt
Read the full article here
