Re: [agile-usability] Where the BA Ends and the Usability Specialist Begins?
- 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 questionSemantics: the study of meaning. Don't let the meaning of the
> get in the way.
question get in the way. Check, I'll try to do that ... ;->
> Take it as a given that the projectIn Agile methods, the words "customer" or "product owner" refer to
> team is focused on supporting the client as well as
> the user.
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 groupSure ... it never entered my mind that you weren't. I think perhaps
> simply seeking a workable methodology that doesn't
> duplicate effort yet provides everyone with what they
I failed to make my meaning clear.
> I'll re-iterate that I am not claiming our approach toI need a little more help understanding the problem first, I'm
> 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?
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.
To be on the wire is life. The rest is waiting. --Karl Wallenda
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
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!
From: firstname.lastname@example.org [mailto: email@example.com ] On Behalf Of Joshua Seiden
Sent: Thursday, August 24, 2006 6:17 PM
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
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. :-)