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

Re: user scenario writing - good references?

Expand Messages
  • 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 1 of 22 , Apr 9, 2006
    • 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 2 of 22 , Apr 9, 2006
      • 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 3 of 22 , Apr 9, 2006
        • 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 4 of 22 , Apr 9, 2006
          • 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 5 of 22 , Apr 10, 2006
            • 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 6 of 22 , Apr 10, 2006
              • 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 7 of 22 , Apr 10, 2006
                • 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 8 of 22 , Apr 10, 2006
                  • 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 9 of 22 , Apr 11, 2006
                    • 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.