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

Re: [agile-usability] Building Agile Personas

Expand Messages
  • Jonathan Kern
    good advice Lou… especially the part about even treating personas in an incremental fashion. also can check out Jeff Patton s Story Mapping stuff…
    Message 1 of 7 , Apr 11 7:49 AM
    View Source
    • 0 Attachment
      good advice Lou… especially the part about even treating personas in an incremental fashion.

      also can check out Jeff Patton's Story Mapping stuff…

      Paritosh, the key is to use judgement to know how deep to go in defining personas (or anything in an agile project for that matter). Unfortunately, as you point out, you are new at this practice. That makes "exercising judgement" hard since you do not yet have any experience from which to draw upon for such judgement. Therefore, I recommend, do only the smallest amount of effort you can think of, and then stop half way there and see if the rest of the team finds the work useful <grin>. 

      I find a wide, shallow approach to understanding the app and the domain is key. Going deep only when and if necessary. More judgement...

      On Apr 11, 2013, at 9:34 AM, lou schwartz <schwartz.lou@...> wrote:

       

      Hi,

      you should be able to rely on the product owner's knowledge of users.

      A first brainstorming can help you to identify the main personas, the ones you will develop.
      Next, the team can ask questions to the product owner to precise the objectives, the behaviour etc. of the personas. It's a common reflection to better appropriate them later. The questions can be more or less structured. E.g. first questions about who they are, then what are their contexts and particularly their contexts of use of the application, ...
      Then the mediator builds a first version of the personas and proposes them to the team for a common validation.

      And don't forget that it can be also agile: so you can improve the personas throughout the project. For instance, for the first sprint you have maybe 1 clear persona and 4 other more lightly described. It is maybe enough to define the first user stories. Then you will try, certainly with the product owner, to collect the missing information to improve the personas and the product backlog.

      Particularly it has allowed us to define user stories that we never thought because the product owner remained in his vision of his needs and didn't always expanded to the needs of all target users.

      Lou Schwartz
      R&D Engineer
      --------------------------------------------------------------------------------
      Centre de Recherche Public Henri Tudor
      SSI - Service Science and Innovation
      Unit SISE - Software Intensive Services Engineering
      29, avenue John F. Kennedy
      L-1855 Luxembourg
      lou.schwartz@...
      www.tudor.lu
      --------------------------------------------------------------------------------

      Please do not print this document unless it is necessary. Consider the environment.


      2013/4/11 paritoshc1 <chhibberparitosh@...>
       

      Hello Everyone,

      I am familiar with personas as Cooper describes in About Face, but am just getting started with Agile.

      Building real research based personas is a time taking activity, and kind of waterfall-ish: research->analyze data->... ... ->publish personas.

      For a sprint which is 2 or 3 weeks, how can we do all that without compromising on conducting qualitative research? 
      (I believe assumption personas are useless and sometimes counterproductive.)

      Thanks in advance.

      Regards,
      Paritosh




    • Larry Constantine
      Hi Paritosh, You are correct about personas. For agile design and development, there are better approaches. The first is to carry out model-driven inquiry
      Message 2 of 7 , Apr 11 9:28 AM
      View Source
      • 0 Attachment

        Hi Paritosh,

         

        You are correct about personas. For agile design and development, there are better approaches. The first is to carry out model-driven inquiry instead of an open ended ethnographic field study or extended contextual inquiry that generates tons of “data”. Instead, you start with exploratory modeling to identify areas for short, focused field inquiry. Then the model is refined and completed as needed for the immediate design.

         

        The second is to employ user roles instead of fully fledged personas. The latter include a great deal of “noise” that serves primarily to make the persona seem real but has little or nothing to do with good design. User roles, as constructed in usage-centered design or activity-directed design, are collections of responsibilities, needs, interests, and expectations of the actor within the role within an activity. A role focuses on the relationship between an actor in role and a designed artifact of interest. In other words, a user role is centered on the important stuff with the greatest impact on good interaction design and user experience in interaction with the designed artifact. It does not waste time on all that “other stuff” that makes personas fun and interesting but offers little leverage for the agile designer.

         

        For agile projects: model-driven inquiry with user roles instead of ethnographic/contextual inquiry and personas.

         

        Prof. Larry Constantine, IDSA, ACM Fellow

        Universidade da Madeira | Madeira Interactive Technologies Institute

        Gabinete 2.56 | int'l m: +44 792.447.5358

         

         

         

        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of paritoshc1
        Sent: Thursday, 11 April, 2013 01:56
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] Building Agile Personas

         

         

        Hello Everyone,

         

        I am familiar with personas as Cooper describes in About Face, but am just getting started with Agile.

         

        Building real research based personas is a time taking activity, and kind of waterfall-ish: research->analyze data->... ... ->publish personas.

         

        For a sprint which is 2 or 3 weeks, how can we do all that without compromising on conducting qualitative research? 

        (I believe assumption personas are useless and sometimes counterproductive.)

         

        Thanks in advance.

         

        Regards,

        Paritosh

      • joshseiden
        I just want to chime in with 98% endorsement of what Larry says here. I made a lot of Cooper style personas when I worked at Cooper. I disagree with Larry that
        Message 3 of 7 , Apr 12 7:59 AM
        View Source
        • 0 Attachment
          I just want to chime in with 98% endorsement of what Larry says here.

          I made a lot of Cooper style personas when I worked at Cooper. I disagree with Larry that all that narrative stuff "offers little leverage." I think that stuff is really really valuable to the creative process. That said, creating those personas with all that narrative stuff is really hard, and really hard to get right, so I've stopped recommending the technique. I just think it's important to understand why designers do it.

          As to the model-driven inquiry portion of Larry's post, I completely agree. In agile environments, I now use a very simplified model of personas. This model starts as a collection of assumptions. If you stop there, the model will have some value, but not much. The key to using this approach is that you have to engage in continuous customer research through the life of project and use that research to continuously update your model. In this way, the persona becomes *a representation of what you know now.* That's a really important construct, and one that's worth maintaining.

          JS



          --- In agile-usability@yahoogroups.com, "Larry Constantine" <lconstantine@...> wrote:
          >
          > Hi Paritosh,
          >
          >
          >
          > You are correct about personas. For agile design and development, there are
          > better approaches. The first is to carry out model-driven inquiry instead of
          > an open ended ethnographic field study or extended contextual inquiry that
          > generates tons of "data". Instead, you start with exploratory modeling to
          > identify areas for short, focused field inquiry. Then the model is refined
          > and completed as needed for the immediate design.
          >
          >
          >
          > The second is to employ user roles instead of fully fledged personas. The
          > latter include a great deal of "noise" that serves primarily to make the
          > persona seem real but has little or nothing to do with good design. User
          > roles, as constructed in usage-centered design or activity-directed design,
          > are collections of responsibilities, needs, interests, and expectations of
          > the actor within the role within an activity. A role focuses on the
          > relationship between an actor in role and a designed artifact of interest.
          > In other words, a user role is centered on the important stuff with the
          > greatest impact on good interaction design and user experience in
          > interaction with the designed artifact. It does not waste time on all that
          > "other stuff" that makes personas fun and interesting but offers little
          > leverage for the agile designer.
          >
          >
          >
          > For agile projects: model-driven inquiry with user roles instead of
          > ethnographic/contextual inquiry and personas.
          >
          >
          >
          > Prof. Larry Constantine, IDSA, ACM Fellow
          >
          > Universidade da Madeira | Madeira Interactive Technologies Institute
          >
          > Gabinete 2.56 | int'l m: +44 792.447.5358
          >
          >
          >
          >
          >
          >
          >
          > From: agile-usability@yahoogroups.com
          > [mailto:agile-usability@yahoogroups.com] On Behalf Of paritoshc1
          > Sent: Thursday, 11 April, 2013 01:56
          > To: agile-usability@yahoogroups.com
          > Subject: [agile-usability] Building Agile Personas
          >
          >
          >
          >
          >
          > Hello Everyone,
          >
          >
          >
          > I am familiar with personas as Cooper describes in About Face, but am just
          > getting started with Agile.
          >
          >
          >
          > Building real research based personas is a time taking activity, and kind of
          > waterfall-ish: research->analyze data->... ... ->publish personas.
          >
          >
          >
          > For a sprint which is 2 or 3 weeks, how can we do all that without
          > compromising on conducting qualitative research?
          >
          > (I believe assumption personas are useless and sometimes counterproductive.)
          >
          >
          >
          > Thanks in advance.
          >
          >
          >
          > Regards,
          >
          > Paritosh
          >
        • desireesy
          Paritosh, I think the way to approach agile personas is to not think of building personas as a heavy, up-front activity. All of the ideas mentioned so far are
          Message 4 of 7 , Apr 12 10:08 AM
          View Source
          • 0 Attachment
            Paritosh,

            I think the way to approach agile personas is to not think of building personas as a heavy, up-front activity. All of the ideas mentioned so far are great starting points. In addition, I'd encourage you to embrace the agile principles of working iteratively, continuously, and collaboratively by (to steal a LeanUX phrase) getting out of the building as you begin both design and implementation work. Refine and update your understanding of who is using your products as you are incrementally creating them. This is particularly important because as you introduce new capabilities to your users, those capabilities will change their behaviour and expectations.

            The key to keeping this lightweight is to move away from thinking of written persona documents as the deliverables. Come up with vivid, quick ways of sharing the new observations with your team as quickly as possible. So your job isn't to capture problems and insights, but to get solutions for those into the product as quickly as possible. You can update your team's understanding of the persona very quickly, but the documents are only an artifact -- it's making sure the team gets the information that's key.

            -Desirée

            --- In agile-usability@yahoogroups.com, "Larry Constantine" <lconstantine@...> wrote:
            >
            > Hi Paritosh,
            >
            >
            >
            > You are correct about personas. For agile design and development, there are
            > better approaches. The first is to carry out model-driven inquiry instead of
            > an open ended ethnographic field study or extended contextual inquiry that
            > generates tons of "data". Instead, you start with exploratory modeling to
            > identify areas for short, focused field inquiry. Then the model is refined
            > and completed as needed for the immediate design.
            >
            >
            >
            > The second is to employ user roles instead of fully fledged personas. The
            > latter include a great deal of "noise" that serves primarily to make the
            > persona seem real but has little or nothing to do with good design. User
            > roles, as constructed in usage-centered design or activity-directed design,
            > are collections of responsibilities, needs, interests, and expectations of
            > the actor within the role within an activity. A role focuses on the
            > relationship between an actor in role and a designed artifact of interest.
            > In other words, a user role is centered on the important stuff with the
            > greatest impact on good interaction design and user experience in
            > interaction with the designed artifact. It does not waste time on all that
            > "other stuff" that makes personas fun and interesting but offers little
            > leverage for the agile designer.
            >
            >
            >
            > For agile projects: model-driven inquiry with user roles instead of
            > ethnographic/contextual inquiry and personas.
            >
            >
            >
            > Prof. Larry Constantine, IDSA, ACM Fellow
            >
            > Universidade da Madeira | Madeira Interactive Technologies Institute
            >
            > Gabinete 2.56 | int'l m: +44 792.447.5358
            >
            >
            >
            >
            >
            >
            >
            > From: agile-usability@yahoogroups.com
            > [mailto:agile-usability@yahoogroups.com] On Behalf Of paritoshc1
            > Sent: Thursday, 11 April, 2013 01:56
            > To: agile-usability@yahoogroups.com
            > Subject: [agile-usability] Building Agile Personas
            >
            >
            >
            >
            >
            > Hello Everyone,
            >
            >
            >
            > I am familiar with personas as Cooper describes in About Face, but am just
            > getting started with Agile.
            >
            >
            >
            > Building real research based personas is a time taking activity, and kind of
            > waterfall-ish: research->analyze data->... ... ->publish personas.
            >
            >
            >
            > For a sprint which is 2 or 3 weeks, how can we do all that without
            > compromising on conducting qualitative research?
            >
            > (I believe assumption personas are useless and sometimes counterproductive.)
            >
            >
            >
            > Thanks in advance.
            >
            >
            >
            > Regards,
            >
            > Paritosh
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.