Copy
Issue 17 \\ Read past issues

Issue 17 // Systemic Design

Planes, buildings, automobiles, software. On the surface, one of these things is not like the other. But at a recent talk at the Warm Gun conference in San Francisco, our UX Developer Federico Holgado connected the systems of manufacturing and app development.

The rapid iterations and MVPs inherent to software already exist in the assembly of products much bigger and more complex. What Federico points out is that a ship, a building, and a car are merely collections of components. Components are manageable and flexible. So long as the components join together seamlessly in the end, modularizing the pieces translates to flexibility, speed, and paradoxically both independence and collaboration. Read on to see how we applied these insights to MailChimp.

We conclude this issue with some links from the world of UX.
Tweet
Share
Forward to Friend
EditingGregg Bernstein
IllustrationCaleb Andrews
Hey, did you miss our last issue?
On Twitter: @MailChimpUX

Architecting a Pattern Library


by Federico Holgado
This article is adapted from a talk Federico recently gave at Warm Gun.

Refabricating Architecture

A few years ago, I read a book called Refabricating Architecture that made a profound impact on me as a designer. My educational background is Industrial Design, which is the design of consumer products for mass manufacture. Industrial design is very closely related to architecture, and a lot of ideas are shared between professions. Industrial design is also closely related to software design—the process is almost identical, but the media for prototyping products differs (foam, wood, and metals, versus html, css, and javascript).
The book compares architecture to the auto, aerospace, and shipbuilding industries. Architectural and building construction processes have not fundamentally changed in the last 80 years or so, while the other industries have radically shifted in how they create, design, and build.
After reading the book, I realized that the most important points relate to the work that we do building and designing software. I began to think in terms of "designing software for mass manufacture."

The pillars of industry

The auto industry has been pushing the boundaries of industrial processes, and has been able to reduce the average time to market to around 12 months. Time to market is measured from when design is started until the vehicle rolls out of the factory. As a comparison, the average time to market a mere 20 years ago was around 60 months!
Recently, Tesla Motors surprised the world with an amazing, fully electric car that rivals the quality and performance of Mercedes Benz and BMW sedans. And this was their first attempt. This car does 0-60 in 4.2 seconds, features a range of almost 300 miles, and showed the world that electric cars are viable today.
The amazing Tesla Model S sedan. Source
The shipbuilding industry rivals architecture in terms of the scale of the end product. Here are the two largest passenger ships in the world, the Allure of the Seas and the Oasis of the Seas. These ships can carry, feed, and entertain over 5,000 passengers and 2,000 crew members, and they do it all while traveling at a top speed of 26 miles per hour. Shipbuilding has implemented a highly modularized construction system, where parts of the ship are worked on simultaneously off-site while the structure and hull are assembled at the shipyard. This allows concurrent production that speeds up build time, while improving quality and reducing costs.
The Oasis and Allure of The Seas. Source
On the other hand, the architecture and building construction industries have not changed much in the last 80 years. They're still ruled by a bottom-up model governed by gravity—the ground level must be completed before the higher sections can be constructed. This forces a strict and linear building process, which in turn segregates different parts of the industry into their own highly specialized silos. Today's architecture has not kept up with the rest of the world.
The ongoing construction in Dubai that never seems to slow down. Source

Architecture and Software

Building software in this day and age is a highly complex matter that rivals architecture, cars, or ships in complexity. Our projects are also scoped in months and years, and require highly specialized teams of people to build.
Our UX team started redesigning MailChimp at the beginning of this year, and we had the chance to experiment with how we design and build software. This was a chance to start "fresh" (or as fresh as conceivably possible with an app of our size). We learned some things along the way, and there was a clear and interesting overlap between our experiments and the ideas that are pushing these industries into the future.
To give you an idea of what we went through, it took:
  • 6 months from concept to build and launch of an entirely new app ready for desktop and mobile devices
  • 6 UX developers, 2 back-end developers, and 2 UI designers
  • 3.5 million customers served
  • 3 rapid releases post-launch to refine
And our initial metric of success was fulfilled: No mass customer revolts.
Even though we survived our redesign, it still felt dangerous.
  • What tools and ideas can we use to make the next redesign more manageable?
  • How can we survive?
  • How can we make meaningful progress in how we build software after a redesign?
  • How can we make the redesign valuable, instead of costly?
  • And how do we stay focused on the user experience and not get lost in the tech to implement it?
The answers lie in the result of a seemingly unrelated but astonishingly relevant question: What is wrong with architecture today?

Architecture 101

Here's a quote from Refabricating Architecture that, at a high level, describes the current state of architecture:

The traditional building paradigm is to gather all the parts of a building on site and then assemble them piece by piece.
First, an architect must survey the land where the building is to be erected. She must take careful measurements, and create 2D drawings based on the designs. These designs must take into account many regulations, laws, and requirements, including accessibility guidelines.

The complexity of architectural plans. Source
A completely different team, using specialized machinery and devices, must then interpret these drawings to prepare the land by grading it, and prepare it for the foundation that will be poured shortly afterwards.
More specialized machinery and teams—including a structural engineer— are required to start the next process, which consists of pouring the foundation.
Note that almost no work can commence until the land is prepped and the foundation is poured. Following the foundation, the structural components of the building can finally go up. Then comes plumbing, and finally the interior finishes. This process is linear, rigid, and has caused fragmentation in the teams that work together to erect a building.

Cars, Ships and Apps

The automotive industry has taken advantage of tools to share information, and has combined multiple processes to optimize production, cut costs, and make higher quality automobiles.
The modern automobile factory is no longer the assembly line that Ford pioneered, but has been effectively reduced to an assembler of finished components.

Instead of manufacturing and assembling every piece of the car under the same factory roof, those pieces are subcontracted to other Original Equipment Manufacturers [OEMs] that specialize in the work.

Even more interesting is that these OEMs are actually divisions within the same company. And if they're not part of the manufacturer, their facilities are actually in very close proximity to minimize transport.
What happens now is that a "door" division of a car manufacturer is effectively gathering parts for the door. The stamped metal frame of the door is manufactured in a different (but adjacent) facility. A completely different manufacturer will produce the mirrors, window, lock switches, and interior panels.
The "door assembler" will gather all these parts—parts that have been individually QA'd at their respective facilities—and turn them into a completed door. The car manufacturer then takes that QA'd, completed door and will bolt it onto the car frame. The only QA that's needed at this point is to ensure that the joints between the car frame and the door are appropriate, and that the electrical connections function properly.
This process allows the development of these components at the same time that other components are being manufactured. It also allows for manufacturers to specialize and optimize the process of creating car mirrors, which would otherwise be too time consuming or expensive to focus on for a car manufacturer.
Manufacturing diagram from "Refabricating Archictecture."
You could argue that we're comparing apples to oranges when we look at cars versus buildings. But what about shipbuilding? Some of the larger ships that sail the oceans rival and sometimes eclipse the size of buildings, yet the technology of building ships has adapted to the changing world.
Modular construction allows shipbuilders to defeat gravity, and concurrently work on different modules of the ship that are not limited by the location or proximity to the ground. Even the infrastructure for building ships has evolved, and massive cranes will transport ship modules that are the size of a building and simply place them like Lego blocks in the appropriate place.
A module from the Oasis of The Seas. Source

Systems

So what can we learn from the auto and shipbuilding industries, and how can we apply them to the world of software development? While working on the MailChimp redesign, we took some of these ideas about modularity and multi-threaded development and applied them to the way we build.
The end result is a system—a system of individual and interchangeable parts that start at the smallest possible level and grows from there. Components are then assembled from these individual parts, and these components make up some of the core parts of our app. Once a group of components are assembled, we get a fully functioning page inside our application that is consistent in design and architecture with the other pages of our app—all because the pages share the same architecture.
Individual parts that make up our Pattern Library.
If you reference the diagram above about modern automobile construction, you can draw some parallels between industries. These blocks can be manufactured in parallel because their underlying structure (typography, spacing, button styles) are already in place! The only crucial part of this process is that all engineers that work on these pieces know how their components will coexist within the rest of this environment. This environment is our pattern library.
Our pattern library consists of both fundamental pieces and ready-made components that are built from these small parts, and provide a developer with a great toolset to build interfaces that adhere to the systems we've created. Instead of going over individual components that are part of our library, I'd like to show you how they've helped us in the real world.

Slats in the real world

One of the most fundamental and far-reaching parts of MailChimp is our system of “slats.” When we began our redesign, we started with the most visited pages of our app—the main section dashboards (campaigns, lists, and reports). In the old MailChimp, we used a simple table to display these items. Upon further examination, we had a hunch that there was a better way of visualizing this data.
We spent a lot of time thinking, sketching, designing, and prototyping ideas, but nothing was making sense to us. We explored a dual-mode interface with “cards” that were visually appealing and tables to satisfy the more information-dense requirements of some of our users.

A visual approach to campaigns doesn't work because of the similarity of the campaigns our users send—they all look generally the same! We also realized that one of the important things our users did in the campaigns table was to sort by different attributes to “find” campaigns. The sortable attributes available didn't make any sense, and this freed us from the notion that we had to display this data in a tabular manner.
Example of slats that are found throughout MailChimp.
The slat system was born from making these connections between different sections of our app, and eventually we landed on something that worked for our three main sections. We added filtering instead of sorting (where it was appropriate), and before we knew it, we created the foundation of our dashboards.
What we didn't know was that this system would make its way into some of the dark corners of our app, and be repurposed in ways that we had not yet imagined. Some of these darker corners are the list of Segments, or the list of Conversations, or most recently, our Exports dashboard. These are usually the parts of an application that will generally not receive the same level of attention as a main dashboard. But with our patterns, they fit within our system, they look beautiful, they're vetted, and they're familiar! They even respond to smaller screen sizes.
The months we spent designing the original slats paid off in more ways than we could have ever imagined. After the initial time investment, we were able to reuse the same code to beautify other parts of the app that would previously have been boring tables. Here are the Campaigns and Exports sections side by side—you can clearly see the resemblance. Adapting our slat system to the Exports dashboard took me all of 45 minutes, and this included a mobile view that functions and looks great.
Mobile campaign slats on the left vs. export slats on the right.
The beauty of this process was that while a small team splintered to work on the slat design, the rest of the team was hard at work implementing other parts of our system, like our Forms, overall page structure, and navigation. They were working on the foundation at the same time we were working on the interior, all while keeping each other in the loop.

The old way, and the new way

With this system we were able to modularize much more than just our slats. After our initial launch, we managed to modularize most of the app! Forms, buttons, tables, and pieces of our editor all started falling into place.
I have to admit, at first it was tough to think in this way. I vividly remember working “the old way:” crafting custom pieces of UI for every new feature we dreamed up. The CSS was unmanageable, and as much as we tried, things never felt like a true family of components—everything had a slightly different makeup, both visually and in the underlying code.
MailChimp circa late 2012.
And even though the time investment is significant in the beginning, we are reaping the benefits almost a year after we started the process. Our teams work independently, but always work from a common place. We have a platform to discuss our changes and ideas that allows not just the front-end devs, but also our engineers, to comment on code and design decisions.
Our visual designers have helped us establish rules of vertical and horizontal rhythm that help us minimize the number of joints when we assemble our pages. If the system is working properly, it means that the designers and front end devs are creating in lockstep.
Our back end developers have also benefitted from this system, since they are now encouraged to create general systems that can be reapplied. They have to learn how to implement less tooling, which speeds up our development time. Our standards now allow them to work on the data layer fully cognizant of what our UI expects.
And overall, the level of consistency and cohesiveness that we've reached feels good. The people that use our software now have a beautiful, responsive, and cohesive app that let's them work faster, and the people that build our software have a toolbox to craft our software in new and better ways.
MailChimp after the redesign.
Taking a cue from our shipbuilding friends, we've created modular pieces of the "ship" that can be developed at any point in the process. From our cousins in the auto industry, we've learned how to share requirements, how to break the QA cycle into smaller chunks, and how to share and tweak components.
In the end, we are in a better place now than we were a year ago, and that makes the hard work and long hours we put in worth it. We've created a system that will be the basis of our application for future iterations. Based on the lessons of our sister industries, we are headed in the right direction.
By the way, we're looking for a talented UI designer to join the MailChimp UX team.
Is this you?

UX Around The Web

Ask Us Anything

We want this newsletter to be a dialogue. If you have any questions for our team about what conferences we're looking forward to, what candy is still left in the office this week, or even Freddie's Halloween Costume, send them in. Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.
Twitter
© 2001-2013 All Rights Reserved.
MailChimp® is a registered trademark of The Rocket Science Group


view in browser   unsubscribe   update subscription preferences   



Email Marketing Powered by Mailchimp

Love What You Do