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

Re: Personas

Expand Messages
  • Ron Vutpakdi
    ... details, ... problems, tech ... more detail ... I agree completely. I like personas and having them can be very helpful, but only if they provide useful
    Message 1 of 23 , Jul 26, 2007
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "Elizabeth Whitworth"
      <elizabethwhitworth@...> wrote:
      >
      > [...] and you are writing for a
      > developer audience, then I would strongly suggest altering the persona
      > formula a little e.g. leave out a lot (but not all) of the personal
      details,
      > and include instead more details about daily workflow, common
      problems, tech
      > usage and set-up, and working context.
      >
      > I also think that it doesn't make much sense to present personas to
      > development without some associated usage scenarios that go into
      more detail
      > about specific user workflow and associated needs .

      I agree completely. I like personas and having them can be very
      helpful, but only if they provide useful information and context. If
      the personas are just a "think of the user" flag full of fluff without
      providing information that the developer sees as useful, they are
      likely to be ignored.

      We're currently trying to bring back personas after a rather
      disastrous earlier attempt. The earlier attempt was disastrous
      because personas and storyboards were oversold and executed poorly.
      As a result, when the personas and storyboards under-delivered, they
      were discredited as a useful tool.

      What I'm hoping that we'll do this time is develop them only as far as
      they are useful tools with helpful information and firmly ground them
      in practical usage scenarios. I'm hoping that we also under-promise
      them a bit as just a tool and not a general panacea. That way, we
      have a good chance of over-delivering.

      Ron
    • Mark Schraad
      I think it is important to develop the persona fully to the detail level. However, that being said, there is an advantage to leaving out those details when
      Message 2 of 23 , Jul 26, 2007
      • 0 Attachment
        I think it is important to develop the persona fully to the detail level. However, that being said, there is an advantage to leaving out those details when presenting them as targets to specific groups. That they are archetypes for a group of users with either common tasks, goals or desired product attributes can be very powerful. If your audience has a tendency to 'design for self', very specific personae can easily dismissed.

        Mark


        On Thursday, July 26, 2007, at 08:50AM, "Ron Vutpakdi" <vutpakdi@...> wrote:
        >--- In agile-usability@yahoogroups.com, "Elizabeth Whitworth"
        ><elizabethwhitworth@...> wrote:
        >>
        >> [...] and you are writing for a
        >> developer audience, then I would strongly suggest altering the persona
        >> formula a little e.g. leave out a lot (but not all) of the personal
        >details,
        >> and include instead more details about daily workflow, common
        >problems, tech
        >> usage and set-up, and working context.
        >>
        >> I also think that it doesn't make much sense to present personas to
        >> development without some associated usage scenarios that go into
        >more detail
        >> about specific user workflow and associated needs .
        >
        >I agree completely. I like personas and having them can be very
        >helpful, but only if they provide useful information and context. If
        >the personas are just a "think of the user" flag full of fluff without
        >providing information that the developer sees as useful, they are
        >likely to be ignored.
        >
        >We're currently trying to bring back personas after a rather
        >disastrous earlier attempt. The earlier attempt was disastrous
        >because personas and storyboards were oversold and executed poorly.
        >As a result, when the personas and storyboards under-delivered, they
        >were discredited as a useful tool.
        >
        >What I'm hoping that we'll do this time is develop them only as far as
        >they are useful tools with helpful information and firmly ground them
        >in practical usage scenarios. I'm hoping that we also under-promise
        >them a bit as just a tool and not a general panacea. That way, we
        >have a good chance of over-delivering.
        >
        >Ron
        >
        >
      • shramlet
        If one has the luxury (or mind-numbing task, depending on your perspective) of having a UCD / UXD / UED specify all the text for all the error messages, as
        Message 3 of 23 , Jul 26, 2007
        • 0 Attachment
          If one has the luxury (or mind-numbing task, depending on your
          perspective) of having a UCD / UXD / UED specify all the text for all
          the error messages, as well as every other intricate detail of the
          user experience, then personas would be less valuable to the
          developers since they can code to your strict specifications.

          If the developer is empowered (by role or resource restrictions,
          perhaps) to make design choices, then a persona might be a good time
          investment to help inform the developer's design choices.

          Susan Ramlet
          User-Centered Designer
          Medtronic



          --- In agile-usability@yahoogroups.com, Brian Weiss <briandweiss@...>
          wrote:
          >
          > So far, the developers I've worked with don't seem to care much
          about gaining empathy for the end-user. Not to say I haven't tried. To
          some degree they care, but they push it off (half-jokingly) that it's
          my "job to care". I tend to agree with them somewhat as giving them
          freedom to make end-user decisions hasn't abated obvious no-nos.
          >
          > To them "Commit error 412. Servlet ODBC cannot find hex 1000:X90d"
          is a perfectly good end-user error. Another good one is they see no
          problem in having pop-up dialogs that stop the user dead in a flow to
          confirm the submission was good. (Like the app is congratulating the
          user for figuring out how to hit the submit button). They debug code
          all day...dialogs are second nature to them.
          >
          > Anyway, personas can take up alot of time to develop for
          complicated sites or apps. Being the only UE guy here, I'd rather use
          my time elsewhere.
          >
          > -Brian
          >
        • Tim Wright
          Just to add something else to the discussion of Personas, I ve started using them in a different way. My company has decided to redesign it s website for
          Message 4 of 23 , Jul 26, 2007
          • 0 Attachment
            Just to add something else to the discussion of Personas, I've started using them in a different way. My company has decided to redesign it's website for accredited users (we give them training then they can sell our product). To get requirements, I've got all our support people (client service managers, accreditation team, consultants, ...) writing the personas and scenarios themselves.

            It didn't take long to teach the basic concepts (about a 2 hour focused meeting with four key personal), and the results I've been getting have been excellent and interesting! Of course, it is a mixed bag - some people can't get past the "what the site does now" versus "what our users want it do to," but a little feedback is keeping them on the right track.

            Of course, this is still early stages in the project, but I feel it's been an excellent requirements gathering exercise that has also got huge buy-in across the business for the project. The next stage is a card-sort (it's an information heavy website). I'm going to try to get people inside the business to do that as well - with some guidance of course.

            This does make me wonder: has anyone else tried to push some of the requirements gathering activities out into the business - where the people are neither technical nor designers. From my perspective, card-sorts and personas are obvious cantidates because they don't require much explanation.

            (I should also add that my place of work is unusual: we have a corporate culture where people are expected to focus on: achieving their goals, helping out other people, being friendly, and being themselves. This means that asking others to perform an activity where they get to be creative is always answered with gusto!)

            Tim

            On 7/27/07, shramlet <shramlet@...> wrote:

            If one has the luxury (or mind-numbing task, depending on your
            perspective) of having a UCD / UXD / UED specify all the text for all
            the error messages, as well as every other intricate detail of the
            user experience, then personas would be less valuable to the
            developers since they can code to your strict specifications.

            If the developer is empowered (by role or resource restrictions,
            perhaps) to make design choices, then a persona might be a good time
            investment to help inform the developer's design choices.

            Susan Ramlet
            User-Centered Designer
            Medtronic

            --- In agile-usability@yahoogroups.com, Brian Weiss <briandweiss@...>
            wrote:
            >
            > So far, the developers I've worked with don't seem to care much
            about gaining empathy for the end-user. Not to say I haven't tried. To
            some degree they care, but they push it off (half-jokingly) that it's
            my "job to care". I tend to agree with them somewhat as giving them
            freedom to make end-user decisions hasn't abated obvious no-nos.
            >
            > To them "Commit error 412. Servlet ODBC cannot find hex 1000:X90d"
            is a perfectly good end-user error. Another good one is they see no
            problem in having pop-up dialogs that stop the user dead in a flow to
            confirm the submission was good. (Like the app is congratulating the
            user for figuring out how to hit the submit button). They debug code
            all day...dialogs are second nature to them.
            >
            > Anyway, personas can take up alot of time to develop for
            complicated sites or apps. Being the only UE guy here, I'd rather use
            my time elsewhere.
            >
            > -Brian
            >




            --
            Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
          • Jeff Patton
            I ve enjoyed this thread! I wanted to tie a few things together and add a couple minor points. Alain pointed out that personas don t have to take a long time
            Message 5 of 23 , Jul 27, 2007
            • 0 Attachment
              I've enjoyed this thread!

              I wanted to tie a few things together and add a couple minor points.

              Alain pointed out that personas don't have to take a long time to
              create, and I agree. The quick one based on what people in your
              organization commonly understand about your users allow everyone to
              get on the same page. These are assumption based personas as
              described by Pruitt and Adlin. And, again, even a persona that lacks
              the rigor a Cooperist would put into it is better than no design target.

              Elizebeth and others brought up user scenarios. I'd second that - the
              persona put into action reaching a goal using the product makes the
              communication that much more meaningful. Try Tim's approach and have
              your stakeholders or developers write scenarios - after supplying them
              with a good example or two.

              William and Susan talked a bit about culture. I've found that
              developers care about users when doing so is part of the company's
              culture. If it is, personas help. If it's not, personas can still
              help - but, you need to know in the latter situation you're trying to
              /change/ company culture, not merely support it. Susan in particular
              talked about developers being empowered to make design decisions. In
              agile contexts especially, they should be. I find it more efficient
              if I don't have to think of or describe (in a user story or whatever)
              every nit-picky detail about the software. It's cool when developers
              who understand and are concerned about users can make decisions on
              their own - then vet those decisions later of course.

              Finally, after all that, the point I wanted to make was this: Someone
              I worked with asked me what the made a persona good. "Relevance" I
              said. By that I mean, given a persona with these characteristics, how
              does it change or affect the design of the software? Look for some
              clear answers that demonstrate why a characteristic of the users, as
              described in the persona, is relevant to the feature choices and
              design of the product.

              For example: I was recently working with some folks writing software
              to support research scientists. These scientists, although extremely
              sharp as scientists, had computer skills that varied wildly. And, the
              research tool we were building was something they'd use likely only
              once a month, but for a few hours at a time.

              Knowing all this allowed us to to decide that the although the users
              were sophisticated technically, the software had to be pretty easy to
              use. Furthermore, since they used it so infrequently, usage needed to
              be obvious since they were relearning it every time. Finally, since
              they used it for a couple hours when this /did/ sit down to use it,
              usage needed to be efficient. We could draw dotted lines between
              specific product features and these concerns that came from profiling
              our target users.

              That's what I mean by making the persona relevant.

              Thanks for all your posts,

              -Jeff
            • Daniel Szuc
              A good set of wire frames set in context for the group (i.e. talking about the end user thru the flow) has as much impact to the developers as would talking
              Message 6 of 23 , Jul 31, 2007
              • 0 Attachment
                "A good set of wire frames set in context for the group (i.e. talking about the end user thru the flow) has as much impact to the developers as would talking to personas."
                 
                Suggest this is the right opportunity to develop Personas. So take a small % of the walkthrough time to brainstorm what we know about our users.
                 
                See: http://www.apogeehk.com/articles/Personas_Focusing_on_getting_the_design_right_Part1.html and using a "walkthrough" to direct around User Goals coming from the personas crafted - http://www.uxmatters.com/MT/archives/000199.php
                 
                rgds,
                Dan

                Daniel Szuc
                Principal Usability Consultant
                Apogee Usability Asia Ltd
                www.apogeehk.com
                'Usability in Asia'

                The Usability Kit -
                http://www.theusabilitykit.com



                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Brian Weiss
                Sent: Wednesday, 25 July 2007 11:21 PM
                To: agile-usability@yahoogroups.com
                Subject: Re: [agile-usability] Personas

                Sort of. We have a modified RUP/Agile process where use cases are still king but there are plenty of opportunities for face-to-face for the group and the artifacts developed are less than a full blown RUP.
                 
                RUP, Agile, Waterfall, XP... done it all and developers still have *their context of what is a good end-user experience to contend with. Empathy won't get them to be able drop that context to look thru the user's eyes. I've yet to see one case where a DBA or a Java person can effectively drive a front-end decision because he/she understands the context or persona using the app. And besides, they just don't care that much nor should they regardless of methodology.
                 
                I'd like to clarify that I didn't mean personas have no value but in the select case where they are being used for development staff empathy - I personally would spend my time elsewhere. Benefit vs. resource consumption. A good set of wireframes set in context for the group (i.e. talking about the end user thru the flow) has as much impact to the developers as would talking to personas.
                 
                As for buy in/defense from a marketing stakeholder I've used them with moderate success. Maybe they aren't my forte, but they seem great in theory...in practice, less so.
                 
                If I had a team, maybe there would be the opportunity for me to work them in more.
                 
                Just my $.02
                -Brian


                Adrian Howard <adrianh@quietstars. com> wrote:

                On 25 Jul 2007, at 15:14, Brian Weiss wrote:

                > So far, the developers I've worked with don't seem to care much
                > about gaining empathy for the end-user. Not to say I haven't tried.
                > To some degree they care, but they push it off (half-jokingly) that
                > it's my "job to care". I tend to agree with them somewhat as giving
                > them freedom to make end-user decisions hasn't abated obvious no-nos.
                [snip]

                Is this on an agile team?

                Adrian


                Pinpoint customers who are looking for what you sell.

              • Brian Weiss
                To echo the thread starter: Thanks for all the responses - I m the only usability person in a company of 10,000+ who custom builds every system and it s nice
                Message 7 of 23 , Jul 31, 2007
                • 0 Attachment
                  To echo the thread starter: Thanks for all the responses - I'm the only usability person in a company of 10,000+ who custom builds every system and it's nice to read these threads. As I mentioned in an earlier email, we are not a true Agile shop and in fact are alot closer to a lightweight RUP shop. This listserv was closest to any speaking to usability concepts and our software development cycle out there and that's why I joined. I don't usually jump in because of that fact but wanted to add to this conversation and didn't feel the Agile process was necessarily germain. Although I've yet to see a perfect implementation of any theoretical development process...
                   
                  To answer several emails: I get it. I understand how to present to teams - been doing it for 10+ years. I know what personas are and how to use them.
                   
                  Again though, in the case originally proposed, I've yet to see a Java coder have any impact on a front end because he understands a persona using the interface. Nor has a persona helped him or her code a servlet better. The inputs are the same regardless of the who.
                  In a development meeting with developers I would not present personas. With marketing people and other business stakeholders, sure. They can bring a nice rounded context to a wireframe.
                   
                  To devs I may speak of UMLish actors, but only in the context of how they interact with the system on a data level as that is all they care about.

                  Thanks again for the responses,
                  -Brian
                   
                   


                  Daniel Szuc <dszuc@...> wrote:
                  "A good set of wire frames set in context for the group (i.e. talking about the end user thru the flow) has as much impact to the developers as would talking to personas."
                   
                  Suggest this is the right opportunity to develop Personas. So take a small % of the walkthrough time to brainstorm what we know about our users.
                   
                   
                  rgds,
                  Dan
                  Daniel Szuc
                  Principal Usability Consultant
                  Apogee Usability Asia Ltd
                  www.apogeehk. com
                  'Usability in Asia'

                  The Usability Kit -
                  http://www.theusabi litykit.com


                  From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Brian Weiss
                  Sent: Wednesday, 25 July 2007 11:21 PM
                  To: agile-usability@ yahoogroups. com
                  Subject: Re: [agile-usability] Personas

                  Sort of. We have a modified RUP/Agile process where use cases are still king but there are plenty of opportunities for face-to-face for the group and the artifacts developed are less than a full blown RUP.
                   
                  RUP, Agile, Waterfall, XP... done it all and developers still have *their context of what is a good end-user experience to contend with. Empathy won't get them to be able drop that context to look thru the user's eyes. I've yet to see one case where a DBA or a Java person can effectively drive a front-end decision because he/she understands the context or persona using the app. And besides, they just don't care that much nor should they regardless of methodology.
                   
                  I'd like to clarify that I didn't mean personas have no value but in the select case where they are being used for development staff empathy - I personally would spend my time elsewhere. Benefit vs. resource consumption. A good set of wireframes set in context for the group (i.e. talking about the end user thru the flow) has as much impact to the developers as would talking to personas.
                   
                  As for buy in/defense from a marketing stakeholder I've used them with moderate success. Maybe they aren't my forte, but they seem great in theory...in practice, less so.
                   
                  If I had a team, maybe there would be the opportunity for me to work them in more.
                   
                  Just my $.02
                  -Brian


                  Adrian Howard <adrianh@quietstars. com> wrote:

                  On 25 Jul 2007, at 15:14, Brian Weiss wrote:

                  > So far, the developers I've worked with don't seem to care much
                  > about gaining empathy for the end-user. Not to say I haven't tried.
                  > To some degree they care, but they push it off (half-jokingly) that
                  > it's my "job to care". I tend to agree with them somewhat as giving
                  > them freedom to make end-user decisions hasn't abated obvious no-nos.
                  [snip]

                  Is this on an agile team?

                  Adrian


                  Pinpoint customers who are looking for what you sell.


                  Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.

                • jawsadieemail
                  Everyone - thanks for all the responses. Great discussion. I just wanted to follow up and (for what it s worth) let everyone know that my team has decided not
                  Message 8 of 23 , Aug 1, 2007
                  • 0 Attachment
                    Everyone - thanks for all the responses. Great discussion. I just
                    wanted to follow up and (for what it's worth) let everyone know that
                    my team has decided not to pursue the introduction of personas at this
                    point. We agreed with many on this list who felt the impact was low
                    relative to the time investment. We're doing other things to bring
                    focus to our users - such as usability test briefings and group design
                    sessions where our design leads mentor our development staff and of
                    course advocate for our user base.

                    That said, I do think there is value with personas. Obviously many of
                    you use them with good success, and they've been helpful for me in the
                    past as well. Two main things drove our decision to not pursue them:
                    1)The context of Agile - time/resources are scarce & 2)It seems the
                    archetype personas are easiest to create but better for marketing and
                    other stakeholders. More detailed personas that focus on detailed
                    tasks & come accompanied with use cases or scenarios are better for
                    developers (our audience in this case) but take longer to use.

                    Thanks all,
                    Jeff
                  Your message has been successfully submitted and would be delivered to recipients shortly.