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

user scenario writing - good references?

Expand Messages
  • Jeff Patton
    I have a question for this group on user scenario writing. I m incorporating user scenarios lately as a critical technique for binding lots of little agile
    Message 1 of 22 , Apr 7 12:31 PM
    • 0 Attachment

      I have a question for this group on user scenario writing.  

       

      I’m incorporating user scenarios lately as a critical technique for binding lots of little agile user stories together.  I’ve written lots of these things and read about them several places, but I’m trying to track down what could be considered the canonical reference for the technique.  I know of Rossen & Carroll’s work – but I don’t own the book.  When I look at this amazon rating (http://www.amazon.com/gp/product/1558607129/002-5489151-1070466?v=glance&n=283155), there’s not much action on it, and the rating don’t seem to say much.  Is there a book, article, or some other work that you’d consider a best reference on user scenario writing?

       

      Incidentally, last year big task models built for user stories was my “killer technique” for pulling some coherence into agile projects, this year I’ve been working on projects that are so huge, with so many users and so many stories, this big models don’t serve me so well.  So, user scenarios are my “killer technique” for 2006.  I’d like to get a little more studied on them – or at least clean up my references when I cite them.

       

      Thanks to anyone with advice or references.

       

      -Jeff

       

    • Desilets, Alain
      I too, have lately found that writing detail-rich narratives about a specific instance of use complements the Roles and Task models nicely. I can t really
      Message 2 of 22 , Apr 7 2:09 PM
      • 0 Attachment
        Message
        I too, have lately found that writing detail-rich narratives about a specific instance of use complements the Roles and Task models nicely. I can't really express clearly what I am getting from scenarios that I am not getting from Roles and Tasks, but definitely there is SOMETHING.
         
        Writing detail-rich narratives seems to put me in a different mode of thinking. Writing a story and coming up with a model are two very different ways of describing a particular reality, and they seem to yield different kinds of information (although there is a large overlap). For example, I find I am more likely to start thinking about the emotional state of mind of a user through writing a narrative than writing a User Role model.
         
        For example, if I start my scenario with something like this:
         
        "Hakan is a Turkish user who volunteers time to translate content on a particular wiki site. He's home from work after a long days work and his kids are finally in bed. He has about 30 minutes of time available before he goes to bed himself, and he wants to use that time to do some translation work on the wiki site."
         
        then I immediatly start thinking about the fact that the system must enable him to easily choose translation tasks that fit his current time availability and level of energy. This is something that might not come to mind immediatly if I was to focus on a more abstract construct like a VolunteerWikContentTranslator user role.
         
        Scenarios also seem to give me a more dynamic view of the worflow. Sort of like seeing your UserRoles map being animated in real time. You get to hear about how the various players and systems interact with each other over time in a particular instance of use. It's a bit like looking at a data flow diagram of a program (a map that shows the various components of a system with arrows showing what data flows between each of them) versus running the program inside a debugger and following its execution. Both have their use. The Data Flow diagram gives you a better high level view of the system, but seeing the program run gives you a better feel for the temporal aspect.
         
        Well, it's 5PM on Friday. Miller time.
         
        Alain
         
         
        -----Original Message-----
        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
        Sent: Friday, April 07, 2006 3:31 PM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] user scenario writing - good references?

        I have a question for this group on user scenario writing.  

         

        I’m incorporating user scenarios lately as a critical technique for binding lots of little agile user stories together.  I’ve written lots of these things and read about them several places, but I’m trying to track down what could be considered the canonical reference for the technique.  I know of Rossen & Carroll’s work – but I don’t own the book.  When I look at this amazon rating (http://www.amazon.com/gp/product/1558607129/002-5489151-1070466?v=glance&n=283155), there’s not much action on it, and the rating don’t seem to say much.  Is there a book, article, or some other work that you’d consider a best reference on user scenario writing?

         

        Incidentally, last year big task models built for user stories was my “killer technique” for pulling some coherence into agile projects, this year I’ve been working on projects that are so huge, with so many users and so many stories, this big models don’t serve me so well.  So, user scenarios are my “killer technique” for 2006.  I’d like to get a little more studied on them – or at least clean up my references when I cite them.

         

        Thanks to anyone with advice or references.

         

        -Jeff

         

      • Bill DeRouchey
        I think it simply moves you from solving a problem to helping a person. For that alone, scenarios are worth the effort. Bill
        Message 3 of 22 , Apr 7 3:07 PM
        • 0 Attachment
          I think it simply moves you from "solving a problem" to "helping a
          person." For that alone, scenarios are worth the effort.

          Bill


          On Fri, 7 Apr 2006, Desilets, Alain wrote:

          > I too, have lately found that writing detail-rich narratives about a
          > specific instance of use complements the Roles and Task models nicely. I
          > can't really express clearly what I am getting from scenarios that I am
          > not getting from Roles and Tasks, but definitely there is SOMETHING.
          >
          > Writing detail-rich narratives seems to put me in a different mode of
          > thinking.
        • Fredrik Matheson
          User scenarios definitely add to the texture that we design from as they give us a space to formulate a lot of the tacit knowledge we have gathered – or
          Message 4 of 22 , Apr 7 3:28 PM
          • 0 Attachment
            User scenarios definitely add to the texture that we design from as they give us a space to formulate a lot of the tacit knowledge we have gathered – or assumed – about our users and the contexts they act within. In that sense, the writing itself serves, perhaps, as a reflective practice. Being able to sequester other project parties and give them a gripping/involving scenario that makes them think is definitely a worthwhile exercise. It helps us reflect on the sitation the user is in (tired, ready to go to bed but wanting to contribute a little time and effort, in Alain's tale) and gives us extra criteria to critique our design with. For example, Alain's narrative let's us imagine that "the user is tired and wants to find his/her focal task quickly.S/he has little interest in what's going on at other parts of the site and wants to get to work with ease and find relevant tools in that workspace" helps us understand the context we should/could provide to aid the user in accomplishing the task at hand.

            However, I'm curious: how do we pull the variegated strings of multiple interviews and observations together and weave them into such textured narratives? What can we do to capture the needs of a few role-model users and reiterate them in a valuable way? In my experience, the mood and timing of the moment I'm writing these scenarios inevitably colors them, and perhaps these factors weigh in more heavily in the completed scenario than I'd like.

            Any tips on capturing insights and distilling them "without emotion"? (Sorry for not helping out with your question, Jeff).

            - Fredrik

            On 4/7/06, Desilets, Alain <alain.desilets@...> wrote:
            I too, have lately found that writing detail-rich narratives about a specific instance of use complements the Roles and Task models nicely. I can't really express clearly what I am getting from scenarios that I am not getting from Roles and Tasks, but definitely there is SOMETHING.
             
            Writing detail-rich narratives seems to put me in a different mode of thinking. Writing a story and coming up with a model are two very different ways of describing a particular reality, and they seem to yield different kinds of information (although there is a large overlap). For example, I find I am more likely to start thinking about the emotional state of mind of a user through writing a narrative than writing a User Role model.
             
            For example, if I start my scenario with something like this:
             
            "Hakan is a Turkish user who volunteers time to translate content on a particular wiki site. He's home from work after a long days work and his kids are finally in bed. He has about 30 minutes of time available before he goes to bed himself, and he wants to use that time to do some translation work on the wiki site."
             
            then I immediatly start thinking about the fact that the system must enable him to easily choose translation tasks that fit his current time availability and level of energy. This is something that might not come to mind immediatly if I was to focus on a more abstract construct like a VolunteerWikContentTranslator user role.
             
            Scenarios also seem to give me a more dynamic view of the worflow. Sort of like seeing your UserRoles map being animated in real time. You get to hear about how the various players and systems interact with each other over time in a particular instance of use. It's a bit like looking at a data flow diagram of a program (a map that shows the various components of a system with arrows showing what data flows between each of them) versus running the program inside a debugger and following its execution. Both have their use. The Data Flow diagram gives you a better high level view of the system, but seeing the program run gives you a better feel for the temporal aspect.
             
            Well, it's 5PM on Friday. Miller time.
             
            Alain
             
             
            -----Original Message-----
            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com ] On Behalf Of Jeff Patton
            Sent: Friday, April 07, 2006 3:31 PM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] user scenario writing - good references?

            I have a question for this group on user scenario writing.  

             

            I'm incorporating user scenarios lately as a critical technique for binding lots of little agile user stories together.  I've written lots of these things and read about them several places, but I'm trying to track down what could be considered the canonical reference for the technique.  I know of Rossen & Carroll's work – but I don't own the book.  When I look at this amazon rating (http://www.amazon.com/gp/product/1558607129/002-5489151-1070466?v=glance&n=283155 ), there's not much action on it, and the rating don't seem to say much.  Is there a book, article, or some other work that you'd consider a best reference on user scenario writing?

             

            Incidentally, last year big task models built for user stories was my "killer technique" for pulling some coherence into agile projects, this year I've been working on projects that are so huge, with so many users and so many stories, this big models don't serve me so well.  So, user scenarios are my "killer technique" for 2006.  I'd like to get a little more studied on them – or at least clean up my references when I cite them.

             

            Thanks to anyone with advice or references.

             

            -Jeff

             



            YAHOO! GROUPS LINKS




          • Larry Constantine
            It s way past midnight here, but the I feel like I must jump in on this interesting, important and ironically timely issue. As regulars here know, for the last
            Message 5 of 22 , Apr 7 5:48 PM
            • 0 Attachment

              It’s way past midnight here, but the I feel like I must jump in on this interesting, important and ironically timely issue. As regulars here know, for the last several years my design work has been on humungous projects with thousands of developer years and anything but agile processes. So I have had a lot of experience with pushing task modeling to the limits and ending up buried in task cards or lost in a birds nest of crossing connections on a whiteboard. In this regard, the problem with typical task models, including the task cases in usage-centered design, is the absence of a higher level of abstraction. Tasks, like use cases, can include other tasks, but this is composition not abstraction and stretched too far leads to awkward and hard to understand nests of subtasks of subtasks of… We’ve sometimes made use of “workflow” task cases that narrate the interdependence of other tasks, but these too get terribly complicated and often fail to capture the free flowing nature of real human performance of these larger aggregations.

               

              Scenarios can definitely be of help as a repository for insight about the larger scheme of things in work and interaction, but scenarios have other problems. Scenarios can chaotically mix details at varying levels of analysis and do not always make clear what is about the user in role (“Suzie is overwhelmed”) and what about the task (“one problem piles up on another”) and what is about the context (“in the crowded office a visitor interrupts”). The informal mash-up makes them fun to write and to read and contributes to the richness that makes them believable and memorable. However, scenarios that are genuinely representative and stick to confirmable essentials tend to be rather dull, while the richly detailed ones can elevate the prominence of small matters that ultimately prove of little consequence.

               

              Spurred by Don Norman’s recent battle cry for activity-centered design (and encouraged by his personal validation of usage-centered design as the method to make it practicable), I and my colleagues at the University of Madeira have been working on using activity theory as a way to fill in the missing pieces in task modeling. I know this group is not big on theory, but don’t worry, activity theory is not big on theory either. Activities are just the higher level of abstraction in which tasks (actions to activity theorists) are embedded. In our applied approach to activity modeling, activities have certain well defined and easily described characteristics. For example, activities take place over time in a particular environment. They involve actors in roles along with other players in a mix of tasks in interaction with the system being designed along with other actions, all constrained or shaped by rules or custom. It’s all connected in a rather straightforward manner to roles and tasks but allows us to tie collections of these together into larger pieces that make contextual sense.

               

              Which is what scenarios do, too, but in a less clean way, and one that is much harder to map into a design architecture. Activity modeling, like role and task modeling, highlights the issues that are most important for design rather than obscuring them in a flurry of storytelling.

               

              Anyway, it is starting to look very promising. Ultimately, this will be the sort of thing that you can put on a card as easily as a user role or task case and that you can map out relationships on a whiteboard just as you can with roles and tasks, but you will be covering bigger chunks of the territory with a single card and mapping out much more of the countryside on the board without creating an overwhelming mess. That’s the good news. The bad news is that it is work in progress and not quite ready for prime time. I just gave a first departmental seminar on it this week and have begun to apply it to some reverse engineering, but it needs more work and use in real design projects. (If there is anybody on the list who thinks they have a project they might like to apply the “beta” to, let me know by email off-list.)

               

              Or you can wait for the book to come out. (Just kidding. But hopefully I’ll have a draft paper to share “real soon now.”)

               

              Or, you can stick with scenarios, which many people do. As to sources on scenarios, Mary Beth and John (Rosson and Carroll) are the best, whatever amazon.com numbers might say.

               

              --Larry Constantine, IDSA

            • Myhill, Carl S (GE Infra, Energy)
              I can see that the richness of scenarios can lead to a chaotic mix of details at varying levels of analysis but it is really not supposed to be that way. They
              Message 6 of 22 , Apr 7 6:29 PM
              • 0 Attachment
                Message
                I can see that the richness of scenarios can lead to a chaotic mix of details at varying levels of analysis but it is really not supposed to be that way. They are only an informal mash up if done badly.
                 
                The way they can work a little more scientifically is:
                1. Sampling - decide on a representative sample of users to visit
                2. Visit, interview and observe users
                3. Analyze findings and write scenarios
                4. Highlight needs from scenarios
                 
                If the majority of users were "overwhelmed" in a particular context, the scenario is right to illustrate it (this can be a "confirmable essential"). If it is just flowerly language used to make a weak point, that's a bad scenario and can lead to the elevation to prominence of small matters, as you say.
                 
                About Face 2 has an explanation of how Cooper use scenarios, and what different kinds of scenarios they use. That may be of interest.
                 
                Carl
                 
                -----Original Message-----
                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry Constantine
                Sent: 07 April 2006 17:49

                Scenarios can definitely be of help as a repository for insight about the larger scheme of things in work and interaction, but scenarios have other problems. Scenarios can chaotically mix details at varying levels of analysis and do not always make clear what is about the user in role (“Suzie is overwhelmed”) and what about the task (“one problem piles up on another”) and what is about the context (“in the crowded office a visitor interrupts”). The informal mash-up makes them fun to write and to read and contributes to the richness that makes them believable and memorable. However, scenarios that are genuinely representative and stick to confirmable essentials tend to be rather dull, while the richly detailed ones can elevate the prominence of small matters that ultimately prove of little consequence.

              • Larry Constantine
                Carl wrote: === I can see that the richness of scenarios can lead to a chaotic mix of details at varying levels of analysis but it is really not supposed to be
                Message 7 of 22 , Apr 8 5:43 AM
                • 0 Attachment
                  Message

                  Carl wrote:

                  ===

                  I can see that the richness of scenarios can lead to a chaotic mix of details at varying levels of analysis but it is really not supposed to be that way. They are only an informal mash up if done badly.

                   

                  The way they can work a little more scientifically is:

                  1. Sampling - decide on a representative sample of users to visit

                  2. Visit, interview and observe users

                  3. Analyze findings and write scenarios

                  4. Highlight needs from scenarios

                  ===

                   

                  Important point. Well-crafted scenarios by superior scenarists based on substantial sampling and careful analysis that remain focused on the matters most salient for design are indeed a good idea and work well. My point would be that the power of scenarios lies too much in the skills of the user and the process in which they are embedded and is not enough intrinsic to the medium. As with personas, it is just too easy to wax literary in service of telling a good story without necessarily being aware of when the boundary is crossed. I am keenly aware of being in the minority here, but my own view is that elaborating and polishing the picture in service of the story or characterization is too often little more than a distraction and worse, is far too frequently an invitation to unconscious and unconfirmable distortion. What I am striving for is models that are easier to get right than wrong and that do not depend quite so much on the combination of ethnographic passion, journalistic integrity, and analytic purity, and literary flare that really good scenarios (or personas) require.

                   

                  In truth, of course, it is possible to have it both ways. As Alistair has suggested, nothing prevents one from having a comprehensive and well-structured task model and writing a plausible scenario based on it. Indeed, this is the way I prefer to work, building and exploring a sound foundation for the story (as activity, task, and role models) before drafting the persona or scenario.

                   

                  --Larry Constantine, IDSA

                    Director, Lab-USE - The Laboratory for Usage-centered Software Engineering

                    Professor, Department of Mathematics and Engineering

                    University of Madeira , Funchal , Portugal


                • aacockburn
                  ... wrote:
                  Message 8 of 22 , Apr 8 4:00 PM
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, "Larry Constantine"
                    <lconstantine@...> wrote:
                    <<Activities are just the higher level of abstraction in which tasks
                    (actions to activity theorists) are embedded. In our applied approach
                    to activity modeling, activities have certain well defined and easily
                    described characteristics. For example, activities take place over time
                    in a particular environment. They involve actors in roles along with
                    other players in a mix of tasks in interaction with the system being
                    designed along with other actions, all constrained or shaped by rules
                    or custom.>>

                    Hi, Larry --- Obviously I won't be able to resist comparing and
                    contrasting these to use cases, which do scale well, through the
                    altitude / level mechanism. What I see in your paragraph that appears
                    important and different is the phrase "constrained or shaped by rules
                    or custom." Also there's a teaser in there with "environment" but I
                    can't read into that what might lie behind.

                    Can you say more on this? Is this the only real difference to use
                    cases, or are there more?

                    Where would I look to learn more about activity theory?
                    thanks, Alistair
                  • Robert Biddle
                    Hi Alistair and Larry! Hey, this is getting really interesting: enough to get me out of my lurker mode! Alistair: The standard ref for Acitivity Theory for
                    Message 9 of 22 , Apr 8 4:35 PM
                    • 0 Attachment
                      Hi Alistair and Larry!
                      Hey, this is getting really interesting: enough to get me out of my
                      lurker mode!

                      Alistair: The standard ref for Acitivity Theory for Computing is Nardi's
                      book:
                      *Context and Consciousness: Activity Theory and Human-Computer Interaction
                      http://www.amazon.com/gp/product/0262140586/002-3848793-0313664?v=glance&n=283155

                      A nice brief paper is her one making the case for AT: it's in a SIGDOC
                      publication:
                      **Concepts of cognition and consciousness**: four voices*
                      *http://portal.acm.org/citation.cfm?id=571783

                      We're using AT for our current work on Agile and on Computer Games. :-)

                      Back on Scenarios vs. Use Cases: we ran a workshop at the CasCon
                      conference in Toronto in 2004
                      on Use Case vs. Scenarios, and made an effort to get HCI people and SE
                      people together.
                      The result: they talked past each other. Blah.

                      That was the workshop where, during a presentation by a RUP guru on RUP
                      Use Cases, an HCI professional asked
                      from the audience: "where are the users?" And the presenter paused,
                      looked puzzled, and asked:
                      "You mean the people who hit the keyboards?"
                      Result: angry HCI people convinced again SE people are best ignored.

                      Larry: that was the conference you missed because of bureaucracy, as I
                      recall -- we could have used you
                      there to help bridge the gap!

                      Cheers
                      Robert Biddle
                      *

                      aacockburn wrote:

                      > --- In agile-usability@yahoogroups.com, "Larry Constantine"
                      > <lconstantine@...> wrote:
                      > <<Activities are just the higher level of abstraction in which tasks
                      > (actions to activity theorists) are embedded. In our applied approach
                      > to activity modeling, activities have certain well defined and easily
                      > described characteristics. For example, activities take place over time
                      > in a particular environment. They involve actors in roles along with
                      > other players in a mix of tasks in interaction with the system being
                      > designed along with other actions, all constrained or shaped by rules
                      > or custom.>>
                      >
                      > Hi, Larry --- Obviously I won't be able to resist comparing and
                      > contrasting these to use cases, which do scale well, through the
                      > altitude / level mechanism. What I see in your paragraph that appears
                      > important and different is the phrase "constrained or shaped by rules
                      > or custom." Also there's a teaser in there with "environment" but I
                      > can't read into that what might lie behind.
                      >
                      > Can you say more on this? Is this the only real difference to use
                      > cases, or are there more?
                      >
                      > Where would I look to learn more about activity theory?
                      > thanks, Alistair
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > ------------------------------------------------------------------------
                      > YAHOO! GROUPS LINKS
                      >
                      > * Visit your group "agile-usability
                      > <http://groups.yahoo.com/group/agile-usability>" on the web.
                      >
                      > * To unsubscribe from this group, send an email to:
                      > agile-usability-unsubscribe@yahoogroups.com
                      > <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                      >
                      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                      > Service <http://docs.yahoo.com/info/terms/>.
                      >
                      >
                      > ------------------------------------------------------------------------
                      >
                    • Larry Constantine
                      ... The short answer has two parts. First, activities can include task cases (or use cases, if you prefer) but they are at a higher level of abstraction, so
                      Message 10 of 22 , Apr 8 11:26 PM
                      • 0 Attachment
                        Hi, Alistair:

                        > Obviously I won't be able to resist comparing and
                        > contrasting these to use cases, which do scale well, through the
                        > altitude / level mechanism. What I see in your paragraph that appears
                        > important and different is the phrase "constrained or shaped by rules
                        > or custom." Also there's a teaser in there with "environment" but I
                        > can't read into that what might lie behind.
                        >
                        > Can you say more on this? Is this the only real difference to use
                        > cases, or are there more?

                        The short answer has two parts. First, activities can include task cases (or
                        use cases, if you prefer) but they are at a higher level of abstraction, so
                        have important properties that are emergent or expressed at that level.
                        Second, activities aggregate task/use cases (and other action) in ways that
                        are awkward to express in conventional ways of narration. The theory sees
                        human activity as hierarchical, with motivated activity at the highest
                        level, goal-directed action next, and condition-dependent operations at the
                        lowest level. It's a good fit with use cases and task modeling in the large,
                        so at some points the correspondence is very straightforward, but, of
                        course, the devil dwells in the details, and that is where we have been
                        working hard for some time. Probably not much help, but I am on my way to
                        the airport. ("Homeward bound, I'm homeward bound...") The long answer will
                        just have to wait until I finish the paper. (I probably shouldn't have even
                        said anything here in the first placed, but it was late at night and I was
                        excited, and...

                        It is not that you cannot do it all with task cases or use cases, it is just
                        that forcing everything into a single construct eventually reaches the point
                        of being awkward and inefficient. You can teach a pig to waltz, but that
                        doesn't mean he will be good at it or pretty to watch. The experience on
                        truly large projects (many hundreds or thousands of use cases) has been one
                        of the strongest motivators for our work, but the isolation of use case
                        modeling from accumulated insights in activity theory is another.

                        > Where would I look to learn more about activity theory?

                        Google, of course. There are some rather clean summaries of what is
                        inherently a messy topic. Even the Wikipedia article is not too bad. The
                        main book-length resources are heavy going and somewhat messy (or sloppy, in
                        some cases), but we are trying to fix all that, at least with respect to
                        modeling for usage-centered software engineering.

                        And I am sure there will be those who take what we are doing and just recast
                        it as mutant use cases or work breakdown hierarchies or... Theme and
                        variation. We are just trying to find the most expressive and convenient way
                        to model what interaction designers in particular need to focus on to do a
                        good job.

                        Cheers, friend, gotta go.

                        --Larry Constantine, IDSA
                        Director, Lab-USE - The Laboratory for Usage-centered Software Engineering
                        Professor, Department of Mathematics and Engineering
                        University of Madeira, Funchal, Portugal
                      • Ash Donaldson
                        ... Alistair, University of Wollongong used to hold an annual AT workshop that was always interesting. They published the proceedings each year and they can
                        Message 11 of 22 , Apr 9 12:40 AM
                        • 0 Attachment
                          Re: [agile-usability] Re: user scenario writing - good references? On 9/4/06 9:00 AM, "aacockburn" <acockburn@...> wrote:
                          Where would I look to learn more about activity theory?
                          thanks, Alistair

                          Alistair,

                          University of Wollongong used to hold an annual AT workshop that was always interesting.  They published the proceedings each year and they can be obtained here:
                          http://infosys.uow.edu.au/atul/publications.php

                          I’ve been keenly interested in Activity Theory for years as I see it as the Soviet parallel to Human Factors.  From my own perspective – AT is a great starting point for thinking about socio-technical and information systems at a high level (especially the hierarchical models) but there hasn’t been much in the way of practical application in the literature to date.

                          Cheers,

                          Ash Donaldson
                        • William Wake
                          If you re an ACM member, you can get online access to Usability Engineering: Scenario-Based Development... (Rosson/Carroll) through the Safari library at
                          Message 12 of 22 , Apr 9 4:20 AM
                          • 0 Attachment
                            If you're an ACM member, you can get online access to "Usability
                            Engineering: Scenario-Based Development..." (Rosson/Carroll) through
                            the Safari library at www.acm.org/pd

                            --
                            Bill Wake William.Wake@... www.xp123.com
                          • Joshua Seiden
                            Earlier in this thread, Alain and Fredrik wrote about the evocative power of good scenarios--without using that word. And that s a really important attribute
                            Message 13 of 22 , Apr 9 9:43 AM
                            • 0 Attachment
                              Message
                              Earlier in this thread, Alain and Fredrik wrote about the evocative power of good scenarios--without using that word. And that's a really important attribute of storytelling that we sometimes ignore when we reduce our storytelling to "just the facts" models. Both personas and scenarios have the ability to advance our thinking because they bring association and evocation to our work.
                               
                              I know that this is one of Larry's longstanding concerns about personas, and of course I won't deny that sometimes personas introduce "unconscious and unconfirmable distortion." However I would argue that it is equally common to see personas introduce unconsious and confirmable insight.
                               
                              There is a moment in every design project where you have to leap from problem modelling to solution synthesis. At this moment, the ability to draw on our unconsious thinking abilities is critical. Some models just engage that part of our brain more effectively than others.
                               
                              (Standard disclaimers apply--of course you don't use these techniques for every type of project etc etc etc. )
                               
                              JS
                              -----Original Message-----
                              From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry Constantine

                               

                               

                              Important point. Well-crafted scenarios by superior scenarists based on substantial sampling and careful analysis that remain focused on the matters most salient for design are indeed a good idea and work well. My point would be that the power of scenarios lies too much in the skills of the user and the process in which they are embedded and is not enough intrinsic to the medium. As with personas, it is just too easy to wax literary in service of telling a good story without necessarily being aware of when the boundary is crossed. I am keenly aware of being in the minority here, but my own view is that elaborating and polishing the picture in service of the story or characterization is too often little more than a distraction and worse, is far too frequently an invitation to unconscious and unconfirmable distortion. What I am striving for is models that are easier to get right than wrong and that do not depend quite so much on the combination of ethnographic passion, journalistic integrity, and analytic purity, and literary flare that really good scenarios (or personas) require.

                            • Jeff Patton
                              Larry... This post describes my problems with lots of tasks pretty well and my motivation for pulling scenarios out as a technique of choice. You mark the
                              Message 14 of 22 , Apr 9 11:05 AM
                              • 0 Attachment
                                Larry...

                                This post describes my problems with lots of tasks pretty well and my
                                motivation for pulling scenarios out as a technique of choice. You
                                mark the "potholes" in the road pretty well also. So, potential
                                problems and all, we're still using them as a binding tool for lots
                                of user stories now. They at least stop our wheels from spinning and
                                get us moving forward. And, to some degree stop us from naively
                                moving forward building a product that can't be used by anyone.

                                I'll impatiently await the activity theory stuff - any more
                                techniques to add to the designer's utility belt are welcome.

                                thanks for this post.

                                -Jeff

                                --- In agile-usability@yahoogroups.com, "Larry Constantine"
                                <lconstantine@...> wrote:
                                >
                                > It's way past midnight here, but the I feel like I must jump in on
                                this
                                > interesting, important and ironically timely issue. As regulars
                                here know,
                                > for the last several years my design work has been on humungous
                                projects
                                > with thousands of developer years and anything but agile processes.
                                So I
                                > have had a lot of experience with pushing task modeling to the
                                limits and
                                > ending up buried in task cards or lost in a birds nest of crossing
                                > connections on a whiteboard. In this regard, the problem with
                                typical task
                                > models, including the task cases in usage-centered design, is the
                                absence of
                                > a higher level of abstraction. Tasks, like use cases, can include
                                other
                                > tasks, but this is composition not abstraction and stretched too
                                far leads
                                > to awkward and hard to understand nests of subtasks of subtasks of.
                                We've
                                > sometimes made use of "workflow" task cases that narrate the
                                interdependence
                                > of other tasks, but these too get terribly complicated and often
                                fail to
                                > capture the free flowing nature of real human performance of these
                                larger
                                > aggregations.

                                ....
                              • Fredrik Matheson
                                While at the movies earlier tonight, far away from use cases and activity theory, a flurry of cuts rushed across the screen. Each one told part of a story,
                                Message 15 of 22 , Apr 9 12:33 PM
                                • 0 Attachment
                                  While at the movies earlier tonight, far away from use cases and activity theory, a flurry of cuts rushed across the screen. Each one told part of a story, jumping back and forth between the different character's memories and past lives. The editing was brilliant, showing this complex scene, now this, now another. One short moment, and a feeling, perspective, realization and understanding was evoked (thanks, Josh. Good point.)

                                  Use cases, task models and the rest all condense a variety of descriptions into a concise ~verb-noun message. That's fine.

                                  Let's combine them with evocations. Evoke:  (1) bring or recall to the conscious mind; (2) elicit (a response).

                                  Build task models, map out use cases, make a span plan. From your observations, insights and conversations, extract the essence of one particular moment or emotion and make a concise, terse, charged piece and place it together with whichever task case(s), it matches with. It could be in written form, it could be a cartoon, a photo, a piece of video or a sound clip.

                                  Evocations are short and self-contained. Perhaps we have multiple evocations for each task, each from a different user/context, reminding us of the users' expectations, limits, wants and so on. Without having to craft a large, continuous narrative.

                                  They could deal with issues from kite-level ("Can I trust this company?") down to clam-level ("Agh, I can never do xyz without abc!")

                                  Put them up on the wall with the task cases (etc.) and the next time you revisit your design with a change in mind, it'll be easier to keep the user's detailed context in mind. If the change is large, you'll have documented your "context assumptions" and hopefully have an easier time re-orienting the system towards it's new target.

                                  Evocations are discrete, succinct, textured and easy to reorganize. They capture one single moment experienced by one real user.

                                  Let me know what you think of this idea.

                                  - Fredrik
                                • Jeff Patton
                                  There s one thing I love about this message. I love reading this mashup of useful concepts: Alistair s goal level stuff, Larry & Lucy s modeling stuff, some
                                  Message 16 of 22 , Apr 9 1:05 PM
                                  • 0 Attachment
                                    There's one thing I love about this message. I love reading this
                                    mashup of useful concepts: Alistair's goal level stuff, Larry &
                                    Lucy's modeling stuff, some of my plan modeling stuff, Cooperish goal
                                    directed/persona stuff... a good grab bag of design methodology
                                    neutral results-oriented thinking.

                                    --- In agile-usability@yahoogroups.com, "Fredrik Matheson"
                                    <fredrik.matheson@...> wrote:
                                    >
                                    > While at the movies earlier tonight, far away from use cases and
                                    activity
                                    > theory, a flurry of cuts rushed across the screen. Each one told
                                    part of a
                                    > story, jumping back and forth between the different character's
                                    memories and
                                    > past lives. The editing was brilliant, showing this complex scene,
                                    now this,
                                    > now another. One short moment, and a feeling, perspective,
                                    realization and
                                    > understanding was evoked (thanks, Josh. Good point.)
                                    >
                                    > Use cases, task models and the rest all condense a variety of
                                    descriptions
                                    > into a concise ~verb-noun message. That's fine.
                                    >
                                    > Let's combine them with evocations. Evoke: (1) bring or recall to
                                    the
                                    > conscious mind; (2) elicit (a response).
                                    >
                                    > Build task models, map out use cases, make a span plan. From your
                                    > observations, insights and conversations, extract the essence of one
                                    > particular moment or emotion and make a concise, terse, charged
                                    piece and
                                    > place it together with whichever task case(s), it matches with. It
                                    could be
                                    > in written form, it could be a cartoon, a photo, a piece of video
                                    or a sound
                                    > clip.
                                    >
                                    > Evocations are short and self-contained. Perhaps we have multiple
                                    evocations
                                    > for each task, each from a different user/context, reminding us of
                                    the
                                    > users' expectations, limits, wants and so on. Without having to
                                    craft a
                                    > large, continuous narrative.
                                    >
                                    > They could deal with issues from kite-level ("Can I trust this
                                    company?")
                                    > down to clam-level ("Agh, I can never do xyz without abc!")
                                    >
                                    > Put them up on the wall with the task cases (etc.) and the next
                                    time you
                                    > revisit your design with a change in mind, it'll be easier to keep
                                    the
                                    > user's detailed context in mind. If the change is large, you'll have
                                    > documented your "context assumptions" and hopefully have an easier
                                    time
                                    > re-orienting the system towards it's new target.
                                    >
                                    > Evocations are discrete, succinct, textured and easy to reorganize.
                                    They
                                    > capture one single moment experienced by one real user.
                                    >
                                    > Let me know what you think of this idea.
                                    >
                                    > - Fredrik
                                    >
                                  • Ron Jeffries
                                    ... I d love to see some concrete examples. Ron Jeffries www.XProgramming.com Now -- Bring me that horizon. -- Captain Jack Sparrow
                                    Message 17 of 22 , Apr 9 1:09 PM
                                    • 0 Attachment
                                      On Sunday, April 9, 2006, at 3:33:48 PM, Fredrik Matheson wrote:

                                      > Evocations are discrete, succinct, textured and easy to reorganize. They
                                      > capture one single moment experienced by one real user.

                                      I'd love to see some concrete examples.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Now -- Bring me that horizon. -- Captain Jack Sparrow
                                    • Fredrik Matheson
                                      In the spirit of Karl Popper, let s test this hypothesis to destruction and see how well it really works. I ve made a simple table that shows goal levels from
                                      Message 18 of 22 , Apr 10 2:59 AM
                                      • 0 Attachment
                                        In the spirit of Karl Popper, let's test this hypothesis to destruction and see how well it really works.

                                        I've made a simple table that shows goal levels from cloud to clam, task examples and matching evocations. At the cloud level, they're like scenes in a movie and they become shorter, more concrete and internal as we move down the ladder.

                                        Each evocation contains something about the user's context (The kids are finally in bed) and his/her internal dialog when using the system. I put the internal dialog in parentheses and quotation marks ("bla bla bla") and the external dialog in quotation marks "Gee wiz wow". The idea was to distinguish between internal, private dialog (puts you in the user's context with the system) and the external context (physical space, noise, people interrupting, etc).


                                        Goal level
                                        Example of a user's goal or task
                                        Persona no. 1's evocation
                                        Persona no. 2's evocation
                                        Cloud (very high summary)
                                        Safeguard family and protect property
                                        Passing the scene of an accident, he wonders how well her car would have protected him and the kids. ("Is this car safe enough?")
                                        She turns off the tv and looks out the window at the dark street. A car alarm is blaring. ("Wait, is that from my car?")
                                        Kite (Summary)
                                        Insure car
                                        Googling different models. ("So do I get some sort of reward for choosing a safe car when I insure it?")
                                        Rading crime stats for her area. ("Should I get better insurance? What good car is seldom stolen?")
                                        Sea (User-goal) 
                                        Calculate price
                                        The kids are finally in bed. Starts calculating. ("Ouch. This is going to take a while".)
                                        Considering the price and her budget. ("Why am I getting this price? Is it because I live downtown?")
                                        Fish (subfunction)
                                        Specify make & model
                                        ("Manufacturer: BMW… OK. Model: agh, why is this list so long?") "Yeah, I'll be there in a moment!"
                                        Calculating several options. ("Come on, just show me what this one will cost compared to that one")
                                        Clam (Too low)
                                        Use tab-button to navigate form
                                        Hangs up an interrupting phone call. ("Let's see, that's a 2006 model. Hey, where'd the cursor go?")
                                        At the end of the form, ready to calculate. ("Did I fill in everything?")


                                        I'm borrowing/stealing from everyone here. I'm using parts of scenarios, parts of personas and chopping them into discrete units that can be glued onto a user story, task card, whatever.

                                        I'm trying to find a way to express the information/hunches I get from observing and talking with users, role taking, etc. and make it granular enough to stay useful at different levels of abstraction, from the first iteration to the last.

                                        Feel free to improve/criticize/use it, it's just an idea.

                                        - Fredrik
                                      • Larry Constantine
                                        Fredrick, I do like the concept of evocations, particularly as I think it focuses on the core purpose and potential of the more literary modeling forms, such
                                        Message 19 of 22 , Apr 10 7:58 AM
                                        • 0 Attachment

                                          Fredrick,

                                           

                                          I do like the concept of evocations, particularly as I think it focuses on the core purpose and potential of the more literary modeling forms, such as scenarios and personas. And, you did a very creative job of creating an array of examples to make the case. On the other hand, it is hard to see from these examples just what they would do for the designer or the design/development team. I guess you’d say I’m a sympathetic skeptic. Guess I’ll just have to try it out.

                                          --Larry Constantine, IDSA

                                        • Fredrik Matheson
                                          Hi Larry, well, they re not quite ready yet but I think there s some role-taking value for the teams here. I want to be able step into the user s shoes at
                                          Message 20 of 22 , Apr 10 10:17 AM
                                          • 0 Attachment
                                            Hi Larry,

                                            well, they're not quite ready yet but I think there's some role-taking value for the teams here. I want to be able step into the user's shoes at different levels, and borrowed Alistair's use case strata.

                                            Our experience so far shows that kite, sea and fish-level evocations are useful tools for catering to user needs when working out the nitty-gritty visual/interface details. Clam-level evocations aren't as valuable, they're more like the mundane, petite feedback you get lots of during usability tests. At cloud level the narratives easily approach scenario form, but they're usually compact.

                                            The main challenge right now is finding a good way to write them out (of course) so they communicate well enough. If they become the designer's internal shorthand for context notes then they have limited value. If they can be made to communicate well enough then evocations can add an uncondensed, evocative image of the user in a certain context, trying to accomplish the task outlined on the task card/in the user story/the use case. The development team would (hopefully) get a richer image context where the action is taking place.

                                            But, as Jeff said, this is a mashup of many ideas. I haven't nailed it down yet, and only came up with it last night ;-)

                                            Thanks for the input!

                                            - Fredrik
                                          • aacockburn
                                            ... Hi, Fredrik, Interesting construct. Here are some preliminary thoughts, one of the Yes,But variety, the other of the HaveYouThoughtAbout variety The first
                                            Message 21 of 22 , Apr 10 5:47 PM
                                            • 0 Attachment
                                              --- In agile-usability@yahoogroups.com, "Fredrik Matheson"
                                              <fredrik.matheson@...> wrote:
                                              >
                                              > In the spirit of Karl Popper, let's test this hypothesis to ...
                                              > I've made a simple table that shows goal levels from cloud to ...


                                              Hi, Fredrik,

                                              Interesting construct. Here are some preliminary thoughts, one of the
                                              Yes,But variety, the other of the HaveYouThoughtAbout variety

                                              The first has to do with the evocations at the kite and cloud level.
                                              My sense is that at those levels (at least, possibly also for the
                                              lower levels), there should be some conflict in mind ... I don't
                                              think it is safe to assume that a person says, "I want to have
                                              safety" but more likely "I want safety, but those safe neighborhoods
                                              cost so much and we have friends here". Or at the kite level, not "I
                                              want to insure my car" but more likely "I probably need to shop
                                              around for better insurance, but I'll lose my package discount with
                                              this company, and I don't have time for this nonsense."

                                              Conceivably at the sea level there is a straight goal: "I'm going to
                                              get online now and at least get a quote".
                                              (Aside, I'd inject that goal as the sea-level goal, and
                                              shift "calculate price" down to fish; shift "specify make and model"
                                              down to clam; and "hit the tab button" is something invisible down in
                                              the mud.)

                                              Somehow, when designing the user side of a piece of software, I'd
                                              like have the dueling concerns visibly in front of the designers at
                                              all times. My sense is that if there aren't dueling concerns, then we
                                              haven't thought about it well enough yet.


                                              For the HaveYouThoughtAboutIt comment, I'm moving forward to the
                                              question of How Do You Represent It?

                                              There is a different affordance offered by the small flat computer
                                              screen (mostly like a long scroll than can be seen across distances)
                                              than that offered by a large wall (zoomable 2D, but with bounded
                                              scaling and needing physical presence).

                                              Your post sounded like multi-media on a wall. I wonder how the
                                              evocations might come out
                                              - on a wall;
                                              - on a web site;
                                              - on a printed out version of the website.

                                              nice thought experiment
                                              Alistair
                                            • Joshua Seiden
                                              I like this Frederik. This reads very much like the natural dialog you hear when a design team uses personas as actors within a scenario. A couple of points:
                                              Message 22 of 22 , Apr 11 5:28 PM
                                              • 0 Attachment
                                                Message
                                                I like this Frederik. This reads very much like the natural dialog you hear when a design team uses personas as actors within a scenario.
                                                 
                                                A couple of points:
                                                 
                                                First, Larry asked how a designer would use this. For me the evocations provide instant feedback about the goals, and instant direction about how to service them. For example, it seems obvious that something is wrong with the goal/task "calculate price" based on the evocation, "Ouch. This is going to take a while." This negative reaction tells me that there's a mismatch between the goal/task as modeled and the persona's goal.
                                                 
                                                Where's the mismatch? That's where you turn to the goals you've defined for the persona, but perhaps this goal "calculate price" matches neither the (hypothetical) experience goal "I want this to be quick and painless" nor the (hypothetical) end goal--"Insure car". Instead, it's a machine-feeding activity that the persona would avoid if he/she could. Of course, it may not be possible to avoid this task, but at least we now have an awareness that avoiding this step or making it shorter will provide a better experience.
                                                 
                                                Seond, I'm glad you represented the "evocations" as belonging to a persona. I think it would be important to always use them that way. The evocations themselves feel very granular, which makes them suspect unless they can be shown to be part of a pattern. It's the persona that represents the pattern (of goals, behavior, needs, feelings, etc.)
                                                 
                                                 
                                                JS 
                                                 
                                                 
                                                 
                                                 
                                                -----Original Message-----
                                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Fredrik Matheson
                                                Sent: Monday, April 10, 2006 5:59 AM
                                                To: agile-usability@yahoogroups.com
                                                Subject: Re: [agile-usability] Re: user scenario writing - good references?


                                                 [snip] 


                                                Goal level
                                                Example of a user's goal or task
                                                Persona no. 1's evocation
                                                Persona no. 2's evocation
                                                Cloud (very high summary)
                                                Safeguard family and protect property
                                                Passing the scene of an accident, he wonders how well her car would have protected him and the kids. ("Is this car safe enough?")
                                                She turns off the tv and looks out the window at the dark street. A car alarm is blaring. ("Wait, is that from my car?")
                                                Kite (Summary)
                                                Insure car
                                                Googling different models. ("So do I get some sort of reward for choosing a safe car when I insure it?")
                                                Rading crime stats for her area. ("Should I get better insurance? What good car is seldom stolen?")
                                                Sea (User-goal) 
                                                Calculate price
                                                The kids are finally in bed. Starts calculating. ("Ouch. This is going to take a while".)
                                                Considering the price and her budget. ("Why am I getting this price? Is it because I live downtown?")
                                                Fish (subfunction)
                                                Specify make & model
                                                ("Manufacturer: BMW… OK. Model: agh, why is this list so long?") "Yeah, I'll be there in a moment!"
                                                Calculating several options. ("Come on, just show me what this one will cost compared to that one")
                                                Clam (Too low)
                                                Use tab-button to navigate form
                                                Hangs up an interrupting phone call. ("Let's see, that's a 2006 model. Hey, where'd the cursor go?")
                                                At the end of the form, ready to calculate. ("Did I fill in everything?")


                                                 [snip] 
                                              Your message has been successfully submitted and would be delivered to recipients shortly.