Graphics Reference
In-Depth Information
do the things it needed to do to fit the original concept? These were questions of art, and
their answers didn't always coincide with the issues raised in everyday use by the general
public. In my earlier work, I'd seldom had to take this conflict seriously.
This perspective changed my own approach in various ways. Projects done using
Waterfall models had been more self-contained. Lacking the pressure of real user testing,
the pace had been slower. We'd had the doubtful luxury of designing products in a vacuum.
We conceptualized, analyzed and developed prototypes and models, then tested them in
our internal usability lab. We adapted and revised according to what we saw among lab
users—who usually understood how to use digital products better than normal consumers
did—then we sent the products forth into the marketplace. In Agile, there wasn't time for
all of that. This was a more rapid process. Agile thrived on constant feedback coming from
tests run along the way. The test subjects were typical people with typical needs—not lab
personnel. In Waterfall, I'd never receive feedback from average users until the design pro-
cess was over. Consumers bought the product, used it at whatever level of delight or frus-
tration it incited in them, then made their praise or complaints known—sometimes loudly.
A smart designer listened to the complaints, but the only chance to answer them came in
the design of the next generation of similar products.
Designing for years using Waterfall methods had eased me into a mentality that I now
call “Artistic Ego.” Like an artist, I was so enamored with my personal vision for a product,
that I seldom gave full consideration to users' specific needs. In Agile, the user was always
near the top in our priorities. An idea only began to make real sense when it supplied what a
user wanted or needed. As we refined the idea into a design, we constantly tested compon-
ents on real users. How did they react to the small red button? Was that easier to use than
the big blue one? Was the screen big enough? Were the controls workable? Could users
readily identify task workflows? Did they have the necessary features to do those tasks in
a clear and concise manner?
Like almost all adjustments, this had its rough patches. At first, I would show up to
the standup meetings with presentations that included cutting-edge interaction models de-
veloped with the newest technology. I'd display these fully fleshed-out designs for my
coworkers, only to learn that my idea didn't make sense for the segment of the AOL audien-
ce we were targeting with our product. I wasn't used to this approach, and at first I rebelled.
How could my state-of-the-art concepts be so out of touch? At my other jobs, my work
hadn't met this kind of reception. These guys were behind the design curve, I thought, and
their competitors were going to leave them behind. My previous experience combined with
my ego convinced me so. I'd worked in a world where the designer's whims came first.
I didn't want to give that up. But I also wanted my designs to mean something. Though
