Loading ...
Sorry, an error occurred while loading the content.

1025Re: [agile-usability] user centered design overlaps with traditional analysis?

Expand Messages
  • Josh Seiden
    Feb 3, 2005
    • 0 Attachment
      Well yes, the point is about communication, not about
      artifacts.

      The fact that the artifacts were missing an entire
      dimension of communication is a symptom of a
      communication problem.

      But paradoxically, if the team had felt that the
      artifacts required a visual channel, then they would
      have had to think about the problem in visual
      terms--and would have been forced to think through the
      problem more completely.

      JS

      --- Chris <chris@...> wrote:

      >
      > Accidentially sent it out.
      >
      > To finish my thought...
      >
      > Sometimes verbal is better than written. It depends.
      > I saw artifacts hinder a project in terms of
      > productivity, infighting and politics. Or the
      > process was to deliver artifacts, not value.
      >
      > Found things usually don't fail from a missing
      > artifact. Usually because of communication -
      > uncontrolled or lack of.
      >
      > -----Original Message-----
      > From: "Chris" <chris@...>
      > Date: Thu, 3 Feb 2005 14:47:45
      > To:agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] user centered design
      > overlaps with traditional analysis?
      >
      >
      > Hmmm... Been my experience that documents and
      > artifacts are communication channels geared to a
      > particular audience... That it is an agreement of
      > what is to be done. If I were to write something for
      > the CEO, it would look very different than if it was
      > for a programmer. Even if I was conveying the same
      > information. Sometimes verbal works better than
      > written to
      >
      > -----Original Message-----
      > From: "Joshua Seiden" <joshseiden@...>
      > Date: Wed, 2 Feb 2005 23:18:24
      > To:<agile-usability@yahoogroups.com>
      > Subject: RE: [agile-usability] user centered design
      > overlaps with traditional analysis?
      >
      >
      >
      > > I've been making the assertion over the last
      > couple months that
      > what
      > > traditional analysts are doing overlaps to a large
      > degree with
      > what
      > > UCD folks do. I'd be curious if others agree.
      >
      > [snip]
      >
      > > And finally, can anyone tell any stories about how
      > they've
      > effectively
      > > [or ineffectively] combined analysts and UCD
      > people?
      >
      > Jeff,
      >
      > I agreee that there is a lot of overlap but as Kay
      > said, a lot of
      > the foundational assumptions are different.
      >
      > What's maddening is that the goals of the analyst
      > and UX person
      > are similar, the differences in assumptions are
      > rather subtle,
      > and the tools similar.
      >
      > Witness the thread last year on use cases that
      > Alistair and I
      > participated in. It took a long time to work out the
      > similarities
      > and distinctions between the narrative tools he
      > calls Use Cases,
      > and the one I call Scenarios. And frankly, a few
      > months later,
      > I've still got a pretty slippery grasp on the
      > subject.
      >
      > Now, a story:
      >
      > On my current project, I'm working with a team that
      > is building a
      > supply-chain management application. The application
      > will be
      > used by an organization of 500+ people, working in a
      > global
      > sourcing operation. The team (composed of 6 outside
      > business
      > analysts, 6 inside business analysts and user
      > representatives, 3
      > inside technology analysts, and a large vendor team
      > with
      > expertise in this business area) worked for 8 months
      > producing
      > functional spec documents. When they saw the first
      > builds coming
      > in from the development team, they realized they
      > needed someone
      > to help with UI design, and called me in.
      >
      > Here's what I found: The team has completed about 10
      > functional
      > spec documents, covering 10 of the 20 modules of the
      > system. Each
      > spec doc is about 80 pages long. Each contains use
      > cases,
      > business rules, and detailed field definitions. They
      > are detailed
      > and carefully considered documents. But they're not
      > enough.
      >
      > Some observations:
      >
      > 1. The functional specs have no drawings in them.
      > They are text
      > documents, with long paragraphs, complex indented
      > bulleted lists,
      > and long multi-page tables. Thus to understand the
      > spec each
      > reader must work hard to visualization the system in
      > his or her
      > head.
      >
      > 2. The specs describe *the way the team wants the
      > software to
      > work* rather than the business problem to solve. In
      > other words,
      > the specs are not problem descriptions,
      > ("requirements"
      > documents) but solution descriptions. To describe a
      > solution,
      > one has to envision a solution, which is what this
      > team did, but:
      > -- they embodied their vision in text, not pictures
      > -- the visioning is thus implicit, not explicit.
      > -- There is no way to be certain that anyone was
      > envisioning the
      > same thing.
      >
      > 3. Some of the specs have been written by analysts
      > with a
      > background in software, but others are written by
      > business
      > experts. Some have good visualization skills, some
      > don't.
      > Regardless, none are experts in visualizing software
      > Uis, so each
      > imagined certain functions working in certain ways.
      > Some way
      > database tables. Some saw the relationships between
      > objects. Some
      > saw Excel. Some saw SAP. Regardless of the relative
      > visualization
      > skills of each reader, there is a high probability
      > that none will
      > be visualizing the same thing.
      >
      > Conclusion: This team created and documented a
      > design, but had no
      > designer working to visualize that design--to turn
      > the abstract
      > concrete. Futhermore, they didn't think they needed
      > one! It
      > wasn't until they saw the project starting to head
      > south that
      > they realized they had to augment their team.
      >
      > So how does this tie back to Jeff's original point?
      >
      > The analysis team did excellent work, but they were
      > missing an
      > entire "dimension" of specification. Without a
      > visual channel,
      > the specs were incomplete, and thus unworkable. I
      > couldn't have
      > done my work without the analysis in place, but if I
      > had come on
      > early, my needs would have changed the structure of
      > the analysis.
      > We probably would have covered the same
      > material--and perhaps
      > made most of the same decisions, but we would have
      > organized the
      > work and the work product very differently, and we
      > would have
      > saved a lot of wasted effort. I think the reverse is
      > true as
      > well--if I had been working on the problem for eight
      > months
      > without "traditional analysis", I would have missed
      > a dimension
      > of specification, and would have had to go back,
      > restructure, and
      > re-spec. (But I never would have gotten 8 months
      > down the road
      > first ;-)
      >
      > JS
      >
      >
      >
      === message truncated ===
    • Show all 26 messages in this topic