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

Usability, personas, use cases

Expand Messages
  • aacockburn
    I received this interesting question about use cases, personas and usability, which I think is relevant to this august body of thinkers / doers. I stripped off
    Message 1 of 8 , Jul 5, 2005
    • 0 Attachment
      I received this interesting question about use cases, personas and
      usability, which I think is relevant to this august body of
      thinkers / doers. I stripped off the identifying details from the
      email to leave the meat of the worries as discussion fodder.

      Anyone have some thoughts on this?

      =============
      I have worked as a Designer in a team of technocratic Java Developers
      who 'get' your (Alistair's) vision of use-cases, but are not able to
      sell or articulate the idea to anyone else in the company other than
      peers. For me, use-cases certainly don't seem to readily interface
      with the prototypes and workflows/scenarios that I produce as work
      products.

      I have looked into them and cannot see anything of any more value than
      Cooper's personas. Whilst both are new 'languages', personas are most
      useful in communicating to the project team what the users (your
      actors) actually desire in terms of their goals, however getting
      empathy from the large majority of developers is an added challenge
      often with fruitless results.

      Use-cases do not seem to bridge any communication gaps as they are a
      language in their own right that needs to be learnt by rote and being
      textual in nature are uninteresting and wordy. In fact I've never once
      seen an effective use-case because they're so difficult to get 'right'
      and even harder to communicate value. Also, the mere thought of asking
      one of my customers to attempt to understand one is tantamount to
      asking them to start coding for me. I can't see it and need
      enlightenment!

      Apologies for being frank. I also long for someone to explain the
      interface between agile programming and 'usability' *.

      Kind regards

      * Usability whilst useful in most contexts is just ' good design ' and
      therefore a misnomer. When was anything 'well designed' unusable?
      =======================================
    • Adi Tedjasaputra
      ... If this Designer is not able (or not willing) to buy the idea, it makes sense that the Designer can t sell or articulate the idea to anyone else in the
      Message 2 of 8 , Jul 6, 2005
      • 0 Attachment
        aacockburn wrote:

        >I have worked as a Designer in a team of technocratic Java Developers
        >who 'get' your (Alistair's) vision of use-cases, but are not able to
        >sell or articulate the idea to anyone else in the company other than
        >peers. For me, use-cases certainly don't seem to readily interface
        >with the prototypes and workflows/scenarios that I produce as work
        >products.
        >
        >

        If this "Designer" is not able (or not willing) to "buy" the idea,
        it makes sense that the Designer can't sell or articulate the idea to
        anyone else in the company.

        --
        Adi B. Tedjasaputra

        IT and User Experience Manager
        TRANSLATE-EASY
        :: RFID and Human-centred Design Innovation Centre in Asia ::
        http://TRANSLATE-EASY.com

        Menara Kadin Indonesia 30th Floor
        Jl. Rasuna Said Block X-5, Kav 2-3
        Jakarta 12950
        INDONESIA

        Direct. +45 - 20 27 77 53
        Fax. +45 - 28 17 09 78
      • William Pietri
        ... My general thought is that formal approaches to things are a fallback when you can t get informal, intuitive approaches to work. Musical notation, for
        Message 3 of 8 , Jul 6, 2005
        • 0 Attachment
          On Tue, 2005-07-05 at 17:18 +0000, aacockburn wrote:
          > I received this interesting question about use cases, personas and
          > usability, which I think is relevant to this august body of
          > thinkers / doers. I stripped off the identifying details from the
          > email to leave the meat of the worries as discussion fodder.

          My general thought is that formal approaches to things are a fallback
          when you can't get informal, intuitive approaches to work. Musical
          notation, for example, is impressive and useful, but its complexity and
          artificiality is a big barrier until you've invested a lot of time in
          learning it. Watching a garage band practice together, I'd be pretty
          surprised to see them resolve a question by writing down the music
          rather than playing or singing the bit.

          Most people I know that are building interactive web products, for
          example, have a deep understanding of their audience. They don't even
          need formal personas, as they're all aware of important segments of the
          user community and often of particular vocal representatives of those
          segments.

          If I see a team struggling with knowing their audience, I may throw
          personas at them, especially at the beginning of a projects, as it's a
          good way to get them to engage with those issues and converge on a
          shared vision.

          I'd only recommend formal use cases to a team if they couldn't keep the
          complexity of the app in their heads. For example, if I were part of a
          team with no industry experience brought into some complex domain, I'd
          sit down and start writing use cases as a way to get a handle on things.
          Whether or not I kept them up over the long haul would depend a lot on
          circumstance. In an agile context I'd always be hoping to find a way to
          let them wither away, just like I would with any other practice that
          doesn't directly add value to the finished product.


          So I'd say if their communications are fine without use cases, then they
          shouldn't use cases. Once they notice a communication problem, then's
          the time to ask whether use cases would solve it.

          William


          --
          William Pietri <william@...>
        • Larry Constantine
          Personas and use cases serve very different functions if used as intended. Personas are an attempt to embody essential understanding about users while use
          Message 4 of 8 , Jul 7, 2005
          • 0 Attachment
            Personas and use cases serve very different functions if used as intended.
            Personas are an attempt to embody essential understanding about users while
            use cases are one way of representing the nature of user tasks in
            interaction with a system. Yes, I know, some people tack elaborate scenarios
            onto personas and others squeeze user profiles into use cases, but that is
            another discussion.

            Not all use cases are arcana needing to be mastered through rote learning.
            Essential use cases (task cases) are simplified expressions in ordinary
            everyday language and the vocabulary of the subject matter. Many have found
            that they are effective for bridging the communication with users about the
            essence of their needs; no special training is needed for users to
            interpret, validate, and amend them.

            Both user role and task case models can not only be reviewed with users and
            customers but also developed in collaboration with them using workshop
            techniques such as those perfected by Jeff Patton or found in the Joint
            Essential Modeling approach. In neither case are users or customers being
            asked to understand or do the coding or anything like it.

            --Larry Constantine, IDSA
            Chief Scientist | Constantine & Lockwood, Ltd.

            > -----Original Message-----
            > From: agile-usability@yahoogroups.com
            [mailto:agile-usability@yahoogroups.com] On Behalf Of
            > aacockburn
            > Sent: Tuesday, 05 July 2005 12:18 PM
            > To: agile-usability@yahoogroups.com
            > Subject: [agile-usability] Usability, personas, use cases
            >
            > I received this interesting question about use cases, personas and
            > usability, which I think is relevant to this august body of
            > thinkers / doers. I stripped off the identifying details from the
            > email to leave the meat of the worries as discussion fodder.
            >
            > Anyone have some thoughts on this?
            >
            > =============
            > I have worked as a Designer in a team of technocratic Java Developers
            > who 'get' your (Alistair's) vision of use-cases, but are not able to
            > sell or articulate the idea to anyone else in the company other than
            > peers. For me, use-cases certainly don't seem to readily interface
            > with the prototypes and workflows/scenarios that I produce as work
            > products.
            >
            > I have looked into them and cannot see anything of any more value than
            > Cooper's personas. Whilst both are new 'languages', personas are most
            > useful in communicating to the project team what the users (your
            > actors) actually desire in terms of their goals, however getting
            > empathy from the large majority of developers is an added challenge
            > often with fruitless results.
            >
            > Use-cases do not seem to bridge any communication gaps as they are a
            > language in their own right that needs to be learnt by rote and being
            > textual in nature are uninteresting and wordy. In fact I've never once
            > seen an effective use-case because they're so difficult to get 'right'
            > and even harder to communicate value. Also, the mere thought of asking
            > one of my customers to attempt to understand one is tantamount to
            > asking them to start coding for me. I can't see it and need
            > enlightenment!
            >
            > Apologies for being frank. I also long for someone to explain the
            > interface between agile programming and 'usability' *.
            >
            > Kind regards
            >
            > * Usability whilst useful in most contexts is just ' good design ' and
            > therefore a misnomer. When was anything 'well designed' unusable?
            > =======================================
            >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
          • Larry Constantine
            As with so many things, it is a matter of scale and objectives. Playing around with musical ideas to get the sound right can work for a garage band but will
            Message 5 of 8 , Jul 7, 2005
            • 0 Attachment
              As with so many things, it is a matter of scale and objectives. Playing
              around with musical ideas to get the sound right can work for a garage band
              but will not be nearly as effective with a symphony orchestra. Putting
              together a 4 minute cut for a popular release is a very different endeavor
              than creating a 5-movement symphony for chorus and orchestra that lasts
              nearly an hour. And there may well be differences between whether one writes
              for a generation or for the ages.

              Musical analogies can carry us only so far, however. In the real world where
              I work the need to ensure traceability for the FDA or guaranteed performance
              for the owners of the electrical grid mitigate against treating anything
              with casual informality. Use cases cannot be allowed to wither away, as they
              are part of the engineering and legal audit trail that connects what is
              delivered to how it was conceived. Which is another form of communication
              function that such models can fulfill.

              --Larry Constantine, IDSA
                Chief Scientist | Constantine & Lockwood, Ltd.

              > -----Original Message-----
              > From: agile-usability@yahoogroups.com
              [mailto:agile-usability@yahoogroups.com] On Behalf Of
              > William Pietri
              > Sent: Wednesday, 06 July 2005 3:51 PM
              > To: agile-usability@yahoogroups.com
              > Subject: Re: [agile-usability] Usability, personas, use cases
              >
              > On Tue, 2005-07-05 at 17:18 +0000, aacockburn wrote:
              > > I received this interesting question about use cases, personas and
              > > usability, which I think is relevant to this august body of
              > > thinkers / doers. I stripped off the identifying details from the
              > > email to leave the meat of the worries as discussion fodder.
              >
              > My general thought is that formal approaches to things are a fallback
              > when you can't get informal, intuitive approaches to work. Musical
              > notation, for example, is impressive and useful, but its complexity and
              > artificiality is a big barrier until you've invested a lot of time in
              > learning it. Watching a garage band practice together, I'd be pretty
              > surprised to see them resolve a question by writing down the music
              > rather than playing or singing the bit.
              >
              > Most people I know that are building interactive web products, for
              > example, have a deep understanding of their audience. They don't even
              > need formal personas, as they're all aware of important segments of the
              > user community and often of particular vocal representatives of those
              > segments.
              >
              > If I see a team struggling with knowing their audience, I may throw
              > personas at them, especially at the beginning of a projects, as it's a
              > good way to get them to engage with those issues and converge on a
              > shared vision.
              >
              > I'd only recommend formal use cases to a team if they couldn't keep the
              > complexity of the app in their heads. For example, if I were part of a
              > team with no industry experience brought into some complex domain, I'd
              > sit down and start writing use cases as a way to get a handle on things.
              > Whether or not I kept them up over the long haul would depend a lot on
              > circumstance. In an agile context I'd always be hoping to find a way to
              > let them wither away, just like I would with any other practice that
              > doesn't directly add value to the finished product.
              >
              >
              > So I'd say if their communications are fine without use cases, then they
              > shouldn't use cases. Once they notice a communication problem, then's
              > the time to ask whether use cases would solve it.
              >
              > William
              >
              >
              > --
              > William Pietri <william@...>
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • katie pula
              That s the best thing I ve read/heard in awhile. Katie Pula Interaction Architect, Blast Radius Larry Constantine wrote: Personas and
              Message 6 of 8 , Jul 7, 2005
              • 0 Attachment
                That's the best thing I've read/heard in awhile.
                 
                Katie Pula
                Interaction Architect, Blast Radius


                Larry Constantine <lconstantine@...> wrote:
                Personas and use cases serve very different functions if used as intended.
                Personas are an attempt to embody essential understanding about users while
                use cases are one way of representing the nature of user tasks in
                interaction with a system. Yes, I know, some people tack elaborate scenarios
                onto personas and others squeeze user profiles into use cases, but that is
                another discussion.

                Not all use cases are arcana needing to be mastered through rote learning.
                Essential use cases (task cases) are simplified expressions in ordinary
                everyday language and the vocabulary of the subject matter. Many have found
                that they are effective for bridging the communication with users about the
                essence of their needs; no special training is needed for users to
                interpret, validate, and amend them.

                Both user role and task case models can not only be reviewed with users and
                customers but also developed in collaboration with them using workshop
                techniques such as those perfected by Jeff Patton or found in the Joint
                Essential Modeling approach. In neither case are users or customers being
                asked to understand or do the coding or anything like it. 

                --Larry Constantine, IDSA
                  Chief Scientist | Constantine & Lockwood, Ltd.

                > -----Original Message-----
                > From: agile-usability@yahoogroups.com
                [mailto:agile-usability@yahoogroups.com] On Behalf Of
                > aacockburn
                > Sent: Tuesday, 05 July 2005 12:18 PM
                > To: agile-usability@yahoogroups.com
                > Subject: [agile-usability] Usability, personas, use cases
                >
                > I received this interesting question about use cases, personas and
                > usability, which I think is relevant to this august body of
                > thinkers / doers. I stripped off the identifying details from the
                > email to leave the meat of the worries as discussion fodder.
                >
                > Anyone have some thoughts on this?
                >
                > =============
                > I have worked as a Designer in a team of technocratic Java Developers
                > who 'get' your (Alistair's) vision of use-cases, but are not able to
                > sell or articulate the idea to anyone else in the company other than
                > peers. For me, use-cases certainly don't seem to readily interface
                > with the prototypes and workflows/scenarios that I produce as work
                > products.
                >
                > I have looked into them and cannot see anything of any more value than
                > Cooper's personas. Whilst both are new 'languages', personas are most
                > useful in communicating to the project team what the users (your
                > actors) actually desire in terms of their goals, however getting
                > empathy from the large majority of developers is an added challenge
                > often with fruitless results.
                >
                > Use-cases do not seem to bridge any communication gaps as they are a
                > language in their own right that needs to be learnt by rote and being
                > textual in nature are uninteresting and wordy. In fact I've never once
                > seen an effective use-case because they're so difficult to get 'right'
                > and even harder to communicate value. Also, the mere thought of asking
                > one of my customers to attempt to understand one is tantamount to
                > asking them to start coding for me. I can't see it and need
                > enlightenment!
                >
                > Apologies for being frank. I also long for someone to explain the
                > interface between agile programming and 'usability' *.
                >
                > Kind regards
                >
                > * Usability whilst useful in most contexts is just ' good design ' and
                > therefore a misnomer. When was anything 'well designed' unusable?
                > =======================================
                >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >




                Sell on Yahoo! Auctions - No fees. Bid on great items.
              • William Pietri
                ... Sorry if I was unclear. When I said that I felt formal methods should be used when you can t get informal, intuitive approaches to work, I didn t mean that
                Message 7 of 8 , Jul 12, 2005
                • 0 Attachment
                  On Thu, 2005-07-07 at 13:58 -0500, Larry Constantine wrote:
                  > Musical analogies can carry us only so far, however. In the real world
                  > where I work the need to ensure traceability for the FDA or guaranteed
                  > performance for the owners of the electrical grid mitigate against
                  > treating anything with casual informality.

                  Sorry if I was unclear. When I said that I felt formal methods should be
                  used when you can't get informal, intuitive approaches to work, I didn't
                  mean that one should treat work casually.

                  For example, writers I know are very serious about their craft. But I
                  don't know any professional writer who follows a formal method to
                  achieve good prose. If they need a powerful closing sentence, they write
                  one, and may be completely unable to explain how they did it.

                  If one doesn't have the knack for writing, then the methods in
                  composition textbooks are a good place to start. Or if an organization
                  wants to write something that's beyond the scope of what one writer or a
                  small team can achieve, then coming up with a formal, process-driven
                  approach can have good results.

                  What I was trying to highlight, though, is that neither of those gets
                  you the same value per effort of one talented, experienced writer fully
                  engaged in the task itself. Thus, I always look first for ways to fit
                  work within that envelope.

                  > Use cases cannot be allowed to wither away, as they are part of the
                  > engineering and legal audit trail that connects what is delivered to
                  > how it was conceived. Which is another form of communication function
                  > that such models can fulfill.

                  Certainly there are environments where that sort of paperwork is the
                  best way to fulfill a goal, and I didn't mean to suggest otherwise. I
                  was really only addressing the situation of Alistair's correspondent,
                  who didn't mention the need for an audit trail.

                  William

                  --
                  William Pietri <william@...>
                • Kevin Doyle
                  ... I m not an agile guru, but I am a design and usability consultant - so, here s my take on it, however wrong it may be. ;) Personas are really more of a
                  Message 8 of 8 , Jul 15, 2005
                  • 0 Attachment
                    > Whilst both are new 'languages', personas are most
                    > useful in communicating to the project team what the users (your
                    > actors) actually desire in terms of their goals, however getting
                    > empathy from the large majority of developers is an added challenge
                    > often with fruitless results.

                    I'm not an agile guru, but I am a design and usability consultant -
                    so, here's my take on it, however wrong it may be. ;) Personas are
                    really more of a tool for determining a product's requirements, and
                    aren't really used by developers. Personas give a face and depth to
                    the possible user that's impossible to create without having a product
                    or prototype you can throw off a group of use-testers. Once you're at
                    the testing stage of the game, personas really help in determining
                    your tester base. They can even be a help to developers -- developers
                    sometimes have a hard time seeing what they're making through the eyes
                    of the user and personas can help with this - however, that implies
                    that the developer wants to know more about the user.

                    > Use-cases do not seem to bridge any communication gaps as they are a
                    > language in their own right that needs to be learnt by rote and being
                    > textual in nature are uninteresting and wordy. In fact I've never once
                    > seen an effective use-case because they're so difficult to get 'right'
                    > and even harder to communicate value. Also, the mere thought of asking
                    > one of my customers to attempt to understand one is tantamount to
                    > asking them to start coding for me. I can't see it and need
                    > enlightenment!

                    Use cases aren't one of my strengths, but they're HUGELY important if
                    you want to determine a product's requirements -- especially if you're
                    developing a completely new application or site. Yes, use cases have
                    their own vocabulary you need to have translated if you're trying to
                    explain them to a group of stakeholders or team members who have never
                    used them. If you're someone responsible for presenting a series of
                    use-cases to a group of stakeholders or team members, you are going to
                    have to learn how to translate those use cases to your team and to the
                    stakeholders. Use cases can reduce the amount of guesswork and can be
                    a big help on determining each step of a complicated process. I can't
                    imagine ~not~ using them -- I'm just not very good at creating them.
                    ;)

                    > * Usability whilst useful in most contexts is just ' good design ' and
                    > therefore a misnomer. When was anything 'well designed' unusable?


                    Have you ever visited a web page that looked great visually, but had a
                    hard time trying to figure out where the link to something important
                    was? As you rolled your mouse over the page, perhaps lots of neat
                    things happened - cool mouseover behaviors or other types of neat
                    animations are triggered, but you still couldn't find that link you
                    were looking for? Sure, the site looks AWESOME, but it's so cutting
                    edge that the novice user can't even figure the page out. (Flash sites
                    are SOOO guilty of this.)

                    When something is considered "well designed" in my book, it has to be
                    intuitive ~and~ visually appealing. The term "design" is a strange one
                    in site and application development. Design, for me, has two parts -
                    visual design and interface design; the two are very different. Sure,
                    both require knowledge of how to layout a page, but interface design
                    is where the "usability" happens. Perhaps visualize interface design
                    as the skeleton and visual design as the skin. (The muscle could
                    perhaps be called the backend and/or "programming".) Interface design
                    includes detailing each part of the site -- menu placement, page
                    behavior (mouseover or onClick), button vs. link usage and placement,
                    radio button vs. checkbox vs. alt/shift menu selection, content
                    placement, etc., etc. Visual design includes stylesheet creation,
                    color guide creation and usage, branding, typography, etc., etc...
                    Frank Lloyd Wright once said, "'Form follows function' - that has
                    been misunderstood. Form and function should be one, joined in a
                    spiritual union." I view "form" as the visual design and "function" as
                    the interaction design.

                    Okay. Babbling is over... Feel free to flame, correct, slap, or comment.

                    Kevin Doyle
                    Senior Consultant, CC Pace, Inc.
                  Your message has been successfully submitted and would be delivered to recipients shortly.