Customers, Analysts, and User Centered Designers was: Re: help wanted
- --- In firstname.lastname@example.org, Cindy Lu
> Hi! Jeff,Yes & no... mostly no.
> Are you still looking for people?
Quite a few people responded to my original post, and I have resumes
for a few very qualified people. When I originally dropped the
message in, we needed people desparately, and I wanted to funnel the
right kind of people into our recruiting engine. Quckly things
changed to having a bit of a surplus of people, so we're in a hiring
holding pattern - likely through the end of the year.
One of the things I quickly had to warn everyone that responded to
the message, and something I should have put into my original post,
was that ThoughtWorks is a consultancy dedicated to Agile
development. One of the tenets of Agile development is face to face
customer collaboration. In short strokes that means all of our work
is on-site with customers. That means plan on working everywhere and
nowhere - plan on travel nearly 100%. [Saturday I'm headed from Salt
Lake City where I live to spend a few weeks in Sydney for a client
I'm responding to this post verbosely because bringing up the role of
a UCD person at ThoughtWorks actually has a lot to do with the role
of a UCD person in any agile context.
In most agile contexts while there's the idea that there's one team,
there's a bifurcation around requirements and planning. Those that
determine what requirements are and what to build first fall on one
side - that side is referred to as the customer team, or simply
the "customer" - customer being a role - not necessarily a guy with
wads of cash in his pocket itching to buy some software. On the
other side are the people who take those requirements and build the
software in short development increments.
UCD people generally fit on the customer side since they help decide
what to build and how it should work.
For those of you doing UCD type of work, you likely know by now that
it's not agile processes that neglect this sort of design work,
it's /all/ software development processes. As a result, many of the
clients we deal with don't usually know what a UCD person is or
does. If the app needs a GUI and they'd like it to look good, often
a UI-person is pulled in late to "make it pretty." So, at
ThoughtWorks, and in many organizations, people who work with
requirements are called "analysts." ThoughtWorks hires business
analysts. Those business analysts work on "customer teams" working
directly with our client's business people and end users to
understand the business process and the software to be built and then
communicate that into development as user stories - little bits of
The work I do within ThoughtWorks is to raise the level of awareness
about the extreme amount of overlap between user centered design work
and requirements gathering. I have hopes that our business analysts
would use a blend of UCD techniques and traditional analysis
techniques. What analyst couldn't benefit from contextual design
style interview and observation skills? - usage-centered design role
and task modeling skills? - or goal directed design's persona
I remembere being at the Agile 2005 conference this year and talking
with Lynn Miller from Alias [who's experience report you /must/ read:
http://www.agile2005.org/XR19.pdf%5d. She mentioned that there were
all these poeple talking about the customer, and that it wasn't till
well into the conference that she figured out that /she/ was the
customer - in her words "they're talking about me!"
So to summarize:
* UCD people, you're "agile customers." Did you know that?
* I believe most people in software development don't know what UCD
people really do, so to them you're "business analysts." Did you
ThoughtWorks always benefits from having good people that can help
that agile customer role. We call them business analysts - cuz
that's what our clients understand. The best people in that role
have user centered design skills - along with a lots of others.