A case study about a design system implementation
Designer vs Devs: All about communication
For nearly two years, I have been a part of the UX/UI team, which consists of four designers and two front-end developers. We have been working on a B2B application that involves approximately 100 people, including designers, developers, product owners, process experts, and scrum masters.
The project is a highly intricate agile one that is constantly evolving. The company that owns the application has just introduced a Design System. We have been tasked with finding a way to integrate this design system into the portal.
Design systems, especially for large companies, have great value and can lead to cross-platform consistency that would otherwise be difficult to achieve. But what happens when we have to transition a web application with 6 years of development behind it and countless flows created with a completely different library?
The key points to consider are as follows:
- We are operating in a technology-driven environment that is regulated and offers limited opportunities for design enhancements.
- Our project follows an agile approach and involves a combined UX/UI team as well as six front-end and back-end development teams. The backlog will keep them occupied for the entire upcoming year.
- The application is developed using a specific programming language, but the library used is independent. Some front-end logics related to the components vary.
- Technological progress is inevitable.
- There is a high turnover rate on the project, and the developers in the individual teams struggle to maintain an overall understanding. Over time, numerous UI misalignments have accumulated, and although the guidelines are documented, they are not consistently followed.
After conducting various analyses and considering different proposals, it has been determined that the best course of action is to replace all the components, page by page. Sometimes this will require redesigning the pages due to outdated components or design patterns. As a result, there is a need to transition in small steps and to begin using the new library for new sections. This will prevent wasting resources on parts of the portal that are already outdated.
However, as things currently stand, this would lead to what we have called the “Frankenstein effect”. Therefore, having a portal with outdated graphics and a few new-looking pages.
It took several months of analysis and collaboration with both the business and the developers to gain this understanding. We focused on identifying important issues, potential bottlenecks, and areas that needed attention. We also acted as mediators between different project stakeholders to ensure that we fully comprehended the development challenges and could propose practical solutions that aligned with the business goals.
So we asked ourselves how we could avoid or limit this obvious visual misalignment, without impacting the various teams already overloaded with activities.
The proposal, which was later approved by the client, involved restyling the current library to closely match the design system. We focused on updating the CSS for 80% of the components while keeping the integration logic unchanged. A full extreme make-over project!
Completing this task was quite complex because we encountered a pre-existing library that had been built over the years with different variants added from time to time. These variants often didn’t directly match the UI Kit that designers had on Figma.
It became clear that collaboration between design and development was crucial for implementing the necessary style changes.
The experiment was a complete success, and both the front-end developers and I were satisfied with the work we did together. 🚀
Managing the delivery of this project taught me a lot, both technically and in terms of communication.
I want to share 7 important lessons that I learned, hoping they can be useful to designers who sometimes struggle with development, to work better and more peacefully!
Tip #001
Designers, be a bit of a developer
In order to communicate more effectively, it is important to understand the perspective of your audience, both from an empathetic and technical standpoint. I believe that all designers should have a basic understanding of CSS and HTML so that they can better communicate with developers and find common ground.
Understanding the work of developers will also help you differentiate between technical limitations and the need for visual solutions. It will also allow you to gauge the time needed for certain activities before making requests.
Tip #002
Play with google inspect
Make sure to familiarize yourself with technical vocabulary and use the words correctly. Spend time experimenting with Google Inspect to understand it better. Try making changes to a website to identify different elements.
Also, take the time to learn the terminology: understand what a class, a variable, a div, a margin, and padding are. Learn how to utilize the bootstrap grid, understand its advantages and limitations to effectively address development challenges, and find solutions quickly.
Tip #003
Release branches and others unfamiliar words
Try to understand the development environments, technologies used, and release processes. Attend front-end alignment calls and make an effort to fully comprehend the discussions. If there's anything you don't understand, ask the developers for explanations. This will help you plan activities in alignment with the project's functioning and anticipate any critical issues related to releases.
Also, this will prevent you from finding something in the production branch without knowing it will be released.
Tip #004
Figma is not code
Figma is a great tool for designers, but what you create in Figma doesn't always translate perfectly to the final product.
It's important to communicate with the development team to understand any potential issues between the design and development processes.
While Figma's dev mode helps start a project from scratch, it may not be sufficient when working on an already-developed project.
Tip #005
Create comprehensive documentation
80% of the work involved in restyling the library was not the actual redesign of the components in Figma, but rather tracking all the changes made, listing them precisely, and providing them to the development team.
We shouldn't expect developers to be able to easily spot the differences between the old and new designs and independently understand the changes needed for a component. Not everyone has the same visual sensitivity.
From a design perspective, it might be easy to see the difference between two fonts at a glance, but not for a developer. And that's okay.
Tip #006
Communicate with the dev team
There is often a tendency to work in silos, so once the design activity is finished, everything is handed to development with just one initial KT moment. For delicate activities such as the restyle of an entire library, working like this would have been a disaster. The coordination and quality assurance role played by the designer is fundamental and cannot be limited to an initial brief.
Set review moments to check together small pieces of code, testing them in all their possible applications. In this way, you can limit the amount of fixes to be made later by going back to activities done months before.
Tip #007
Make mistakes and learn from them!
Despite following the best practices, you may encounter misunderstandings or misinterpretations.
Instead of letting them cause conflict, learn from the mistakes made by both parties and value them for the future. 🙂