Hi John --
Glad to hear they explained it in a way that made sense to you. I have
definitely heard this message before from the Fluid design team. It's
probably not stated on the wiki in exactly the same way. What you
describe is also one of the reasons the designers often talk about not
being able to provide personas out of context of the design problem.
It sounds like the example was very helpful to you, so perhaps adding
some examples to the wiki would help. Although, probably much better
would be having a camtasia + video type of tutorial since it could
also visually show the process and make it more accessible. In
general, the Fluid wiki has an awful lot of text, which I think could
be enhanced with more visuals. Of course, I am more of a visual
learner than a textual learner, so I will always learn better that way.
But glad you are a convert -- for the moment at least!
Mara
On Nov 2, 2008, at 10:59 AM, Nathan Pearson wrote:
Thanks for sharing this John -- neat stuff.
Another method to this (I'm sure there are others) is to use task
analysis to map behavior by stripping away the "system" context and
emphasizing the non-virtual world.
Start by imagining a time when everything was done with paper forms,
before computers were invented. Now walk each user profile (what
you call marketing personas) through the tasks needed to accomplish
a goal while asking the question "what would it take to motivate
this person to migrate their offline behavior to an online system?"
The emphasis being on "motivation".
In the end, you derive groupings of users who have different
motivations. Some are motivated by convenience, others by
socializing, etc. Then tie those factors to your persona models to
drive design choices.
Of course, this approach is stretched when dealing with things like
"building a site" and other purely virtual activities. But you
typically can employ a reasonable offline analogy to approximate the
concept.
---
But to your point about being skeptical of personas -- there may be
reason for this beyond not understanding process. Personas, IMO,
are scalpels used as lead indicators. In other words, they're great
for fine-grained detail and innovation, but when it comes to getting
the general shape of your product together or cleaning up what you
already have, they tend to be marginally beneficial.
For example, what amount of persona work is required to know if a
site should have a title or not? Or that a site will require users
to be added to it? Or that a site concept is at all relevant?
Can't the market and system logic generally guide us through
answering these questions?
In terms of the usability of these features, can't heuristics and
some usability testing get us on track? And aren't these options
far more efficient than deep, time consuming, and expensive user
research?
To clarify, so my colleagues don't think I'm a complete trader,
personas are great when it comes to innovation or working through
some detailed nuance with user behavior. But is that what's needed
for Sakai today or can we benefit from lag indicators (as opposed to
lead indicators like personas) to help us close the gap between
where Sakai is and where it should have been by now w/rt the
original product vision?
More over, is any investment in design worth while if this community
is unwilling to stick through a disciplined implementation effort
where teams are committed to quality, attention to detail, and a
common, reasonably scoped design spec?
Nathan
On Sun, Nov 2, 2008 at 8:52 AM, John Norman <[EMAIL PROTECTED]>
wrote:
Those who have spoken with me about personas in user centred design
will know that I have been a bit of a sceptic. Nevertheless, we are
about to start paying a commercial company to help us with UCD! They
are called Flow Interactive (www.flowinteractive.com).
The reason for this post is that in the kick off meeting, they shared
something that was far more persuasive than anything I have read on
the Fluid wiki to date so I wanted to share this insight as I
understand it.
So here is the big idea: Design personas are different to marketing
personas. A design persona is not a description of a person, it is the
result of analysis of *goals* and *behaviours* of users in a
particular context. The analysis seems to involve identifying which
goals and behaviours have high discriminating power in terms of design
tradeoffs, describing them in terms of behavioural axes and plotting
real user behaviours on those axes. Clusters of user plots one one
axis become a single characteristic of a potential persona. Profiles
of plots on different axes become design personas. They *express the
user research* in terms of different behavioural profiles *that are
relevant to design choices*.
So for most of you this probably still sounds like gobbledegook and
you are unimpressed that I have now joined the ranks of the speakers
of UCD. But Flow gave me an example that really helped me understand
the concept:
They had a client who wanted some work done on a hotel booking site.
The client told them the users of the site had 5 personas - the
business traveller, the short-break weekender, the family with small
children, the single holidaymaker, and - well lets just say the
romantic short stay customer. These personas are valid marketing
personas, with different communication channels, different price
sensitivity and so on. Flow's user research phase discovered that from
a site design perspective there were only 2 design personas - those
who knew where they wanted to stay and those who didn't. That is, the
marketing personas did not exhibit behavioural differences when it
came to the factors that impact on the site design and the user
behavioural differences that did impact on site design revealed a
different clustering of users into 2 design personas - destination
known and destination unknown.
Now, this makes sense to me. The next test is to see if it works as
well for some projected theoretical future (Academic Social
Networking) as it does for some real-world goal seeking behaviours.
Note that the slideshow linked at the bottom of the main Fluid
personas page
(http://www.slideshare.net/toddwarfel/data-driven-design-research-personas
) includes a couple of pages (27/28) that appear to illustrate this
concept, but the slides are not very explanatory.
I hope this helps someone else find their way into this UCD stuff.
John
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
) from the DG: User Experience site.
You can modify how you receive notifications at My Workspace >
Preferences.
--
Nathan Pearson | UX Lead | Sakai Foundation
E. [EMAIL PROTECTED]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)
http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
) from the DG: User Experience site.
You can modify how you receive notifications at My Workspace >
Preferences.
==================================
Mara Hancock
Educational Technology Services Interim Director
http://ets.berkeley.edu
University of California, Berkeley
Educational Technology Services
9 Dwinelle Hall, #2535
Berkeley, CA 94720
Desk: 510-643-9923
Mobile: 510-407-0543
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
