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

972Re: Task model => User Interface ... Through task (esential use) cases?

Expand Messages
  • Agustín Villena
    Dec 15, 2004
    • 0 Attachment

      Alistair wrote in a past message that you have documented some real examples
      about this process
      Any link?


      "Jeff Patton" <jpatton@...> escribi� en el mensaje

      --- In agile-usability@yahoogroups.com, "Agust�n
      <agustin.villena@g...> wrote:
      > Hi!
      > Conantine & Loockwood proposes that tasks must be described
      as "essetial
      > use cases". Well... when I try to apply this format of use cases, I
      > quickly involved in an endless loop of refining the redaction of
      this use
      > cases... Thinking about it, I realized that he problem is that I
      > don't have a good understanding about when an esential use case is
      > enough to begin the user interface design based on it

      The essential use-case is a handy variation of a conventional use
      case. The two column format limits the use case to a discussion
      between a single user and the system - ideal for considering the
      user's interaction with the system. The column headings "user
      intention" and "system responsibility" suggest thinking about what
      the user intends to do with the software rather than specific UI
      solutions to the problem. But, moving from the abstract nature of an
      essential use case to UI design is an act of design. The essential
      use case indicates what the user intends to do - it's up to you to
      determine what user interface might best help the user accomplish
      their goals - and the system accomplish its responsibilities.

      The EUC is only a small part of the picture though. The EUC
      describes, abstractly, the interactions. The use case is executed by
      a user role with a specific goal and operating from a specific
      context of use. Information about that role helps.

      The EUC describes interactions for a user task. I've found
      clustering tasks by affinity [in a task model] helpful for finding
      interaction contexts. Task performed by like people at similar
      points in time cluster close together. This usually suggests a place
      in the UI where several tasks might be performed. Knowing the
      interaction contexts lets you think about navigation from context to

      Constantine & other's approach using canonical components
      [http://foruse.com/articles/abstract.htm%5d helps to bridge the gap
      between a the EUC and a paper prototype. Paper protyping [I like
      Carolyn Synder's book on the subject] is critical for validating a
      proposed user interface. Try using the essential use case as a
      script for validating the UI.

      If I had a point in all this rambling it would be that the essential
      use case doesn't stand alone. You need all the models from usage
      centered design to help, along with lots of other techniques worth
      borrowing from other UCD approaches. The Cooper people talk
      about "jumping the spark gap." Basically crossing from the essential
      use case and all the other models you prepare to an appropriate user
      interface is a jump - like a spark crossing a spark gap in a spark
      plug. You need a concise useful set of models expressing your
      understanding of the user, their goals, context of use and tasks to
      help close that gap - make the jumping easier.

      Have you combined the essential use case with some of these other
      techniques? If you're interested in working through a specific
      situation, consider posting an essential use case here. I and the
      group might likely be able to ask you questions to fill in the
      context needed to suggest appropriate user interface.

      Thanks for your post,


      > Well, is the "esential use cases" the only way to map tasks to
      > Any advice?
      > Agustin

      Yahoo! Groups Links
    • Show all 10 messages in this topic