When I’m adding or changing something in Commerly, I’m trying to filter all of my decisions through the values, that Commerly is based on.

It’s not a problem to make small design choices, without a filter. But then you make more, more and more choices, without even noticing it.

And eventually, you’re left with something inconsistent and hard to use — even though every step seemed reasonable at the moment you’ve made it.

Once the project drifts far enough, it becomes hard to understand how to fix everything. I’ve noticed this problem in my workflow before. So those “filters”, that I developed over time, makes the risk of mistakes lower, and gives me confidence that I'm moving in the right direction.

My experience and problem that I faced, leads me to 3 core values, that I use as filters for design decisions.

• Good enough today, is better than perfect someday;
• If something needs explaining, it’s already too complex;
• Flexibility over complexity.

First of all, I want my design system to be useful, even if it’s not perfect from start. Oftenly, I was spending too much time on perfecting something, that already “good enough”.

So now I’m adding the status labels for elements into the design system, to release updates exactly when I think it’s “good enough”. That’s why you may see “deprecated” labels, above some elements which I'm still using, but also planning to redesign it in the future.

The next step is documentation. I want to make a good guidelines for every part of design system. But unfortunately I don't have enough time for most of them so far.

That's why I’m trying to make it so easily understandable as I can. Of course for some parts it’s just not possible. But if you can understand how things works, without having to read the documentation first, it means I've done my job the way I wanted.

And the last value is “Flexibility over complexity”. Unlike big companies that use "all-in-one" solutions, I prefer smaller components.

Big components covers most of cases and having a lot of variations, but when you need something slightly custom, it becomes difficult to adapt them. And most of the times, it's easier to create specific “one-time” component.

That’s why I use smaller components as core part of the system. They are easy to copy, adjust, and reuse across projects. This helps to keep the system flexible and user-friendly over time.

The same approach I‘m using for “foundations” and planning to use it for “patterns” and “templates” in a future.