{"id":12284,"date":"2017-04-03T18:26:15","date_gmt":"2017-04-03T17:26:15","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12284"},"modified":"2025-01-03T13:16:42","modified_gmt":"2025-01-03T13:16:42","slug":"the-full-stack-design-system","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/the-full-stack-design-system\/","title":{"rendered":"The full stack design system"},"content":{"rendered":"

UI methodologies like Atomic Design bring logic and structure to individual screens. Now it\u2019s time to extend that thinking to every aspect of your product.<\/p>\n

Here\u2019s a little mystery. Why is it that \u2013 a bit like hangovers and pop music \u2013 most products somehow seem to get worse with age?<\/p>\n

You\u2019d think the opposite should be true: that having a great team spend many years iterating on a product should eventually result in some immaculately perfect finished product. Instead after ten years it\u2019s suddenly harder to unlock your phone<\/a>. Why?<\/p>\n

The long, painful answer is ill-discipline. Projects grow over time. More people join, some earlier folks leave, and clarity of design vision deteriorates. The business decides to chase new markets, and new features get tacked on like Christmas decorations. Internal collaboration gets harder and sub-teams develop their own design philosophies. Requests flood in from a more diverse customer base. Competition needs to be kept at bay by adding in more stuff. Sprawl sets in. Before long it doesn\u2019t feel safe to enter some screens alone after dark. Good products degrade. It happens to the best of us.<\/p>\n

The shorter answer is most product teams don\u2019t adhere to a solid underlying design system<\/strong>. Something that unifies and guides all aspects of the experience from the conceptual building blocks of the product, to the details of the UI, to how things are named.<\/p>\n

So if you\u2019re suffering from the nice-to-have problem<\/a> of designing a successful, growing product, here\u2019s how considering all aspects of your design as a single system can save you \u2013 before the rot sets in.<\/p>\n

The TL;DR<\/h2>\n

Given that this is the internet and you\u2019ve probably got animal videos to watch, I\u2019ll cut to the chase:<\/p>\n

    \n
  1. 50 years ago graphic designers figured out that it\u2019s a good idea to come up with some shared underlying rules when designing a bunch of related things.<\/li>\n
  2. Digital product designers realized this is also a good way to make sure your buttons always look the same. \u201cDesign Systems\u201d emerged as a useful way to build consistent UIs.<\/li>\n
  3. But most Design Systems are really just Pattern Libraries: a big box of UI Lego pieces that can be assembled in near-infinite ways. All the pieces may be consistent, but that doesn\u2019t mean the assembled results will be.<\/li>\n
  4. Your product is more than just a pile of reusable UI elements. It has structure and meaning. It\u2019s not a generic web page, it\u2019s the embodiment of a system of concepts.<\/li>\n
  5. By embodying product concepts in Design Systems designers can go beyond consistent UIs towards creating consistent products.<\/li>\n<\/ol>\n

    That\u2019s the nutshell version. If you already get it, godspeed<\/a>.<\/p>\n

    Software with structural integrity<\/h2>\n

    Making software isn\u2019t like building a bridge. Construction workers have a clear end goal to aim for, mature methodologies and well-understood materials, and most of them dress better. The majority of industries are far more stable than software development. That’s good \u2014 most people generally prefer driving across bridges that weren\u2019t designed using whiteboard markers and engineered by Googling for error messages.<\/p>\n

    \"Manhattan
    \nManhattan Bridge under construction, 1909. \u00a9 Irving Underhill\/Library of Congress<\/em><\/span><\/p>\n

    Digital product design is still in its infancy. We\u2019re figuring this shit out as we go. As soon as we do figure something out, things change again \u2013 the tech improves, your team grows, competition emerges \u2013 and that process that you finally figured out breaks again. Plans are obsolete almost as soon as you\u2019ve made them.<\/p>\n

    Without a blueprint of some sort to rely on it\u2019s not surprising that so much software eventually buckles under its own weight.<\/p>\n

    So clearly we need something to set and keep us on course. Something to make the difficult parts of product development easier, make the slow parts faster, and to power us away from the enormous Pit Of Complexity that all products seem to get drawn into over time.<\/p>\n

    Enter Design Systems.<\/p>\n

    A brief history of design systems<\/h2>\n

    Design Systems of one flavor or another have been around for quite a while. Simply put, a design system is useful for when you need to design not just one thing, but a whole set of things that you want to feel like a coherent family. If you come up with a template and always stick to it, you\u2019ll get that coherence for free.<\/p>\n

    So instead of designing one subway sign you might come up with a set of graphic standards that allow you to design a whole set of signs and symbols that work together in concert. Also, can we bring back ring binders please? Old school cool.<\/p>\n

    \"New
    \nNew York City Transit Authority Graphics Standards Manual by Massimo Vignelli and Bob Noorda, 1970     source<\/a>. <\/em><\/span><\/p>\n

    Or instead of designing a logo for an organization you might develop a visual system for representing that organization in all sorts of different contexts. Space exploration and classic graphic design, what\u2019s not to love?<\/p>\n

    \"The
    \n The NASA Graphics Standards Manual by Richard Danne and Bruce Blackburn, 1975.<\/em><\/span><\/p>\n

    CSS frameworks like Twitter Bootstrap dragged these ideas into the world of web development, providing reusable code snippets to easily build consistent UI elements like buttons and dropdowns. Wonderful, even if every website in the world basically looked identical for a while there.<\/p>\n

    \"Twitter
    \nTwitter Bootstrap, originally created by Mark Otto and Jacob Thornton, 2011 <\/em><\/span><\/p>\n

    Brad Frost\u2019s influential Atomic Design methodology put forward a more structural approach. Rather than a jumble of \u201catomic\u201d elements scattered across a screen (e.g. a label, an input, a button), Atomic Design suggests that a small collection of UI elements should be thought of as a meaningful component, (e.g. a page footer, a login form). Put a pin in this idea, we\u2019ll come back to it in a bit.<\/p>\n

    \"Brad
    \nBrad Frost\u2019s     Atomic Design methodolog<\/a>y, 2013<\/em><\/span><\/p>\n

    Finally, Google\u2019s Material Design guidelines pushed the concept further, bringing deeper formal rationality, a bold aesthetic and resources and guidelines for building UI elements across a range of platforms. (I worked at Google and wrote the first set of guidelines for the Android Wear platform.)<\/p>\n

    \"Material
    \n    Material Design<\/a> by Google, 2014<\/em><\/span><\/p>\n

    Today, many larger companies have built their own custom, in-house design systems in an attempt to stave off the inevitable creep of inconsistency. Airbnb, Salesforce and Uber have built comprehensive systems that keep their own product UIs in check.<\/p>\n

    The limitations of pattern libraries<\/h2>\n

    Maybe none of this is news to you. Maybe you\u2019ve already got someone maintaining a nice little pattern library on your own team. (If you\u2019re not sure who, just look for the person who can\u2019t stop making Lego analogies.)<\/p>\n

    So can\u2019t you just check the box and move on? Or is there a difference between a pattern library and a design system?<\/p>\n

    I mean, sure. But yes there is.<\/p>\n

    Most Pattern Libraries take the form of a web page that lists the different styles of all your UI elements: all the different sized headings, all the button styles, all the dropdowns that are used to build your UI. If all the designers and engineers on your team agree to only ever use these elements, your UI automatically stays consistent. It also allows you to tweak those styles down the road if you want to make a design change across your app. Not bad at all.<\/p>\n

    \"\"
    \nIntercom\u2019s old, now-retired pattern library. Need some buttons? We got \u2018em.<\/em><\/span><\/p>\n

    But there are a few problems with pattern libraries. Yes, they allow you to keep all of the smallest elements consistent. But they don\u2019t have an opinion about how they should be put together. They don\u2019t know anything about your product or the concepts behind it.<\/p>\n

    To return to our Lego analogy, simply having a limited pattern library of bricks to choose from doesn\u2019t preclude me from building some really crazy shit.<\/p>\n

    \"\"
    \nImpressive, but not exactly coherent design \u2013 and that\u2019s just the curtains.<\/em><\/span><\/p>\n

    Now think about those branded Lego kits you can buy. Each piece is much more opinionated. It knows what it\u2019s going to get used for. There are still generic pieces involved, but when you put them together in a certain way they form something specific, like the leg of an AT-AT Walker. This is a design system.<\/p>\n

    \"\"<\/p>\n

    (Caveat: those highly-prescribed branded kits are actually kind of boring and there\u2019s no Lego better than a giant bucket of bricks and an imagination. Coherence is strictly for grown-ups.)<\/p>\n

    From Atomic Design to full stack design systems<\/h2>\n

    This approach is not unlike the Atomic Design approach I mentioned earlier. Atomic Design will tell you to take some of your basic elements (label, input, button), stick them together, and call it a molecule. Then you can reuse that molecule again and again. Further, you can stick some molecules together to form a reusable organism.<\/p>\n

    The problem with every real-world example of a system like this that I\u2019ve encountered is that they remain wilfully unaware of the product being built.<\/p>\n

    When you\u2019re creating a bespoke Design System for a specific product, you have the opportunity to not just group common UI elements together, but to actually represent your core product concepts at many levels. I call this a Full Stack Design System<\/strong>.<\/p>\n

    Here\u2019s what a Full Stack Design System might consist of:<\/p>\n