A conversation between a Designer and an Engineer on Design System

In Bowtie, the collaboration between designers and engineers is highly valued. We work closely together in finding solutions to problems, regardless of whether it is a feature, fix, or workflow improvement to make our work more efficient. Vincy (Product Design) and I (Engineering) have had the opportunity to develop a design system together and we shared a conversation on our experiences.

Vincy: When I first joined Bowtie as a UX designer and started my first project, I found it difficult to learn about our existing design approach: What font sizes are we using? What are the styles of our action button? Although I can make some educated guess while inspecting our existing platform, it isn’t the most intuitive way to do so.

Frances: That’s right. It was really the “itch” for those of us who worked on the user interface frequently. “What is this button variant? is this new?”, “Oh! it looks like a paper box with different paddings.”, “I must have seen this pattern in other projects. Give me a minute searching through the design screens…………..argh never mind.” were questions I had frequently. It was a golden opportunity for us to try solving this problem, as suggested by Eric Raymond as the itch-to-scratch model.

Sometimes it is not as itchy, perhaps maybe the project is brand new, or we can judge by some “common sense”. The itch magnifies when you look at the full picture, where different people work on different features. After all, it affected the experiences we delivered to our customers and we couldn’t look away.

Vincy: The problem kind of magnifies when Bowtie’s business is growing at a very fast pace, designers are working on multiple projects concurrently. We see the need to have a systematic approach to our product development workflow. We want to make sure the features we deliver to our customers are up to standard by introducing some common practices to the team.

Frances: Yes. We need to jump across a wide spectrum of features in different applications. Scaling up is going to bring more conflicts between designers and engineers, as our team grows. The sooner we start tackling the issue, the more iterations we can try out to mitigate the risk. We started thinking about the what-ifs. What if we have a centralised location for the better discoverability of design assets? What if we have a process to rationalise engineering decisions on what should be a shared component and what should be a snowflake? etc. The idea of having a single source of truth, with guidelines, principles, sharable components and constraints simply sounds great.

The fact that we did not start from zero also gave us the initial thrust. Like many others, we were already leveraging Material UI to help us get going from the beginning. It gave us the flexibility to customise the out-of-the-box components with themes. We also have a UI library package in our front-end monorepo managed by lerna and a storybook set up for designers and engineers to browse through the library.

Frances: It sounds great to say “Ok! Let’s fix all of this.!”. But how? Understanding what our team needs is the most important thing. After all, it is all about the people. There are so many resources out there suggesting how to implement a design system, what are the steps etc. Different companies essentially have their own set of problems, and there is no ‘perfect’ approach. The right thing to do is to find an approach that fits our culture.

Vincy: Early this year we formed a design operation squad at Bowtie to focus on improving our designer / engineering workflow, and to create a scalable design system for our growing teams and the company’s business needs. We identify 3 key areas we wanted to improve in our product development cycle: Lack of clarity in contribution flow, Accumulated Inconsistency and, Low Discoverability of Design Patterns.

One of our first initiatives is switching to using more collaborative tools such as Figma to encourage the team to ideate and open up communications between designers and engineers. Together with well-defined tasks documented in Notion, designers and developers can go in and check on the progress of each feature and who is responsible for what tasks.

Not everyone is comfortable with adapting new tools at first, but as our confidence grows, it allows more ideas to come in, and eventually grow into good practice which we can follow and iterate upon over time.

Frances: Another issue that we couldn’t look away from was the accumulated inconsistency. It was mainly rooted in the number of snowflakes in our ecosystem, and partially was a victim of lack of discoverability. We knew that understanding the debts in depth would be the first important milestone of the project. As many have suggested, UI Audit is the way to go by taking screenshots of everything in your application as stock and categorising them. We understood the benefit of taking a snapshot of your entire application to at least know your enemy, however, it was too time-consuming and costly especially while things were still moving rapidly. As mentioned, we already have a UI library that was shared across applications — however, we were at a stage where it was partially adopted. We needed to know where and how these components were being used.

We decided to build a plugin to allow us to see the usage summary of different components of the current UI library, namely Dependents Finder. It helped us to understand if a component is under-utilised, in which part of the app that it is being used, the values of attributes applied etc. The same plugin helped us to understand our dependencies on Material UI. This gives us a quantitative insight into our progress, and as a great reference to set actionable goals and roadmap based on priority.

Vincy: After discovering all the inconsistencies/areas to improve in our platforms, the next step really is to find ways to improve them. We started organising forums that encourage team members to give any topic a good debate. “What is a Chip? and what is a Badge?” When do we use a popup modal versus a slide-out drawer? …and so on.

Any member of the product team can bring up topics they want to discuss and improve on. The benefits of finding out all the problems/pain points enable us to create reusable design patterns. Having common design patterns can really speed up developing new features in our platforms, as well as improve the usability of our products.

Frances: Needless to say, these are good problems to have. As our team grows, we can afford to invest more effort into streamlining the workflow and making adoption as easy as possible. A good channel of voicing out ideas/concerns or general discussion on matters was also an area that we experimented in. Adoption is the key to success. For example, if a member found issues with a component’s definition so he/she is confused over whether or not to create a snowflake or update the UI library component directly. Is there a way for the member to voice out and seek advice? Is the process transparent enough so everyone is aware of the latest changes? These are the things that are constantly in our minds and we are actively seeking ways to address them.

Vincy: Different organisations have different design maturity levels, and the biggest challenge is to convince different teams that design is not just a function in the company that ‘beautify’ things but has a place in improving other aspects of the business as well. For example, the inconsistent use of call-to-action buttons can really hurt the user experience and eventually affect a company’s conversion rate.

It’s also tricky to quantify the value of good design. It can not be measured by the amount of policy sold like the sales team does. At the end of the day, we need to give the company trust that good design will make our customers happier and more satisfied with our service.

It might take some time to see the real advantages of having a design system of our own, but I believe that if some people start seeing the benefits of it, others will be willing to follow and adapt to our new ways of working.

Frances: Most people prefer to see things visualised. Of course, we can go on for hours immersing in our own world hyping about things like eg. interactive components in Figma, our recent work with Button. An effective way to showcase and broadcast the progress with team members will be a good start. Notion-storybook-Figma is our hero trio as mentioned. Our storybook build has been integrated into our CI/CD pipeline so every pull request will trigger a new build with the most updated components. People hate seeing outdated references as it would leave them even more confused. Having elements like these definitely have saved us time and effort to maintain visualised documentation.

Vincy: The product team is in this ‘experiment’ together. We are not trying to be cops going around policing everyone when they have done something wrong in the workflow. We have to create a safe environment for teammates to share what’s been working for them and what areas can be improved. From there we can create a culture where everyone takes part in growing it.

There are a lot of things we can do for a design system: Setting up components library, writing extensive guidelines, Setting very sophisticated workflow etc. I think the worst thing we could do is blindly follow what’s been done by other companies and have our teams adapt to them. A design system is a living and breathing thing, so don’t expect a component will stay the same forever. They should all evolve with our products’ needs.

Frances: Exactly. A Design System is a description of how our organisation design and build our products. There is no one-set-fit-all solution, and it takes time and effort to find the optimised framework that is sustainable. As the book “The Hard Thing about Hard Things” suggested, “The hard thing isn’t setting up an organisational chart. The hard thing is getting people to communicate within the organisation that you just designed”. The hard thing about a design system isn’t getting it set up. The hard thing is maintaining the momentum to keep actively tuning it by small incremental changes. It is a long road journey, but made of satisfaction surely! I must point out that, one of the most enjoyable bits is having great and enthusiastic team members nerding out and working hard together.

Vincy: I am glad that we are in this thing together, bravo to collaborations!

Originally posted on Medium