What is needed to get started

Nothing really. The will to get something set up is the first and foremost need if you ask me. A lot of things speak for a design system of some kind and that is why there will always be a chance to get the budget for it. But there is none such thing as a "motivation grant" one can give.

Okay, but that is not why you came her. Let's talk about the things to create a budget. This post will point you towards things you might need to take into consideration, however it will not give you specific details of how many Euros, dollars or whatever cash is needed. That could be another post going into more examples. Today I would like to offer you the insights to calculate a budget yourself which is more reasonable anyway as the rates for certain tasks differ a lot depending where you are or get your work done.

A trial run, a group of people

From an employee perspective I have heard people who did not get a budget to work on a design system. They did it anyway, unpaid for. They got together in a group of motivated people because they believed in setting up such a system. Once they got the basics right they pitched the system again, this time with way more leverage, as the argument of initial costs just got a whole lot weaker. But they were motivated to do work in a certain way, they invested time to reach that state of work culture at their workplace.

But even if you do not find the group of people you can start small. As a designer work in a way as if you had such a system. Write a specs sheet and refer to it whenever possible. Do not pass along distances in pixels anymore but mention a value on your specs sheet, like "spacer XL". This is the first step of showing how valuable it can be to have such a system in place.

From an employer's perspective it can be a great idea to dedicate a specific time budget per week or maybe something like a team day to work on a design system / Pattern Library. This has the benefit of making it budgeted and it might even have the big benefit of getting the team to work on something together beyond the everyday ticket mill.

What costs money

In general money is not the only currency here. We are more or less talking about resources. You can either have two designers working on dead slow machines because you do not want to spend new hardware, and they get stuff done. Just. But maybe with the proper hardware not making them wait every few seconds a single designer might be able to get the job done at the cost of a faster computer. And with less therapy costs for anger management (that spinning beachball of death on a Mac can make you go crazy for sure).

Time is one currency

The main part on the budget is basically time (spent by the people working on it). How much time is needed then?

Let's take a look at the tasks at hand:

• Creating the design / concept
• Writing the documentation
• The meetings to get people synced
• Research within the teams (workflows, opinions, ideas, …)
• Research outside (software, tools, best practices)
• Setting up a system
• Bringing content, code, and documentation into the system
• Converting existing design and code into a (standardised) components

Hardware, hosting, and other costs

The other aspect when talking about costs is hardware and connectivity for example. You might need a server to host a design system, a machine to build it, a domain. Depending on your setup this can range from a few bucks to a larger sum. But you certainly won't need a 64 core, 512 GB Ram, 32 TB SSD machine with 155 TB/s connection. Most systems could probably be hosted on a Raspberry Pi for a few euros. But maybe you have a server already and there is space on it for your design system as well. After all we are talking about something that is more than a static PDF to be served, but not a full fledged shop system either.

So when hosting, hardware, and a domain are out of the way, what else is there to pay attention to on the costs sheet? Well, quite frankly, that could be it. Maybe you have licence costs for a software to display your design system, but there are a lot of free and open-source alternatives out there, like the UIengine, Fractal, Storybook, Pattern Lab, patternplate. Or have a look at the growing list of similar tools to generate pattern libraries / styleguides.

Where can you save money?

Now we get to the interesting part: Saving money and reducing costs. For management this is crucial, because so far we have talked about spending extra money and time.

The headline itself is not quite right, as there is no money being saved, but rather time. But in the end time needs to be paid for be it in the form of wages or freelance invoices wanting to be paid.

So where does a design system help to save time?

Consistent use of components

The first thing is a no-brainer, literally. When you have components with a good documentation and flexibility it is a natural thing to use them. You do not have to invent the wheel when it comes to buttons obviously. But in the case of a more complex form this is something you do not want to reinvent once you have figured it out and designed it with maximum comfort and conversion chances.

Be it in the conceptual phase, when the UI is brought together, or in the development stage, everyone on the team can tap into the components and make use of them. And since it is either a quick reference on a scribble ("this box is our standard form type C") during the concept development, a quick dropping of a sketch symbol in a layout, or a copy and paste / include in a code editor, it becomes somewhat ridiculously simple.

While you might not want to re-use forms all the time, there is a lot of communication which can get saved because a developer does not need to ask for styles anymore, a module to be used, or a which exact colour code should be used. Either it is used in the Pattern Library or it is a potential candidate for it. The latter case is a great point for an exchange to enhance or defend the style guide ("great let's add mauve to the list of colours" vs. "do we really need a 25th shade of red?"). However the mere question for a colour code is something nobody wants to be delayed by.

A last example could be the use of spacers. The way an interface makes use of space and areas is something that can be systemised. It does not make sense to create re-usable components and do some random spacing job over and over again. Make distances a standardised thing and communicate them with clarity.

Plausibility and Clear concepts

Everyone makes mistakes. We know that since layouts have been passed to developers despite the fact that they were not finished yet, resulting in updated files, which again were only updated partially, etc. When a design system is in place and lived by by everyone it is a lot easier to spot things gone sideways or to answer questions by doing a quick look-up, not by sending questions to colleagues who are in meetings all day making you need to wait for the answer before you can continue working.

So you feel like setting up a concept how certain things in a design should behave? An example would be a button. Active, inactive, hover, busy, whatever the state is, you can define it. What about links? Do they behave similarly? Is there a shared rule or two? May that rule even apply to the mega menu you dreamt up? Embrace the power of clear concepts. To a UI designer this might be a relief because they do not need to visualise a gazillion different states. To a developer this could mean that a certain behaviour can be moved to a mixin and be used over and over again. Win win again.

Having simple and easy to remember rules and making them available to everyone is a great start to get the system more reliable in terms of what can be expected from a user's perspective and from a production perspective as well. This reduces questions and leaves time. For instance for more feature development. Ouh, nice!

Planning the budget

When setting out to create a budget it makes sense to have a team of people getting together again. The different trades and departments can give better evaluations of what might be needed and can be expected. Make sure to evaluate often whether you are on track, especially in the beginning.

What needs to be accounted for in a design system?

The following list is a good start to discuss what you need and what you estimate. Be aware of the different experience levels and rather let the realistic people be in the lead instead of the enthusiastic founding team members we talked about previously.

Depending on your product, industry, and teams the list items might be applicable to more than one department.

• Research: What is needed and should be included in the system
• Research: Accessibility and permissions
• Research: Which software is needed?
• Research: What should be included?
• Research: Is the system a living system?
• Inventory check: What is available already?
• What needs to move? What does not?
• What needs to be created?
• When are certain parts needed?
• Will a versioning system be needed?
• How will people get to know about the system?
• How are updates being handled?
• Where is input and feedback gathered?
• Who does quality control?
• Where and when will the work on a design system take place?
• What are the goals and milestones?
• How is the system future proof and technology agnostic?
• etc. etc. etc.

Hidden costs

When you go through a list of questions like those in the previous section you might be able to discuss and estimate how much time is needed for certain things. However there are quite a few things which can go wrong and bear hidden costs by taking more time. Let me give you a few examples so you can have an eye open for similar issues in your project:

1. Misunderstanding of what a design system can and cannot do, what is part of it and what is not. Having experienced that some people thought they would pretty much get a self-running system doing their work for them is not the best thing to plan with. Be realistic, do not glorify a system. It is a system, not an autonomous self working robot ninja wonderthingy.
2. Getting started prematurely and eventually having to start from scratch again because the system is not ready for the whole team.
3. Not integrating the system into the workflow, making it fail to be reliable, which causes either a collapse or a strong effort to bring it up to speed. In the meantime wrong, faulty, or outdated things might have been produced. Maximum harm is done this way buy hurting everyone's trust in such a system.
4. A new technology is introduced and the design system documentation / the templating system / Pattern Library is not able to incorporate this. This might either result in a major refactoring or even the need to move the documentation to a new setup all together.

The list of potential hazards goes on and on. Just be aware of the pitfalls you can think of and get the other team members to chime in with their end-of-the-world scenarios as well. We cannot think about everything but a few brains more close the potential gaps a lot more effectively. And this does not only apply to design systems as we know but to holding a fortress agains zombies trying to get in as well. You get the point: Work together to keep things running smoothly. And despite all the problems and pitfalls being mentioned, work on how those can be overcome as well. That is the power of such a system beyond patterns and components: Team communication and collaboration imporves. Something which is almost impossible to account for in numbers.

Up next: Checking inventory