Stop doing design system projects
Your design system is not a project.
When new designers and developers join forces to evolve your design system it is tempting to start working in projects. You might even create some epics and sprints to move user stories from your backlog in a Scrum environment. But when your design system is not a full-time effort, this will work counter-productive.
Our agency WebNL was growing when we started a design system team. New designers and developers had joined our teams, and we also acquired another UX agency. With this growth came a need for better organising and standardisation of processes and tools.
Our new coworkers started to work on client projects and they needed a well-functioning design system to do that. Ironically, I found that making our design system into yet another project didn’t function well.
Starting a design system team
Last year we started a design system team. Before that, I was already doing solo work to create a Figma starter kit and coded components for our developers and designers. So why did we need a design system team?
Our teams at WebNL are seperated by profession: Creative, development and marketing. Each team is lead by at team lead, optionally assisted by a planning manager.
But we also have project teams. Each project team is led by a project manager and consists of several designers, developers, and marketers. Project teams may also vary across time.
So designers, developers, and marketers have to report to their team lead, but also to a project manager for different projects. Nielsen and Norman Group call this a matrix UX team.
Because of this model it’s challenging for our teams to share resources. We often don’t know what other people are working at, unless we ask them or hear about it in a standup. This results in work being done multiple times.
So we need more standardised components for these teams in order for them to work efficiently, but we also need more eyes and ears in these different teams to know which components they need the most.
But mainly our agency needed more components, more then one person could build and distribute on their own. To generate more components, a project was started.
Our design system project followed the convention of our regular project teams. We needed project management, research, design, and code to create components. So the project was started with a project manager, a ux researcher, a designer, and a developer.
Our first project
Our first task as a design system team was to create a site header and navigation component. The project manager had asked us for estimations and calculated a return on invest based on time saved in future projects. He wanted to use this project as a case to convince upper management of investing in more standardization.
His understanding was that upper management wouldn’t let us work on more standardisation before this project became a success. So we wouldn’t be working on any other components before this project was finished.
Research
As a UX practitioner, I was responsible for UX research. I wanted to move quickly, so I collected different navigation patterns, looked for occurences in competitors websites and our own websites. A week later I presented the results to our team in order to move forward.
After the presentation, I had planned to create guidelines together with our team. This was met with some aversion. We did manage to create some guidelines, but there was a lot of discussion about which variants of a new component would be most important and would be built first.
Design
Then our visual designer went to work. It had taken some time to find time in his schedule between client projects. But two months later he presented a slick clickable prototype in Figma.
The design introduced some inconsistencies with our existing design system. Our visual designer created the navigation component in a new file, with a duplicate of our design system templates. Other designers were starting to wonder which file they should use.
Our visual designer showed that he could listen to designer feedback, implement feedback quickly and understand how systems work. I decided to have my design system files archived and let him maintain the visual part of our design system. This way we made sure that designers knew where to find our design system.
Development
We hoped to start development sooner and have the navigation component in our codebase fast. But it was just as difficult to find time in our developers schedule between client projects. We also changed our asset bundler to Webpack during that time, and we optimized for Google page speed, which also took some of our time.
Two months later, four months after the project was initially started, we still hadn’t been able to find time for the development of our navigation component. In the end, I contributed by taking over development of the component.
I coded the navigation component in Storybook. I would be able to test multiple variations of the component, share the component with my team and have automated documentation. It was exciting to start using this promising tool.
Storybook turned out to be problematic in our workflow. People didn’t understand all the buttons, tabs menus it had. And those people also weren’t used to testing components in isolation.
But more importantly, Storybook didn’t fit in our code stack. We used Vue’s inline-templates to optimize for SEO and compatibility with our backend framework Laravel and our CMS. Storybook did not offer support for Vue’s inline-templates with Laravel, but required single-file-components instead.
I built the navigation component to support both single-file-components and inline-templates. This didn’t work. Having the same functionality in two different places wasn’t scalable and introduced a lot of head-aches. We decided to stick with inline-templates and adjust our navigation component.
Eight months after the project was started, our lead frontend developer merged our code into the main branch of our codebase and the navigation component was released.
Problems with design system projects
When we started our first design system project we estimated a quick release. This didn’t happen, because on numerous occasions our project got deprioritized. As a result the release was rescheduled numerous times.
That didn’t come as a shock to us. Working in an agency we know that client work is always prioritized. We have to move fast for clients in order to deliver. Prioritizing large internal projects over client work is most often not an option for us.
But our design system project becoming a bottleneck was a problem. I wasn’t allowed to do research on new components. And our visual designer had to wait for the research since we used a Waterfall process. Simply because our team assumed that we weren’t allowed to work on new components. I felt that this assumption was wrong.
Earlier this year, I attended a talk by Sander Hoogendoorn, Agile coach, speaker and writer. He talked about agile, scrum and how they fail in a modern-day software development environment. According to him we should STOP doing projects . This message appealed to me, even though I work at an agency where we make money from doing projects for clients.
The solution Sander provided was continuous delivery. This is not a new concept, and it’s getting more attention lately. Especially in DevOps, where launch cycles are mostly automated nowadays. With continuous delivery, features are divided into smaller parts that can be released when they are ready.
The reason why this message of continuous delivery appealed to me was that our design system project became stuck. We had a growing amount of components waiting to be researched, designed and built. Designers outside our team were also asking for new components.
But our resources were limited, our navigation component was too large and our project it was blocking the development of other components. It was clear that projects did not work here.
Improving the design system process
When we started our design system team, I had wanted to establish a design system proces by making a design system process puzzle with our team.
I was introduced to this tool in a workshop organised by Angi Studio, and I had used it to help some students with their design system project. At both times I had been amazed at how the puzzle gave a clear picture of what a design system process should look like.
When our process became stuck it seemed like a great oppertunity to re-evaluate our waterfall/SCRUM process and see if we could gain from continuous delivery, while starting work on more components.
It was hard to find support in our team. Others didn’t see a need to change the status quo, and assumed they were right about following a pre-approved schedule. In order to encourage them I talked to one of our directors.
I had worked with this director on our first design system and knew that he would approve of working on more components if it would help us standardise. When I talked to him about our design system becoming a botttleneck, he recommended scheduling a meeting with him and our team to discuss doing more components.
I used the meeting to do the process puzzle as well. In the meeting I explained how the design system process puzzle worked, and I provided the materials. But the process puzzle was quickly set aside when a lack of general understanding of our existing process became clear.
Some people didn’t know about the release cycle initiated by our frontend developer. Others didn’t know about how the installable packages in our codebase were used to release components. And even others didn’t know about the already existing backlog or our Figma starter kit.
In the end we didn’t do the process puzzle and just discussed how we could get things moving again. The initial assignment for our project manager was extended to include research, design and development of other components. We also decided to collect these components in a backlog and set up a kanban board.
To document these decisions I layed out the process puzzle after the meeting. I did this on a part of my desk were people could see it. This way I got feedback from our team without having to organise another meeting.
Other people in our agency gave feedback as well and the puzzle was changed each time someone walked by. When no more changes were being made, I digitalized our process into a visualisation.
Process visualisation
Our process starts with standardisation by our design system team. We have a shared backlog that contains a list of components that we want to build. These components are researched to generate guidelines, best practices or requirements. Then the components are designed and developed. After each step in our process, we do a review.
The second step in our process involves releasing. During development we need to choose an installable Composer package for each component. The components are then released in those packages by a senior developer.
When a component is released in a package, we can also release the component in Figma as ‘available in code’. We communicate those releases to our design and development team in standups, tech meetings or email.
While the components are being used, we can measure how they perform. We can measure the experience of designers and developers by doing surveys. We can measure the time spent on adjusting components for clients by measuring time logs. We can measure the user experience by doing usability testing, surveys or web analytics. Or we can measure SEO impact in web analytics.
Each measurement can result in a new component request or an update request. These requests should flow back to our design system team.
At the moment we haven’t set up these measurements specifically for our design system. But we are already logging our time, doing usability testing and collecting analytics for clients. These existing metrics could be converted into feedback for our design system team in the future.
Finally we made a Trello board to track progress of these components. This Trello board should be public to everyone in our agency so everyone can make requests on our backlog. In the future we could guide these requests by setting up an automated form with general questions that would then convert any submitted forms into Trello cards.
Evolving process
Moving to a continuous and agile workflow isn’t always easy. Especially when people inside an agency are accustomed to working consecutively in waterfall. For client projects we use scrum and kanban to estimate tasks and log issues, but design and development are often seperated by a waterfall process.
When we came up with new components after our process meeting we prioritized the components. Then our project manager created a new project in which we would do research, design and development in a waterfall process all over again.
When development started, a backender had done some work that we could use. But there was no design for his work. We proved that we could work in an agile and continuous flow by involving our designer and including the backend work.
In other cases priorities change, and we have to abandon a predefined roadmap. Early this year, I encouraged our team to implement Webpack as our default asset bundler. This wasn’t on our roadmap, but we needed it to modernize our codestack and create compatibility with modern front-end tooling.
A few months later this change proved beneficiary to page speed scores on our websites. We were able to make some improvements which hadn’t been able without webpack. This delayed our work on the design system, but by making these improvements we were able to build better components.
A final example of evolving workflows is changing tools. I started using Storybook to build and test multiple variations in components in isolation. I later found Storybook wasn’t optimal for codestack and workflow. But I still needed a place where I could build and test different variations of our component.
That is why I built Storybase. It’s a package for Laravel applications and it is compatible with any html component, including Vue inline-templates. Storybase renders our components on the server so we can optimize them for SEO while testing. It also allows us to mock data in Laravel for each story. And finally each story is also embeddable in our documentation.
When I built Storybase our site navigation component was already in its final development stage. But we started a client project with some snowflake components that introduced a lot of variations. I installed Storybase into the project and documented and tested each component there. This helped a great deal in convincing my fellow developers of the value of such tools. I now plan on using Storybase not just for our design system development, but also for each client project.
Takeaways
- Don’t build your design system in waterfall projects or scrum sprints. It’s simply too big. Establish a backlog with components and make sure the tasks for these components are small so you can work on them continuously.
- Set up a process with your team early on so you can get on the same page about which steps to take before components are released and when to build new components or update older ones.
- Use a tool like Storybook to document and test variations of your components, or create your own tool for this.
