Better. Faster. UXIER.Atomic Design

jennifer gergen@b9punk

Agile UX NYCFebruary 25th, 2012

This talk is about an idea for a new way of doing things, not a baked & tested solution.

Even describing the problem together is worth it. Let’s start the discussion.

Imagine a better way of handling the brass tacks of agile design.

Join me in a (day) dream

Design is the difference between awesome and awesome-sauce.

Big Design Upfront just doesn't cut it.

Agile Rocks (We believe!)

Can’t we get more done, faster, with less drama?

Let’s pretend

we already agree

iterate

Agile UX could use another iteration...

Prototype

We're not so good at iterating when it comes to "big" visual changes.

Most of our regular iterations focus on building or improving features or pages, and can’t really encompass global look & feel updates.

When this is the case, designers usually choose existing styles (they frequently hate and are dying to improve), so as not to "break" the look & feel and confuse their users.

Enough of this and eventually we end up with "redesign" projects. Which suck.

iterating onLook & feel is still a slow boat

The agile manifesto defines simplicity as:“the art of maximizing the amount of work not done."

Either you're (doing some variation of ) linking comps together, or you have demos that work fine, but look really rough.

In either case, it's often hard to be sure of your results. (Maybe the test would have had different results if the hover states had worked properly, etc.)

By the time you marry the two halves, you're so far along that you might as well just release and figure it out from there.

Prototyping is harder than it

should be

Scenarios that suck

Hey, I still need that

file...

Scenarios that suck.

What?I totally emailed

that to you yesterday

Was the attachment

larger than 5mb?

Dude, just put it on the “Z” Drive.

Developers don’t have

access to “z.”

Want to borrow my

thumb drive...?

What is a “LW_xmod_oxy_1376_final_new.psd?”

Scenarios that suck.

?

Yay! I’m finished! It looks just

like your design!

Scenarios that suck.

Oh no! That’s the old version...

Hey, This project sounds familiar...

didn’t we mock this up last year?

Scenarios that suck.

Yeah. The Blue team was working

on it but it got de-scoped.

Word. Where are the comps?

Um, Judy worked on that but she’s not here anymore.

Where are her files?

UM...Does someone have the password to her mac?

Hey team, i know we’re working on “project y”, but

“project y” involves “widget x” which could really use a new

design...

Scenarios that suck.

But “widget x” is all over the place...if i change it here can we

change it everywhere?

Hmm.. let’s see...

OMG, changing “widget x” means updating 100’s of

pages.

Is this even going to affect

our KPI’s?

That would be awesome! “Widget x”

sucks!

That turns our 3 point story into a 20

point story.

... so that’s a no..

What’s with this stylesheet?There’s no difference between

.grey-text-regular.text-default-grey

&.grey-caption-text!

Scenarios that suck.

...Dunno, Dude ... That’s what the designers sent.

i just copied and pasted...

Seriously, we can do better.

Global Incremental Style Change or Continuous Design Deployment

actually Rapid useful Prototyping

Good designer ‹—› developer collaboration on markup and css

Good design asset management & collaboration (versioned)

Easy Discovery

Okay, what do we want?

It’s actually agile—smaller changes globally based on user feedback

Redesigns are expensive, and their value is hard to measure, so they happen very infrequently

Redesigns can cause massive user backlash

Style guides aren’t clairvoyant

No one ever reads the @!&*ing manual anyway

Continuous Design deployment

High fidelity / low effort

Enable designers & product managers, etc., to create these prototypes

Ability to build prototypes instead of mockups for some projects

Actually Rapid Useful Prototyping

stay DRY (Don’t Repeat Yourself )

Enable & teach designers to write production-ready code (images don't have to get re-pathed, etc.)

Share workload for patterns, components & prototypes

Knowledge sharing

Appropriate medium-to-task matching (no more juggling forms in photoshop)

designer ‹-› developer collaboration

on markup & css

The way most designers store & backup their files is just plain scary

It’s central (The whole team gets their stuff from the same source)

Get all related project design assets together (Wireframes, comps, copy, etc)

Certainty that you are always working with the newest file

Potential for embedded art

Version control is a form of automatic documentation

Better design asset management & collaboration

= version control

Shared vocabulary (across all teams & departments)

Be able to find things quickly, without having to ask

Central & Accessible

Ability to guess what something is by the way it's named

Quickly learn how things are organized (easy on-boarding)

easy discovery

A ssetsToM arkup (for)

I terativeC ollaboration

EnterAToMIC Design

(just go with me on the awkward backronym...)

A new (?) Design strategy

Brand Guideline

Component Library

Pattern Library

“A pattern is a solution to a recurring design problem.”

Examples of patterns are:buttonstabspagination

They are icons, mechanisms, etc., that have commonly accepted behaviors that make up a universally understood visual language for software.

Patterns

Borrowed from “Modular Web Design” by Nathan Curtis

“A component is a chunk of a page design.”

Components

A component is a logical grouping of related content & functions that are combined into a meaningful building block used—and reused—in the interface design of a site.

Borrowed from “Modular Web Design” by Nathan Curtis

Once you start to think of your content in this way, you can set yourself up to evolve the look & feel of these chunks in the same way that we evolve our features and products.

You need the whole team—maybe even the whole department—to help define and name these chunks, but once you have, you can start organizing your files, photoshop layers, & css classes, etc. against them.

You’ll get consistent names, and a shared vocabulary.That, alone, is worth the price of admission...

it’s an organizing principle

AToMIC Design

Organize for continuous design evolution(component + pattern scheme)

COLLABORATION

Versioned Design Assets

organized Markup + CSS

Library

show me the money

App Folder(s)

.

.

.

Components

SEARCH-RESULT

HTML(one file for each state)

CSS

js(includes a state handler)

Data

DEMO

App Folder(s)

.

.

.

Components

SEARCH-RESULT

HTML(one file for each state)

CSS

js(includes a state handler)

Data

DEMO

Patterns

Prototypes

Get Started

Define "component" v "pattern" that makes sense for your project/team

Naming guidelines (semantic, outsiders should be able to guess what it means, hyphens, no scheme/codes, etc.)

Setup some minimal infrastructure

version control (s) - branch scheme, file organization scheme, etc.get everyone accounts + trainingbuild the component & pattern browser

Starter workflow

— Iterate until it works for your project —

Sample Workflow

Discovery+Initial designs

COmponent definition

& naming

design,Develop,style,QA,[Document]

&Add to library

Assemble Pages

Thanks!

jennifer gergen@b9punk

Can we please keep talking about this?

Please connect with

@DesignAtomic

Wayne Warner@wawjr3d

The whole Ladders Team@Theladders

Our Lovely Hosts@agileuxnyc

—Big ups—