Agile methodologies for discovering user needs

15 Feb 2008 - 9:05pm
6 years ago
7 replies
882 reads
oliver green
2006

Hi All,

We are in the discovery phase of the project, where we have absolutely no
idea what the user needs are. There is limited time and resources this we
cant conduct ethnographic studies. What would be the best set of "agile"
methodologies that can be used to start the process?

Thanks,
Oliver

Comments

16 Feb 2008 - 4:18pm
Daniel Williams
2005

Hi

User stories are one of the most common Agile methods for this.

If you type user stories into google you will find lots of information, but
it generally involves sitting down with the users to gather stories which
will form the basis of the product backlog.

During sprint 0 the user stories are usually quite high level and can be
broken down to the required level of detail during the development sprints.
A story will take the form of - As a <user type> I want <some feature> So
that <reason for the feature>. Index cards can be used and the user (or user
advocate / proxy user) is usually encouraged to write the stories themselves
under facilitation.

I have used them myself and I really like the approach for scoping out the
size of a piece of a work. However as a word of warning I probably wouldn't
use them if I did not have access to users and proxy users in later sprints
as they do require to be fleshed out in more detail during the development
sprints.

Hi All,

We are in the discovery phase of the project, where we have absolutely no
idea what the user needs are. There is limited time and resources this we
cant conduct ethnographic studies. What would be the best set of "agile"
methodologies that can be used to start the process?

Thanks,
Oliver
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

16 Feb 2008 - 7:50pm
Luis de la Orde...
2007

Hi Oliver,

Do you think it wouldn't be better to focus on an activity-oriented approach
instead of a goal-oriented one?

It seems to me that if a project gets to the point where no user data (be it
from a proxy user, a customer service employee, a marketing representative,
anybody who deals with users) is available, user needs as such cannot be
traced and translated into user needs and goals nor a system response for
the accomplishment of those goals can be created, for there are no
recognizable and factual users in first place. By default, I would have
switched to design something that works and caters for the accomplishment of
activities; bringing new users, which to me are unknown, from beginners to
intermediate level quickly.

Given that user data is collected as this first activity-oriented release is
used by people, the users' needs and goals would start to be defined as
users start to materialise. Then, a second more goal-oriented user-centric
release would ensue.

I believe the Agile factor would serve with the iterative and evolutionary
process of designing this system for a set of activities until user needs
can be raised from minimally trustworthy sources.

Do you guys think I would have lost an opportunity by following the approach
above?

Cheers,

Luis

We are in the discovery phase of the project, where we have absolutely no
idea what the user needs are.

17 Feb 2008 - 2:39am
White, Jeff
2007

Yes. :-)

On Feb 16, 2008 7:50 PM, Luis de la Orden Morais <luis at webalorixa.net> wrote:

>
> Do you guys think I would have lost an opportunity by following the approach
> above?
>

17 Feb 2008 - 7:44am
Stew Dean
2007

Hi Oliver,

I think it's rare not to have limited time to do user research. First,
and this may be obvious, use what resources you have to you. If you
are designing for an end customer then people who deal with end
customers on a regular basis will have a lot of the information you
need already distilled.

If you're looking to do some ethnographic studies then providing you
have some idea of the user base and someway to set up meetings (two
big things) then I would focus on one to one interviews lasting about
an hour each with as many as you can get really. Whilst user testing
stops being much use after about six folks the correct approach to one
to one interviews keeps on yeilding results much much longer. On one
project I was still finding useful information on interview number 30
(squeezed into a week and a half interviewing).

In terms of technique I find the key is not to 'rush to solution' -
that is don't go in there and ask 'so what do you want to see?'. For
example if you're developing a banking site then I would structure
each interview roughly like this. Start off by finding out about the
person, their rough background, age, what they do, a quick portrait of
who they are (this can be used later to replace composite personas).
Then you then explore the things they do with their bank - I stress
it's important to get the tasks that the users carry out and not focus
on what you're going to build. If they talk about online banking as
part of what they do that's great but think user tasks not tasks
related to the online bank.

Now what should happen is the user will have told you about who they
are and what they do. In a natural way you start to introduce
questions about such as what sources of information they use to make
decisions, what are the things that drive them crazy etc. - again
within the overall area of banking.

Finaly and I usualy do this in the last 15-10 minutes if the user
hasnt already lead upto it you talk about online banking - if they use
it (I'll talk more about that later), how they use it and towards the
end get their suggestions.

Now I've seen a lot of other folks do these kinds of interviews and to
start talking about features and functionality towards the final part
of an interview to some will appear crazy. I can assure you it's the
opposite. By the time you've got to details you will have a good
portrait of the user, have a picture of how the product fits into
their world, the tasks they carry out and how they already use the
product (if they do) and most of the time because they are thinking
about something that is part of their life will have already have
started talking about ways to make it better for them without
prompting.

If you go in there and ask them to carry out a task on a site and tell
you what you think (even with a five minute 'who are you' session') in
my view it feels more like a test of the user and less an exchange of
thoughts - this is the reason that given limited time I would always
go for the one to one interviews and would probably never see the need
for user testing!

Also I have seen user research where part of the recruitment criteria
is 'must have used the system'. Why? You're doing user research not
systems testing! It's the task you're interested in not what path they
use through an arbitrary solution.

>From these sessions you can then create real human profiles (I really
do recommend people avoid composites as they tend towards stereotypes
and are often just a bunch of assumptions rather than about real
users). You can also create user stories if people what those, I
personaly prefer more detailed task disagrams that can then be used to
create user journies relating to the final solution.

There's much more to my approach than I can fit in a short email but
it's based upon the problems I've seen with more traditional
approaches which are often take a lot of time, money and often colour
results or produce user research documents where it's impossible to
determine what is 'real' and what is just an assumption someone has
made up - the reason why I suggest not using personas if you don't
have real people. In my view if you've made up a name and put a
picture from google onto a persona it's already coloured and can be
misleading.

Cheers

Stewart Dean

On 16/02/2008, oliver green <oliverhci at gmail.com> wrote:
> Hi All,
>
> We are in the discovery phase of the project, where we have absolutely no
> idea what the user needs are. There is limited time and resources this we
> cant conduct ethnographic studies. What would be the best set of "agile"
> methodologies that can be used to start the process?
>
> Thanks,
> Oliver
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
Stewart Dean

17 Feb 2008 - 4:07pm
Luis de la Orde...
2007

Hi Jeff,

I am curious, how would you approach a project in which there is no data on
who the final users will be and, as it seems from the original question,
development has to start? I am assuming all the steps for some kind of user
research have been tried and no data could be collected either because the
product is novel or nobody in the organisation wants to risk.

Cheers,

Luis

========================
From: Jeff White

Yes. :-)

17 Feb 2008 - 7:39pm
White, Jeff
2007

Hey Luis,

You busted me! Apologies for my sarcastic comment. It wasn't directed
at you, but the notion of ACD, which is a frustrating one for me. I'll
spare the details so as not to risk starting a "what is ____"
conversation.

What I would do is have the agile team work on low ui cost system
features (the 'scaffolding' as we call in in my organization - DB
schemas, a stab at system architecture, etc) during the first sprint.
During this time, I would be out interviewing the targeted customers
for the product. By the time the second sprint starts, I would aim to
have research results ready to go for the team, and get going on more
tangible interface work. I would also be advocating for the practice
of a sprint zero for any new project, and trying to figure out why the
project was allowed to start w/o an understanding of the people who
will be using the darn thing. To me, it sounds like some evangelism
for user-centered design is in order.

Even if there are no server logs, customer service support logs, etc -
there should be an idea of what the product is going to be, what goals
exist, and a rough idea of who the audience will be. If that doesn't
exist, I'm afraid the project is in trouble before it begins. User
research can and should take place even if the product is novel, brand
new, etc.

It's difficult really to comment on this one as many details aren't
clear. My assumption, which could be completely wrong, was that it was
one of those "you just start coding, I'll go figure out what the users
want" type of scenario. Which sounds all kinds of alarms and puts me
right into the "institutionalization of usability" mindset.

Jeff

On Feb 17, 2008 4:07 PM, Luis de la Orden Morais <luis at webalorixa.net> wrote:
> Hi Jeff,
>
> I am curious, how would you approach a project in which there is no data on
> who the final users will be and, as it seems from the original question,
> development has to start? I am assuming all the steps for some kind of user
> research have been tried and no data could be collected either because the
> product is novel or nobody in the organisation wants to risk.
>
> Cheers,
>
> Luis
>
> ========================
> From: Jeff White
>
> Yes. :-)
>
>
>
>
>
>
>
>

18 Feb 2008 - 11:54pm
Luis de la Orde...
2007

Hi Jeff,

:)).

This sounds pretty good. I like the ACD approach but reading you, I agree
that one should push for the user discovery and try to exhaust the
possibilities.

Thanks for sharing this, your email goes straight to my clipping notebook!

Cheers,

Luis

What I would do is have the agile team work on low ui cost system
features (the 'scaffolding' as we call in in my organization - DB
schemas, a stab at system architecture, etc) during the first sprint.
During this time, I would be out interviewing the targeted customers
for the product...

Syndicate content Get the feed