Should I implement a Design System?

So in the last years everyone’s been talking about how Design Systems are becoming so important for companies from various segments.

The point here is not to deny that — actually I’m a big fan of Design Systems and I have been actually trying to evangelize a “Design System-ish” culture at my company since I began to understand its benefits.

Unfortunately, though, nothing is ever all sunshines and flowers… I’ve gathered enoguh experience to know that for a fact, haha. So 2 questions have always been stuck in my mind:

1. Do we really have to start implementing Design Systems for all projects now?

2. If not, so… When do we implement it — or, to formulate in a more alarming way — when do we NOT implement it?

Short answer for question #1 is a big “No”, as you might have imagined. As for question #2, well, there is no short answer.

So what I did was to learn a bit more about Design Systems while simultaneously trying to put it in practice in a real project for a real client. I thought being too philosophical wouldn’t do much and, like people say, trying something is better than doing nothing, right?

After 6 weeks, though, I started questioning my own decision. Why? You see, I do not feel like getting that much of benefits out of it in the long run anymore, because, well… It’s hard to keep that monster updated when there is not a complete team exclusively dedicated to it, and treating it like an evolving product. Being optimistic, at the moment I can only say I have an outdated style guide… Comparing to the ideal scenario, it’s not even close to what people would call “a working Design System”.

I’ve learned a lesson, yes. But then I started getting considerably more afraid of that second question. “When NOT to implement it?”

Right now it’s Saturday 4:00pm, and before that I was Googling and reviewing all those Design System articles from 7:00am to 1:00pm. Largest Saturday morning bibliographical reference gathering of my life, indeed. Then from 1:00pm to 3:00pm I wrote down a list of Pros and Cons from the morning studies and merged it with a list of my own.

No lunch. That’s how obsessed I’ve become!

So the content I’m showing below is intended to be kind of a lightning-fast pros and cons list about the usage of Design Systems, made for those of you who just want a quick overview. After that, I began sketching around this idea of creating a flowchart for people to decide if they really want to implement a Design System or not in their projects. However, laziness took over, so I ended up “MVP-izing” the idea — just a linear Google Form would work better at first. That’s what you will have access to in the last part of this text.

Finally, the complete, ultimate, do-not-miss-it-under-any-conceivable-circunstance list of pros and cons about Design Systems:

18 Pros about Design Systems

1. Scalability

2. Consistency & standardization

3. Long-term efficiency (around 20% according to some data I honestly haven’t checked)

4. Modularization

5. Reuse

6. Ease to apply changes

7. Autonomyentrants

8. Alignment & clarity (without verbal communication)

9. Collaboration & sharing

10. Design + Dev approximation

11. Reduction of duplicate work

12. Works as documentation for newcomers

13. Reduction of design & code debt in the long run

14. Great for medium & large projects/products

15. Great for multiple teams

16. Great for growing teams

17. Faster prototyping and deliveries

18. Plenty of examples out there to serve as inspiration

27 Cons about Design Systems (I’m a realist, alright?)

1. It can reduce exploration & innovation

2. Hard to come up with unique and personalized solutions while using it

3. Flexibility gets decreased if not well managed

4. Need for continuous maintanance & updating

5. Documentation complexity

6. Centralization (and all of its downsides)

7. Demand for dedicated team

8. Slow short-term progress

9. Abstraction

10. UI component’s usage is hard to foresee

11. It can be hard to get buy-in from stakeholders for it

12. It’s hard to stablish habits around its proper maintenance

13. Need for experienced & qualified team

14. Demand for careful planning & organization

15. Demand for well established versioning culture

16. It can contain useless UI components

17. Existing UI components can be applied to the wrong scenarios

18. Not great for small projects/products

19. It can make people blind for sistematic view of the solution

20. It needs a well established design culture

21. Demand for various departments involvement

22. People don’t know if it’s best to use pre-built Design Systems or to create a custom one

23. I’ts hard to explain relationships between various UI components

24. It’s hard to explain interaction behaviours that extrapolate the modularization concept

25. Works properly when using a Mobile-first approach

26. It doesn’t make sense for temporary / ephemeral projects

27. Designers must understand more about coding

Yeah, I know the list is messy and probably people would want me to go through a more in-depth explanation for some of the items there. I will try to include here the original materials I have consulted just in case.

What I really wanted to share is the following link — a rough sketch of what could be a tool for the assessment of a team’s level of benefit or harm when implementing a Design System to help guide its solutions.

Fow now it’s quite simple. First set of questions would be just to generate some insightful data in the future. In the second set, each possible answer is worth some points according to a Likert scale. Respondents write down their points sum while taking the questionnaire. In the end, they get feedback based on the total number of points.

There could be different sets of questions depending on some key answers in the beginning of the form too, so the tool would be more sophisticated and tailored too a larger amount of possible scenarios.

Here it is: https://drive.google.com/open?id=1j6z6LGG9QKbKAkKC4xmmUdODZqXbAviCUZav20-7hLY

If you have already implemented a Design System for a real project or product, and also if you still remember what was the specific context of your team back then, please feel free to try the form out yourself! Please share the results you get and your impressions about the form and the result.

Do you think there is anything missing? Would you create the form differently? Am I too crazy to propose such a presumptuous tool? Share!