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

Multi-user use cases?

Expand Messages
  • ERiba@lotus.com
    Hi. I m new to the design field. I ve been reading loads of books (Arlov, Cooper, Raskin, and just started Software for Use ) with tons of different (but
    Message 1 of 3 , May 11, 2000
    • 0 Attachment
      Hi. I'm new to the design field. I've been reading loads of books
      (Arlov, Cooper, Raskin, and just started "Software for Use") with
      tons of different (but related) ways to approach initial design
      (tasks, scenarios, personas, use cases, etc.)

      I've recently started my first actual design assignment. Since I
      keep getting bogged down by the existing technology I have to work
      with, moving further towards abstraction with essential use cases
      seems like a good idea.

      However, EUCs seem to split things binarily between user and system.
      What about situations where there are other users involved? What if
      it's not always a "System Response/Responsibility" that provokes a
      "User Action/Intention" but for some steps it's ANOTHER user's
      action/intention that provides the stimulus?

      Offhand, I can think of a couple ways to do this, but I'm not sure
      which is best.
      1) A 3 column layout for "User Intention", "System Responsibility"
      and "Other User's Responsibility"
      2) Making the other user's actions a subcase or extension of System
      Responsiblity.
      3) ??

      Anybody else deal with this situation yet? Any ideas?
    • Larry Constantine
      Elisabeth, ... There is more than one way that you can find yourself in this sort of apparent dilemma, and it is unclear from your question with which sort of
      Message 2 of 3 , May 11, 2000
      • 0 Attachment
        Elisabeth,

        > I've recently started my first actual design assignment. Since I
        > keep getting bogged down by the existing technology I have to work
        > with, moving further towards abstraction with essential use cases
        > seems like a good idea.
        >
        > However, EUCs seem to split things binarily between user and system.
        > What about situations where there are other users involved? What if
        > it's not always a "System Response/Responsibility" that provokes a
        > "User Action/Intention" but for some steps it's ANOTHER user's
        > action/intention that provides the stimulus?
        >
        > Offhand, I can think of a couple ways to do this, but I'm not sure
        > which is best.
        > 1) A 3 column layout for "User Intention", "System Responsibility"
        > and "Other User's Responsibility"
        > 2) Making the other user's actions a subcase or extension of System
        > Responsiblity.
        > 3) ??
        >
        > Anybody else deal with this situation yet? Any ideas?

        There is more than one way that you can find yourself in this sort of
        apparent dilemma, and it is unclear from your question with which sort of
        problem you are struggling. Most commonly this sort of confusion arises
        because the designer is trying to model the workflow or a business process
        rather than the interactive needs of some users in particular roles.

        There are two main possibilities: Either the "other user" about whom you are
        concerned is interacting with the system being designed or is not. In the
        latter case, they are not a direct user but an indirect user, who may be
        interacting with a user in some role, but not with the system.

        EUCs are intended to model the needs of the direct or immediate users of a
        system who actually interact with the system, not other, indirect users who
        may in turn interact with direct users. This "restriction" arises simply
        because the objective is the visual and interaction design of the user
        interface that mediates between users (direct users) and the system. The
        business process or workflow may often involve a direct user in some role
        who obtains information from or delivers it to another person who is not a
        direct user--they do not interact with the system but with the user of the
        system.

        For example, a telephone order taker working in a call center would be a
        direct user of an order entry system. The caller on the phone may be viewed
        by a business analyst as part of the context of the application, but they
        are not a direct user, since they do not have any interaction with the
        application itself. They do not see the screen nor can they select a field.
        All their interests in relation to the system are mediated by the order
        taker and fulfilled by the use cases supporting the order taker role. Those
        use cases would properly only show the user intentions of the order taker
        and the system responsibilities of the order entry system.

        The other possibility is one in which there are other direct users of the
        system, which is perfectly normal; typically there are multiple users
        interacting with a system in various roles.

        For example, you might be thinking of a situation in which a document or
        other online artifact created by one user is handed off to and must be
        further processed by another user. These users represent distinct roles in
        relation to the software, and each will be facing some kind of interface
        that must be designed. Each of these roles will need to be supported by a
        collection of use cases. So the first role, say the "Originator" role, will
        need some use cases associated with creating the document and handing it off
        to another user. The other role, call it "Completer" will need its own use
        cases associated with modifying or further processing the document. However,
        every use case for either role involves just the intentions of the user in
        that role and the system's responsibilities, and these intentions and
        responsibilities will guide the design of that part of the user interface of
        interest to users in the particular role.

        In any case, the actions or intentions of other direct users are mediated by
        and represented by the system through its user interface. Thus the
        Originator does not "trigger" some action or intention on the part of the
        Completer. Either the Completer intends to work on the next document or the
        system has the responsibility of indicating the availability of a document
        for action.

        Aside from these more common confusions of workflow with interaction design,
        yet another possibility is an attempt to cover more than one essential use
        case in a single description. In these cases, decomposing inclusions or
        extensions is usually the cleanest solution.

        > I've been reading loads of books
        > (Arlov, Cooper, Raskin, and just started "Software for Use") with
        > tons of different (but related) ways to approach initial design
        > (tasks, scenarios, personas, use cases, etc.)

        Personas are indeed an attempt to capture the same basic information as
        represented by user roles but in a concrete and realistic form rather than
        as abstractions. Personas are intended to be representative but are often
        fleshed-out with background details and personal history in the interest of
        verisimilitude. This is precisely the problem, because personas often
        contain much description that may be creative or interesting but is
        irrelevant to user interface design. Having constructed the persona, the
        designer must somehow deconstruct it, distinguishing the information that is
        generally relevant from whatever is irrlevant or is unique to this version
        of the persona. It is much the same problem as with scenarios. The
        abstraction of user roles and essential use cases highlights the most
        relevant essentials, filtering out the gratuitous and unimportant details
        that often permeate scenarios and personas.

        The relationships among scenarios, tasks, use cases, and essential use cases
        is discussed in some detail in a new paper
        <http://foruse.com/Files/Papers/Structure&Style.PDF>.

        --Larry Constantine
        Director of Research & Development | Constantine & Lockwood, Ltd.
        58 Kathleen Circle | Rowley, MA 01969
        t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
      • ERiba@lotus.com
        ... of ... sort of ... arises ... process ... Sorry for the vagueness. This is involving two (or more) simultaneous users on different machines. Related to
        Message 3 of 3 , May 11, 2000
        • 0 Attachment
          <lConstantine@c...> wrote:
          > There is more than one way that you can find yourself in this sort
          of
          > apparent dilemma, and it is unclear from your question with which
          sort of
          > problem you are struggling. Most commonly this sort of confusion
          arises
          > because the designer is trying to model the workflow or a business
          process
          > rather than the interactive needs of some users in particular roles.

          Sorry for the vagueness. This is involving two (or more)
          simultaneous users on different machines. Related to instant
          messaging. The user may initiate an action which will affect the
          other user(s) or (more importantly as far as I understand use cases)
          the other user(s) could initiate the action which will affect what
          this user sees and has to respond to.

          As I understand it, both users are in essentially the same role. It
          may just be different use cases depending whether the role initiates
          the action or whether it's initiated by someone else.

          > Aside from these more common confusions of workflow with
          interaction
          design,
          > yet another possibility is an attempt to cover more than one
          essential use
          > case in a single description. In these cases, decomposing
          inclusions
          or
          > extensions is usually the cleanest solution.

          > The relationships among scenarios, tasks, use cases, and essential
          use cases
          > is discussed in some detail in a new paper
          > <http://foruse.com/Files/Papers/Structure&Style.PDF>.

          I've printed out most of your PDFs and Application Notes. I'm still
          a little shaky on the different relationships between use cases (when
          to use extensions vs. specializations vs. composition vs. affinities)
          but now that I think I've got my roles straightened out, I'm going to
          push my way through use cases next.
        Your message has been successfully submitted and would be delivered to recipients shortly.