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

RE: [agile-usability] I to R - was Re: Where the BA Ends and the Usability Specialist Begins?

Expand Messages
  • Lylan Masterman
    All very good points. While personas originate from the world of design, I see them having maximum value when they affect an entire organization. When an
    Message 1 of 66 , Aug 25, 2006
    • 0 Attachment

      All very good points.

       

      While personas originate from the world of design, I see them having maximum value when they affect an entire organization.  When an entire org can rally around a single set of personas, I believe that personas deliver much greater value.  This includes (in no particular order):

      -          product management/product owners uses the personas to prioritize upcoming projects

      -          product management uses the personas to communicate business needs to the dev team/program management/design/etc

      -          marketing uses the personas to create better collateral, etc

      -          sales better understands who is “in the room”, and target the sales pitch based on the audience

      -          user training is geared based on which personas are attending the training

      -          user documentation is “designed” based on the personas

      -          design making design choices

      -          design, program management, etc work well with the dev team using the personas

      -          everyone, but especially BizDev, looks to create new business opportunities by understanding and focusing on the personas

      -          etc…

       

      Hence, this is why an org might choose to have a BDM as its primary persona.  In the end, everyone in the org needs to focus on both the short-term and long-term needs of the BDM… this is an attempt to address Ron’s statement ‘The above sounded like creating a product that's easy to sell but that will come back to bite you when the users hate it”.  If the users hate it, the BDM will find out about it and probably will go to your competition in the medium to long-term.

      This does not exclude the possibility that any given project team might rally around a different persona, so long as the team understands the organization’s needs.  And, for any specific project, the business might say that UX is paramount because the BDM-persona wants a specific user-persona to have a better experience.

       

      One last thought: an org might choose to make the BDM the primary persona not because it is necessarily the most important persona, but because an organization might have a good argument when claiming that the BDM is the only persona that would be considered as at least an important secondary persona for each of the bullets I listed above (either as a primary persona or as a secondary when thinking of scope-control and long-term customer loyalty).

       

      This whole email begs the question: does it make sense for an entire org to have a primary persona?  Is an org too high-level to specify primary personas?  Perhaps… probably…. definitely!

       

      Lylan Masterman

       

       


      From: agile-usability@yahoogroups.com [mailto: agile-usability@yahoogroups.com ] On Behalf Of Joshua Seiden
      Sent: Thursday, August 24, 2006 6:17 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] I to R - was Re: Where the BA Ends and the Usability Specialist Begins?

       

      I just want to point out that this is a slightly different interpretation of
      the idea of primary and secondary personas. It made me nervous, and perhaps
      that's what Ron is responding to as well.

      The idea of primary persona vs. secondary persona was invented to give you a
      mechanism to handle *design* priorities. By setting a primary persona, you
      are saying, "we design first for the primary, but test against and
      accommodate the needs of the secondary." A secondary persona can use a
      product designed for a primary, as long as you add a few special
      accomodations. The opposite is not true.

      In this way, you keep the system design structured around the key usage and
      behavior patterns.

      The persona system has a few other useful types of personas, including
      served personas, who don't use the system at all but whose needs must be
      accomodated (such as BDMs), and negative personas--those who are explicitly
      out of scope.

      This last point is important: unless a persona is declared explicitly out of
      scope, that persona will have his or her needs addressed. Primary vs.
      secondary is not at heart a scope making decision, rather a style-making
      decision. Secondary does not mean "out of scope" or even "less important to
      the business." It simply means that the USAGE needs are mostly fulfilled by
      designing for the primary personas.

      (Typically, the primary vs. primary decision is where major scope decisions
      take place--for example, you might be designing an in-flight entertainment
      system--in scope initially is the flight attendant UI, but the ground-crew
      UI is not in scope until next year.)

      Phew--the reason that all this is important is that when it comes time to
      use personas for design, you have to construct usage scenarios for them. If
      your primary persona is not a user, well, this pretty damn hard. :-)

      JS

    • Lylan Masterman
      All very good points. While personas originate from the world of design, I see them having maximum value when they affect an entire organization. When an
      Message 66 of 66 , Aug 25, 2006
      • 0 Attachment

        All very good points.

         

        While personas originate from the world of design, I see them having maximum value when they affect an entire organization.  When an entire org can rally around a single set of personas, I believe that personas deliver much greater value.  This includes (in no particular order):

        -          product management/product owners uses the personas to prioritize upcoming projects

        -          product management uses the personas to communicate business needs to the dev team/program management/design/etc

        -          marketing uses the personas to create better collateral, etc

        -          sales better understands who is “in the room”, and target the sales pitch based on the audience

        -          user training is geared based on which personas are attending the training

        -          user documentation is “designed” based on the personas

        -          design making design choices

        -          design, program management, etc work well with the dev team using the personas

        -          everyone, but especially BizDev, looks to create new business opportunities by understanding and focusing on the personas

        -          etc…

         

        Hence, this is why an org might choose to have a BDM as its primary persona.  In the end, everyone in the org needs to focus on both the short-term and long-term needs of the BDM… this is an attempt to address Ron’s statement ‘The above sounded like creating a product that's easy to sell but that will come back to bite you when the users hate it”.  If the users hate it, the BDM will find out about it and probably will go to your competition in the medium to long-term.

        This does not exclude the possibility that any given project team might rally around a different persona, so long as the team understands the organization’s needs.  And, for any specific project, the business might say that UX is paramount because the BDM-persona wants a specific user-persona to have a better experience.

         

        One last thought: an org might choose to make the BDM the primary persona not because it is necessarily the most important persona, but because an organization might have a good argument when claiming that the BDM is the only persona that would be considered as at least an important secondary persona for each of the bullets I listed above (either as a primary persona or as a secondary when thinking of scope-control and long-term customer loyalty).

         

        This whole email begs the question: does it make sense for an entire org to have a primary persona?  Is an org too high-level to specify primary personas?  Perhaps… probably…. definitely!

         

        Lylan Masterman

         

         


        From: agile-usability@yahoogroups.com [mailto: agile-usability@yahoogroups.com ] On Behalf Of Joshua Seiden
        Sent: Thursday, August 24, 2006 6:17 PM
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] I to R - was Re: Where the BA Ends and the Usability Specialist Begins?

         

        I just want to point out that this is a slightly different interpretation of
        the idea of primary and secondary personas. It made me nervous, and perhaps
        that's what Ron is responding to as well.

        The idea of primary persona vs. secondary persona was invented to give you a
        mechanism to handle *design* priorities. By setting a primary persona, you
        are saying, "we design first for the primary, but test against and
        accommodate the needs of the secondary." A secondary persona can use a
        product designed for a primary, as long as you add a few special
        accomodations. The opposite is not true.

        In this way, you keep the system design structured around the key usage and
        behavior patterns.

        The persona system has a few other useful types of personas, including
        served personas, who don't use the system at all but whose needs must be
        accomodated (such as BDMs), and negative personas--those who are explicitly
        out of scope.

        This last point is important: unless a persona is declared explicitly out of
        scope, that persona will have his or her needs addressed. Primary vs.
        secondary is not at heart a scope making decision, rather a style-making
        decision. Secondary does not mean "out of scope" or even "less important to
        the business." It simply means that the USAGE needs are mostly fulfilled by
        designing for the primary personas.

        (Typically, the primary vs. primary decision is where major scope decisions
        take place--for example, you might be designing an in-flight entertainment
        system--in scope initially is the flight attendant UI, but the ground-crew
        UI is not in scope until next year.)

        Phew--the reason that all this is important is that when it comes time to
        use personas for design, you have to construct usage scenarios for them. If
        your primary persona is not a user, well, this pretty damn hard. :-)

        JS

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