user requirements vs business requirements

13 May 2005 - 4:01pm
9 years ago
3 replies
3609 reads
Billie Mandel
2005

Hi all -

Background to question: I had previously been working in an
environment where it was part of my job to collect *both* business
requirements *and* user requirements, and make sure my design
solutions addressed both. Now I have a new job, new project and a
full team, which includes product management.

The task at hand: Come up with a plan for gathering requirements for
the second version of the system. The requirements for version 1 were
collected by the product team, and it's not clear to me whether they
were differentiating at all between user requirements and business
requirements.

My question: How have you (or have you at all) gone about defining
"business requirements" gathering as opposed to "user requirements"
gathering, and how have you defined that line/divided the work between
IxD and product management?

Thanks,
- Billie

Comments

13 May 2005 - 4:11pm
mtumi
2004

This may sound naive, but I would think in a good company there would
be significant overlap between the 2. I would think that business
requirements would be a subset of the user requirements that are in
line with the market direction. If the company is growing the
product into new markets, then some part of the business requirements
will also not be requirements of the current users. I would think
the majority would be overlap though.

Michael

On May 13, 2005, at 5:01 PM, Billie Mandel wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi all -
>
> Background to question: I had previously been working in an
> environment where it was part of my job to collect *both* business
> requirements *and* user requirements, and make sure my design
> solutions addressed both. Now I have a new job, new project and a
> full team, which includes product management.
>
> The task at hand: Come up with a plan for gathering requirements for
> the second version of the system. The requirements for version 1 were
> collected by the product team, and it's not clear to me whether they
> were differentiating at all between user requirements and business
> requirements.
>
> My question: How have you (or have you at all) gone about defining
> "business requirements" gathering as opposed to "user requirements"
> gathering, and how have you defined that line/divided the work between
> IxD and product management?
>
> Thanks,
> - Billie
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

13 May 2005 - 4:55pm
Billie Mandel
2005

Well, yes - I agree. I suppose the question was unclear. What I'm
actually wondering about is process - whether product management
usually gathers user requirements, or should be doing so, in this
organization or in others, and others' opinions on how IxD can/should
work with product management in requirements gathering.

My suspicion is that in many companies, business and user requirements
are subsumed, and the designers are handed a unified set of
"requirements" that were collected from a primarily business frame of
mind and are therefore not comprehensive.

One way to improve upon that would be for designers to talk to
users/gather user requirements and for product folks to talk to
business people/gather business requirements. Are there other ways
IxD and product management could work together that you've seen or
used/that have worked or not?

Thanks,
-Billie

On 5/13/05, Michael Tuminello <mt at motiontek.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> This may sound naive, but I would think in a good company there would
> be significant overlap between the 2. I would think that business
> requirements would be a subset of the user requirements that are in
> line with the market direction. If the company is growing the
> product into new markets, then some part of the business requirements
> will also not be requirements of the current users. I would think
> the majority would be overlap though.
>
> Michael
>
> On May 13, 2005, at 5:01 PM, Billie Mandel wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > Hi all -
> >
> > Background to question: I had previously been working in an
> > environment where it was part of my job to collect *both* business
> > requirements *and* user requirements, and make sure my design
> > solutions addressed both. Now I have a new job, new project and a
> > full team, which includes product management.
> >
> > The task at hand: Come up with a plan for gathering requirements for
> > the second version of the system. The requirements for version 1 were
> > collected by the product team, and it's not clear to me whether they
> > were differentiating at all between user requirements and business
> > requirements.
> >
> > My question: How have you (or have you at all) gone about defining
> > "business requirements" gathering as opposed to "user requirements"
> > gathering, and how have you defined that line/divided the work between
> > IxD and product management?
> >
> > Thanks,
> > - Billie
> > _______________________________________________
> > Welcome to the Interaction Design Group!
> > To post to this list ....... discuss at ixdg.org
> > (Un)Subscription Options ... http://discuss.ixdg.org/
> > Announcements List ......... http://subscribe-announce.ixdg.org/
> > Questions .................. lists at ixdg.org
> > Home ....................... http://ixdg.org/
> >
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

19 May 2005 - 9:16pm
Lada Gorlenko
2004

BM> My question: How have you (or have you at all) gone about defining
BM> "business requirements" gathering as opposed to "user requirements"
BM> gathering, and how have you defined that line/divided the work between
BM> IxD and product management?

In my group, we run two workshops with a customer at the beginning of
each engagement:
- Business Usability Needs (BUN) and
- Roles and Goals (R&G).

BUN participants are decision makers and stakeholders in the client
organisation. At the workshop, we identify a prioritised list of
distinct business goals (1-3 year outlook), where success of each goal
is tied to the changes of human behaviour. For example, for a
financial client these goals may be increased cross-sales of financial
products through branches, increased uptake of customer self-service
operations, etc.

For each goal, we define business benefit, constraints to success and
target audiences. For each audience, we identify audience value
proposition, success metrics, audience inhibitors, mechanism for
change, and key usability goals.

Usability goals are the differentiators that define our design
direction. They describe the most important qualities of the system
and set design priorities. Different systems (or even similar systems
for different clients) will have different profile of usability goals,
depending on the client's business goals and target audiences.
Currently, we work with a set of 10 usability goals, from which we ask
a client to identify up to three critical goals. For example, our set
includes:
- Adoption rate (increased usage of a discretionary system);
- Efficiency (increased human performance, such as speed and
productivity);
- Compliance (reduced legal liability);
- Learnability (reduced need for training and training time);
- Appeal (increased emotional response to a design).

Business goals together with usability goals give us a pretty good
picture of business requirements.

R&G workshop involves both stakeholders and "power users" of the
target system. The goal of the workshop is to identify a list of
distinct audience roles with an interest in the system (one level
below target audiences identified previously). For each role, we
describe demographic profile, education, experience, social, business,
economic factors, as well as personal and professional goals. For each
goal, we then define key tasks, identify enablers and inhibitors, and
describe physical and social context of use.

Typically, both workshops are conducted by the same two people who will
later lead user research and product design activities. Both workshops
address different requirements, but tie them together very
efficiently.

Lada

Syndicate content Get the feed