Why design systems in agencies are different.

The current online hivemind for design systems is still heavily centred in product circles, everything referenced is heavily app and heavily in-house, but there’s a whole underbelly of the design world that isn’t spoken for. A place where the idea of designs systems is slightly different, where time is a lot more precious and the ideas around maintenance can be a little murky.

My observation lies like this, agency projects are usually smaller, usually faster and when the go-live is all gravy, when everything is done and dusted a new client is on the horizon.

When time is what you sell, “design systems” can be a difficult one to balance. They are by definition, time-intensive, they need maintenance and near-constant attention. They require a buy-in all the way from the top; this is all kinds of difficulty in a world where the teams focus is rationed, when the team is on a continual cycle of jumping between projects and clients.

So here comes the crux of this, the question…
Does this project even need a design system?
(And, if so what does it look like)

Currently, the scope of what type of system or even if a system is built for is highly based on budget and time, other factors are rarely brought into the discussion. In a good chunk of cases it’s not even a discussion, it can be left to the designers to decide. A sort of inventing the parts, writing the instructions, and building the furniture all in one, with no consideration for the time needed.

These three points should weigh equally on the decision:

The longevity of the project/product.
Is it a small campaign site or a huge ecommerce store?

The future of the system.
Is the agency maintaining it, does the client need to use it?
Does the client team have the skills to use/maintain it?

The time/budget available.
Is there time to build something useful? Can we get the time?

And then, and only then, after all, these have been considered can a decision be made about what is built.

The word “design system” has become a broad term, a sort of catch-all for everything relating to defining styles and making components, it includes everything from its smallest implementation up to the mammoth systems some companies have in place.

Deciding “what is built” implies that you also have a good idea of the varying scales of what can be built and can articulate this. A lot of poorly defined terminology floats around and is used somewhat interchangeably.

UI kits, pattern libraries, style libraries, design systems, templates, starter kits, and the list goes on. A standardization and definition job on all this terminology is desperately needed, this is something the design world should embrace.

Until then though, agency design teams should be defining these internally and it should be entwined with the considerations.

Overall, when time is rationed, the considerations, scale and scope of a design system need to be at the forefront of the conversation. It’s an interesting side stream to the development of design systems and one that deserves more attention.