Since I’ve been back from abroad, I’ve written a lot about how designer and developer teams can work together more effectively. I’ve elaborated that it’s more than just making a pattern library. Now, I’ve finally done some work I can actually talk about: I can explain the design process that I’ve been writing around.

Shortly after arriving back in New Zealand I started working with the team at Figure.NZ. They had some front-end development work for me to do that was a short-term contract. I arrived at the tail end of the design process. A product had been designed. High-fidelity mockups were in progress. In a traditional waterfall design process we only had to wait for those high fidelity designs to be complete and it would be ready to implement.

I had my ideas about what an effective design process looked like, and the team graciously decided to let me try out these ideas. I promised them it would be more effective. It would cut down on churn and allow us to solve multiple problems at once. We put a hold on all design work that had been in progress at the time and set off on this new course.

1. Back to the wireframes

The first step was revisiting all our wireframes and identifying all the different components required to build this product. What was the sum of work we would have to do (in components—not pages). 15 components. Instead of 4 pages.

Now, examine your component library. They’re just names at this point. On a sheet of paper. See where the lines blur between components. What things are really just buttons. Or a list of buttons. Be ruthless. Do you need two types of buttons? Yes. Are you sure? Yes. What if we tried one. Let’s try one.

12 components.

Do not create deviations of components unless you actually have to. Very frequently we thought we might need variations of a component but by continually denying ourselves the option we realised that we either didn’t need them at all, or could find a different solution to the problem for which we were about to create a variation.

One of the components, where we were pretty sure we were going to need a variation, was the segmented controller. We thought we needed two varieties: radio and multi-select. Despite this, we spent hours trying to determine how we could get one UI component serving both roles from a UX point of view. This process allowed us to determine exactly what needed to be different in the variation. We didn’t change any more than was required.

Be strict on this. A component must justify its reason to exist. It is not your job to justify a reason for it not to.

The process for each component follows the traditional design process: IA → UX → Visual Design → Front-end development. The difference here is that each component is given the time of day. The designers aren’t caught up trying to solve big picture problems. They’re making sure this little bit works as best as it can.

2. Components and systems

These next three streams of work happen in parallel: Human-computer interaction design (or UX), Visual design and Front-end development.

UX

This stream has so many different names in our industry, I’m not even sure what to call it. The job is thinking through how a user interacts with each component and what affordances they require in order to be able to successfully interact with each component.

This often leads to wireframes or low-fi mockups of what said component needs to look like. How it should work. And what states exist in the component.

Visual

Visual designers can at the same time be figuring out the look and feel of the entire experience. Developing rules around the height of components, the padding around text within components. Figuring out what borders, highlights and backgrounds look like. Choosing typefaces and colours.

This phase normally zooms out to the big picture to make sure all these pieces work together, before diving back all the way down to the nitty gritty details of pixels. The designer’s role here is to just test the visual design. They aren’t creating high fidelity mockups from the wireframes. The content doesn’t really matter. It’s the visual DNA we’re after. They’re essentially creating style tiles.

Be strict on this. Once a rule has been set, follow it. This Visual DNA helps a product feel cohesive, and allows developers to create systems around your work. Only break these rules when it’s justified from a UX point of view.

Front-end Development

The front-end developers can start marking up patterns for the components in the library.

When the UX designers start making decisions around how components should work, they can start building low-fi versions of these components that can be used by the UX designers for validation.

When the UI designers start making decisions around typography styles, colours and spacing, they can start developing the Sass framework they’ll be relying on to describe what components should look like. It’s important to understand the rules, or tease out the rules from the visual designer’s work. These rules allow you to abstract out the visual DNA into ways you can use to make your code feel like prose. Allow you to write what the designers mean.

Hold your designers accountable. You’re part of the design team too. Make sure you follow the Visual DNA, not the PSD. In fact, don’t open the PSD. Know the DNA so well you can read the design from a JPG.

Systems (Visual DNA)

// define colour rules
$swatches: (
	clickable: #4d90fe
);

function swatch($name) {
	@return map-get($swatches, $name);
}

// define the rules around shapes: padding and decoration.
@mixin shape-pill {
	padding-top: 6px;
	padding-right: 14px;
	padding-bottom: 8px;
	padding-left: 14px;
	border-radius: $global-borderradius;
	border: 1px solid;
}

Components

// links should the colour of clickable things in our UI
a {
	color: swatch(clickable);
}

// buttons should be a pill shape, and look clickable.
.button {
	@include shape-pill();
	border-color: darken(swatch(clickable), 40%);
	background-color: swatch(clickable);
}

3. Pages

At some point, your library feels complete enough to be able to build out pages. At this time, UX designers, visual designers and front-end developers already have most of what they need to be able to knock out page designs in no time.

An idea should be able to travel from a UX designer to both the front-end developer and the visual designer at the same time. Both FED and visual designer can get to work immediately, and by the time the front-end developer has completed the page in browser, the visual designer is ready with high-fidelity mockups solving the thorny design problems specific to this page.

Although this third phase (page design) is somewhat dependent on the second phase (components and design systems), it by no means requires the second phase to be complete. In fact, the components and design systems are never done and will continue to evolve.

4. Change is constant

This project could probably have been completed with a traditional waterfall design process. It would have needed a longer schedule and resulted in a less ideal outcome. At the end of the project we would have realised we needed to change things that were too late to change. In fact, we did need to change a lot, continuously, throughout this project as we learnt more and more about what was needed.

As the front-end developer for this project, I never wanted the designers to feel like they weren’t allowed to make design changes because my work had already started. We were making branding and visual decisions until ridiculously late in the project and very few of us were worried because we understood (and had seen) how quickly these changes in decisions can filter through the project by switching up a variable here, or modifying a mixin over there.

In the end, because our pages were assemblies of components that were all built from a unified design system, we were able to drag components around in the browser to respond to design critiques. Or to quickly test new ideas. We were able to change a couple of settings to make fairly dramatic and far-reaching changes across our product, again, just to test them. Finally, we were able to solve multiple problems at once, without holding each other up, because we had seperated out UX from visual design, pages from components and components from design systems.

What is this thing you worked on?

Ah, well I can’t wait for you to see it. I’m insanely proud of the work we did, and you should be able to experience it around the end of March. Be sure to follow @FigureNZ or @ludwigw, we are bound to mention it the instant it’s live.

Up Next: Speak the same language

In this post I used an iceberg phrase: “They’re just names at this point. On a sheet of paper.” The iceberg below this phrase is the importance of naming components and why it’s so important that the entire team speaks the same language. Find out why it is important to speak the language »