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

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

Expand Messages
  • aacockburn
    Jeff Patton contributed a section on essential interaction design to the book Crystal Clear: A Human-Powered Methodology for Small ... Deriving the UI When it
    Message 1 of 10 , Dec 14, 2004
      Jeff Patton contributed a section on essential interaction design to
      the book "Crystal Clear: A Human-Powered Methodology for Small
      Teams." In that there are few paragraphs on this subject:

      ----- begin extract -----
      Deriving the UI

      When it comes time to develop the UI prototype, consider a technique
      described by Constantine, Windl, Noble, and Lockwood
      [http://www.foruse.com/articles/canonical.htm%5d, which I [Jeff] also
      practice and have slightly modified to suit my personal style.

      Do the following for each user task, on poster sheets:

      * Write in two columns a synopsis of the dialog between the user and
      the system. Put the User Intentions in the left column and the
      corresponding System Responsibilities in the right. This is what
      Constantine calls an 'essential use-case.'

      * Place sticky notes next to the user intentions and system
      responsibilities that will be UI elements. Put those for input areas
      and user actions on the left side and those for information
      containers on the right side.
      For example, a user intention such as 'user identifies self' suggests
      two input areas and one action (name, password, some sort of "GO"
      button). Write "username" and "password" on two sticky notes.
      Write "action" on a third, or just use one with a different size or
      color to indicate its presence. Stick all three next to the
      phrase "user identifies self."
      For a phrase such as 'system displays open orders,' you want a
      component showing a list of orders. Write "list of orders" on a
      sticky note and put it next to the phrase 'system displays open
      orders.'

      When you're done, the use case should be spotted with sticky
      notes.

      * Transfer the sticky notes to another flip chart, representing
      screens the user will see, placing them in areas that seem
      appropriate for the user interface of the system. When you're
      comfortable with the placement, replace each sticky note with a
      simple line drawing of the component drawn approximately the size
      you'd expect the component to appear on the user interface. Do
      this with each component. You now have what is called a "wire-frame"
      drawing of the user interface.

      Test the wire-frame user interface by referring back to the use case.
      One participant plays a user role performing the task, the other
      plays the role of the system. Make sure the user interface you've
      designed supports easy performance of the task.
      ----- end extract -----
    • Jeff Patton
      ... as essetial ... was ... this use ... really ... good ... The essential use-case is a handy variation of a conventional use case. The two column format
      Message 2 of 10 , Dec 14, 2004
        --- In agile-usability@yahoogroups.com, "Agustín Villena"
        <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
        was
        > 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
        really
        > don't have a good understanding about when an esential use case is
        good
        > 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
        context.

        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,

        -Jeff

        > Well, is the "esential use cases" the only way to map tasks to
        UI
        >
        > Any advice?
        >
        > Agustin
      • Jeff Patton
        Object oriented designers describe a process where they might read a narrative describing a business process circling nouns and underlining verbs. Nouns
        Message 3 of 10 , Dec 14, 2004
          Object oriented designers describe a process where they might read a
          narrative describing a business process circling nouns and
          underlining verbs. Nouns become objects, verbs services the object
          offers. The process described below "feels" similar to that for me.

          In practice when I look at the essential use case I'm looking for
          things on the screen: containers that hold information and actions
          that need to be buttons, links, or gestures. And, in practice I
          really do write essntial use case large on whiteboards or poster
          paper. This makes it easy to stick post-its on the EUC marking
          containers and actions. I can then easily transfer those post-its to
          another sheet of paper and arrange them in a way that best supports
          the workflow expressed in the essential use case. I do this
          stuff "in the large" collaborating with others. Never design alone
          if you can help it. It's kinda like pair programming - without the
          programming.

          Of course the devil is in the details. An interaction context often
          supports multiple tasks - so you'd need to do this process a few
          times and merge results into one visual context. Just as circling
          nouns and underlining verbs trivializes the skills of a good OO
          designer, this technique suggests UI design is a simple task of
          mapping. There's more to it than that. But this technique is a good
          starting point. Try it, you'll get useful results.

          -Jeff

          --- In agile-usability@yahoogroups.com, "aacockburn" <acockburn@a...>
          wrote:
          >
          > Jeff Patton contributed a section on essential interaction design
          to
          > the book "Crystal Clear: A Human-Powered Methodology for Small
          > Teams." In that there are few paragraphs on this subject:
          >
          > ----- begin extract -----
          > Deriving the UI
          >
          > When it comes time to develop the UI prototype, consider a
          technique
          > described by Constantine, Windl, Noble, and Lockwood
          > [http://www.foruse.com/articles/canonical.htm%5d, which I [Jeff] also
          > practice and have slightly modified to suit my personal style.
          >
          > Do the following for each user task, on poster sheets:
          >
          > * Write in two columns a synopsis of the dialog between the user
          and
          > the system. Put the User Intentions in the left column and the
          > corresponding System Responsibilities in the right. This is what
          > Constantine calls an 'essential use-case.'
          >
          > * Place sticky notes next to the user intentions and system
          > responsibilities that will be UI elements. Put those for input
          areas
          > and user actions on the left side and those for information
          > containers on the right side.
          > For example, a user intention such as 'user identifies self'
          suggests
          > two input areas and one action (name, password, some sort of "GO"
          > button). Write "username" and "password" on two sticky notes.
          > Write "action" on a third, or just use one with a different size or
          > color to indicate its presence. Stick all three next to the
          > phrase "user identifies self."
          > For a phrase such as 'system displays open orders,' you want a
          > component showing a list of orders. Write "list of orders" on a
          > sticky note and put it next to the phrase 'system displays open
          > orders.'
          >
          > When you're done, the use case should be spotted with sticky
          > notes.
          >
          > * Transfer the sticky notes to another flip chart, representing
          > screens the user will see, placing them in areas that seem
          > appropriate for the user interface of the system. When you're
          > comfortable with the placement, replace each sticky note with a
          > simple line drawing of the component drawn approximately the size
          > you'd expect the component to appear on the user interface. Do
          > this with each component. You now have what is called a "wire-
          frame"
          > drawing of the user interface.
          >
          > Test the wire-frame user interface by referring back to the use
          case.
          > One participant plays a user role performing the task, the other
          > plays the role of the system. Make sure the user interface you've
          > designed supports easy performance of the task.
          > ----- end extract -----
        • Agustín Villena
          jeff: Alistair wrote in a past message that you have documented some real examples about this process Any link? Thanks Agustin Jeff Patton
          Message 4 of 10 , Dec 15, 2004
            jeff:

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

            Thanks
            Agustin

            "Jeff Patton" <jpatton@...> escribi� en el mensaje
            news:cpoiji+m6q9@......


            --- In agile-usability@yahoogroups.com, "Agust�n
            Villena"
            <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
            was
            > 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
            really
            > don't have a good understanding about when an esential use case is
            good
            > 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
            context.

            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,

            -Jeff

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







            Yahoo! Groups Links
          • Agust�n Villena
            Hi Larry! The problem that I faced when trying to apply U-CD (in the Larry way) is that Is really dificult to know when the esential use case is ready .
            Message 5 of 10 , Feb 24, 2005
              Hi Larry!

              The problem that I faced when trying to apply U-CD (in the Larry way) is
              that Is really dificult to know when the esential use case is "ready".
              Thnking "a la" Test Driven Development: what tests the essential use case
              should pass to be considered "ok"?

              Agustin
            • Larry Constantine
              Agustin, Of course, there is no simple algorithmic test, but here is how I view it. An essential use case is ready when four things are true. (1) It is
              Message 6 of 10 , Feb 24, 2005
                Agustin,

                Of course, there is no simple algorithmic test, but here is how I view it.
                An essential use case is "ready" when four things are true.

                (1) It is expressed at an approprate level of abstraction. It is abstract
                and generalized but still specific to the particular task case and the
                application being designed. In other words, it is not "unsuitably vague."
                ("Expressing needs" as a user intention is unsuitably vague; "specifying
                kinds of entertainment is of interest" is not.)

                (2) It is technology- and implementation-independent. It has been purged of
                all technological or implementation terms and of all references, explicit or
                implicit, to specific solutions. This includes hidden assumptions in such
                technology-oriented words as "list" (implies a list of items). Seemingly
                innocent common words like "search" often carry implied baggage. (A user may
                intend to "find" or "get" or "identify" something, but "search" is a
                specific technology solution, not a user intention. The moment you use the
                word, it becomes all but impossible not to visualize a search box with a
                "go" button.)

                (3) It is expressed in terms of ordinary user language and the defined
                vocabulary of the subject matter or application domain. Elements of the
                subject matter or application domain are correctly and consistently
                referenced.

                (4) It is complete, enabling the user to perform the overall intention it
                represents. We verify completeness by walking through the task case, asking
                whether the user could complete the task assuming a user interface that
                supplied the necessary features and a system that carried out its
                responsibilities.

                With regards to the last criterion, completeness may refer only to the
                "happy case" or also to exceptions and alternatives, depending on resources
                and level of formality of the process. If it is a small application being
                designed under agile conditions, extensions may be allowed to emerge as
                needed rather than being elaborated and validated explicitly at the outset.


                --Larry Constantine, IDSA [mailto:lconstantine@...]
                  Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com

                > -----Original Message-----
                > From: news [mailto:news@...] On Behalf Of Agustín Villena
                > Sent: Thursday, 24 February 2005 1:58 PM
                > To: agile-usability@yahoogroups.com
                > Subject: [agile-usability] Re: Re: Task model => User Interface ...
                Through task (esential use)
                > cases?
                >
                >
                > Hi Larry!
                >
                > The problem that I faced when trying to apply U-CD (in the Larry way) is
                > that Is really dificult to know when the esential use case is "ready".
                > Thnking "a la" Test Driven Development: what tests the essential use case
                > should pass to be considered "ok"?
                >
                > Agustin
              Your message has been successfully submitted and would be delivered to recipients shortly.