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

Re: [agile-usability] Where the BA Ends and the Usability Specialist Begins?

Expand Messages
  • Ron Jeffries
    Hello Andrea, thank you for writing. On Saturday, August 19, 2006, ... Semantics: the study of meaning. Don t let the meaning of the question get in the way.
    Message 1 of 66 , Aug 19, 2006
    • 0 Attachment
      Hello Andrea, thank you for writing. On Saturday, August 19, 2006,
      at 6:46:40 PM, you wrote:

      > Sure, sure. Don't let the symantics of the question
      > get in the way.

      Semantics: the study of meaning. Don't let the meaning of the
      question get in the way. Check, I'll try to do that ... ;->

      > Take it as a given that the project
      > team is focused on supporting the client as well as
      > the user.

      In Agile methods, the words "customer" or "product owner" refer to
      the business person who has the responsibility to say what features
      of the product will be built next. My point was that in my
      experience, the analysis and usability people are, in a sense,
      "staff" -- support personnel -- to whoever has the final
      responsibility to decide what will be done. They help that
      individual (or group) come up with what to do. Advisors, mostly,
      though of course their advice is taken to heart in their areas of

      > We're actually a very cooperative group
      > simply seeking a workable methodology that doesn't
      > duplicate effort yet provides everyone with what they
      > need.

      Sure ... it never entered my mind that you weren't. I think perhaps
      I failed to make my meaning clear.

      > I'll re-iterate that I am not claiming our approach to
      > be a formal Agile methodology. Perhaps a different
      > way to approach the question that you may be more
      > comfortable answering is: How do Usability
      > Specialists and BAs work together in an Agile +
      > Usability world?

      I need a little more help understanding the problem first, I'm
      afraid. Could you tell us a bit about the difficulties you're
      presently having working together? It sounded as if you were looking
      for "boundaries" between the duties. To my taste, boundaries aren't
      usually the best strategy for teamwork, but I'm interested in
      hearing about current conflicts or misunderstandings or whatever's
      going not as well as it might.


      Ron Jeffries
      To be on the wire is life. The rest is waiting. --Karl Wallenda
    • 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. :-)


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