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

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

Expand Messages
  • Cummins, Darin
    Feb 10, 2005

      We’ve only recently started writing use-cases, so take this for what it is worth.

       

      When we sit down to create the use-cases (usually with product management, QA and someone from customer service all taking the role of “user”), it’s been interesting to see how the UI has changed from what the developer thought it should be, to something that really works for the user.  By discussing the failure conditions and how the UI is going to respond, the developers have really been re-thinking the entire front end, especially how it interacts with the backend.

       

      We had one project recently where a developer created the UI based on the simple requirements delivered, just the way we use to do it.  Everyone, including people from outside of development, really liked what he had done.  He was then pulled off on another project while we got together and created use-cases.  When we revisited the UI, it became blatantly obvious that it would not work and we redesigned it.  (What a concept!)

       

      Anyway, in that case, the failure conditions and how it was decided to be handled in the UI, actually simplified the way the backend needed to work.

       

      --Darin

       

       

       

       

       


      From: Jeff Patton [mailto:jpatton@...]
      Sent: Thursday, February 10, 2005 7:54 AM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Re: user centered design overlaps with traditional analysis?

       


      I'm just catching up with this list [and the rest of my life for that
      matter...]

      --- In agile-usability@yahoogroups.com, Josh Seiden <joshseiden@y...>
      wrote:
      > This team has been very detail oriented, so the specs
      > represent a documentation of every possible thing that
      > could ever happen. (What if a fire alarm sounds while
      > the user is eating a low-fat tuna sandwich while
      > entering this data? Is that different from the case in
      > which the tuna sandwich is made with regular tuna
      > salad?")

      These are the failure conditions I hear Alistair Cockburn harp about
      frequently... and he's winning me over.  Doing design work often has
      me focusing on the most probable "happy path" and paying a bit less
      attention to failure conditions.  Alistair asserts that use cases
      force consideration of those failure conditions sooner.  And,
      supporting what he's saying I've seen lots of nasty stuff that causes
      delays in development bubble out of the failure conditions.  But,
      often that nasty stuff only slightly affects UI design or user
      interactions.

      Is it safe to assume that fire-alarm-with-low-fat-tuna-salad was a
      failure condition on a use case?  Did you have use cases to work
      from, and did you find that the usecases documented basic user
      interaction reasonably - in a way useful for your design work?

      Thanks,

      -Jeff






    • Show all 26 messages in this topic