Syndy — Design System

At Syndy I helped develop a design system that would significantly speed up the design process and make the platform as a whole more consistent and better to use. Next to this we set out to create something that would also be scalable for the future. I was responsible for leading the design in this project and researching how to best build such a system. The result is that there is now a solid framework which can be further improved as the platform matures. You can read more about this project in the case study in which I explain how we approached all of this.

The background

When I joined Syndy in 2015, its platform was relatively simple compared to now. The processes for design were not yet clearly defined, which meant that every new project was started from scratch by our small design team and we would make it up as we went along. There was no style guide or pattern library present. Working like this resulted in a large amount of one-off solutions. These solutions aren’t bad initially, but a sure way to eventually build up technical and design debt. We weren’t working towards structured solutions in which reusability and systematic thinking were main factors.

As the product started to become more complex and the frequency of shipping increased, so did the design process. Next to starting every new project from scratch, there were times that we needed to provide quick solutions and fixes which in their turn contributed to a significant growth of different styles, colors and non-standard components. At times it was difficult to keep up with the high demand of shipping new features, especially because the lack of design patterns or a style guide. In 2016 after working for almost a year like this and seeing that this process is in no way efficient or desirable, I brought together the right stakeholders and proposed we start exploring the possibilities of developing a dedicated design system for Syndy.


We started investigating how to best develop a design system and we set up a list of goals for this system. What we wanted to achieve was:

  • Design a system, not pages
  • Design a system that is scalable for the future and that is flexible so it can change with the company
  • Reusable and consistent; no one-off solutions
  • Speed up the design and development process
  • Have a dedicated pattern library for designers and developers. A source of truth, which will also reduce discussions to a minimum
  • Improve the collaboration between designers and developers
  • A style guide (as part of the system)
  • Documentation for the design system

My role for this project was to focus on researching and developing the design system. The objective was not to only build the design system, but define a solid foundation for our current platform while also being scalable for the future. At that time we didn’t have a style guide or truly reusable components, which meant that these all needed to be created. One of the challenges was to evaluate what we had now, research and understand design systems, then create a new system from scratch while still evolving the current platform further under tight deadlines.


There is a lot to learn from other design systems and we were thankful for the many companies that open sourced theirs. I started studying most of them, one of which is Lightning Design System from Salesforce. This in itself is an amazing resource and something that I personally learned a lot from.

Next to studying other design systems, we needed an approach for creating reusable components and patterns which are also scalable. These are important factors; we wanted to avoid developing one off-solutions or simply creating pages. We learned a lot from Atomic Design by Brad Frost to achieve our approach. Brad’s methodology was slightly adapted by us so it fit more with our way of working and thinking.

After these study cases I looked back at the history of our design to establish what was actually working and could be transferred to the new design system. For this I conducted an interface inventory of our current UI (components, elements, visual design). What was learned from this inventory was not a surprise anymore; an abundance of different patterns, styles and colors.

The next thing was to start building the elements starting from the ground up and developing a system that is scalable and reusable, in other words; modular. I worked together with our developers to align on functionality and know what is realistic for our small team to build. We also needed to develop both guidelines and principles. And last but not least, this was also a good opportunity to refer to our backlog of user feedback and do new research on user workflow and processes when it comes to entering and managing product information data on Syndy.


Our design decisions are based on the following principles. These are at the core of building the system and help us to take a step back and have a high-level view. They furthermore help us to support design decisions, improve communication to the development team, and achieve a consistent and intuitive platform.

  • Simplicity: in the way that the platform works and looks. Easy to work with, easy to understand by speaking the users’ language.
  • Feedback: the user is always informed in a meaningful way by the system about what is going on. Whenever mistakes occur, help them recover from these.
  • Trust: the user should at all times have the feeling that they are in control, offer guidance throughout the platform and provide a consistent experience.
  • Performance: our platform needs to perform at its absolute best at all times. Never let the user wait. Always best fast and reliable. For every new feature that we build, keep the performance in mind.

With the principles set, it was time to approach the next phase in building the design system. I started with the foundations, then went step by step in building atoms, molecules and organism—in line with Brad Frost’s Atomic Design.


TypographySyndy is a data-heavy platform and space is in that sense very expensive. We show the data on various hierarchical levels, which means that at times we need to use the smallest font sizes. Previously we were using Source Sans Pro on the platform. While it has its good points, we found that on these smaller sizes it started to break, making processing data into useful information more difficult. We tried several alternatives and with the help of prototypes and user testing we choose for Roboto as our main typeface. It is very robust, even in smaller sizes, and neutral which means it is not trying to have a very distinct character of its own.

ColorAnalysis of our stylesheets revealed that there was a high volume of different colors, including colors that were ever so slightly different from each other. The challenge here was to bring that number down while still being flexible enough. In the previous version of the platform we were using blue as our primary color which was very recognizable. We wanted to at least keep this color in a slightly tweaked way. We supplemented this with platform-generic colors like green, orange, red, grey, black and white.

Grid & SpacingThe last part in laying a solid foundation for the Syndy platform was the grid and overall spacing between elements. We started experimenting with an 8-Point Grid. Using this even number as the base meant that it could both scale up in an easy to remember progression while also being highly divisible. Instead of using random numbers to space things out until they felt right, we now have a range of standardized numbers and a very flexible grid in which we can align everything properly, creating a consistent looking platform.

Screenshot of Typography Foundations
Screenshot of Color Foundations
Screenshot of Spacing Foundations

Atomic Design

As mentioned, one of the goals was to build a design system that is reusable and scalable. The foundations helped in paving this path. Following these foundations, we found Atomic Design to be the next logical step by tweaking the methodology ever so slightly into an approach that better matched our workflows and processes. Then it was time to build the elements starting from the ground up. The beauty of Atomic Design and its metaphors for atoms, molecules, and organism made it easier to explain this approach to stakeholders. They understood its power and that this would set the way free to truly working in a modular way. In essence we were developing our own Lego building blocks.

UI Components

By combining the foundations and the atoms we now have the flexibility of building almost any component imaginable. Of course keeping consistency in mind.

These components are driving both the platform for the users as well as our own back-end admin tools for managing the platform. The latter is interesting as we sometimes can use this as a testing ground for new components. For brevity’s sake, a small sample of our most used components can be seen below.

Screenshot of Buttons
Screenshot of Field Inputs
Screenshot of Datepicker
Screenshot of Modal
Screenshot of Modal
Screenshot of Modal
Screenshot of Cards
Retailer & User Cards
Screenshot of Product List
Screenshot of Modal Screenshot of Modal Screenshot of Modal

Lessons learned

  • We should have moved earlier towards testing what we actually built (component wise) instead of first trying to think of all possible and future cases a component could exist in. Building a platform and internal tools with new components will soon enough reveal if anything needs to be changed or plainly doesn’t work. Refining in small steps helps improve the system.
  • Sketch acted as both a playground and a tool to build the library for the designers. Whenever we were satisfied with a component, we would create it as a symbol in Sketch. Together with nested symbols and overrides we can now quickly design and test new features or screens.
  • In conjunction with the Sketch library, we created a living style guide for developers including the components, example usage and code for easy copy and pasting into projects.
  • We set this as one of our goals, documentation, and it’s important to repeat it here. Start documenting the design system as early as possible. Documentation will help in explaining how things work and why they work that way.
  • Modular thinking—we like to use the Lego metaphor—helps in building a design system. Questions to keep asking yourself are: How does everything fit with each other? How can you build components that are stand-alone and can plugged in almost anywhere?


I’m extremely excited to be part of this huge achievement for Syndy. We worked long on this project starting from setting our goals and guidelines, research and testing to a solid design system. It is something that will keep evolving which means that it needs to be maintained and improved constantly.