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

1019RE: [agile-usability] user centered design overlaps with traditional analysis?

Expand Messages
  • Joshua Seiden
    Feb 2, 2005
    • 0 Attachment
      > I've been making the assertion over the last couple months that
      > traditional analysts are doing overlaps to a large degree with
      > UCD folks do. I'd be curious if others agree.


      > And finally, can anyone tell any stories about how they've
      > [or ineffectively] combined analysts and UCD people?


      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

      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 ;-)

    • Show all 26 messages in this topic