This talk proposes a new approach called Atomic Design for improving agile UX processes. It focuses on enabling rapid prototyping through higher fidelity prototypes, better collaboration between designers and developers on markup and CSS, and improved design asset management through version control. The approach involves organizing design assets into reusable patterns and components stored in a central library. This would allow for continuous incremental improvements to design globally based on user feedback, rather than large, infrequent redesigns. It aims to make discovery and collaboration easier through a shared vocabulary and standardized organization of files.

1. Better. Faster. UXIER.
Atomic Design
Agile UX NYC jennifer gergen
February 25th, 2012 @b9punk

2. Join me in a (day) dream
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.

3. Let’s pretend
we already agree
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?

4. Agile UX
could use another iteration...
Prototype
iterate

5. iterating on
Look & feel
is still a slow boat
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.

6. Prototyping is
harder than it
should be
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.

7. Scenarios that suck

8. Scenarios that suck.
Hey, I still Dude, just put it on
need that the “Z” Drive.
file...
Was the
attachment
larger than 5mb?
Want to
What? borrow my
I totally emailed thumb drive...?
that to you
yesterday
Developers
don’t have
access to “z.”

9. Scenarios that suck.
What is a
“LW_xmod_oxy_1376_final_new.psd?”
?

10. Scenarios that suck.
Yay! I’m finished!
It looks just
like your design!
Oh no! That’s the
old version...

11. Scenarios that suck.
Hey, This project
sounds familiar... Um, Judy worked on that but
she’s not here anymore.
didn’t we mock this
up last year?
Word. Where are
the comps?
UM...Does
someone have
the password
Yeah. The Blue to her mac?
team was working
on it but it got
de-scoped.
Where are her
files?

12. Scenarios that suck.
Hmm.. let’s see...
Hey team, i know we’re
working on “project y”, but OMG, changing Is this even
“project y” involves “widget x” “widget x” means going to affect
which could really use a new updating 100’s of our KPI’s?
design... pages.
That would be
awesome! That turns our 3
“Widget x” point story into a 20
sucks! point story.
But “widget x” is all over the
place...if i change it here can we ... so that’s a no..
change it everywhere?

13. Scenarios that suck.
What’s with this stylesheet?
There’s no difference between
.grey-text-regular
.text-default-grey
&
.grey-caption-text! ...Dunno, Dude ... That’s what the
designers sent.
i just copied and pasted...

14. Seriously,
we can do better.

15. Okay,
what do we want?
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

16. Continuous
Design deployment
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

17. Rapid
Actually
Useful Prototyping
High fidelity / low effort
Enable designers & product managers, etc., to create these prototypes
Ability to build prototypes instead of mockups for some projects

18. designer ‹-› developer
collaboration
on markup & css
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)

19. Better design asset
management & collaboration
= version control
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

20. easy discovery
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)

21. Enter
AToMIC Design
(just go with me on the awkward backronym...)
A ssets
To
M arkup (for)
I terative
C ollaboration

22. A new (?)
Design
strategy
Brand Guideline
Component Library
Pattern Library

23. Patterns
“A pattern is a solution to a recurring
design problem.”
Examples of patterns are:
buttons
tabs
pagination
They are icons, mechanisms, etc., that
have commonly accepted behaviors that
make up a universally understood visual
language for software.
Borrowed from “Modular Web Design”
by Nathan Curtis

24. Components
“A component is a chunk of a page design.”
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

27. it’s an organizing
principle
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...

28. AToMIC Design
Versioned
Design Assets
Organize for L
continuous i
design b
evolution COLLABORATION r
(component + a
pattern scheme) r
y
organized
Markup + CSS

29. show me
the money

33. .
.
App Folder(s)
Components
SEARCH-RESULT
HTML
(one file for each state)
CSS
js
(includes a state handler)
Data
DEMO

34. .
Prototypes
Patterns
App Folder(s)
Components
SEARCH-RESULT
HTML
(one file for each state)
CSS
js
(includes a state handler)
Data
DEMO

35. 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 + training
build the component & pattern browser
Starter workflow
— Iterate until it works for your project —

36. Sample Workflow
design,
Develop,
COmponent
Discovery style,
definition
+ QA, Assemble
Initial & [Document]
Pages
designs naming &
Add to
library

37. Thanks!
Can we please keep talking about this?
Please connect with
@DesignAtomic
jennifer gergen
@b9punk
—Big ups—
Wayne Warner The whole Ladders Team Our Lovely Hosts
@wawjr3d @Theladders @agileuxnyc