Standardising Product UI with Design, Product, Development Teams
In this post, I want to share my personal experience working in my team of in-house designers and an intern, to create a collaborative process with developers to standardise the User Interface (UI) component design and development process.
Challenge
The project I am working on involves a B2B enterprise solution. The product is complex and has many different features used by various user groups within and outside of the ports. The production and reselling of the enterprise solution are conducted across different ports in the world. Hence, in order to deliver a comprehensive solution for our clients, multiple product delivery teams work on various features simultaneously.
Apart from looking at the UX and UI of the existing product design, there is also a need to propose a revamp of the new look and feel for the product.
While different teams are working to develop the respective parts of the solution, the UIUX Team has to propose an entirely new UI Design System which has a more modern, new look and feel.
As the design team is very lean with only 2 designers (including myself) and 1 intern, we work with leads from the product delivery teams to share the ownership of designing the solution for different groups of users. With the prototyping also done by the Product Leads themselves, the UIUX team has to review and suggest possible improvements to advocate for user-centric design as a whole.
This enables the role of the design team to be on a governance level, advocating for user-centric designs that consider the product and technical constraints faced by other teams.
In addition, it is also a challenge to discuss design concepts with developers, and at the same time streamline the way product designs are created because of how the teams are structured and working on broad or overlapping areas.
For example, the product teams are responsible for gathering the business requirements from the client and sharing user requirements (including user needs, pain points, and other feedback consolidated by the client’s business analysts) with the design team.
From there, Product Leads take ownership to design Figma mockups before seeking design consultation with the designers to look at the UX and UI together. This is important in making sure that the solutions meet the users’ needs and look consistent across the whole product as much as possible (there are dozons of modules that makes up one product).
During such design consultation sessions, you would often hear feedback from my team that:
“the design is 1 pixel off from the grid”,
“you could standardise the capitalisation of the texts”, and
“you could reconsider the layout of the page so that it’s more user-friendly and consistent with features already implemented by other teams”.
Hence, with the product teams working concurrently on different modules and features for different user groups, it becomes increasingly challenging to ensure that the design and development of the UI are consistent across the product.
How might we enhance collaboration between the design, product, and development teams so that the product design and delivery process can be streamlined?
Solutions
Firstly, there could be a way for the design and product team members to design high-fidelity mockups using common components that are available available in both the Figma library, and in the code repository (AKA developed).
This would also serve as an inventory to align the Design, Product, and Development teams on what component designs are already available for the project, or what is not available yet.
And because there is a need to propose a new look and feel for the product in the next phase of the project, it is possible to create a new UI Design System to facilitate how design and development teams can co-own this piece of work.
For Product Leads who may not have the experience of designing in Figma, the Design System would be their best buddy in guiding their prototype designs. Thus, the Design System can include the component designs, how they would behave, and a sample layout of how the product team could build the pages in a more user-friendly way.
Hence, my team started working out a Design System on Figma. We used the Google Material design language and another component library as the reference points for our Design System.
The first version of the Design System was completed by me and the UIUX Intern within 1 month. We did it in a “pair designing” manner and consulted the other senior designer on the team for the work.
We each handled the creation of different components on Figma and the intended component behaviours like scrolling, autolayout fields, and other interactions through interactive prototyping were worked on by me. I was also the “go-to troubleshooter” for interactions that are not working on the page.
The Design System was also created in a way that Developers, Product Leads, and non-designers with no experience in Figma are able to play with the prototype by interacting with the components, and read the specifications in pixels.
At the 1 month mark, I showcased the proposed Design System on behalf of the team to the management, and it was a success on the first sharing (phew). The next step to follow up would be getting the product teams to adopt the UI Design System when designing prototypes for the new product look and feel.
To facilitate the adoption, sample prototype layouts were created, which include how the page or system behaves after the user interacts with the components (i.e. generic functions associated with Create, Read, Update and Delete user actions). And this would supplement and support the existing way of work where Product Leads come up with a design draft before collaborating with Designers during UX consultation sessions.
In short, the hidden mission for the UIUX Team is to encourage everyone to be a user-centric designer, even if they are not yet one ;)
Takeaway
Through the process of working on a Design System for a complex product, I have worked with different product and development team members and gone through many discussions so that everyone could be aligned.
Sometimes there are disagreements on how a certain component should look and behave because 1 common component needs to be used across dozens of features. Hence, there could be trade-offs in deciding on a certain design. Whether we are placing emphasis on the usability of the design, business requirements, or the effort required to have it developed, alignment is very important.
I learned a lot about getting stakeholder buy-in and support when proposing new design ideas, from the senior designer on the team. And constantly promoting and educating the importance of user-centricity within the department is a really important practice.
From my experience, it helps to find supportive figures from the Product or Development team (e.g. design allies), and ask for more time to re-ideate and regroup to have more discussions until the most suitable solution is reached.
It is a tedious process that made me see the value of teams coming together to create meaning for users. Afterall design, development, and project delivery shares the same goal of providing a solution that the client finds useful.
Like tending to a garden, systems are living and require constant care and feeding to really blossom. Every team member has a part to play in maintaining a consistent and adaptable Design System — Design, Product, Development, and Management.
Ending Note
It was a very hands-on experience for me to start and complete a UI Design System, especially when most of my exposure was related to User Research during my bootcamp and freelance projects. This experience allowed me to practice my Figma prototyping skills, and be more mindful of co-designing with other team members (i.e. practicing design hygiene and ensuring the way the framing and layer naming are done is consistent).
There is no way UI design is just about visuals, and I make sure to share the importance of UX as an overall experience when working across teams. The “Wow” factor has to start from the Discovery stage so that the teams can understand what components are needed for the product, and how it could be designed.
Writing on Medium is a way for me to journal my growth as a designer, and reflect on the way I approach problems. If you have any ideas to share with me after reading my article, feel free to reach out as well.
*The information in this article is a self-reflection of my experience and does not necessarily reflect the views of anyone apart from me.
