2006/5/10, Jeff Patton <jpatton@...>:
> <warning - long response>
> June,
>
> Sorry I didn't get back to you right away.  I'm sure you understand

That's OK. I really appreciate your long and detailed response.

> how non-trivial the situation you describe is – and potentially how
> risky that makes giving advice.  But, although I've hesitated, I won't
> let it stop me.
>
> The pain point or problem I hear you wanting to solve is the large
> amount of time planners spend crafting this communication artefact to
> designers and developers – so I'll talk about that first.  Of course
> if you take a hard agile line with all this, you'd do everything you
> could to avoid the written communication.  You do that by seating the
> teams close together, by encouraging them to talk over a whiteboard
> whenever possible.
>
> But, this doesn't solve everything.
>
> The planner seems to be performing the role of an interaction designer
> [they invent what needs to be built and document the user interaction
> and what I think is the visual design].  Concurrently they perform the
> role of project manager.  Sounds tough.  Sounds like a lot of

They initially devise and propose the core idea of the service. They
do strategic planning for the web service also; thinking about the
positions of the web service in the company's whole web services
portfolio, SWOT analysis, benchmarking other rival services, sometimes
coming up with marketing plan and etc. And usually there is a process
that the planner should do the presentation in front of executives to
persuade them into allowing the service.

> responsibility for one person.  In support of the interaction design
> work, they'll still need to work through somehow what the application
> should look and behave like.  They'll need to model with cards, draw
> pictures on whiteboards, build and test paper prototypes.  So, they
> still need to build something to contain all their own thoughts – even
> if it isn't powerpoint.  That'll take time.
>
> And, if we encourage the planner to talk more over the whiteboard, and
> over their paper prototypes with the designers and developers, that's
> going to take lots of time.
>
> So, at the end of the day, we won't give the planners back any more
> time – they'll be spending as much or more, but we may reduce some
> significant risks of miscommunication caused by reliance on paper
> documents.  In addition, I think people are ultimately happier when
> they can talk… but does this organization place value on "happy"?  Do
> they perceive any pain caused by miscommunication?
>
> As far as a documentation mechanism goes, right now, I believe
> powerpoint works as well as anything.  These days I spend more of my
> life than I want to admit building powerpoint storyboards.  Part of
> the reason I prefer it over potentially other tools is that I can
> control the fidelity a little bit.  By that I mean I can make very
> realistic UI when I think the situation demands it, or I can paste in
> and manipulate whiteboard photos when they're sufficient – and lots of
> points in between.  The point is I control the fidelity.  But, it
> doesn't seem like your planners are working with that "fidelity knob".
>  Could they be?  Would it save them time?

Enlightening! I never thought I could lower the fidelity in the
power-point. Of course, we could even use varying levels of fidelity
in a same power-point file, depending on the significance and needs.

I did some instruction on paper prototyping to a few teams(developer
teams and planner teams), and they were very interested in the
technique and Guindon's idea of opportunistic design(top-down and
bottom-up).

I totally agree that fidelity knob is very important. Thanks for
pointing this out.

>
> What does come to mind is that the scale of the operation you describe
> indicates that building a healthy _community of interest_ is in order.
>  By that I mean planners need to start regular collaboration with each
> other about how they do their job.  They need to share techniques,
> document and share interaction patterns, basically have the
> opportunity to collaborate with each other about how to get better at
> what they do.  Does this sort of opportunity for planner collaboration
> exist in the organization?  If not, could it?

I am trying to nudge in. With a few teams, I came to the point where
the planner team and developer team became willing to collaborate
(like agile planning) but still the designer dept is the problem.
There is a political issue, and a mentality issue.


>
> Seems like planners could also work in small teams – dividing up work
> and building these prototypes faster.  I've seen many organizations
> that have a design team that feeds and collaborates with development.
>  Whether they believe they are or not, the BA teams we use at

What are the BA teams?

> ThoughtWorks on projects function as a design team.  They collaborate
> and take collective responsibility for the functionality of the
> software, the artefacts they hand to development, and the day to day
> communication with development.  Could planners work in 2-3 person
> teams?  Would that help them move faster?

They could in some fortunate teams, and it would make them move
faster. But there are planner teams that take responsibility for
almost 100 services(24 x 7) with 10 people, each one serving 10
services. They make a new event for their services, plan renewal ,
resolve customer dissatisfaction and etc. For such a team, that kind
of move might not be feasible, well, in the shorter term

>
> Now, the things that make me twitchy – problems I sense but problems
> you didn't express:
>
> How does the planner determine what was needed?  How does he research
> and understand his users and their needs?  How does he validate his
> solution is indeed a good one?  Seems his life is so dominated by
> building powerpoints to keep the project running that he may have
> little time to determine if the resulting product is going to be a
> good one.  That scares me.  Issues there would manifest themselves as
> projects being completed on time, but end users and customers not
> liking what was built.  Does that happen?
>

I would say yes. I think they do mostly speculative researches.
Conceptual design?

> I'm twitchy about how little the planners seem to collaborate with
> anyone on what they doe – end users, developers, each other.  I'm
> always suspicious of solutions arrived at by individuals working in
> isolation with little context on which to solve their problems.
>
> What do you mean by designers?   [or did you say and I missed it?]

They are graphic designers. Planners plan the service, developers
implement the "blue-print" and designers do all the artistic parts,
like drawing jpg images, choosing specific colors for buttons, and
even coding html. They have not much room to consider usability,
information architecture, and all the luxury, but they are always
concerned about aesthetics, I guess.

Oh, the mentality problem I mentioned above, is that they are worried
if their desiging skill would lag or even deteriorate when they join
to become a whole team with developers and planners. They are some
designers who belong to a task force (with developers and planners in
the same room) but their pride is very low and they consider they are
there because their design skill is not professional enough. They want
to be with their kinds. They want to form a professional group.

> Are they designing the inside of the system – the architecture-y stuff
> – or the outside if the system – the visual and interaction design?

Outside.

> My guess is the former – not the latter.  If that's the case, based on
> what I'm hearing as constrained collaboration between them and
> developers, I suspect problems come out of that too.
>
> Finally, the last piece of advice I could give is think about how
> things would look if they were better.  What would things look like if
> problems were solved?  Then given that mental picture of the solution,
> what's the first tangible thing you can do/change you can make to move
> towards it?
>
> In the future do planners simply spend less time doing powerpoint work
> because they have a cool prototyping tool?  This brings me back to one
> of the first things I asked – what really is the problem here?  Is
> this really about saving the labour costs/time spent by the planners?
>  No offence to the planners – but who cares?  If you saved them 25% of
> their time, would that be significant to the company you work for?
> Might the company them be tempted to fire 25% of the planners?  The
> net result being that their life really isn't any better.  Look deeper
> to what the problem really is here.  Does it take to long to build
> product?  Is the product quality low?  Is it too expense to build
> products vs. your competition – do you need to reduce costs overall?
> Where is the pain coming from?
>


These are good questions.

I started coaching a new team with developers and planners (haven't
yet figured out to have the designer participate, and they are
thinking about working without a designer as far as they can get --
they think the political problem is too difficult to solve) and their
morale is very high. The team is working very agile using agile
usability techniques.

The problem is other teams.

> Hope that give you some more things to think about – and potentially
> some more questions to ask.

Thank you. I will keep in my mind those questions and report the result later.

>
> Thanks for posting this here to make the discussion public.
>

Your welcome. Thank you again for your response.

June

> -Jeff
>
> --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
> >
> > Following is email I sent to Jeff but I suppose it didn't make it to
> > him. I think it would be better to post it to a larger audience and
> > ask for help.
> >
> > ---------- Forwarded message ----------
> > From: June Kim
> > Date: Apr 19, 2006 5:08 PM
> > Subject: On the Communication between Planner, Designer, and Developer
> > [snip]
> >
> > BTW, I just want to ask some comments from you. I would greatly
> > appreciate your opinion or any reference you could afford me.
> >
> > As I told you I am coaching a few major web portal companies in Korea.
> > They have half a thousand developers and a few hundreds of designers
> > and planners. Oh, the job title, "planner". I think you are
> > unfamiliar with that job title. In Korea, we call those people who
> invent
> > and plan the web service(product manager?) as planners. They invent
> > the concepts and ideas and then draw storyboards and sometimes
> > organize the team and arrange the schedule, being the mediator between
> > designers and developers.
> ...
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

At 06:41 AM 5/11/2006, Adrian Howard wrote:
>Oh yes, I quite agree. It's more a question of nomenclature. Once you
>add a bunch of application specific detail to them is it really right
>to carry on calling them patterns? Haven't they then lost the generic
>nature that the name implies?

I guess I was thinking about large applications, where design elements
(such as date input or user login) may repeat themselves multiple times in
a variety of contexts. I would think patterns would be ideal in this scenario.

I agree that for small applications, it's probably overkill. But for a
suite of small applications, it could be useful.

Jared


Jared M. Spool, Founding Principal, User Interface Engineering
510 Turnpike Street, Suite 102, North Andover, MA 01845
978 327-5561   jspool@...  http://www.uie.com
Blog: http://www.uie.com/brainsparks

Leina,

For simplified explanation, I recommend the two articles by Rajkumar and
Waite at http://www.slis.indiana.edu/faculty/yrogers/hci_theory.html. These
do not tie in to agile design but are good summaries. I am working on a
paper on the subject and will share it with this list when complete. I am
also teaching a class on activity modeling at Architecture and Design World
in Chicago, 17-20 July.

--Larry Constantine, IDSA

--- In agile-usability@yahoogroups.com, leina elgohari
<leina_elgohari@...> wrote:
>
> Hello Jeff,
>   A very well written article.
Thank You!

> However are you missing a trick here?
>   I do remember someone saying that Activity Theory could be the
answer to your problem.

I generally try to write from some center of experience - before I
suggest that someone use user scenarios and give a little guidance on
how, I'd better have written them myself on several projects in
several contexts and have a some founded belief that they deliver
benefits and some tactical advice on how to get started.

Activity theory is an interesting thing on the horizon for me.  Links
like those Larry just posted will help me get up to speed on the
subject.  If I can get the basics into my head of hwo it works, I can
then come of with something tactical I can do on a project to
leverage activity theory.  Either that or steal some of the
techniques that someone like Larry will likely publish shortly. ;-)

So, I ignored activity theory because I just didn't have anything
sensible to say about it.

Does anyone listening have a story about how leveraging activity
theory afforded them the opportunity to do something tactically
different on a particular project?

Thanks,

-Jeff

Learn new, innovative agile approaches at the Better Software
Conference & EXPO...

Characterized by lightweight processes and short, iterative
delivery cycles, Agile development has revolutionized the
software industry to keep up with the rapidly changing nature
of the Web-based economy. Agile development practices respond
positively to the inevitable changes that occur in software
projects and stress the value of collaboration between the
development team and the customer.

Gain access to leading industry experts delivering the latest
agile techniques at the Better Software Conference & EXPO.

**************************************************************
            BETTER SOFTWARE CONFERENCE & EXPO 2006
             June 26-29, 2006 * Las Vegas, Nevada
                http://www.sqe.com/bsce6agile

                Development Lifecycle Practices
  AGILE DEVELOPMENT | PLAN-DRIVEN DEVELOPMENT | TESTING & QA
      SECURITY & SPECIAL TOPICS | MANAGING PROJECTS & TEAMS
            | PROCESS IMPROVEMENT & MEASUREMENT |

Conference Web site:  http://www.sqe.com/bsce6agile
Conference Brochure:
http://www.sqe.com/downloads/bettersoftwareconf.pdf
Register Now:         http://www.sqe.com/bscereg

For more information, call 888-268-8770 or 904-278-0524.

Register now and save $200! --> http://www.sqe.com/bscereg

**************************************************************
                     AGILE HIGHLIGHTS

--------------------------------------------------------------
KEYNOTES
http://www.sqe.com/bettersoftwareconf/keynotes.asp
--------------------------------------------------------------

- Agile Productivity Metrics
   Michael Mah, QSM Associates

--------------------------------------------------------------
IN-DEPTH, ONE-DAY PRECONFERENCE TUTORIALS AND WORKSHOPS
http://www.sqe.com/bettersoftwareconf/tutorials.asp
--------------------------------------------------------------

- Introduction to Agile Practices
   Robert Martin, Object Mentor

- Scrum: Project Management for Agile Software Development
   Jean Tabaka, Rally Software Development Corporation

- Test Automation for Agile Development
   Linda Hayes, Worksoft, Inc

- Agile Retrospectives: A Team Leader's Guide
   Esther Derby, Esther Derby Associates, Inc.

- Use Cases for Agile and Traditional Development
   Alistair Cockburn, Humans and Technology

- Agile Estimating and Planning
   Mike Cohn, Mountain Goat Software

- FIT for Requirements Collaboration
   James Shore, Titanium I.T.

--------------------------------------------------------------
CONCURRENT SESSIONS
http://www.sqe.com/bettersoftwareconf/sessions.asp
----------------------------------------------------------------

- Risk Management on an Agile Project
   Michele Sliger, Rally Software Development

- Fishing for Requirements in an Agile Project
   Jennitta Andrea, clearstream Consulting, Inc.

- Leadership--The Forgotten Element of Agile Development
   Michael Portwood, Spectra Intelligent Marketing

- Agile Development and Its Impact on Productivity
   David Garmus, The David Consulting Group

- Even the Best Get Stuck: Transitioning to Agile Development
   Alex Pukinskis, Rally Software Development

**************************************************************

Hi everyone:

I was a CHI a few weeks ago, and at the panel on Agile Development
there were some very interesting discussions.
I've been mulling over some issues since then, and have a question for
you to
consider:

Q: Where and how, in the UCD process,
      should *business* requirements be determined?

When I say "business", I mean the kinds of things that are not primarily
driven
by end-users, but are critical for the success of the system.

When I say "requirements", I mean to be inclusive and understanding of
how flexible and evolving that can be.

When I say "should",  I am interested in your views of what is done,
what processes say should be done, and what you think should be done.

Anyway, I'd appreciate seeing your answers and comments.

Cheers
Robert Biddle

Robert Biddle wrote:
> Q: Where and how, in the UCD process,
>      should *business* requirements be determined?
>
> When I say "business", I mean the kinds of things that are not primarily
> driven by end-users, but are critical for the success of the system.
>

Hi, Robert. That's an interesting question.

I'm having trouble understanding the distinction you're drawing here. It
seems to me that when making software in a business context, business
requirements and user requirements are intertwined, both  ways of
expressing the same idea.

If we are in the business of making software that serves our users,
shouldn't we always try to keep in mind the business, the software, and
the users?

Or are you drawing a distinction here between the primary users of
software (customers) and secondary users (like sysadmins)?

Thanks,

William

Business stakeholders have goals that are unrelated to
user goals.

For example, I'm working on a system to manage the
development of garments. During the design process,
many changes are made to the design of the product.
(Sound familiar? :-)

- Business stakeholders want to capture and measure
the volume of change.

- End users care not one whit about such measurements.
Instead, they must cope with each change directly.

A system designed to support only one of these goals
is incomplete at best. At worst, it services one goal
in a way that makes it impossible to serve the other
one.

JS

--- William Pietri <william@...> wrote:

> I'm having trouble understanding the distinction
> you're drawing here. It
> seems to me that when making software in a business
> context, business
> requirements and user requirements are intertwined,
> both  ways of
> expressing the same idea.

--- In agile-usability@yahoogroups.com, Robert Biddle
<Robert_Biddle@...> wrote:

> Q: Where and how, in the UCD process,
>      should *business* requirements be determined?
>
> When I say "business", I mean the kinds of things that are not
primarily
> driven
> by end-users, but are critical for the success of the system.
>

Someday when I write a book - which I hope to be someday in my
lifetime, this is one of my focal issues.  It's impossible for me to
separate the work that a BA [business analyst] does from the work a
user centered designer does.  To over simplify I often see BAs
concerned with the needs of the business, UCD people concerned with
the needs of the user.  That's not to say that BAs aren't concerned
with users or UCD people aren't concerned with business - but just
their area of emphasis and bias is different - and the questions they
ask and techniques they use reflect it.  And, neither approach by
themselves seems balanced enough to end up with good overall software
requirements.

Alistair Cockburn has pounded in to me that a use case always serves
at least 2 people - one might be the primary actor, the person behind
the keyboard, the other is at least one stakeholder not at the
keyboard who's interests get guaranteed - usually by the system.

I don't think most people use software for pure enjoyment - that
they're generally doing so for business interests – either their own
and/or the interests of their employers.  Basically there's always
interest to guarantee outside the immediate needs user and use.

So, coming to the point, if a use case documents the interaction
between a human and a computer, and that interaction motivates user
interface design, and that interaction needs to guarantee the
interests of business, it sort of makes them inseparable at an
interaction design level.

But if one needs to be sort of first, or at least discovered first,
it's likely business interests.  Since it's business interest that
form the business case for building the software, which motivates
choosing particular user constituencies to support, and in the case
of business software used to automate business processes, the high
level workflow of people using the software.  Without business
requirements there aren't user requirements.  Furthermore without
user needs being met, often business needs aren't met.

In the context of work ThoughtWorks does for a its QuickStart
analysis efforts, we focus first on the business case, then the
business process, then the user constituencies supported, then
individual user goals and tasks.  Then when working at the detail
level we focus on user tasks and business requirements
simultaneously – all of that meeting in user scenarios storyboarded
into low-fi UI prototypes.  Along the way always keeping in mind the
business case/business goals, and the individual user goals - and
what is often some tension between them.

This is a good line of discussion.  Thanks very much for posting!

-Jeff

So if I understand rightly, Josh, you're saying that my second
interpretation of Robert's question was the correct one. Namely, that he
was asking about different groups of people who use a system, some of
whom we call business users and some we call end users. Is that right?

I guess to me they're all users, so my answer to Robert's question would
be that I default to gathering information about everybody. However,
doing just-in-time requirements gathering for features whose order is
controlled by business goals means that I invest in understanding
different needs at different times.

William


Josh Seiden wrote:
> Business stakeholders have goals that are unrelated to
> user goals.
>
> For example, I'm working on a system to manage the
> development of garments. During the design process,
> many changes are made to the design of the product.
> (Sound familiar? :-)
>
> - Business stakeholders want to capture and measure
> the volume of change.
>
> - End users care not one whit about such measurements.
> Instead, they must cope with each change directly.
>
> A system designed to support only one of these goals
> is incomplete at best. At worst, it services one goal
> in a way that makes it impossible to serve the other
> one.
>
> JS
>
> --- William Pietri <william@...> wrote:
>
>
>> I'm having trouble understanding the distinction
>> you're drawing here. It
>> seems to me that when making software in a business
>> context, business
>> requirements and user requirements are intertwined,
>> both  ways of
>> expressing the same idea.
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
>
> So if I understand rightly, Josh, you're saying that my second
> interpretation of Robert's question was the correct one. Namely,
that he
> was asking about different groups of people who use a system, some
of
> whom we call business users and some we call end users. Is that
right?

No, I think Robert's talking about the business people paying for the
software.

If you're reading this post from the web you might see sponsored
links, links to other yahoo products, banner adds etc.  I, as a user,
have no strong desire to see those things.  The business paying for
the software however, thinks it important that I do.  They also
likely want to keep track of how many times I saw those links, and if
I click on them or not.  Although downstream there may be UI to
report on some of those aspects - so that does sort of make them
users.  But, just not right now for the user interface that I'm
looking at.

So mixed in with the UI are my concerns, and the people's concerns
who paid for the software.

-Jeff

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
>
> So if I understand rightly, Josh, you're saying that my second
> interpretation of Robert's question was the correct one. Namely,
that he
> was asking about different groups of people who use a system, some
of
> whom we call business users and some we call end users. Is that
right?

No, I think Robert's talking about the business people paying for the
software. 

If you're reading this post from the web you might see sponsored
links, links to other yahoo products, banner adds etc.  I, as a user,
have no strong desire to see those things.  The business paying for
the software however, thinks it important that I do.  They also
likely want to keep track of how many times I saw those links, and if
I click on them or not.  Although downstream there may be UI to
report on some of those aspects - so that does sort of make them
users.  But, just not right now for the user interface that I'm
looking at.   

So mixed in with the UI are my concerns, and the people's concerns
who paid for the software.

-Jeff

Hi William: Josh pretty much answered for me.

In the case of some "shrink-wrap" software, there might indeed be no
distinction.
But in much software developed, the people who commision the software
are not the end-users.
My bank is an example, so is my government, so is Amazon, etc. etc.
And my goals are not the same as those of my bank, my government,
Amazon, etc. etc.

The truth is: many of us are not in, as you say, the business of making
software that serves our users.
At least not only.
I think Larry Constantine sometimes points out that that an ATM that
serves only the user would dispense cash
and not debit their account! :-)

Cheers
Robert


William Pietri wrote:

> Robert Biddle wrote:
> > Q: Where and how, in the UCD process,
> >      should *business* requirements be determined?
> >
> > When I say "business", I mean the kinds of things that are not
> primarily
> > driven by end-users, but are critical for the success of the system.
> >
>
> Hi, Robert. That's an interesting question.
>
> I'm having trouble understanding the distinction you're drawing here. It
> seems to me that when making software in a business context, business
> requirements and user requirements are intertwined, both  ways of
> expressing the same idea.
>
> If we are in the business of making software that serves our users,
> shouldn't we always try to keep in mind the business, the software, and
> the users?
>
> Or are you drawing a distinction here between the primary users of
> software (customers) and secondary users (like sysadmins)?
>
> Thanks,
>
> William
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "agile-usability
>       <http://groups.yahoo.com/group/agile-usability>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        agile-usability-unsubscribe@yahoogroups.com
>       <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Well, note then that we are playing with the word "user". Many of the
people who commision software will never use it.
So to call the marketing executive a "class of user" seems a bit of a
stretch: their usage consists of commisioning the software
and collecting a big paycheque.
But of course your suggestions are reasonable.
And I repeat my question: how should this fit into UCD?
Cheers
Robert


Tobias Mayer wrote:

> Jeff,
>
> Aren't you just talking about different classes of users?  When
> capturing these requirements there need be no difference in the way
> the User Story is written, it would simply be a case of identifying
> the role "user" in the story.  To follow Mike Cohn's User Story
> template:
>
> As a <Marketing Exectutive for X> I want to <see a Banner Ad from a
> partner on every page> so that <the end user is tempted to click and
> thus generate reveue for X>.
>
> As a <Marketing Exectutive for X> I want to <see a record of each user
> click-through on a Banner Ad> so that <we can determine which partners
> provide the best value for X>.
>
> etc.
>
> The developers still have to design, write code and test these
> stories.  What is essentailly different?
>
> Tobias
>
>
>
> */Jeff Patton <jpatton@...>/* wrote:
>
>     --- In agile-usability@yahoogroups.com, William Pietri <william@...>
>     wrote:
>     >
>     > So if I understand rightly, Josh, you're saying that my second
>     > interpretation of Robert's question was the correct one. Namely,
>     that he
>     > was asking about different groups of people who use a system, some
>     of
>     > whom we call business users and some we call end users. Is that
>     right?
>
>     No, I think Robert's talking about the business people paying for the
>     software.
>
>     If you're reading this post from the web you might see sponsored
>     links, links to other yahoo products, banner adds etc.  I, as a user,
>     have no strong desire to see those things.  The business paying for
>     the software however, thinks it important that I do.  They also
>     likely want to keep track of how many times I saw those links, and if
>     I click on them or not.  Although downstream there may be UI to
>     report on some of those aspects - so that does sort of make them
>     users.  But, just not right now for the user interface that I'm
>     looking at.
>
>     So mixed in with the UI are my concerns, and the people's concerns
>     who paid for the software.
>
>     -Jeff
>
>
>
>
>
>
> SPONSORED LINKS
> Usability testing
>
<http://groups.yahoo.com/gads?t=ms&k=Usability+testing&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=Lq9LzH\
OR6YRi-lf0j4B6dw>
>  Usability
>
<http://groups.yahoo.com/gads?t=ms&k=Usability&w1=Usability+testing&w2=Usability\
&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=PVbhEkH6SIuzHM\
pGgwL25w>
>  Agile software development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+software+development&w1=Usability+tes\
ting&w2=Usability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.s\
ig=JG8w5gzRWtYA_eGc8BIx7A>
>
> Agile development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+development&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=D3toDT\
lyTOUpo9SpurF4ZA>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "agile-usability
>       <http://groups.yahoo.com/group/agile-usability>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        agile-usability-unsubscribe@yahoogroups.com
>       <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]
On Behalf Of Tobias Mayer
... Stuff deleted
As a <Marketing Exectutive for X> I want to <see a Banner Ad from a partner on
every page> so that <the end user is tempted to click and thus generate reveue
for X>.

--> IMHO, the <Marketing Executive> should not be called a user as he is NOT
using this page. In fact, this is a perfect example where something in the user
interface fulfills a business need but but not a user need (at least I could do
without most of these ads on the web sites that I visit). Thus, the business
requirement on the system and the user requirements are not the same. Agile
approaches seem to focus on business needs while UCD-oriented approaches
emphasize user needs.

Frank

Robert Biddle wrote:
> Hi William: Josh pretty much answered for me.
>
> In the case of some "shrink-wrap" software, there might indeed be no
> distinction.
> But in much software developed, the people who commision the software
> are not the end-users.
> My bank is an example, so is my government, so is Amazon, etc. etc.
> And my goals are not the same as those of my bank, my government,
> Amazon, etc. etc.
>

Then this still puzzles me. Why would those other people affected by
your system be less users of your software than the ones you call the
end users? When I'm building things I focus on what lives I touch, not
who touches the mouse.

The effect that software has is mediated in different ways (screen and
keyboard versus e.g., paper report or hallway discussion) for different
stakeholders, of course. But when it comes to collecting requirements,
I'm not inclined to order my efforts by proximity to the system. Instead
I start with the business goals and ask which audiences I have to
address first.

For example, if I'm writing code for for a climate control system, I
wouldn't start with the maintenance console, even if that would be my
main contact point with end users. Instead, I'd start with keeping
people comfortable, even though those people might never touch any UI.
Indeed, the ideal would be that they never touch UI. And that in turn
might require a very highly tuned maintenance UI, so that your average
janitor could run a sophisticated climate system. But that's a result,
not a starting point.

William

Frank Maurer wrote:
> From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]
On Behalf Of Tobias Mayer
> ... Stuff deleted
> As a <Marketing Exectutive for X> I want to <see a Banner Ad from a partner on
every page> so that <the end user is tempted to click and thus generate reveue
for X>.
>
> --> IMHO, the <Marketing Executive> should not be called a user as he is NOT
using this page. In fact, this is a perfect example where something in the user
interface fulfills a business need but but not a user need (at least I could do
without most of these ads on the web sites that I visit). Thus, the business
requirement on the system and the user requirements are not the same. Agile
approaches seem to focus on business needs while UCD-oriented approaches
emphasize user needs.
>

Hmmm... You might be using the page to read content. The authors use the
page to make money via publishing content. The executive uses the page
as inventory to sell, getting the money to pay the authors. The
advertisers buy part of the page because they want a slice of your
attention. And let's not forget the sysadmins, who need data from the
viewing of the page to make sure things are running smoothly.

I would agree that you could be called the primary user of the page, but
I think all of those people are users of the system. And in that the
system only works when everybody's needs are met, I have a hard time
privileging one class of needs over another.

I believe that agile methods see business needs and user needs as two
sides of the same coin. Or, more precisely, by creating a tight feedback
loop between business intention and user reaction, they relentlessly
seek synergy between the two, turning apparently zero-sum interactions
into positive-sum relationships.


William

Ok, so it sounds like this wasn't just about word choice, and that is
interesting to me.

So you think that with this wide idea of user, UCD is a complete
approach to determining
what the system should be: is that right?

If so, then my next question is: what kind of people should be doing
this? In other words,
is requirements analysis solely an HCI area?  Or how do you see, for
example, business analysts
fitting into this?

Cheers
Robert


William Pietri wrote:

> Robert Biddle wrote:
> > Hi William: Josh pretty much answered for me.
> >
> > In the case of some "shrink-wrap" software, there might indeed be no
> > distinction.
> > But in much software developed, the people who commision the software
> > are not the end-users.
> > My bank is an example, so is my government, so is Amazon, etc. etc.
> > And my goals are not the same as those of my bank, my government,
> > Amazon, etc. etc.
> >
>
> Then this still puzzles me. Why would those other people affected by
> your system be less users of your software than the ones you call the
> end users? When I'm building things I focus on what lives I touch, not
> who touches the mouse.
>
> The effect that software has is mediated in different ways (screen and
> keyboard versus e.g., paper report or hallway discussion) for different
> stakeholders, of course. But when it comes to collecting requirements,
> I'm not inclined to order my efforts by proximity to the system. Instead
> I start with the business goals and ask which audiences I have to
> address first.
>
> For example, if I'm writing code for for a climate control system, I
> wouldn't start with the maintenance console, even if that would be my
> main contact point with end users. Instead, I'd start with keeping
> people comfortable, even though those people might never touch any UI.
> Indeed, the ideal would be that they never touch UI. And that in turn
> might require a very highly tuned maintenance UI, so that your average
> janitor could run a sophisticated climate system. But that's a result,
> not a starting point.
>
> William
>
>
>
>
> SPONSORED LINKS
> Usability testing
>
<http://groups.yahoo.com/gads?t=ms&k=Usability+testing&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=Lq9LzH\
OR6YRi-lf0j4B6dw>
>  Usability
>
<http://groups.yahoo.com/gads?t=ms&k=Usability&w1=Usability+testing&w2=Usability\
&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=PVbhEkH6SIuzHM\
pGgwL25w>
>  Agile software development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+software+development&w1=Usability+tes\
ting&w2=Usability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.s\
ig=JG8w5gzRWtYA_eGc8BIx7A>
>
> Agile development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+development&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=D3toDT\
lyTOUpo9SpurF4ZA>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "agile-usability
>       <http://groups.yahoo.com/group/agile-usability>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        agile-usability-unsubscribe@yahoogroups.com
>       <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Hi, Robert. You ask more good questions. Here I should explain that I'm
not primarily a UI designer, although I've certainly done some of that
and am a vigorous advocate for usability. My answers come more from my
experience as a process consultant and as a professional interested in
making excellent software.

Robert Biddle wrote:
> Ok, so it sounds like this wasn't just about word choice, and that is
> interesting to me.
>
> So you think that with this wide idea of user, UCD is a complete
> approach to determining
> what the system should be: is that right?
>
> If so, then my next question is: what kind of people should be doing
> this? In other words,
> is requirements analysis solely an HCI area?  Or how do you see, for
> example, business analysts
> fitting into this?
>

I believe that no approach to determining requirements is -- or can be
-- complete. Agile methods acknowledge this by shipping early and often.
You try to gather the right people, you take your best guess at what to
build, and then you see what you've missed. And then you do it again and
again.

As to selecting a team, I'm relatively uninterested in formal roles or
titles, and instead focus on what knowledge and experience people have
and how that relates to the purpose of the project. For most projects, I
think deciding what to build requires input from a range of specialties.

I could see putting the steering wheel in the sole hands of HCI experts
if the project were an HCI research project. I could see that business
analysts could be in sole charge if the project were, say, an automated
trading system with no UI.

But in the general case, where you have multiple stakeholders, each of
which must be satisfied for success, I think you need a team of people
of different backgrounds. So in the case of the simple on-line magazine
mentioned elsewhere, I might look for a HCI/UI person; a software
designer with experience in high-volume web sites; a businessperson with
experience in publishing and ad sales; a writer, perhaps; and hopefully
somebody with on-line community experience. Where I couldn't get a
particular person, I would be especially assiduous in learning about and
representing those views, and getting early feedback in those areas.

To me, a well-designed product is one that beautifully balances all the
concerns appropriately. And generally, I think that takes a team. Not
just a group, mind you, but a team.

William

Ok, interesting.
So what do you think about the customer role in XP?
And how, in the approach you advocate, would the planning game work?
That is to say, in playing the planning game, who would have the
customer role?
Cheers
Robert

William Pietri wrote:

> Hi, Robert. You ask more good questions. Here I should explain that I'm
> not primarily a UI designer, although I've certainly done some of that
> and am a vigorous advocate for usability. My answers come more from my
> experience as a process consultant and as a professional interested in
> making excellent software.
>
> Robert Biddle wrote:
> > Ok, so it sounds like this wasn't just about word choice, and that is
> > interesting to me.
> >
> > So you think that with this wide idea of user, UCD is a complete
> > approach to determining
> > what the system should be: is that right?
> >
> > If so, then my next question is: what kind of people should be doing
> > this? In other words,
> > is requirements analysis solely an HCI area?  Or how do you see, for
> > example, business analysts
> > fitting into this?
> >
>
> I believe that no approach to determining requirements is -- or can be
> -- complete. Agile methods acknowledge this by shipping early and often.
> You try to gather the right people, you take your best guess at what to
> build, and then you see what you've missed. And then you do it again and
> again.
>
> As to selecting a team, I'm relatively uninterested in formal roles or
> titles, and instead focus on what knowledge and experience people have
> and how that relates to the purpose of the project. For most projects, I
> think deciding what to build requires input from a range of specialties.
>
> I could see putting the steering wheel in the sole hands of HCI experts
> if the project were an HCI research project. I could see that business
> analysts could be in sole charge if the project were, say, an automated
> trading system with no UI.
>
> But in the general case, where you have multiple stakeholders, each of
> which must be satisfied for success, I think you need a team of people
> of different backgrounds. So in the case of the simple on-line magazine
> mentioned elsewhere, I might look for a HCI/UI person; a software
> designer with experience in high-volume web sites; a businessperson with
> experience in publishing and ad sales; a writer, perhaps; and hopefully
> somebody with on-line community experience. Where I couldn't get a
> particular person, I would be especially assiduous in learning about and
> representing those views, and getting early feedback in those areas.
>
> To me, a well-designed product is one that beautifully balances all the
> concerns appropriately. And generally, I think that takes a team. Not
> just a group, mind you, but a team.
>
> William
>
>
>
> SPONSORED LINKS
> Usability testing
>
<http://groups.yahoo.com/gads?t=ms&k=Usability+testing&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=Lq9LzH\
OR6YRi-lf0j4B6dw>
>  Usability
>
<http://groups.yahoo.com/gads?t=ms&k=Usability&w1=Usability+testing&w2=Usability\
&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=PVbhEkH6SIuzHM\
pGgwL25w>
>  Agile software development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+software+development&w1=Usability+tes\
ting&w2=Usability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.s\
ig=JG8w5gzRWtYA_eGc8BIx7A>
>
> Agile development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+development&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=D3toDT\
lyTOUpo9SpurF4ZA>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "agile-usability
>       <http://groups.yahoo.com/group/agile-usability>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        agile-usability-unsubscribe@yahoogroups.com
>       <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Robert Biddle wrote:

> I think Larry Constantine sometimes points out that that an ATM that
> serves only the user would dispense cash
> and not debit their account! :-)

Who me?

--Larry Constantine, IDSA

Robert Biddle wrote:

> Q: Where and how, in the UCD process,
>      should *business* requirements be determined?
>
> When I say "business", I mean the kinds of things that are not primarily
> driven
> by end-users, but are critical for the success of the system.
>
> When I say "requirements", I mean to be inclusive and understanding of
> how flexible and evolving that can be.
>
> When I say "should",  I am interested in your views of what is done,
> what processes say should be done, and what you think should be done.

As we have practiced usage-centered design, both user roles and tasks
(essential use cases) are prioritized on the basis of importance to the
business success of the application thus reflecting functional business
requirements as these relate to the user interface.

William Pietri wrote:

> I'm having trouble understanding the distinction you're drawing here. It
> seems to me that when making software in a business context, business
> requirements and user requirements are intertwined, both  ways of
> expressing the same idea.
>
> If we are in the business of making software that serves our users,
> shouldn't we always try to keep in mind the business, the software, and
> the users?
>
> Or are you drawing a distinction here between the primary users of
> software (customers) and secondary users (like sysadmins)?

As Josh Seiden points out, users, that is people who actually interact with
an application, are typically quite distinct from customers, who make the
decisions. Indeed, user priorities and customer priorities are very often at
odds.

Agreeing with Frank Maurer, both William Peitri and Tobias Mayer are using
the term "user" more broadly than is generally accepted among interaction
designers. A user interacts with a system. A marketing person with certain
goals for a system but who does not use it is a stakeholder but not another
class of user. The distinction is important because otherwise the design of
the user interface can become so muddied by multiple competing stakeholder
interests that the result is unusable, even if it reflects those stakeholder
interests.

--Larry Constantine, IDSA

Larry Constantine wrote:
> Agreeing with Frank Maurer, both William Peitri and Tobias Mayer are using
> the term "user" more broadly than is generally accepted among interaction
> designers. A user interacts with a system. A marketing person with certain
> goals for a system but who does not use it is a stakeholder but not another
> class of user.

That's a very plausible definition of user for people focused on
building human/computer interfaces, and I'm glad to run with it if you'd
like. We can substitute "audience" or "stakeholders" for the broader
definition I was using.

Note however, that such a definition of user is a redefinition from the
common sense of the word. The executive is using the product to make
money and build a brand. Even if he never touches it, he's using it and
is therefore a user of it. And I was deliberate in using the broad
definition. Why? in my view, part of the problem that motivated the
original question comes from conflict between people hewing too much to
specialties.


> The distinction is important because otherwise the design of
> the user interface can become so muddied by multiple competing stakeholder
> interests that the result is unusable, even if it reflects those stakeholder
> interests.
>

How could it be in the interests of any stakeholder to have an unusable
interface?


William

Robert Biddle wrote:
> Ok, interesting.
> So what do you think about the customer role in XP?
> And how, in the approach you advocate, would the planning game work?
> That is to say, in playing the planning game, who would have the
> customer role?

It works like it always should: via consensus.


There are two ways I'll explain it to clients depending on the
situation, but I feel like they converge functionally when they're
working well, so it's mainly a matter of approach.


One way is to make all of the people with valuable input on what to
build the "customer". There are many ways they can manage their
competing visions, but when it comes time to schedule work, they speak
with one voice.

The other is to make one person the customer, and the rest end up
advising, just like the development team does. Plans are proposed and
discussion ensues. As new facts and new perspectives come to light,
plans are rearranged. Eventually you get plans that everybody can live with.


As I said, these should converge. Why? Because you have one team making
one product. Eventually, you all ship something and you all have to live
with it.

The first meeting is rarely smooth, but that's fine. Every week you meet
and come up with a new plan. Every week you see the results and try them
out. In my experience people always get pretty good at it sooner or
later. Maybe I've just been lucky, but I don't think so.



William

>
>  Q: Where and how, in the UCD process,
>       should *business* requirements be determined?
>
>  When I say "business", I mean the kinds of things that are
>  not primarily driven by end-users, but are critical for the
>  success of the system.

I'm coming in a little late on this, but here are my 2 cents on business
goals.

You forgot to define 'success'.  :-)
Success can be that the software makes money for the company creating
it, particularly for shrink-wrapped software.

I know a company (NOT the one I work for) that puts out absolutely
crappy software that is unusable.  The company is successful because
they price it very cheaply ($99) and make sure that they have checklists
of all the main features that the useable ($2000) software has.  Novice
users buy this software, realize too late that it doesn't actually work,
then buy the higher priced software. This is a business decision of this
company and it makes the company successful.

Business goals don't have to be that slimy, of course.

A company's business goal might be to release the software at a major
trade show.  The UCD person has to work within this goal to be
successful.  The end-user doesn't care when the software is released,
but it makes a huge difference to the company.

Or, a company business goal might be to produce innovative UI that can
be patented.  The end-users may not care about patented UI.

Or, a company business goal might be to release a tempting low-end
version that specifically limits what end-users can do so that they will
buy the higher-end (more costly) version.

With these kinds of business goals, they need to be determined at the
initial planning stage (market validation) and communicated to the whole
team so that everyone is working towards the same goals.

Lynn

Hi Lynn!

So picking up on this:

"With these kinds of business goals, they need to be determined at the
initial planning stage (market validation) and communicated to the whole
team so that everyone is working towards the same goals."

With this approach, how do you interact with the business people to get
their agreement
on whether your work looks like meeting their goals?
What happens if the business goals change?

Cheers
Robert


Lynn Miller wrote:

> >
> >  Q: Where and how, in the UCD process,
> >       should *business* requirements be determined?
> >
> >  When I say "business", I mean the kinds of things that are
> >  not primarily driven by end-users, but are critical for the
> >  success of the system.
>
> I'm coming in a little late on this, but here are my 2 cents on business
> goals.
>
> You forgot to define 'success'.  :-)
> Success can be that the software makes money for the company creating
> it, particularly for shrink-wrapped software.
>
> I know a company (NOT the one I work for) that puts out absolutely
> crappy software that is unusable.  The company is successful because
> they price it very cheaply ($99) and make sure that they have checklists
> of all the main features that the useable ($2000) software has.  Novice
> users buy this software, realize too late that it doesn't actually work,
> then buy the higher priced software. This is a business decision of this
> company and it makes the company successful.
>
> Business goals don't have to be that slimy, of course.
>
> A company's business goal might be to release the software at a major
> trade show.  The UCD person has to work within this goal to be
> successful.  The end-user doesn't care when the software is released,
> but it makes a huge difference to the company.
>
> Or, a company business goal might be to produce innovative UI that can
> be patented.  The end-users may not care about patented UI.
>
> Or, a company business goal might be to release a tempting low-end
> version that specifically limits what end-users can do so that they will
> buy the higher-end (more costly) version.
>
> With these kinds of business goals, they need to be determined at the
> initial planning stage (market validation) and communicated to the whole
> team so that everyone is working towards the same goals.
>
> Lynn
>
>
>
>
> SPONSORED LINKS
> Usability testing
>
<http://groups.yahoo.com/gads?t=ms&k=Usability+testing&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=Lq9LzH\
OR6YRi-lf0j4B6dw>
>  Usability
>
<http://groups.yahoo.com/gads?t=ms&k=Usability&w1=Usability+testing&w2=Usability\
&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=PVbhEkH6SIuzHM\
pGgwL25w>
>  Agile software development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+software+development&w1=Usability+tes\
ting&w2=Usability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.s\
ig=JG8w5gzRWtYA_eGc8BIx7A>
>
> Agile development
>
<http://groups.yahoo.com/gads?t=ms&k=Agile+development&w1=Usability+testing&w2=U\
sability&w3=Agile+software+development&w4=Agile+development&c=4&s=93&.sig=D3toDT\
lyTOUpo9SpurF4ZA>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "agile-usability
>       <http://groups.yahoo.com/group/agile-usability>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        agile-usability-unsubscribe@yahoogroups.com
>       <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

On May 19, 2006, at 9:54 AM, William Pietri wrote:

> One way is to make all of the people with valuable input on what to
> build the "customer". There are many ways they can manage their
> competing visions, but when it comes time to schedule work, they speak
> with one voice.
>
> The other is to make one person the customer, and the rest end up
> advising, just like the development team does. Plans are proposed and
> discussion ensues. As new facts and new perspectives come to light,
> plans are rearranged. Eventually you get plans that everybody can
> live with.

This is a bit off-topic - sorry.

1. I've been the customer / product director on two projects, one
going on now. I find that I spend a lot of time making small
decisions, be they GUI-related or "functional". How does that work
with a customer team? Do programmers ask the most appropriate
immediately available customer? I'd hate to have decisions slowed
down because only one person can make decisions about GUI tweaks or
because consensus among the customer team has to be reached rather
than assumed.

2. The customer / programmer relationship often seems to me a
personal one. Rather than serving the company, the User, the stock
price, or some other abstraction, the programmers want to make that
person, Nickieben, the one sitting in that chair over there, happy.
Provided Nickieben is making decisions that serve the company, User,
etc., the personal relationship is an advantage, I think.

Do the programmers form the same attachment to a team-that-speaks-
with-one-voice as they do to a human who really truly has only one
set of vocal cords?

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.testing.com/cgi-bin/blog