All of these are real problems we face on the day-to-day that have pushed us to develop new technologies, seek out new ways of working and new ways to better manage and scale design.<\/p>\n
These are just some reasons companies started investing so much more in the design systems<\/a> space. However, because it\u2019s a new term, it\u2019s meaning and process is still unclear, vague and inconsistent \u2013 which is why we\u2019re seeing a flare in discussions, buzz and occasionally a good ol\u2019 meme.<\/p>\n I doubt that aliens have to worry about design in the same ways we do but I\u2019d actually love to see what challenges they face!<\/p>\n As far as I\u2019m aware, there isn\u2019t a formal definition on what a design system is. I think because the problems it solves (particularly in the digital product space) have emerged fairly recently - so to try and explain what it means for us at Marvel<\/a>, I\u2019ll give a real-world example.<\/p>\n We have a bunch of products that all have separate codebases and more or less separate teams\/owners:<\/p>\n We also develop and support a few static sites:<\/p>\n Using our own API<\/a>, we build and ship integrations<\/a> and their marketing pages like these:<\/p>\n We also send out HTML emails daily:<\/p>\n We also have different teams collaborating on a daily basis:<\/p>\n With all of these different platforms, channels, teams and processes involved, there are a range of challenges that surface. For example:<\/p>\n We\u2019ve created a system that manages all of this and most importantly evolves with it. It lives inside all of our products and web apps, but is a separate entity entirely. That means maintenance is done in one place and almost eliminates the need to think about design processes and workflow when working on a product.<\/p>\n The following flow chart goes into slightly more detail \u2013 but please forgive my vague terminology:<\/p>\n <\/p>\n We have a bunch of design values for colors, typography, layout and more, structured in a simple JSON format<\/a>. From there, we send them to a few places. On one hand, we have a Swift Styleguide Generator<\/a> which generates the design values consumed by our iOS and Mac apps. On the other, we have a simple atomic CSS framework, which then gets consumed by anything that uses web technology; be that React, PHP or old school email table templates.<\/p>\n We also manage design work with Abstract and use shared libraries<\/a> extensively to distribute the same UI kit into everyone\u2019s projects. We\u2019re also experimenting with sending out our live production components into Sketch<\/a>, instead of recreating them manually<\/a>, demonstrated with the dashed lines in the diagram.<\/p>\n This diagram is an example of what our design system looks like. Other companies will have different needs, so a solution might look entirely different. Simpler and more elegant, or twice as complex.<\/p>\n Of course, there\u2019s a lot more to it than a simple flow diagram. For example:<\/p>\n For further reading, I would recommend this article<\/a> by Varya Stepanova<\/a> which goes into a lot more detail on design system terminology, which in our case is a little all over the place! Another great read is the design systems book<\/a> by Alla Kholmatova<\/a>.<\/p>\n I briefly mentioned some of the problems we faced before building our design system earlier. So the advantages work out to be solutions to the mentioned problems such as shipping consistent and accessible products across different mediums, reusing and maintaining code and design in a more efficient way. And of course, improve cross-team collaboration.<\/p>\n Building a design system that scales well as the team grows is challenging. Doing the same thing whilst the products grow in scope and complexity is even more so. It takes a lot of time and effort and there always seems to be hurdles in the way.<\/p>\n What I\u2019ve realised in the past two years is that treating the design system as a separate product is hugely helpful. It needs it\u2019s own requirements, it\u2019s own set of features, a solid roadmap and clear prioritisation.<\/p>\n For example, our pattern library is not something we\u2019ve built and left in the wild. It evolves every day, there\u2019s an ever-growing backlog of feature requests, just internally, and we haven\u2019t even open-sourced it yet. So managing all of these things whilst making sure the products that consume it\u2019s APIs stay consistent, don\u2019t break or look odd proved to be the most challenging part for us. At the end of the day, it\u2019s a mixture between design and software so it needs to be treated in the same way.<\/p>\n Other things that I realised were crucial to the process, especially when time and resources are tight, were:<\/p>\n Lastly, it might sound very obvious, but I\u2019ve noticed that anything new that\u2019s complicated (a UI kit or a pattern library, or even design process for that matter) will be slow to get adopted - unless enforced religiously.<\/p>\n If it causes overhead in learning and takes time to get used to, people will get confused and ignore it. Reason being is that everyone wants to get their job done fast, which means they\u2019re more likely not to invest in something new that slows them down in the short term. It\u2019s just hard to see the long term efficiency gains. Any deviation from regular workflow is going to need some time for adjustment, so making sure your solutions are easy, understandable and straight forward might be a challenge too.<\/p>\n Another question I have no concrete answer for as every business is different but I can share how we went about doing it. The first thing we did was an audit of the existing brand, products and user interfaces.<\/p>\n When we started building our Styleguide<\/a>, Marvel had already been running for two years. By that time, it was an established product which already had a good, consistent design which people loved and enjoyed using. However, it was getting to a point where major features were being introduced and turning it into a platform, rather than a single product, so the need for consistency was becoming more and more essential.<\/p>\n We did an audit of the existing codebase and identified quite a few problems which Colm Tuite<\/a> summarised<\/a> in his post on how we built the first version of the Marvel Styleguide:<\/p>\n From there it was deciding on tech and our approach to solve the following problems:<\/p>\n You can read more about it all in the original article<\/a>.<\/p>\n I don\u2019t think I can really pin point a specific thing and would say it definitely depends on execution, but I think the following makes for a good design system:<\/p>\n If it over-complicates and clutters people\u2019s workflows with unnecessary process, then it\u2019s not a good solution. In fact, it isn\u2019t a solution at all.<\/p>\n You can have a pattern library without calling it a Design System. You can have a simple UI kit. Or a set of design variables when building a simple website. If it helps you build faster, then it does the job. It doesn\u2019t always have to be a system.<\/p>\n You can also design and style everything on the go. Like when you\u2019re building marketing sites. Or products with a lifespan as part of marketing campaigns. It doesn\u2019t really matter what and how you use, as long as you are productive, efficient and get the work done.<\/p>\n \u2533\u253b| \u2014 Stevie Buckley (@StevieBuckley) September 17, 2018<\/a><\/p><\/span><\/blockquote>\n![\"Design](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/10\/designsystem1.jpeg\")
<\/a><\/p>\nLet\u2019s imagine for a moment that I\u2019m an alien, now explain a design system to me.<\/h2>\n
\n
\n
\n
\n
\n
\n
How does it work?<\/h3>\n
\n\t\t\t
<\/a>\n\t\t\t<\/dt><\/dl>
\n\t\t<\/div>\n\n\n
What are the advantages of using a design system?<\/h2>\n
What have you learnt from building a design system?<\/h2>\n
\n
How does somebody even begin with building a design system?<\/h2>\n
\n
\n
What makes a good Design System?<\/h2>\n
\n
Any times when using a design system is not a good solution?<\/h2>\n
\n
\n\u253b\u2533|
\n\u2533\u253b|
\n\u253b\u2533|
\n\u2533\u253b|
\n\u253b\u2533|
\n\u2533\u253b|
\n\u253b\u2533|
\n\u2533\u253b|
\n\u253b\u2533|
\n\u2533\u253b|
\n\u253b\u2533|
\n\u2533\u253b| _
\n\u253b\u2533| \u2022.\u2022) I don't know what
\n\u2533\u253b|\u2282\uff89 a \"design system\" is
\n\u253b\u2533|<\/p>\n