Pallet story #3 — Design system in a small team

In the previous episodes, we explained the processes behind component creation and design system management, but from a design perspective.

In this article, we will describe how we manage to push these components into production in a fast growing and changing environment.

Commute routine

Commuting, everyday, the same way, without any issue is probably the biggest satisfaction of my daily routines.

And when it comes to the components we plan to add in Pallet (our design system, you remember ?), I expect the same satisfaction, a routine with no issue, a clearly defined process that repeats over time, which could be summarized as follows:

Theory often works… in theory

With a clearly defined path to follow, all we have to do now is to dedicate resources in order to get things done.

In some occasions, we can allocate resources for that schema.

But in most occasions, we have high business impact features to provide, code to maintain, code to review, specs to detail, documentation to write, etc…

Basically, we often run out of time… like, most of the time.

That’s a real issue.

But there is a bigger problem. If we don’t improve and rely on our design system, we trigger issues like design inconsistencies, code repetitions, and we don’t provide reusable UI parts to increase development speed.

This is why we can’t do without it. And we have to find another path to support design, engineering and business at the same time.

Don’t stick with a unique plan, or you’ll get stuck

Our new features generally can’t wait for the design system, and the traditional design system release is not flexible enough.

We need another workflow, which allows us to feed the design system with components while making features.

We experienced another approach : developing design system components directly in our application codebase, and moving them to the design system with the smallest effort once they work as expected.

This strategy implies a strong decision : app and design system share the same UI dependencies with the same versions. This decision would appear risky, short term or not scalable to some of you.
Well, in fact, it works great.

There is no perfect decision, focus on the benefits

Of course, this decision is questionable (mostly from a developer’s perspective),but what initially looked like a scrappy workaround turned out to be profitable in many aspects:
- we can deliver missing design system pieces on demand.
- improved feedback loops during real features development vs. a classic release flow.
- better debugging, polishing vs storybook stories, as we test and use in the real usage context
- moving the components to the design system is a low cost process

Find your way

Here we are, after 1 year and a half we only ship UI made with Pallet components. We saved a lot of time when it comes to build a feature, by just composing Pallet elements.

We gained a lot of confidence on design consistency, with quicker design reviews. And finally, users and business make the most out of it, thanks to design impact with the User Experience.

Depending on your business, your team and your growth, there must always be an alternative path if the standard way is blocked.
You may think you’re heading the wrong way, but there’s no wrong way when multiple benefits await you by the end of the journey.

Unlike my daily commute, processes and flows are not daily routines, or repeating schemas, they evolve depending on your environment, and satisfaction comes up once you find the right path for your company.

Thank you for reading.