TITLE: Agile Moments: Stories, Tests, and Refactoring in Visual Design
AUTHOR: Eugene Wallingford
DATE: June 20, 2013 12:32 PM
DESC: 
-----
BODY:
In
<A HREF="http://www.teehanlax.com/story/medium/index.html">
   A Place for Sharing Ideas and Stories</A>,
designers Teehan+Lax tell the story of their role in creating
<A HREF="https://medium.com/">
   Medium</A>,
"a better place to read and write things that matter".  The
section "Forging ahead", about features added to the platform
after its launch, made me think of some of the ideas we use
when designing code test-first, only at a much higher level.

<BLOCKQUOTE><EM>
 We reset by breaking the team up into new feature teams.  Each
 feature team would have at least one designer, one front-end
 developer and a back-end developer.  Some teams would take on
 multiple features depending on their complexity.  We used one
 page briefs that were easy to write, easy to understand and
 helped guide the teams when working through their feature(s).

 <B>They consisted of questions like:</B>
 <UL>
 <LI> Who is this page for?  </LI>
 <LI> What problem does this page solve for the user?  </LI>
 <LI> How do we know they need it?  </LI>
 <LI> What is the primary action we want users to take on this page?  </LI>
 <LI> What might prompt a user to take this action?  </LI>
 <LI> How will we know that this page is doing what we want it to do?  </LI>
 </UL>
</EM></BLOCKQUOTE>

This bullet list embodies several elements of agile development.
For each feature, the brief acts like a story card that boils
the feature down to a clear need of the user, a clear action,
and, most important in my mind, a test: <EM>How will we know
that this page is doing what we want it to do?</EM>  In a lot
of my work, this is a crucial element.  As Kent Beck says, "How
will I know I'm done?"

The paragraph preceding the list highlights a couple of other
attributes common to agile development.  One, teams are working
on stories in parallel on a common artifact.  Two, the teams
include a designer, a front-end developer, and a back-end
developer.  The team doesn't include a user, which can be a
huge advantage for developers, but the author mentions elsewhere
that nearly everyone on the team was a user:

<BLOCKQUOTE><EM>
 As the internal product progressed and its features and
 capabilities became clearer, we would reduce the amount of ad
 hoc meetings and focus on getting stuff built into the product
 so we could actually use it.  Talking about work is great at
 first, but usage is what breathes life into the product.
</EM></BLOCKQUOTE>

The author also stresses the value of physical co-location of
the designers and developers over even well-supported electronic
communication, which echoes for me the value of having a user in
the room with the developers.

What happens as features were enhanced or added by separate teams?
<B>"... maintaining some sort of design integrity across the entire
product</B>."

<BLOCKQUOTE><EM>
 This thing was about to get full of user choices (read:
 complexity) in a hurry -- The product was now at a critical
 point in its life.
</EM></BLOCKQUOTE>

Of course, complexity and incoherence can creep into products even
when they are designed and built by one team, when it works on
multiple features in rapid succession.

The solution for Medium sounded familiar:

<BLOCKQUOTE><EM>
 We took a week off current fixes and features and focused on
 redesigning three pages from scratch: Home, Collection and
 Post.  Some of it went live, some of it went away.
</EM></BLOCKQUOTE>

And:

<BLOCKQUOTE><EM>
 We hated to see some of the stuff we'd designed (and even
 built) not go live, but it needed to die so the product could
 grow through simplification.
</EM></BLOCKQUOTE>

This reminded me a lot like refactoring, even with differences
from the way we refactor at the code level.  As teams added
features without considering the effect of the changes on the
global structure of the product, they accumulated something
akin to "design debt".  So after a while they dedicated time
to paying off the debt and bringing back to the product the
sense of wholeness that had been lost.  I am curious to know
whether the teams ever looked back at the page briefs to verify
that the redesigned pages still did what they wanted them to do.
That would be the equivalent of "running the tests".

We programmers really do have it nice.  Lines and units of code
are a bit more separable than the visual design elements of a
product.  This allows us to refactor all the time, if we are so
inclined, not just in batch after a large set of changes.  The
presence of concrete tests, written as code, allows us to test
the efficacy of our changes relatively easily before we move
forward.  While down in the trenches writing code, it's easy to
forget just how liberating -- and empowering -- this combination
of separability and testability are for design and redesign.

It's also easy to forget sometimes that similar challenges face
designers and creators across domains and disciplines.  Many of
the same themes run through stories the things we create,
whether software in the small, software in the large, or
physical artifacts.  Reading Teahan+Lax's story reminded me of
that, too.
-----