Table of contents

est 9 min read

Introduction At Sitecore and Templafy, we successfully developed and delivered two headless design systems, I am now sharing the insights and lessons learned from these two projects in small fragments.

Back in 2016, as a junior UI designer, my first project involved building a UI component library for SAP. Ever since I was always fascinated by collaborating with developers and understanding their thought process. While it wasn't always easy, I'll highlight some challenges I faced and how I worked around them.

Despite the difficulties, that initial project sparked my interest in design systems thinking.

Bridging gap between design and engineering The best outcomes for digital product features happen when engineering and design collaborate effectively. This collaboration motivated me to work with design systems, bridging these two worlds with a common language.

I enjoy advocating for design decisions in engineering groups and serving as a "developer whisperer" in design meetings. This allows me to learn from both disciplines, making me a better designer, collaborator, and professional. Innovation often arises from the intersection of these worlds, which motivates me to be involved in both daily.

There’s definitely been times where developers said things like my UI proposed changes will impact performance and I’m left scratching my head as to why. I also learned to comprise. I’m all for compromise but not without just cause. This is where data can come in handy. Using user data to support design decisions when presenting design in a engineering meeting.

I think there’s always going to be this slight tension between design and engineering but when you’re working with an engineering team that wants to work with you to find a solution it’s a game changer.

Different characters Some people don’t care as much as you and you can’t force them to care.

This is something I’ve learned working as a stakeholder management. As someone who is passionate about design, the “business” side of things is hard for me to work with at times. There are many trade-offs teams have to make in product development - for example, designing within existing components.

I once collaborated with a designer who strongly advocated for making a significant change to a component either designing a new one specifically for the project at hand. The designer's suggestion would indeed benefit the users and enhance the user flow. However, the engineers emphasized that focusing on such changes wasn't feasible at the moment. They recommended using the existing components, stating that the alterations the designer proposed weren't critical: “The business isn’t going to focus on that right now.”

I always make sure I am collaborating with our devs from discovery phase, asking what they need to appropriately develop, and then deliver organized files and work through our design system. But sometimes it feels like people don’t wanna have to put much effort into things and this is when the eternal clash between design-dev situation appears. Ending with the Figma design not looking like the live implementation.

I would never try to convince a developer that the screen color must be exactly right. They may be dealing with difficulties I don’t see and it’s a waste of my time. For me is important to be effective in my role - and support others if they ASK. Then, if the “client / end-user” comes back wondering why the screen color is incorrect, I direct them to my design as proof that it was considered and then I pass it off to the dev team to explain why it wasn’t implemented.

Developers are one of the most important stakeholders for me in the design process. No matter of their characters I will always try to be around them from the earliest stage of a project. This is the only way that gives me assurance that the user-centric design I made will be implemented correctly.