View the original post
Accepting the Holy Grail of UI Design
A jigsaw puzzle tarts as a whole picture before it’s broken down into pieces. You’d have a terrible puzzle if you designed the pieces first, then later discovered they don’t fit together! — Andrew Couldwell
You can google about design systems and get a lot of articles and information about the same. But I’m not here to help you tell what is a design system, but instead tell how design system can streamline your entire development process.
Communication gap is something that I have came across a lot that happens between the designers and engineers, in many firms and studios. During the implementation duration it may crop up has frustrations and disputes. Effective communication is required between engineers, designers PMs and head of engineering to make these systems effective.
Effective collaboration between developers and designers is required to build a frontend for an MVP in a few months. Engineers are perceived as terrible communicators. However, disagreements between designers and engineers are not caused by engineers being fundamentally bad communicators.
WHY NOT THE HYPE?
One widespread misconception about design systems is that once developed, they become an all-powerful and immutable source of truth. Thinking in such a rigid approach is a sure way to have your design system effort backfire. If customers feel trapped and pigeonholed into using patterns that don’t solve their problems, they will dismiss the design system as a useless tool and go elsewhere for something that will better fulfil their demands.
The holy grail of design systems is to create an environment in which the pattern library and real-world applications are perfectly synchronised. The goal is to be able to change a UI pattern and see it immediately reflected in both the pattern library and everywhere the pattern is used in production.
LOOKING BEHIND THE VEIL
When we merely consider displays, we do not obtain a thorough grasp of the numerous components and how they work together. This may result in inconsistencies and problems with the user interface. Features that span many interfaces may be added as an afterthought to the interface rather than extensively investigated. The concepts of modularity and reusability are core to the software development mindset; it is done in the code, therefore it stands to reason that it should be done in the design as well.
Aside from conceptual issues, the method has so far discouraged conversation. It encourages us to perform tasks on our own and to stay primarily inside our own industry. We only share and talk when we’ve completed our tasks. Working alone diminishes empathy, which raises the probability that conflicts may be taken personally. Working in isolation also entails that we use various terms to refer to components and concepts and have different ideas about how to implement state and animation. Despite the fact that we are talking about the same thing, we are speaking in different languages.
WHAT ARE THE ADVANTAGES?
Using a design system has various advantages. It results in a more uniform UI/UX, which the user can understand more quickly. When you’re not reinventing the wheel, it’s easier to plan and create, and there are fewer complications (reusing patterns and focusing on distinct components make it more manageable to implement different forms of testing and add accessibility). Putting those reusable, well-tested components into a component/pattern library offers a shared vocabulary for everyone in the organisation, making product communication easier.
A design system has the ability to serve as a public pool for the whole organisation, aiding in the formation of a common vernacular for all disciplines engaged in the success of the company’s digital goods. Establishing a common language inside an organisation may result in more efficient work, enhanced communication, and more collaboration across disciplines. As a result, the style guide should be a welcome destination for all users of design systems, not only design system users.
You wouldn’t offer someone a iron, a welding machine, and a screwdriver and tell them, “OK, you’ve got all you need; now go build me a lovely new car.” Knowing how to utilise a tool correctly is frequently more essential than its availability. Documentation in the form of a style guide is unquestionably beneficial, but it is insufficient on its own. To guarantee that your design system’s users successfully get up and running with the tool kit and continue to generate exceptional work with it, it’s critical to give proper training and continuous support.
More communication, more frequently and more openly, is at the heart of what has been effective trying to implement design solutions in this effort. This includes designers and engineers working together to finish components, knowledge sharing sessions that provide insight and empower one another, and face-to-face communication. We must exercise greater communication and collaboration on a regular basis, explaining our own thought processes and ideas. That is how we progress.
You can have the best style guide in the world, the most advanced technology, an outstanding staff, and passionate users, but if you don’t actively promote the design system and convey updates, the entire endeavour will suffer.
Propagandizing your design system may and should start before it is ever deployed. To help create awareness and passion for the design system endeavour, you may put up places to track project progress at the outset of your project.
Ending note — more discussion, more acceptance and more love for design systems would lead to more healthy channels of acceptance for the same.
Thanks for reading 👍.
Connect with me and let’s share our knowledge!