Fri, Aug 26, 2005
Extreme Usability Redux
#
Another great FLOSS Usability Sprint is in the books. As usual,
great
people make for great gatherings, and this event was no exception.
But we did have a new goal for this event, and it resulted in some
different outcomes, many of which were related to this new notion of
ExtremeUsability. (JOS)
I have three overarching goals with all of these sprints: (JOT)
- Improve the usability of the participating projects. (JOU)
- Build greater SharedUnderstanding between the usability and
OpenSource communities. (JOV)
- Catalyze community collaboration. (JOW)
Additionally, as an organizer, you also want to "hit a home run," as
JeffShults likes to say. You want people to walk away feeling
wonderful about themselves and about the group at large. As with
baseball, you're not going to hit a home run with every event, but
you're constantly hoping for it. (JOX)
I think we hit a triple with our
first
sprint. We had great camaraderie and positive energy, everyone
learned tons, and all of the participating projects made tangible
progress. In fact, in the past few weeks, I learned that we made even
greater progress with "catalyzing community collaboration" than even I
had realized. KieranLal, JanMuehlig, and RashmiSinha have all been
developing tools for remote usability testing, a critical prerequisite
for OpenSource usability, where projects are usually distributed.
(Our next sprint will most likely be a Remote Usability Sprint,
tentatively scheduled for late Fall.) MimiYin's experiences at the
first sprint helped form the seed for her
most recent thinking for
Chandler. Mimi's informal discussions with DaveGreenberg at the
first sprint influenced the most recent release of CiviCRM, and they
worked together more closely this week. Most importantly,
the
many
report-backs generated buzz in the community and helped bring in new
talent, like TonyChang and JingWu. There was also room to improve,
though, and we incorporated some of that learning into this past
sprint. All in all, people walked away feeling good. (JOY)
This week's sprint felt like a double. Once again, our projects made
progress, people were buzzing and learning, and I think people had fun
overall. Nevertheless, there was a cloud hanging over everybody's
head, one that made folks a bit more uncomfortable and the process as
a whole more challenging. The cloud was the result of a special goal
for this particular event -- defining ExtremeUsability. (JOZ)
An Aside on Event Design (JP0)
We did not define ExtremeUsability prior to the event, largely because
none of us knew exactly what it was. I had opinions, based on
feedback from the first sprint and my own personal experiences, but I
didn't want to dictate the design of the event based on my own biases.
One reason for this stemmed from my growing faith in the power of
collective wisdom. Another reason was that I didn't want people
worrying too much about whether they were "doing it right." My main
concern was for the projects to get better. (JP1)
Gathering a large group of folks with diverse backgrounds isn't the
most efficient way to develop a methodology. The vast majority of
developers knew very little about usability, and only a handful had
ever practiced ExtremeProgramming. We had 25 people attend, including
users. In contrast, two people -- KentBeck and WardCunningham --
co-conceived ExtremeProgramming, and they had many years of software
development experience between them. (JP2)
The other complication, which we downplayed, was that this was not
simply an experiment in software development methodology. It was an
experiment in OpenSource software development methodology, which
introduced its own constraints. ExtremeProgramming isn't rampant in
the OpenSource community, primarily because its tenets are difficult
to practice in this environment. Who is the customer? How do you pair
program? What does a 40-hour work week mean, when you're writing code
on the side? (JP3)
Given all of these factors, it seems unrealistic to have expected our
participants to have contributed consciously to the creation of a new
methodology. Why, then, did we try? Why this format? (JP4)
My framing of ExtremeUsability to the participants provides some
insight as to why we chose this event format: (JP5)
- AgileProgramming is an acknowledgement that software development is
a collaborative process, and collaboration is hard. Agile
methodologies offer a framework for alleviating these
difficulties. Iteration and validation, for example, is a way to
build SharedUnderstanding. (JP6)
- Methodologies like ExtremeProgramming lack an explicit role for
usability practitioners. ExtremeProgramming provides rudimentary
methods for developers to collaborate directly with customers,
emphasizing "soft" forms of communication rather than requiring
rigorous structure. UserCenteredDesign, on the other hand,
incorporates into the process a usability specialist who has
a range of methods for understanding user behavior. (JP7)
- The theory behind ExtremeUsability is that usability practitioners
should be co-collaborators with programmers for the entire lifecycle
of the development process. (JP8)
- The biggest roadblocks for developers in this process would be to
open up their minds, willingly and sincerely embracing the usability
practitioners as codesigners, and accepting the possibility that
their assumptions about the users and the design might be wrong. (JP9)
The challenge is developing the framework in which usability
practitioners and developers collaborate. This sprint was a
laboratory in which we could experiment with this framework. (JPA)
Rather than impose a more rigid process up-front, I wanted to test a
general premise about collaboration: Eliminating barriers is generally
more empowering than problematic. PairProgramming is a perfect example
of this. A lot of programmers (and managers) react negatively to
PairProgramming the first time they hear about it, because they assume
that programmers need to be isolated to work effectively, and that
they will be unable to collaborate effectively without this separate
space. Experience has raised serious doubts about that assumption. We
see a similar phenomenon with Wikis. Most people still assume that we
have to impose structure and authority or our information spaces will
devolve into chaos. Wikis obviously challenge this premise. (JPB)
I wanted to watch how developers would work with usability
practitioners with no preimposed constraints, hoping that our
collective observations and experiences would result in a more useful
framework than I could have come up with on my own. (JPC)
The event was successful in this regard, but it came at a cost. We
placed a heavy burden on our participants by making this goal
collective and explicit. It's hard, even debilitating, to be
self-reflexive about process while you're working. This was most
evident on our second day. Frustration was palpable among our
participants, as they struggled to both work on their projects and
think about process. That everybody stayed positive and productive was
a testament to everybody's great attitudes, and for that I am
grateful. (JPD)
The conclusion among most of our participants, in the end, was that
what most of us practiced was not ExtremeUsability. I concur.
Nevertheless, it offered some clues as to what ExtremeUsability might
be. (JPF)
It may be a misnomer, for one. RashmiSinha suggested that what we were
aiming for was actually "Collaborative Usability." I would go further
and say that it was "Extreme Design," centering attention on the
design rather than the overall development methodology. (JPG)
Other thoughts: (JPH)
- "Customers" are not "users." Once a customer becomes a codesigner,
he or she loses value as a user, because he or she becomes subject
to major bias from the design process itself. We attempted to
include "users" as codesigners, which was wrong. You're either one
or the other (and it's okay for a "customer" to be a codesigner),
but you can't be both. (JPI)
- Pairing is good. We required each project to bring two developers,
and we assigned two usability specialists to each projects.
However, we did not mandate pairing, and there were also other
people working with each project. By the middle of the second day,
each of the projects had figured this out on their own. If we do a
second ExtremeUsability sprint, pairing will play a central role in
the process. (JPJ)
- ExtremeUsability is not about taking shortcuts. Sprints are. The two
should not be conflated. Many participants from our first sprint
said that their biggest takeaway was that informal usability was
valuable. You don't need to have a high-overhead (i.e. expensive)
usability process to develop usable software. I think this week's
sprint reinforced that. At the same time, I think it's important not
to conflate the sprint format with ExtremeUsability. (JPK)
Usability-Driven Projects (JPL)
We intentionally chose early stage OpenSource projects to participate
in this sprint, but in doing so, we were still propagating what seems
to be a given with all OpenSource projects: they are started by
developers. That naturally tips the power balance towards
developers. I would love to do a sprint where the roles were reversed.
Usability practitioners could bring project ideas -- perhaps with
wireframes or workflows -- and developers would come to help with the
design and implementation. (JPM)
In a similar vein, MimiYin had a great idea. There should be an
"inverted Sourceforge," a place where
usability practitioners -- not developers -- could start OpenSource
projects. (JPN)
/blueoxen |
Posted at 4:02pm
