Design Systems basics at DesignWays 2019 conference
On November 30 Michał took the stage at the DesignWays Conference in Kraków, to talk about "systemic approach to design". The goal wasn't to push design systems per se, but more of a push towards having any kind of a system in place. Even the simplest set of rules will improve the consistency and speed of building digital products.
The conference was a great way to hear fantastic talks by likeminded people and a way to see the industry is in a far better shape than we expected. This is good news and we felt right at home there.
Why should you even think about a design system?
We started by talking about how we managed to use systemic approach to design hundreds of products in the years 2010-2017 with a three person design team. In many cases reacting to a problem "on the spot" would prove to take a lot longer, than predicting patterns and planning for them.
The techniques we used weren't really design systems, but they all shared a similar systemic approach to design. That meant the products were planned from the start and after the first few look and feel establishing shots they were documented and componentalised.
Answering one of the audience questions here in more detail
This of course all comes down to the fact, that the larger the project you're making the harder it will be to maintain consistency, focus and quality. And the farther the vision and execution drift apart, the harder it will be to effectively fix the problem. One question we received at the end was how to "systemize" an already existing product. In that particular case it had some style related rules, but they were chaotically implemented resulting in "similar-but-not-the-same" components across the board.
The best way to approach a problem like that is to document what you already have - every iteration of a similar button or text-field. Place them all in a doc and then assign a team of designer / developer / product owner to go over them in detail. Divide them into reasonable chunks and go through them one by one in more detail.
Ask yourself the most fundamental question here.
Was this element done this way on purpose? Or was it simply a mistake?
Then start eliminating the mistakes and writing up the proper way to handle gradients, shadows, colors and fonts. 🔥🔥🔥
When trying to put a system on an already existing product don't go overboard. Start with a few simple changes (colors and fonts are the most obvious ones) and then show the results to the stakeholders at your company. Explain to them that even those small changes now have a huge impact (measure it behind the scenes and talk to developers).
Once you gain even a tiny bit of traction and are able to show the results it will be far easier to convince the higher-ups to go full DS. And once you go full DS you never go back 😂
Get the developers onboard.
If you need to convince them - tell them it will be like bootstrap, but theirs to define (with you). You'll definitely score some points there! 😎
They should be pretty easy to convince as a Design System will make their jobs easier and less stressful. The main thing to remember is that in a Design System team a Developer is a core member. Not just the person that executes your creative ideas. Find a developer in your organization who understands even a tiny bit of design and aesthetics (and readability). That developer should become the second driving force behind the idea.
Have fun with your DS
Once you establish some ground rules and build out your first components use them to test their versatility. We sometimes redesign an existing app using DS components just to see what can be done. It can spark many creative ideas for your own product in the long run and future-proof your components in ways you wouldn't normally even start to imagine.
Put it to work, stay commited and treat your system like a product in it's own right.
It will improve your workflow in a great way!
Liked this post?
Share it on social media :-)