Published on <a href="http://ift.tt/2oGFWnt">| Prototyping: From UX to Front End &mdash; Medium</a> Morgan Gore 
Designing for growth, ambiguity and uncertainty.
<img alt="" src="http://ift.tt/2q9mikn">Photo courtesy, Echo Grid via <a href="http://ift.tt/2oZZZ2O">Unsplash</a>
<blockquote>“Every project that you do should be a design systems project.” —<a href="http://ift.tt/2q9rZyN"> </a><a href="http://ift.tt/2oZRjti">Dan Mall</a></blockquote>
<h4>Design Systems</h4>
The popularity of pattern libraries has has caused some debate in design-land. Pattern libraries are seriously having a moment! I’ve seen a good amount of negativity towards the popularity of pattern libraries because of the idea that they promote the creation of visual artifacts for the sake of creating visual artifacts (without guiding principles and logic). Even if it begins at the surface-level, we should be happy that designers are thinking in terms of systems.
Pattern libraries help create a shared language between teams, reducing wasted lines of code, increasing site performance and lifting considerable cognitive load from both design and development teams — allowing them to move faster (and break less things). Their existence helps combat the need to debate minutiae and allow teams to work on solving more complex problems.
<img alt="" src="http://ift.tt/2q9iuzF"><a href="http://ift.tt/2nfx7jj">Salesforce Lightning Design System</a>, Image by <a href="http://ift.tt/2o8A1XA">Thanh Quach</a>
If we think about a design system as a product, we inherently know that there is more to be done than to create a beautiful UI component or pattern library. Pattern libraries are extremely powerful tools, but they are just one piece of a design system (and a topic for another article).
<blockquote>“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, and environment in a city plan. -Eliel Saarinen,” 1930</blockquote>
<h4>Designing for the next largest context</h4>
Think of your UI in the context of the system it exists in (the next larger context). A button in a form, a form on a page, the page in the browser, etc. Elements and components should be designed to live in and adapt to different contexts.
This translates to designing apps to fit into a platform-specific ecosystem, or within the browser and device.
<h4>The Rate of Change</h4>
Pace Layer Protocol (or <a href="http://ift.tt/1P9n4GM">Pace Layered Application</a>) suggest that components of a system change at different rates. This concept is easily demonstrated in urban planning and the development of cities: The natural landscape and underground infrastructure, such as railways, etc, change at a much slower pace than the fabrication of buildings or the addition of solar panels on a roof.
The example below depicts the different rates of change for the components of a house or building. You’re likely to replace or change your appliances, furniture or color of the walls before you move your fireplace to the next room. In design, the rate of change for UI components is greater than changing the location of your severs — or maybe you like to change servers all the time and a better example would be switching from a mutated version of Magento 1 to Magento 2 ?.
<img alt="" src="http://ift.tt/2q92EEY">Pace Layer Protocol
Design problems can be solved by stepping back from the immediate problem (one data point) and seeing the system as a whole. Look for what’s moving fast and what’s moving slow. By taking a step back, you may be able to more easily spot the underlying issues or, root cause, of the issue.
<blockquote>“A design system is the architectural core of product” — <a href="http://ift.tt/2p00JF9">Marcin Treder</a></blockquote>
<h4>Building the system</h4>
Apply this in your design process by “enabling change in fast layers and building on stability in slow layers” (<a href="http://ift.tt/2q9wtWg">Dan Hill</a>). Whatever the system, spend time on the foundation and build on it.
When building a design system, invest time in structuring the foundational core principles and create a solid framework (slower changing layers) that will guide the fundamental design decisions made when creating the UI and interaction patterns (faster changing layers). These principles enforce consistency, help designers navigate ambiguity and create alignment amongst teams.
<blockquote>“Design principles have to become part of the design system” — <a href="http://ift.tt/2oaNaUB">Marcin Treder</a></blockquote>
When building product, invest in the infrastructure. Product features and UI exist on fast changing layers that you can quickly learn and iterate on. We can also consider development cost here, where architecture can be very expensive to refactor, but features, usually less so.
<blockquote>“For any Designer who wants to spend time working in a large complex system, they must be aware that every system will inevitably fail.” <a href="http://ift.tt/2nP7pDN">Helen Tran</a></blockquote>
<h4>Know that systems will fail</h4>
When organizations grow, they come to a point where the existing system can no longer support it and breaks down. Communication breaks down across growing teams, reporting processes become strained and the needs of the organization need to be reassessed.
As team structures need to adapt to the evolving needs of the organization, design systems (and systems, in general) will need to adapt to scale effectively, and across platforms.
When a system fails, we need to look at where it broke down and adjust. The system does not have to be replaced entirely, but it must adapt.
There is an argument that start-ups and high growth companies shouldn’t encourage design to waste time creating “scalable” design systems that will soon become artifacts. While the concern is valid, the importance of thinking in systems is that you create pieces that can more easily adapt and grow — which results in less wasted time redesigning or rethinking existing components. The design of products will continue to evolve over time, and the systems we build should extend themselves to support that growth.
<img alt="" src="http://ift.tt/2p00Lgf">Photo: <a href="http://ift.tt/2bfXUpQ">The Incomplete City</a>, Dan Hill
I was fortunate to hear <a href="http://ift.tt/2nOOTvt">Dan Hill</a> speak at the O’Rielly UX Design Conference about an urban planning project that he conducted with Joseph Grima called, <a href="http://ift.tt/2bfXUpQ">The Incomplete City</a>. The project explored adaptive design in urban planning and architecture, guiding a group of students to incrementally build out a city focussing on elements, not buildings. Remaining ‘incomplete’ kept the focus on adaptable elements that can easily build on each other.
<blockquote>A Design System isn’t a Project. It’s a Product, Serving Products” — <a href="http://ift.tt/1p9Fuh6">Nathan Curtis</a></blockquote>
As design is an ongoing relationship between user and designer, design systems are a constantly evolving process. Some layers grow and change faster than others. A design system needs to be reassessed and maintained over time to sustain growth.
<h4>Design systems that adapt</h4>
The principles that inform the creation of pattern libraries should be able to translate across contexts and mediums. When designing them, consider the context and environment they will (or can) exist in. Leave space for patterns to evolve.
Spend time creating a solid foundation and iterate quickly on fast-changing layers. Invest in the infrastructure.
Step back from a problem and see the system as a whole. Understand where it works well and where it doesn’t. Anticipate where the system will break and design for it.
<h4>Further Reading</h4>
<ul>
<li><a href="http://ift.tt/2q9wtWg">Architecture and interaction design, via adaptation and hackability</a></li>
<li><a href="http://ift.tt/266B5PJ">Maintaining Design Systems | Atomic Design by Brad Frost</a></li>
<li><a href="http://ift.tt/2q9gF5P">Journal: Tom Moran on Everyday Adaptive Design (long)</a></li>
</ul>
I’m a product designer currently building a team and driving design culture at an edtech startup. Follow me on <a href="https://twitter.com/bildcreative">Twitter</a> <a href="http://ift.tt/2p03Qgt">Instagram</a> or <a href="http://ift.tt/2q9dTgG">Dribbble</a>!
<img src="http://ift.tt/2oZTXiP" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2q9yl0S">Why Every Project Should be a Design Systems Project</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why Every Project Should be a Design Systems Project

Top Stories