New IxD Techniques to Try in 2007

20 Dec 2006 - 12:11pm
7 years ago
57 replies
3752 reads
Dan Saffer
2003

Hi!

I'm putting together a list of new IxD methods and techniques I've
found that I want to try next year:

http://www.odannyboy.com/blog/new_archives/2006/12/new_interaction.html

Oddly enough, however, looking back over the blogs I follow, I didn't
find too many new methods this year. (Just personas, personas,
personas!)

What new methods are you going to try?

Dan

Dan Saffer, IDSA
http://www.designingforinteraction.com book | work http://
www.adaptivepath.com
http://www.noideasbutinthings.com project | site http://
www.odannyboy.com

Comments

22 Dec 2006 - 5:30pm
Robert Hoekman, Jr.
2005

> The more important questions-- like, "what should the software do in the
> first place?"--are enabled by good models about what people are trying to
> achieve. And personas are one good way to model this.

Obviously, this is an important question (the *most* important).
Obviously, IxD work starts, for good reason, with concepts and product
definition. Clearly, I'm not saying our work is all about figuring out
where to put a checkbox.

I'm saying the studying the activity is more effective than studying users.

It's interesting that so many people equate ignoring users with
ignoring everything good about interaction design.

-r-

26 Dec 2006 - 11:18am
Dante Murphy
2006

Robert-
Have you ever considered that personas and scenarios (or user stories)
might be the best or only path to discovering what the activities are?
In my experience, this is often the case, especially when designing or
evolving a process that doesn't have an established pattern or
precedent.

These are some of the greatest challenges and opportunities in the IxD
space, and it makes sense to have a variety of techniques and tools to
address them.

I can also attest that it is very important to understand specific user
attributes and keep them in mind when designing experiences for small
and highly specialized audiences, such as surgeons and bond traders.
Their needs and preferences are very different than those of the general
public, and the interfaces they use have far greater impact on their
lives (and the lives of their patients/clients) than the Target
e-commerce website. Using well-constructed personae throughout the
design process is without question a valuable tool in working on these
kinds of projects.

Dante
_______________________________________
Dante Murphy | Director of Information Architecture
Medical Broadcasting Company | A D I G I T A S INC. COMPANY

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Robert Hoekman, Jr.
Sent: Friday, December 22, 2006 5:31 PM
To: Joshua Seiden
Cc: discuss at ixdg.org
Subject: Re: [IxDA Discuss] New IxD Techniques to Try in 2007

> The more important questions-- like, "what should the software do in
the
> first place?"--are enabled by good models about what people are trying
to
> achieve. And personas are one good way to model this.

Obviously, this is an important question (the *most* important).
Obviously, IxD work starts, for good reason, with concepts and product
definition. Clearly, I'm not saying our work is all about figuring out
where to put a checkbox.

I'm saying the studying the activity is more effective than studying
users.

It's interesting that so many people equate ignoring users with
ignoring everything good about interaction design.

-r-
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

26 Dec 2006 - 11:58am
jbellis
2005

Dante,
I'd enthusiastically consider it. Can you give some of the many examples
where personas (if possible, as opposed to scenarios... or are they the same
thing in your work?) were the best or only path?

I don't disagree that in innovative situations, every exercise in adding
dimensions to the research would help. My problem with personas is that the
limiting factors I see in most software are not concerning exploratory
design but answering basic needs that are well established.

Thanks,
www.jackbellis.com
----- Original Message -----
From: "Dante Murphy" <dmurphy at mbcnet.com>

> Robert-
> Have you ever considered that personas and scenarios (or user stories)
> might be the best or only path to discovering what the activities are?
> In my experience, this is often the case, especially when designing or
> evolving a process that doesn't have an established pattern or
> precedent.

26 Dec 2006 - 12:48pm
Robert Hoekman, Jr.
2005

> Have you ever considered that personas and scenarios (or user stories)
> might be the best or only path to discovering what the activities are?

Only if the activity is to create a persona. ;)

Again, I've said that if the studying the activity means talking to people
that perform it regularly, then cool. But that's where the buck stops for
me. I see no reason to spend time creating personas based on that
information. Personas are about the people I talked to, not about the
activity, so I don't need them.

(Incidentally, user stories, as I know them anyway, are VERY different than
personas. They should not be grouped together.)

> I can also attest that it is very important to understand specific user
> attributes and keep them in mind when designing experiences for small
> and highly specialized audiences, such as surgeons and bond traders.
> Their needs and preferences are very different than those of the general
> public, and the interfaces they use have far greater impact on their
> lives (and the lives of their patients/clients) than the Target
> e-commerce website.

Definitely ... sort of. Surgeons and bond traders have very different needs
than the general public. But the activities they perform are also very
different than those performed by the general public. And within those
audiences, different surgeons have different needs, different levels of
experience, different specialties, different tastes, and so on. Are we
talking only about, say, orthopedic surgeons? If so, we've eliminated
exactly *one* of the points of difference: specialty. All the others remain
true.

Next year I'm going to redesign my house. When I do that, I'll pay close
attention to how my wife and I actually function within that space, how we
organize things, the colors and styles we like, etc, and find ways to make
that work really well for us. In this case, we are the only two people that
care how this turns out. We are the only two people that will live there, so
we're the only people that matter. There's simply no point in abstracting
our designs so they work for lots of other people. It's our house.

If I was coming up with an interior design, however, that would be used by
everyone in the neighborhood, I'd do things a lot differently. I'd design
for activities. It's the only real option, because the people living in all
those houses are very different from me and I can't possibly design
something to satisfy all of their unique, individual needs and desires. To
optimize my chances, I focus on the activity, and I do this with a general
understanding of how people perform the activities for which I'm designing
solutions.

I have a friend, in fact, that designs communities, and her whole company
uses a very similar approach, with much success.

-r-

26 Dec 2006 - 2:15pm
Jared M. Spool
2003

On Dec 26, 2006, at 12:48 PM, Robert Hoekman, Jr. wrote:

> Again, I've said that if the studying the activity means talking to
> people
> that perform it regularly, then cool. But that's where the buck
> stops for
> me. I see no reason to spend time creating personas based on that
> information. Personas are about the people I talked to, not about the
> activity, so I don't need them.

Personas are a tool. Not every tool is necessary all the time. Some
tools are rarely necessary. And some practitioners may never use
certain tools.

It may be the case that *you* don't need personas to do your job. I
can believe that.

However, others may need them. In specific, I've found personas to be
very important under the following conditions:

1) The design team is an actual team, with more than a single
individual working the entire process from ideation through
implementation (and beyond).

2) The team members are different from their users (which is most of
the time).

3) The team members do not have constant interaction directly with
the users, particularly getting feedback on how the relevant
artifacts are used.

4) Different users will interact with the artifacts differently
because they have different intentions, context, knowledge, skills,
or experience.

The well-executed persona description helps the team work "on the
same page," when it comes to understanding who their users are. It
can eliminate the confusion and wasted efforts that come when team
members are walking around with different ideas of who their users are.
http://tinyurl.com/mgz95

The well-executed persona description enables successful role-playing
and story-telling for intra-team communication and for inter-group
understanding of the design goals and objective.
http://tinyurl.com/y75t9h

The well-executed persona description helps the team members fit the
design solution against the attributes which make one persona
different from another, to ensure they've not excluded activities or
impaired actions because they were ignorant (or forgot) about a
subtlety of use.
http://tinyurl.com/vxcur

I see a major role for personas to be dissemination of information
about users to others in the organization. When well executed, the
entire organization understand who the design is for and the
subsequent design rationales.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

26 Dec 2006 - 4:44pm
Robert Hoekman, Jr.
2005

> 1) The design team is an actual team, with more than a single
> individual working the entire process from ideation through
> implementation (and beyond).
>
> 2) The team members are different from their users (which is most of
> the time).
>
> 3) The team members do not have constant interaction directly with
> the users, particularly getting feedback on how the relevant
> artifacts are used.
>
> 4) Different users will interact with the artifacts differently
> because they have different intentions, context, knowledge, skills,
> or experience.

All of this assumes the designers need to know about a specific audience.
Yes, if you decide to do user research, and decide to let user research
guide your design work, then all of these situations are ones in which
personas will be helpful.

However, if you study an activity - let's say the activity of organizing and
sharing photos online - all of this becomes moot. When the team members (1)
focus on the activity and they design for completing tasks, it doesn't
matter at all whether the designers are different from the audience (2)
because the tasks remain the same. The team doesn't need constant
interaction with users (3) because they're not designing based on the
demands, whims, personalities, and quirks of users, but rather the very
stable notion of an activity. Yes, different users interact with the
artifacts differently (4). That's exactly *why* users are unreliable as a
source of guidance.

Your argument is valid only if you decide to let user research guide your
design work. I don't, so your reasons for using them don't apply. (I think I
may have just said, "I'm rubber and you're glue", but you get the idea.)
Yes, sometimes I talk to real users about activities they perform so I can
understand them better, but most of the time it's unnecessary, and even when
it is necessary, it takes more time than most software companies will ever
allow on a release schedule.

On the occasions when I do talk to users who already perform such an
activity, I still find it unnecessary to create personas. All my
documentation is about the activity itself. If other team members are
working on the same project, we share documentation about the activity.

Man, this is exhausting. I feel as though you guys are trying to beat me
into submission, as though UCD is the Bible and that's all there is to it.
There's no other reality.

Strangely, a gentleman named Larry Constantine, who you (Jared) invited to
speak at your very own conference (UIE Web App Summit), who just wrote an
article called "Designing Web Applications for Use", which appeared on your
very own web site (uie.com) and which you promoted through the UIE
newsletter, advocates designing web applications for usage and not for
users. Some of the very same things I'm saying here. Yet it seems like
you've ignored my argument completely, in favor of talking about why
personas are so great.

I may just be overly-defensive at this point, so my apologies if I'm wrong
here.

-r-

26 Dec 2006 - 5:48pm
Jared M. Spool
2003

You *are* being overly sensitive, but that's ok. We still love
you. :) xoxo

On Dec 26, 2006, at 4:44 PM, Robert Hoekman, Jr. wrote:

> However, if you study an activity - let's say the activity of
> organizing and sharing photos online - all of this becomes moot.
> When the team members (1) focus on the activity and they design for
> completing tasks, it doesn't matter at all whether the designers
> are different from the audience (2) because the tasks remain the
> same. The team doesn't need constant interaction with users (3)
> because they're not designing based on the demands, whims,
> personalities, and quirks of users, but rather the very stable
> notion of an activity. Yes, different users interact with the
> artifacts differently (4). That's exactly *why* users are
> unreliable as a source of guidance.

In generic activities, such as "organizing and sharing photos", I'd
agree that a pure activity focus is the right direction, since, as
you say, there are so many users and all of them are so different
that they become almost homogenous in their differences. And teams
themselves can easily put themselves in the role of a Photo Sharer,
so they don't have to do much beyond their own perspective.

However, all I'm trying to say (hopefully without red-lining your
sensitivity meter) is that not all activities fall into this
category. An example would be the activity of ordering a blood test
in a pediatric ICU. Here, the activity is done most commonly by
nurses, but occasionally by doctors themselves. Some tests are
routine (CBC, CHEM7, toxin screen), based on the standard protocols
of the PICU, whereas others are unique to the given child's
condition. Some nurses are temporary assignments or new to the PICU,
whereas others have been there for years.

I'm suggesting that creating Personas, Scenarios, and Activity models
would help the team understand the specifics necessary to create a
design that will be effective in a variety of common (and
occasionally uncommon yet critical) contexts. Just a pure focus on
activities may omit critical user assistance tools or design elements
that would create a better experience overall. Especially for a team
who has never spent time in a PICU.

>
> Your argument is valid only if you decide to let user research
> guide your design work. I don't, so your reasons for using them
> don't apply. (I think I may have just said, "I'm rubber and you're
> glue", but you get the idea.) Yes, sometimes I talk to real users
> about activities they perform so I can understand them better, but
> most of the time it's unnecessary, and even when it is necessary,
> it takes more time than most software companies will ever allow on
> a release schedule.

I guess I don't see how you get to the activities of an interface
used in a foreign setting (such as a pediatric ICU) without some sort
of research. And I don't think you're suggesting designers just guess
based on what they've seen on Grey's Anatomy.

(By the way, *my research* showed *I* was rubber and *you* were glue,
but it could be faulty. I probably don't have enough data points for
a high confidence value.)

I think what software companies will allow is relative to the value
they perceive they'll receive.

> On the occasions when I do talk to users who already perform such
> an activity, I still find it unnecessary to create personas. All my
> documentation is about the activity itself. If other team members
> are working on the same project, we share documentation about the
> activity.

And what we may have here is a failure to communicate.

Personas, when executed well (and our research shows that they are
regularly executed poorly), are about the activity. They are used by
the team to highlight how different people approach the same activity
differently. So, by definition, Personas *are* documentation about
the activity, albeit background documentation to describe the context
the activity exists within.

> Strangely, a gentleman named Larry Constantine, who you (Jared)
> invited to speak at your very own conference (UIE Web App Summit),
> who just wrote an article called "Designing Web Applications for
> Use", which appeared on your very own web site ( uie.com) and which
> you promoted through the UIE newsletter, advocates designing web
> applications for usage and not for users. Some of the very same
> things I'm saying here. Yet it seems like you've ignored my
> argument completely, in favor of talking about why personas are so
> great.

Indeed. I love Larry dearly and believe everything he says. However,
I didn't read that article and come away with the notion Personas
were a bad idea and useless. Instead, I came away with a belief that
they need to be balanced with an activity perspective to be totally
helpful. Something I've always known, but Larry said it much better
than I could.

Love ya,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

Syndicate content Get the feed