{"id":18969,"date":"2020-01-20T16:00:50","date_gmt":"2020-01-20T16:00:50","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=18969"},"modified":"2020-11-05T10:58:08","modified_gmt":"2020-11-05T10:58:08","slug":"holistic-design-system","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/holistic-design-system\/","title":{"rendered":"7 Requirements of a holistic design system"},"content":{"rendered":"

I recently created a case-study for my colleagues in New York about a multi-brand Design System project I worked on, for one of our clients back in London. While gathering information for this presentation, I was inspired to write an article and share my thoughts about what I\u2019ve learned during this year-long experience and how it opened my eyes to the broader picture. I finally found the time to publish it.<\/p>\n

\"\"From left to right: gap analysis and inventory process images, third photo by Bal\u00e1zs K\u00e9tyi<\/a> from Unsplash.<\/p>\n

I\u2019ll start by stating that everyone in the Product Design world is selling, talking or reading about Design Systems. It has become a \u201cbuzzword\u201d. To add to it, there are so many interpretations out there, it is frequently misused. I want to take a step back and define what exactly is a Design System, and what it isn\u2019t.<\/p>\n

\"\"\"\"<\/a>Image reference from Sarah Federman<\/a> featuring: Jan Toman<\/a>, Adam Zeiner<\/a>, Nate Baldwin<\/a> & Audrey Hacq<\/a>.<\/p>\n

A \u201cDesign System\u201d in the context of Product Design, is a relatively new term. This is also due to the problems it is trying to solve \u2014 with the increase of digital products, screen sizes and number of devices we have these days. That is why the term is still vague and unclear.<\/p>\n

What a Design System isn\u2019t<\/h2>\n
<\/div>
<\/svg><\/div>

\"It\u2019s important to understand that a Design System not a visual system or a design language; it is not a style guide, not a CSS framework, nor a pattern library. And yet, all these artifacts use system thinking (and system design), which is not new to us.\"<\/p><\/span><\/blockquote>\n

This is why words like \u201cdesign<\/em>\u201d and \u201csystem<\/em>\u201d can be misleading. A style guide or a pattern library can be a starting point of a Design System (they are in fact the most common artifacts) but they\u2019re not the only component.<\/p>\n

(There\u2019s a great talk<\/a> from Diana Mounter<\/a> at GitHub,<\/em> that I strongly recommend if you\u2019re interested in expanding on this topic).<\/p>\n

As a starting point, I find useful to look at the differences between: 1. design guidelines and style guides; 2. living style guides; and 3. holistic Design Systems:<\/p>\n

    \n
  1. Design guidelines and style guides<\/strong>, are static guidelines (non-editable in principle). A great example is the beautiful NASA<\/em><\/a> \u201cGraphics Standards Manual<\/em>\u201d. Style guides and UI toolkits, provide the building blocks and design elements, along with guidance, theory and principles behind components and its usage.<\/li>\n
  2. Living style guides<\/strong> are a step further in the design process, they embed the actual UI and are a trustworthy representation of the current state of things, with automatic rebuilds. For this reason, they\u2019re also easier to maintain, in contrast with style guides created as a PDF for example. Lonely Planet<\/em><\/a> and Mail Chimp<\/em><\/a> are great examples of living style guides, they display the real components along with the code (the real button \u2014 with its behavior, such as hover or click states \u2014 not an image of a button). They\u2019re extremely useful for quick testing because you can immediately check the components\u2019 behavior in different browsers.<\/li>\n
  3. A holistic Design System<\/strong> includes all design assets and tools, but also governance, ways of working and processes. BBC Gel<\/em><\/a>, Salesforce Lightning<\/em><\/a> and the UK GDS<\/em><\/a> are perfect examples of Design Systems available publicly. In the case of the UK GDS website, there\u2019s a community section with rules around how to propose and develop a new component or pattern and a criteria for contribution. There\u2019s a system in place with clear guidelines, managed by teams of people who are responsible for its outcome.<\/li>\n<\/ol>\n
    <\/div>
    <\/svg><\/div>

    \"The manifestation of a Design System can be a website but fundamentally it\u2019s an ecosystem, it affects the organization.\"<\/p><\/span><\/blockquote>\n

    It is also relevant to add that just because something looks visually or \u201ccosmetically\u201d consistent it doesn\u2019t mean there\u2019s a system underlying it \u2014 a Design System is not visible at a glance. It\u2019s hard to judge how companies work internally, their level of automation, or if there\u2019s more to it than what is being shared. It\u2019s worth keeping in mind that not every organization is fully-transparent about their internal processes and design methodology, and what\u2019s frequently shown on the web is just \u201cthe tip of the iceberg\u201d.<\/p>\n

    What a Design System is<\/h2>\n
    <\/div>
    <\/svg><\/div>

    \"A Design System is an ecosystem of components, interfaces, guidelines, architecture and processes, to satisfy requirements of a product or organization, and build deliberate outcome.\"<\/p><\/span><\/blockquote>\n

    It enables teams to collaborate and build good design outcome, guided by standards and design principles. It\u2019s a cross-disciplinary platform that streamlines the design process<\/strong>. To corroborate and add to this definition, I\u2019ve compiled below seven requirements of a holistic Design System:<\/p>\n

    1. Creating a Design System requires designing the system itself<\/h2>\n
    <\/div>
    <\/svg><\/div>

    \u201cA Design System is the official story of how your organization designs and builds digital products.\u201d Brad Frost<\/p><\/span><\/blockquote>\n

    It is not just about digital design. A Design System is made of many parts; not just the UI toolkits, UX patterns, the code and accessibility guidelines \u2014 those are the tools, the tangible output; but there are also the invisible layers (not necessarily reflected in the platform, but essential) such as processes and a governance model \u2014 it\u2019s about how people work and communicate, what\u2019s the process for reviews and feedback, and how new patterns are approved. It\u2019s about \u201chow we design\u201d at [insert the name of your] organization.<\/p>\n

    \"\"\"\"<\/a>Core skills needed in the creation and maintenance of a holistic Design System. Teresa Mira<\/a><\/p>\n

    The creation and maintenance of a Design System blends different skills (visual UI and UX design, development, strategy, business and service design \u2014 it is also about the service this system provides). It encompasses different audiences too: the company and teams (by shaping the way the organization approaches design, their vision and mission), the individual users of the System (PO, UX, UI designers, developers), and the end-users (the people who use the digital products, the final output).<\/p>\n

    <\/div>
    <\/svg><\/div>

    \u201cA Design System isn\u2019t a Project. It\u2019s a Product, Serving Products.\u201d Nathan Curtis<\/p><\/span><\/blockquote>\n

    To add to the different facets, a Design System needs constant maintenance, it\u2019s a living thing<\/strong>. The real challenge is approaching it from this perspective.<\/p>\n

    2. Its main challenge is a mindset shift<\/h2>\n
    <\/div>
    <\/svg><\/div>

    \u201cA design system needs ongoing maintenance and support. Many teams still focus on the final implementation rather than the underlying system. There\u2019s the need of a mindset change.\u201d Brad Frost<\/p><\/span><\/blockquote>\n

    \"\"\"\"<\/a>The different layers of a Design System. Teresa Mira<\/a><\/p>\n

    In terms of best practices and to paraphrase Brad Frost, a Design System is based on four pillars: the Content<\/strong>, People<\/strong>, Processes<\/strong>, and Maintenance;<\/strong> as described earlier. It becomes obvious why a Design System is never completed and needs to be kept alive, constantly. That\u2019s why it is so challenging \u2014 it requires a mindset shift from focusing on the tangible artefacts and final implementation to focusing on the actual system that is underlying everything.<\/p>\n

    To bring the project forward in the organization and for the System to thrive, you\u2019ll need everyone to contribute. And because a Design System requires investment, a big part of the initial process is socializing and selling it internally \u2014 \u201cwinning friends and influencing people<\/em>\u201d, quite literally. It\u2019s important to tailor your message according to your audience, in order to communicate its benefits. For example, when talking to the teams and the design community, it\u2019s useful to highlight how this system will make their lives easier, and showcase how much faster it will be to design; versus talking to managers or the \u201capprovers\u201d, where the focus should be on numbers, KPIs and metrics such as time saved, how many teams can be affected in the short\/long-run, how much can be optimized and saved.<\/p>\n

    3. A successful Design System depends on ownership and advocacy<\/h2>\n
    <\/div>
    <\/svg><\/div>

    \u201cThe biggest existential threat to any system is neglect.\u201d Alex Schleifer, Airbnb<\/p><\/span><\/blockquote>\n

    Because without everyone on board there is no Design System. A company\u2019s culture needs to be matured in order to adopt it; this type of initiative needs both top-down and bottom-up support. Design teams and leadership need to be on board with Design Systems and dedicate time and resources to it.<\/p>\n

    It is crucial to have a solid governance model in place and review processes for teams to work more efficiently. Part of it is the creation of a dedicated team responsible for standards<\/strong> and design integrity, guidance, resources and processes<\/strong> such as approving new components (when there\u2019s the need to create new ones), evaluating whether a pattern is an exception or reused enough across the journeys to become part of the Design System, facilitate discussions and feedback implementation.<\/p>\n

    It is not just about what we design but also about the way we design.<\/strong> While creating the foundation or building a Design System for your client, encourage the right people to own the decisions, because they\u2019re the ones who will need to keep it alive. Give your client ownership of the design process so they become advocates of this transformation.<\/p>\n

    4. Design and development are (really) two sides of the same coin<\/h2>\n

    A Design System entails a framework for digital teams to create components from a shared library, in order to mitigate duplication work (for both design and development), inconsistency (i.e. visual, UX patterns), and solve for pain points in the process. It improves cross-team collaboration and defines how teams design.<\/p>\n

    Among other aspects, a relevant example is naming conventions. Its structure should be heavily discussed between the design and development teams, to arrive at terms that make sense for designers but also for how things are actually built in code \u2014 this enables a shared vocabulary<\/strong>. This is when Atomic Design<\/a> principles also come into play, to organize and divide components into categories that make sense for both teams, by asking questions like: \u201cwhat\u2019s the logic for designers to assemble UI elements<\/a> when building screens<\/em>?\u201d and \u201chow are molecules and organisms generated and built upon, in code?\u201d <\/em>(these categories can and should be adapted to your company\u2019s specific needs). Technical details impact design decisions \u2014 this exercise is a team effort<\/strong>.<\/p>\n

    5. A holistic Design System is future-friendly<\/h2>\n

    It goes without saying: understanding the requirements of design at scale is vital in a holistic Design System. The larger the project, the more important the process becomes (even more than speed and delivery). The scope and complexity of a company-wide Design System is also very different than creating a suite of websites or an app. The System needs to enable scaling (whether it\u2019s a new brand, and added platform, or a new product) it should grow and adapt along with the teams and the technology.<\/p>\n

    A practical example is the overarching design principles of a Design System. These will inform every new component or product that is designed in the company \u2014 when designing something new, the teams should cross-reference the output with these rules to make sure it ticks all the boxes. Ideally, they should be kept high-level enough to apply to the different domains (not only interaction or visual design, but also tone of voice, content), as well as the desired qualities of the end-product as a result \u2014 while remaining flexible and open to future adjustments (i.e. product teams and expertise required, or product\u2019s audience\/consumers, when expanding offering).<\/p>\n

    6. Solid standards eradicate design debt<\/h2>\n

    We know that incremental errors and changes accumulate over time, and create a disjointed experience. When rules are not clear or teams have doubts regarding how to go about it, it\u2019s a recipe for inconsistency and disaster \u2014 this is the opposite of a Design System. It\u2019s also the reason why exceptions are not supposed to be added to the System (adding countless variations of a component generates unnecessary confusion, since it\u2018s not crystal clear when or how to use it anymore). It is called a System <\/em>for a very good reason.<\/em>
    \n    \"\"<\/a>Tweet from Karri Saarinen<\/a>.<\/p>\n

    A successful Design System provides a clear framework and a centralized library for teams to test and create consistent, effective <\/strong>and valuable digital products.<\/strong> This is not possible without a solid documentation. Getting into the habit of documenting early and clearly is paramount. After all, \u201cyou\u2019re building a system and that cannot work if the system is you\u201d as Karri Saarinen puts it in the image above. Miriam Susanne<\/a> also sums it all up: \u201cIf it\u2019s not documented it doesn\u2019t exist<\/strong>.\u201d<\/p>\n

    The platform should give the teams all the information needed to create and maintain digital products (their structure, the guidelines, the \u201cdo\u2019s and dont\u2019s\u201d, in addition to the components and UI kits) \u2014 these are the fundamental rules. <\/strong>Without the \u201cinstructions manual\u201d, two designers may be looking at the same style guide and still interpret it or assemble components differently. Similarly, if a pattern or feature is not clearly documented, it might prevent incremental changes\/adaptation, or appear broken. Details matter.<\/p>\n

    \"\"\"\"<\/a>One great example is Polaris<\/a>, Shopify\u2019s Design System.<\/p>\n

    Another big part of documentation is onboarding (i.e. guidelines for designers on how to use certain tools or how to create a new UI toolkit; guidelines for library contributors, for versioning control or the creation of new libraries; guidelines for research and exploration of new patterns). These standards and procedures are really important to be documented when onboarding new team members who just joined a project, or for new hires. It ensures everyone is working from the same baseline.<\/p>\n

    7. Better design requires investment<\/h2>\n

    There are plenty of case-studies available and public reports with concrete numbers on how much companies like Westpac<\/em><\/a> or the Gov.uk<\/a> have saved with their Design Systems. Better design clearly means \u201cbetter business\u201d, but better design also requires investing in a better system first.<\/p>\n

    The benefits of a Design System are hopefully sold by now, but it\u2019s still worth pointing out its top three design strengths<\/strong>:<\/p>\n

      \n
    1. Increased quality and efficiency, by reducing complexity;<\/li>\n
    2. Optimized skill distribution, by allowing teams more time to focus on overall user experience or the creation of new products, versus production;<\/li>\n
    3. UX & QA efficacy and savings.<\/li>\n<\/ol>\n

      These are huge business advantages<\/strong>. With a successful Design System in place, changes are easier to implement, because the platform becomes the single source of truth. This helps with consistency and encourages reuse \u2014 therefore building interfaces is done in a systematic way \u2014 not only faster but also resulting in higher quality output.<\/p>\n

      The system also becomes more valuable and requires less effort as time goes by, because the more components you have in a library, the less you need to design from scratch. The fact that the components are reusable is what enables scalability \u2014 teams spend less time duplicating, and more time creating<\/strong>. It is worth the time and money invested.<\/p>\n

      Design Systems continue to be a \u201chot\u201d, relevant topic because their benefits are an integral part of any legitimate digital transformation<\/em> initiative in the exciting days to come (not a mere add-on).<\/p>\n

      Design Systems are hard work to setup, run and maintain; it is not uncommon to take several months to a year \u2014 just to get started. It really depends on the scope and project\u2019s complexity; the company\u2019s needs, ways of working and preferred tooling. Not every client needs a company-wide Design System, and teams come in many different sizes<\/a>; the crucial part is to design the System with a holistic approach.<\/p>\n

      Despite the big efforts involved, savings are considerable and immensely valuable. When summarized in one line, as faster, cheaper and better products to market; <\/strong>the case for a holistic Design System couldn\u2019t be more compelling.<\/p>\n

      Originally posted on Teresa's Medium<\/a> page.<\/p>\n","protected":false},"excerpt":{"rendered":"

      I recently created a case-study for my colleagues in New York about a multi-brand Design System project I worked on, for one of our clients back in London. While gathering information for this presentation, I was inspired to write an article and share my thoughts about what I\u2019ve learned during this year-long experience and how it opened my eyes to… Read More ￫<\/a><\/p>\n","protected":false},"author":317,"featured_media":19004,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[484],"tags":[],"class_list":["post-18969","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-design-systems"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n