Re: [agile-usability] Where the BA Ends and the Usability Specialist Begins?
- Sure, sure. Don't let the symantics of the question
get in the way. Take it as a given that the project
team is focused on supporting the client as well as
the user. We're actually a very cooperative group
simply seeking a workable methodology that doesn't
duplicate effort yet provides everyone with what they
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 +
--- Ron Jeffries <ronjeffries@...> wrote:
> Hello Andrea, thanks for the explanation. You'llAndrea L Spray
> find that my
> thoughts and yours do not line up very well, at
> least not yet. On
> Saturday, August 19, 2006, at 2:06:10 PM, you wrote:
> > The project in question here is a redesign of a
> > content-heavy, marketing website which
> incorporates a
> > few web apps. The primary business client first
> > contacted an Engagement Manager expressing an
> > in the project. The Engagement Manager gathered
> > high level requirements and worked with a
> > Specialist and a Technical person to come up with
> > very rough estimate & proposal. This all happened
> > within 1 week.
> > For this project we began with conducting focus
> > and usability labs on the existing website. There
> > a group of stakeholders, beyond the client who is
> > footing the bill, that are interested in this
> > A subgroup of those stakeholders were volunteered
> > work with the project team to move the redesign
> > forward.
> > The project team has since consisted of a
> > Specialist (that's me!), 3 business clients (each
> > representing a different area of the business),
> and a
> > visual designer. In addition to the Usability
> > Specialist role, I am also acting as the BA/PM.
> > I essentially used Jesse James Garrett's Elements
> > User Experience process to guide our work from
> > We began by establishing high level goals,
> > user needs (from usability labs and focus groups)
> > site objectives, defining scope and information
> > architecture.
> > Here's where there starts to be a problem. While
> > working through wireframes (information
> > portion of the process), we begin brainstorming
> > new functionality. I don't want to carry this
> > visioning too far without confirming that our
> > are actually feasible and whether the cost of
> > implementation is in the range of $1, $1,000, or
> > $100,000. $10,000 might be doable but $100,000
> > be a show-stopper. So at this point I bring in a
> > Business Analyst to begin to chase down some of
> > technical requirements and rope in the appropriate
> > technical folks who can answer for feasibility.
> > phew.
> > that was long, my apologies.
> > Does this help? I probably inappropriately call
> > type of project Agile-esque, but the question of
> > line between BA and Usability Specialist has
> > up in our truly Agile projects as well and I think
> > that its the same issu
> Well, Andrea, all I can really say is that this
> appears to be some
> new kind of Agile that I wasn't previously familiar
> with. The Agile
> methods I know about all start with software in the
> first week or
> I would also think that, in an Agile project, as I
> understand them,
> the question "the line between" would be indicative
> of a problem.
> Agile projects aren't about dividing, they're about
> coming together,
> at least as I perceive them. I would think, as a
> rule, that the
> business analyst and usability specialist would be
> support people
> to the "customer" or "product owner".
> I would furthermore anticipate that neither, the
> customer / product
> owner, nor the business analyst, nor the usability
> specialist would
> be the persons to go to to get an estimate of the
> cost of building
> something. I'd think that would be the job of the
> Ron Jeffries
> The rules are ways of thinking, not ways to avoid
Join the Design + Usability Yahoo Group: http://groups.yahoo.com/group/DesignandUsability/
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. :-)