nice read: On Apple's connection with the consumer continued...

24 Sep 2009 - 3:45pm
4 years ago
7 replies
465 reads
Thomas Petersen
2008

"Yes and perhaps thats the nature of business - make money, save
money, profit and hopefully along the way do good. Perhaps business
needs to change its model in a sustainable world? (but that's
another discussion) But ... Why can't a business focus on all 3? Why
are these mutually exclusive? Why not find a balance of all 3?"

Business can do that, but they don't need UCD for that.

On the contrary I would claim that UCD all to often muddles the water
by providing a false impression of quality even when you have
conducted for instance a usability test where you come up with some
interesting findings.

There is no transcendence from these findings into the actual design
and implementation.

What you need is some really good UX people who care about the nitty
gritties of interface design (the pull downs, the roll overs, the
organisation of data, structure, accordions, buying process), some
good developers and designers to follow that through who care equally
and who have a genuine interest in making interfaces and user
experiences that are easy to use.

What bothers me even more is that it seems as if UCD ignores any kind
of accumulated knowledge and insist that every project should be using
the UCD process.

Now that does not mean that there are not proponents and
practicioners of UCD who care about these things, but then it's them
and their accumulated knowledge that makes the difference not the UCD
process.

"Suggest by pissing off your user base long enough they will be sure
to move on (unless of course they have no choice, as was the case with
mobility a few years back)"

Yes and that is despite that plenty of mobile companies did plenty of
usability studies. Along came apple and turned it on it's head now
everyone is running to catch up and I am sure a lot of Mobile UCD
experts are going to make notice of their arrival. Yet the real
experts where those who didn't use UCD IMHO, apple.

Again if users don't know what is possible then they can't make
suggestions that pushes you into a new paradigm. They can make
suggestions in the old paradigme but that is hardly of any real value
when it comes down to it. That is in 90% of the cases.

"Disagree and suggest users do know what they want, its just that
they may not always know how to articulate it."

They know what they want in the old paradigme but that is hardly
different than what any good interface desiger or UX knows through
the accumulated knowledge they have or by conducting reasearch into
mapping what kind of problems users are going to make.

None the less even when the occasional user know what they want, we
are again back to the problem of transcendence. You haven't solved
the problem by stating the problem or suggesting what would be a nice
feature. The "how" you are going to solve the suggestion is the
important factor not the "what".

"Users certainly know when they have experienced a "crap product or
service" and in some cases have nice ideas on how to improve upon it.
Its embarrassing at times to have users tell us things that should
have been addressed by the business much earlier (again yet another
discussion)"

I simply don't buy this as an argument. If you really find users who
can help you solve the "how" you should hire them and not test
them.

I am all for doing user research and finding out what kind of
problems users have, but to claim that they can suggest how to solve
them is flat out wrong, how would they know?

Knowing something is crap does not mean that you know how to make it
better. And whatever suggestions they might have, you are going to
work hard to convince me that their suggestions transcend well into
the design or development process.

And let's be honest here. Most of the times UCD is used by our
clients to push away responsibility. And THAT is a problem of
businesses that I think would be fair to address both for the
companies and the end users.

Just because I know how to use a hammer does mean that I know how to
make a good one. I can however listen to customers my customers and
learn what kind of tasks they are trying to accomplish and then go
back into the lab and try to come up with a better hammer.

Why would that be so different in our field?

I take the users needs and problems very serious, that is what I am
being payed to do, but it's my responsibility to convert my
knowledge of their problems into a solution, that is what makes me
the expert and them the user.

"Thomas, out of interest - How do you think about your target users
in the work you do? "

It really depends.

Mostly when I think about target users I think about them in terms of
style and communication.

If I think about them in the context of creating for instance a
product or service I look at them based on the frequency of use of
the product or service. The allowed complexity curve.

www.hellobrand.com/complexitycurve.pdf

If it's an area that I know little off I am going to read up on the
research that exist on them as much as I can.

If little research have been conducted and the area is complex I
might propose that my client get that done first or I might ask for
statistics of their current user base.

And then based on the type of frequency (newsletter signup vs. a CMS
system) I am then going to allow a greater learning curve and use
metaphors that corresponds to the type of user I am communicating
to.

But from a GUI point of view I am using my design skills to make it
easy to understand which is accumulated knowledge about how to create
heirachy, create overview, grid structures, readability, layouts.
choreography etc. All these things that users don't know how to
formulate and that have nothing to do with whether they are persona a
or b.

A button is a button no matter what kind of person you are. A good
interaction flow is a good interaction flow no matter what kind of
persona you are.

And user research normally provide me with enough information to get
going and make solid solutions.

Well there is of course much more to this but that's the fast
version.

Comments

24 Sep 2009 - 7:41pm
dszuc
2005

Hi Thomas:

Tried hard to avoid definitions, but ... *sigh* what is your
definition of UCD?

"There is no transcendence from these findings into the actual
design and implementation." - Don't agree. There are plenty of
instances where Usability Testing, as an example method, has provided
clear findings and solid recommendations towards improving the design
or in some cases completely realigning strategy or UI frameworks.

"some good developers and designers to follow that through who care
equally and who have a genuine interest in making interfaces and user
experiences that are easy to use." - Agree but still think you need
to involve users along the way. Does it have to be a pure UCD
process, maybe not, but again this is where the right balance of
focusing on user needs, knowing what research they are based on,
following best practice, listening to the business, using design
patterns (to name a few) and involving users at the right stages is
is helpful.

"What bothers me even more is that it seems as if UCD ignores any
kind of accumulated knowledge and insist that every project should be
using the UCD process." - Dont think it should and what do you base
this on?

"Yet the real experts where those who didn't use UCD IMHO, apple."
- Do we know this about Apple? Do we know that Apple didnt apply some
part of UCD in their process?

I dont see this a whole or nothing approach with process - following
UCD or not following UCD, its a mix of the right approaches that make
all the difference - time, budget, culture, usability/UX/design
maturity also play a role.

"They know what they want in the old paradigme but that is hardly
different than what any good interface desiger or UX knows through
the accumulated knowledge they have or by conducting reasearch into
mapping what kind of problems users are going to make." - Perhaps
but we have also seen many cases where the user articulates what they
want clearly, it confirms what we thought and it helps the business
communicate the voice of the customer to help make their case to
management.

"I am all for doing user research and finding out what kind of
problems users have, but to claim that they can suggest how to solve
them is flat out wrong, how would they know?" - Some do and are
becoming savvy enough to know. Part of our job is to know what
suggestions to use and not use for our user base. This includes
looking for patterns in data and finding insights that make a
difference.

Will conclude by saying that no one process solves all problems, but
think its a flaw not to involve users at some point. Does it have to
be the purist UCD approach, perhaps not ...

For the rest, would make for a good face to face discussion at
Interaction 10 or maybe a panel? *yikes!*

Good stuff!

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46034

24 Sep 2009 - 9:59pm
Jared M. Spool
2003

On Sep 24, 2009, at 5:41 PM, Daniel Szuc wrote:

> Tried hard to avoid definitions, but ... *sigh* what is your
> definition of UCD?

Please don't go there.

Please. Please.

Jared

24 Sep 2009 - 10:10pm
dszuc
2005

Lets take it for one more spin around the dance floor :)

Maestro if you will ... one, two and ...

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46034

25 Sep 2009 - 3:05am
Thomas Petersen
2008

The real short version of UCD is:

Where users are asked to help you make design decisions.

"Don't agree. There are plenty of instances where Usability
Testing, as an example method, has provided clear findings and solid
recommendations towards improving the design or in some cases
completely realigning strategy or UI frameworks."

You are assuming your conclusion.

Recommendations does not mean transcendence that is exactly my point.
Transcendence is when the quality of the recommendations transcend
into the quality of the actual end product.

Usability tests are tests of the usability of whatever phases the
design exist in, if it's wireframes you will test wireframes, if
it's screens you will test screens. The problems being tested in
these phases are inherrent in the phases themselves.

If users don't see you button in the wireframe does not mean that
he/she don't see it in the design.

There is no process that ensures that whatever findings you have in
your UCD process will transcend into the pixels and the programming,
i.e. there is no transcendence.

That you can get valuable finding through UCD is obvious and besides
the point. They are still to my mind most of the times not worth it
(there are a few situations where it makes sense, I have already
listed those in another thread)

"Agree but still think you need to involve users along the way."

Only if the problem you are dealing with are new and within the old
paradigm.

"Does it have to be a pure UCD process, maybe not, but again this is
where the right balance of focusing on user needs, knowing what
research they are based on, following best practice, listening to the
business, using design patterns (to name a few) and involving users at
the right stages is is helpful."

At the right stage yes, but that is where the disagreement lies.

My claim is that you use users to figure out what tasks they are
trying to accomplish and what problems they have with trying to solve
them (qualitative user research) and then you test the actual usage
statistically afterwards. No usability test, no focus groups, I would
even be so bold to claim no personas. I personally don't need them
and don't see their value they are false safety and false impression
of quality.

"- Dont think it should and what do you base this on? "

On experience.

90% of the cases that UCD is normally used for you could just have
gone with the accumulated knowledge that the UX in question already
had. Do you really need to test if your navigation makes sense for
the umpt time even though it's a bar in the top and a left menu
navigation on the left? I say no, I say if you want to call yourself
an expert that should be the type of expert that make sure that the
end product is of good quality, not just the process of gathering
user input.

Where UCD really goes wrong is when it starts to think that every
problem is unique and that you need users to find those little
differences and that this should somehow inform your product or
service down in the UI.

That is in my opinion and experience simply just death wrong. A
sign-up process shouldn't be unique, the communication to getting
you sign-up should on the other hand.

"Do we know this about Apple? Do we know that Apple didnt apply some
part of UCD in their process? "

Yes we do.

"I dont see this a whole or nothing approach with process -
following UCD or not following UCD, its a mix of the right approaches
that make all the difference - time, budget, culture,
usability/UX/design maturity also play a role."

Again I am not against user input, I am against using users to make
design decisions with. That is what UCD is all about and that is
where it is missing the point.

"- Perhaps but we have also seen many cases where the user
articulates what they want clearly, it confirms what we thought and
it helps the business communicate the voice of the customer to help
make their case to management."

The only thing that it do is save asses. Cause even when the product
or service launches and fails, every one can claim that they asked
the users what they wanted.

You can't build a business on what users want. They want all sorts
of things and they just want more of the same. You would soon end up
with a spaceship that no one knows how to fly.

What you need to do is to give them what is necessary. And that is
your job as the expert to figure out what that is. If you look at the
problems they have instead of what they want, then we are on to
something.

"Some do and are becoming savvy enough to know. Part of our job is
to know what suggestions to use and not use for our user base. This
includes looking for patterns in data and finding insights that make
a difference."

This have no value is the transcendence is not happening into the
actual finished product and that is what I am saying.

UCD process lack fundamental transcendence into the actual design of
the product. My guess is that is because it is primarily an academic
discipline.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46034

25 Sep 2009 - 3:57am
dszuc
2005

Hi Thomas:

Can you explain these a little further for me, I am not understanding
the concept of "transcendence" (and perhaps others who are
listenings in, perhaps painfully, may want to help out)

1) "Recommendations does not mean transcendence that is exactly my
point. Transcendence is when the quality of the recommendations
transcend into the quality of the actual end product."

2) "There is no process that ensures that whatever findings you have
in your UCD process will transcend into the pixels and the
programming, i.e. there is no transcendence."

"Do you really need to test if your navigation makes sense for the
umpt time even though it's a bar in the top and a left menu
navigation on the left?" - No you don't but this is where we may
have a misconception or mis-communication around UCD, its value and
have said along the way that users need to be brought in at the right
time and place to inform design. Again, does this mean involve or
invite the user in at every single point of delivery, maybe yes and
maybe no, but the value of user input is still high on my priority
list.

Coming full circle, companies do care at some level about their user
(as they pay the bills), how much care and how much their users are
involved varies.

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46034

25 Sep 2009 - 5:06am
Thomas Petersen
2008

With transcendence I mean that there is some sort of quality transfer
from one phase of the process to the next.

I.e. the quality of the user research gets transferred into the UCD,
that then get's transferred into the visual design and development
and then at last into the user experience of the product/service.

This does not happen because UCD focuses on the users needs,
suggestions and validation of the current state of affaird rather
than on the users problems and actual usage of the product.

It becomes a pseudo solution to a pseudo problem, with pseudo
suggestions that are not as such transferable into the actual design
and development. I.e there is no guarantee that the end product is
going to be any good just because you have done a fantastic
comprehensive UCD process.

Now that is not the fault of the people doing the UCD, that is the
fault of the UCD approach in itself.

My suggestion is that you do UCD when it's needed which in my mind
is when you are dealing with something there is no accumulated
knowledge about. Otherwise it's your damn job to know enough about
most areas to design a decent and usable solution yourself.

UCD have become a mantra and the fact that there are companies who
only do that is to me a clear evidence that something have gone
terrible wrong.

It should have been a tool, now it has become a religion.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46034

25 Sep 2009 - 7:50am
Jared M. Spool
2003

On Sep 24, 2009, at 8:10 PM, Daniel Szuc wrote:

> Lets take it for one more spin around the dance floor :)
>
> Maestro if you will ... one, two and ...

George Bernard Shaw once said: "I learned long ago, never to wrestle
with a pig. You get dirty, and besides, the pig likes it."

Jared

Syndicate content Get the feed