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

RE: [agile-usability] Origins of user stories

Expand Messages
  • Larry Constantine
    ... the individual. Using it to represent users glosses over many of the inter-role issues like role ambiguity, role incompatibility, role conflict and so on.
    Message 1 of 23 , Mar 27, 2013
    • 0 Attachment
      William said:

      > A role is a systemizing concept so really makes no allowance for needs of
      the individual. Using it to represent users glosses over many of the
      inter-role issues like role ambiguity, role incompatibility, role conflict
      and so on. Of course, we have Ivar Jacobson and use cases to thank for
      roles, and they're not entirely without merit, but someone filling role A in
      one context of use may have quite different needs to someone filling the
      same role in a different context. <

      The user role concept traces back to contributions from Rebecca Wirfs-Brock
      and was developed and elaborated in usage-centered design and later
      model-driven activity-centered design (Constantine and Lockwood). A role is
      a relationship between users and a system or service and is defined (ala
      Wirfs-Brock) by a characteristic set of needs, expectations, interests, and
      responsibilities in relation to the system/service and in the context of the
      activity in which the user is participating. As such, a user role focuses
      precisely on those issues most salient to effective interaction design (see
      my chapter in The Persona Lifecycle for persuasive support). That it blurs
      or compresses "individual differences" is precisely why it is a more compact
      and efficient model, particularly for agile design and development.
      Individual incumbents in a role vary immensely; the role itself is are far
      less variable. Individuals are extremely complicated; roles are far simpler.
      A well-formulated role absolutely does make allowance for the needs of the
      individual, but not as an individual, not as a person, but rather as an
      individual in a particular activity and in a particular relationship to a
      designed artifact.

      The critical issue in modeling for agile IxD/UxD is to model only what is
      most important to model, compactly and concisely, to focus on what is likely
      to yield the biggest payoff in guidance toward an effective design in the
      least amount of time. The templated user role profiles employed in
      usage-centered design and human activity modeling do just that,
      concentrating the modeler/designer's attention on those things that are most
      likely to directly impact and shape the design.

      The issues you mention-role ambiguity, role incompatibility, role
      conflict-are interesting from an intellectual standpoint and often play some
      part in a complete analysis of human activity (we incorporate them in our
      application of activity-theory to educational research, for instance), but
      the relationship of the actor in role to the designed artifact is far more
      relevant to designing that system or service. Inter-role issues that may be
      important in organizational dynamics or social psychology are typically far
      less central to getting the design right.

      In the most recent incarnation of the user role profile that we use in
      model-driven agile design (not yet written up), we have reduced the template
      further to include just 3 categories (ORB): Orientation, Responsibilities,
      and Background. Orientation and attitude of the actor in role to focal
      activities and to the designed artifact; Responsibilities of the actor in
      role within focal activities and with the designed artifact; Background
      characteristics expected in relation to use of the designed artifact within
      focal activities. This is a vast simplification from the concept of role in
      activity theory and role theory, but it zeroes in on the stuff that is most
      likely to make a difference, covering the bases on a single index card.

      Modeling efficiency and design leverage are behind most of my work and the
      usage/activity-centered design community. It is why we favor concise role
      profiles over the decorative embellishments of personas, why essential use
      cases win out over traditional concrete use cases and scenarios.

      Psychologists and humanists can plead for attention to the individual, but,
      as Don Norman and I pointed out some years ago, that is precisely the
      problem. It is the focus on humans, on individuals, that diverts our
      attention from the more important focus on what people are doing and trying
      to do, that is, on activity as mediated by designed artifacts. This badly
      needed shift in focus was behind my development of human activity modeling
      (with Don's encouragement and contributions) and then its adaptation to
      agile design and development. We drive AD&D by activity models not to
      capture a complete analysis embodied in those models but to move as quickly
      and efficiently as possible toward good designs. That means concentrating on
      roles and activities and glossing over stuff that is less critical to speedy
      solutions.

      Prof. Larry Constantine, IDSA, ACM Fellow
      Universidade da Madeira | Madeira Interactive Technologies Institute
    • William Hudson
      Thanks, Larry. Very interesting. Do you know when Rebecca first started talking about roles? I have a paper here from Jacobson dated 1987 that describes their
      Message 2 of 23 , Mar 27, 2013
      • 0 Attachment
        Thanks, Larry. Very interesting. Do you know when Rebecca first started
        talking about roles? I have a paper here from Jacobson dated 1987 that
        describes their use in OO development.

        BTW, I wasn't suggesting that designers of information systems should
        thoroughly research roles and their interrelationships. My point is more
        that roles are not a very useful focus of attention in many systems.

        Regards,

        William


        -----Original Message-----
        From: agile-usability@yahoogroups.com
        [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry Constantine
        Sent: 27 March 2013 13:06
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] Origins of user stories

        William said:

        > A role is a systemizing concept so really makes no allowance for needs
        > of
        the individual. Using it to represent users glosses over many of the
        inter-role issues like role ambiguity, role incompatibility, role conflict
        and so on. Of course, we have Ivar Jacobson and use cases to thank for
        roles, and they're not entirely without merit, but someone filling role A in
        one context of use may have quite different needs to someone filling the
        same role in a different context. <

        The user role concept traces back to contributions from Rebecca Wirfs-Brock
        and was developed and elaborated in usage-centered design and later
        model-driven activity-centered design (Constantine and Lockwood). A role is
        a relationship between users and a system or service and is defined (ala
        Wirfs-Brock) by a characteristic set of needs, expectations, interests, and
        responsibilities in relation to the system/service and in the context of the
        activity in which the user is participating. As such, a user role focuses
        precisely on those issues most salient to effective interaction design (see
        my chapter in The Persona Lifecycle for persuasive support). That it blurs
        or compresses "individual differences" is precisely why it is a more compact
        and efficient model, particularly for agile design and development.
        Individual incumbents in a role vary immensely; the role itself is are far
        less variable. Individuals are extremely complicated; roles are far simpler.
        A well-formulated role absolutely does make allowance for the needs of the
        individual, but not as an individual, not as a person, but rather as an
        individual in a particular activity and in a particular relationship to a
        designed artifact.

        [snipped]
      • Gerard Meszaros
        ... Yes, they used cards for all sorts of purposes including organizing presentations by putting each thing they wanted to talk about onto a card. Easy to
        Message 3 of 23 , Mar 27, 2013
        • 0 Attachment
          On 3/26/2013 10:03 PM, Adam Sroka wrote:
          > I can't remember who said it or the exact context, but I remember hearing that
          > Ward and Kent really liked using cards for a variety of different things and
          > that when stories came along it was just a natural fit.
          >
          >

          Yes, they used cards for all sorts of purposes including organizing
          presentations by putting each thing they wanted to talk about onto a card. Easy
          to reorganize the content simply by moving the card. Other agilist/OO people
          have adopted this style of presentation "notes" most notably (Uncle) Bob Martin
          (who rarely uses visuals in presentation) and Ron Jeffries (another CCC team
          member.)

          Gerard

          --
          Gerard Meszaros
          Lean/Agile Coach/Mentor/Trainer
          http://www.gerardmeszaros.com
          1-403-827-2967

          Author of the Jolt Productivity Award winning book "xUnit Test Patterns -
          Refactoring Test Code" and winner of the "Programming with the Stars"
          competition at Agile 2009. Learn more at http://xunitpatterns.com/index.html
        Your message has been successfully submitted and would be delivered to recipients shortly.