Is UCD Really Broken?

23 Jun 2008 - 10:39pm
6 years ago
61 replies
3728 reads
ambroselittle
2008

I've been following the frequent allusions to Google, 37signals, Facebook,
et al (including Jared Spool's presentation) as evidence that UCD is somehow
broken with interest. There's no debating that these products have been
successful, but it is also worth considering that they are the exception,
not the rule. As such, they can't be the basis for guidance
towards repeatable results.

I could be wrong (*no really*!), but it seems to me that the goal of UCD is
not so much to be innovative and groundbreaking but to add some degree of
reliability in terms of actually creating something that meets folks'
needs. I would suggest, FWIW, that innovation is nice and sometimes quite
lucrative, but you can't bank on it. You have a great, innovative idea or
you don't, and UCD won't deeply affect that, but that doesn't make UCD
something that should be tossed out. For the *vast majority* of apps that
are, I hope we all agree, not terribly innovative and yet at least have the
potential to serve the needs for which they were conceived, UCD is about the
most promising approach to building the right thing, the right way. Agile
is a close second for those who don't have the skills/knowledge for UCD.

Can you over invest? Absolutely, but abusus non tollit usum.

[I tend to think that some blend of UCD with Agile is the sweet spot for
most software.]

As for innovation and the dreamy potential of advancing the industry towards
some fanciful new future, well, most businesses can't bank on that, and even
most who aspire to that will fail regardless of process or lack of process.
I don't think it's wise to base an entire discipline like IxD upon such
aspirations, nor is it wise to toss out process--the point of which is to
provide some repeatable consistency, even if imperfect and not particularly
sexy. By nature, process is not geared towards innovation but rather
towards producing *reliable, repeatable* results, which is what most
businesses need and want, and any sustainable profession should have the
concerns, needs, and wants of business stakeholders close to heart over and
above laudable, if unrealistic, dreams about the future.

So I guess I don't really get the controversy.

--Ambrose

Comments

23 Jun 2008 - 11:13pm
Spencer Nowak
2008

I don't think the companies you mentioned should even be considered
exceptions to the rule. Facebook and 37signals both practice
self-centered design. 37s uses all their own products internally, and
I imagine most Facebook devs are the right age to be on Facebook. By
testing their designs against their own expectations, they can
approximate the UCD process with less overhead and a much shorter
turnaround time. Their success actually has a lot to do with their
ability to internalize UCD, and is most definitely not a good example
of why UCD is broken.

Their approach can only work when the target audience and the
devs/designers are drawn from a relatively homogeneous group with
shared core values around which the application can be built. In
cases where the target audience isn't likely to include a lot of
devs/designers, traditional UCD methods are still the best way to
ensure that the needs of the audience are addressed.

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

24 Jun 2008 - 1:17am
mojofat
2004

Correct. And they continually iterate their products, which are
easily changed, based on user feedback. I think sometimes we may lose
sight of the world of tangible electronic products with UI's that run
on embedded software and maybe even no internet connection. It seems
like we wouldn't want to narrowly define "interaction design" to mean
"web page design." With that in mind, there's probably something to
be said for the talented interaction designer taking a prudent route
in non-web situations and testing their designs prior to launching a
product with millions of dollars on the line and no way to put the
genie back in the bottle.

-al

On Jun 23, 2008, at 9:13 PM, Spencer Nowak wrote:

> I don't think the companies you mentioned should even be considered
> exceptions to the rule. Facebook and 37signals both practice
> self-centered design. 37s uses all their own products internally, and
> I imagine most Facebook devs are the right age to be on Facebook. By
> testing their designs against their own expectations, they can
> approximate the UCD process with less overhead and a much shorter
> turnaround time. Their success actually has a lot to do with their
> ability to internalize UCD, and is most definitely not a good example
> of why UCD is broken.
>
> Their approach can only work when the target audience and the
> devs/designers are drawn from a relatively homogeneous group with
> shared core values around which the application can be built. In
> cases where the target audience isn't likely to include a lot of
> devs/designers, traditional UCD methods are still the best way to
> ensure that the needs of the audience are addressed.
>
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=30642
>
>
> ________________________________________________________________
> 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

24 Jun 2008 - 5:12am
ambroselittle
2008

On Tue, Jun 24, 2008 at 12:13 AM, Spencer Nowak <spencer.nowak at gmail.com>
wrote:

> I don't think the companies you mentioned should even be considered
> exceptions to the rule. Facebook and 37signals both practice
> self-centered design. 37s uses all their own products internally, and
> I imagine most Facebook devs are the right age to be on Facebook. By
> testing their designs against their own expectations, they can
> approximate the UCD process with less overhead and a much shorter
> turnaround time. Their success actually has a lot to do with their
> ability to internalize UCD, and is most definitely not a good example
> of why UCD is broken.
>

I was wondering about that myself, but I guess folks are dispair(ag)ing of
the user research phase and focused usability testing in these cases. ?

As counter examples, I have personal experience with software companies
focused on software devs who turn out, let's say, less than usable
products. The engineering (and sales and marketing, to be fair) focus on
function overrides any focus on other aspects of user experience like
usability, findability, and desirability. They can be very successful in
terms of the business despite that.

So I think these folks, mostly "Web 2" types, are doing something different,
and I agree with you, Spencer, that they are using certain aspects of UCD
(or is it SCD? :) ). I saw a talk by Ryan Singer that made it very clear
that they followed UCD principles, even if they weren't out doing formal
research and usability testing. I don't know about Facebook, and Google
now, if not originally, is certainly using UCD principles as well. Heck, I
think someone just recently was talking about their usability labs, which
sounds pretty UCD to me.

And I tend to think Allen's point about less-easily-changeable products is
important as well. Perhaps it's not UCD that's a problem but an
unwillingness to adapt it to one's environment and needs, e.g., excising
aspects that are less necessary because you, say, already deeply know your
audience. ?

Are there any advocates of the idea that UCD is broken out there that can
clarify what they see the problem with UCD to be?

--Ambrose

24 Jun 2008 - 5:38am
Dave Malouf
2005

I'm sorry but one of the main goals of UCD is to avoid
"self-centered" design. Once you go that route in any way, you are
not applying UCD methods. Unless you consider users beyond your 4
walls, it ain't UCD. Simple.

Ignoring our best examples of successful design feels like bad
business. It is standard Business practice to study case studies to
learn from them. Avoiding these seems impractical.

Why the heck doesn't anyone talk about how Google does (today) and
Amazon has for a really long time DO use research. Google does mini
AB tests out in the wild all the time, and so does Amazon.

Now, I would like to hear from the host of UCD practitioners here
about their top of market efforts they work on and how UCD was the
champion that got them there? and which processes they used.

-- dave

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

23 Jun 2008 - 11:17pm
Kontra
2007

> producing *reliable, repeatable* results, which is what most
> businesses need and want

How do we know this?

Take a popular field of contention: an endless coterie of businesses
tried to follow their "tried and true, reliable and repeatable"
processes to compete against the iPod, iTunes, iTunes Store, etc. The
*results* have been not just minor disappointments, but colossal
losses in the billions, forcing the vast majority of them exiting the
business altogether.

Look at an anti-UCD company like Apple. When the chips were down, they
bought SoundJam for iTunes; they went to Tony Fadell for the iPod;
when everyone and his brother was telling Apple opening retail stores
were an insane idea, they built and re-built a completely functional
prototype; when everyone else was shipping customer support to India,
Apple brought direct support and training right into the stores; when
every pundit claimed devices without floppy drives, FM radios or
physical keyboards were doomed they brought us the iMac, the iPod and
the iPhone, etc. Non-trivial problems require contextual,
problem-specific thinking.

"Repeatability" opens the door to copy-ability and with the
ever-escalating speed of competition, if a company doesn't have
sufficient differentiation, it's dead meat.

--
Kontra
http://counternotions.com

24 Jun 2008 - 11:15am
Robert Hoekman, Jr.
2005

>
> I'm sorry but one of the main goals of UCD is to avoid
> "self-centered" design. Once you go that route in any way, you are
> not applying UCD methods. Unless you consider users beyond your 4
> walls, it ain't UCD. Simple.

If 37signals really is designing exclusively to "scratch their own itch",
then they are the users, and it could easily be argued they are indeed
practicing UCD principles.

That said, I don't believe for a second that they can truly say they only
design for themselves. Maybe it was true a long time ago, but now that their
livelihoods depend on their customers, it would be foolish to stick to that
mantra.

Why the heck doesn't anyone talk about how Google does (today) and
>
Amazon has for a really long time DO use research. Google does mini
> AB tests out in the wild all the time, and so does Amazon.

So, running AB tests means they're practicing UCD? I would hope they do a
whole lot more than that.

Now, I would like to hear from the host of UCD practitioners here
> about their top of market efforts they work on and how UCD was the
> champion that got them there? and which processes they used.
>

What about people using other approaches on top-of-market products and how
those methods got them there? Are you interested in those stories, or do you
only care about UCD successes?

-r-

24 Jun 2008 - 11:20am
Robert Hoekman, Jr.
2005

>
> As counter examples, I have personal experience with software companies
> focused on software devs who turn out, let's say, less than usable
> products.

This is hardly a counter-example. There are approaches other than UCD that
are every bit as valid and every bit as successful. Not practicing UCD does
not necessarily mean you're letting engineers make all the design decisions.

-r-

24 Jun 2008 - 11:50am
Robert Hoekman, Jr.
2005

>
> Are there any advocates of the idea that UCD is broken out there that can
> clarify what they see the problem with UCD to be?
>

I suppose that would be me.

UCD is filled with problems. Here's a list.

- User research is horribly unreliable, either because it's done poorly,
not done to a great enough extent, or focused on the wrong people.
- Focusing on niche groups can mean alienating audiences that could
otherwise use the product but weren't part of the research.
- User research can be horribly expensive and time-consuming, and I have
yet to work for or with a web company who was willing to devote an
appropriate amount of time to it. Companies with industrial products might
be different (Apple is a notable exception, of course), but on the web,
things move fast. Since the ability to iterate is built into the web, it
makes far more sense, financially, to iterate continually rather than put
great effort into research prior to the start of a project.
- User research, as it's typically done, results in a set of persona
descriptions, which are, well, less than useful as project deliverables.
Managers care about results. Numbers. They want to see progress, not
fictitious character descriptions. They hired you to design, not write movie
scripts.
- Far too many people seem to think you have to perform all new,
app-specific research any time you start work on a new product.
- Reliance on UCD methods can lead managers to mistrust a designer's
instincts, and instincts are a huge part of design. I've seen managers on
many occasions ask for all sorts of research-based validation on things that
should not need it at all—the usability of a design pattern, the validity of
a task flow decision, etc. It discounts the designer's experience, skill,
knowledge, and talent. It turns designers into scientists, and designers
don't make for very good scientists.

I could go on.

Even those who often advocate the practices included within UCD, such as
Jared/UIE (who researched the best web teams to see what they have in
common), fully admit that most of the time these things are done wrong, and
done poorly.

Usability testing has flaws as well, but should still definitely be done
when it makes sense.

For the record, none of this means a non-UCD designer has no understanding
of human behavior on the web. I've personally sat through hundreds of hours
of usability tests, study psychology in my spare time, constantly engage in
conversations with people about their computing experiences, etc. I just
think that it's far better to focus on activities rather than people.

Yes, this can mean talking to people who perform the activities you're
designing to support, but in many cases, you can become a SME on an activity
without ever talking to another person—particularly when designing web apps.

>From there, I rely heavily on metrics—click paths, click stats,
etc.—combined with an iterative design process, to determine how people are
using an app and improve upon it.

No method is perfect, but in my experience, UCD has far too many flaws to
come even close. And considering there are so many great apps out there
designed and built without an ounce of app-specific user research, I think
it's safe to say you can indeed create something wonderful by throwing
traditional UCD methods entirely out the window.

-r-

24 Jun 2008 - 12:36pm
White, Jeff
2007

I don't have time for a long response, but some quick comments:

It's interesting that some of the same people saying "UCD is dead" are the
same ones saying they don't know what it is and are constantly trying to
define it. How can it be dead if we don't know what it is? Seems like a lot
of the argument is around semantics and granular definitions instead of the
broad concept of what UCD is.

For me, all this simply means there is not a standard way of doing things
that is alway repeatable - sometimes UCD is not the right approach and more
a visionary design strategy is best. Apple, some Google products, the other
products mentioned in discussions here are all examples.

However, when the problem is more complex than simple text based search UI,
or playing music on a device, then clearly it can be really advantageous to
pick the appropriate UCD tools and techniques and use them to one's
advantage. It's contextual and making blanket statements about any approach
always working or not working seems unwise. You don't always have to do
personas to do UCD. And UCD research doesn't have to be this monolithic
gigantor of a time and money hog. You can use super cheap and lightweight
methods and get great results.

Industry leaders who use UCD: Salesforce.com, Autodesk, Google, Amazon.com.
Cooper's products, Adaptive Path's clients and products, AA Razorfish. Those
firms I believe are examples of great design, and each use some flavor of
UCD, as far as I know.

I don't think any method should be wholly discarded - as designers we should
have a big 'ole toolbox of approaches, and know when and why to use certain
ones.

UCD is not broken in my opinion. Just my two cents. Great discussions here
recently.

Jeff

On Tue, Jun 24, 2008 at 9:50 AM, Robert Hoekman Jr <robert at rhjr.net> wrote:

> >
> > Are there any advocates of the idea that UCD is broken out there that can
> > clarify what they see the problem with UCD to be?
> >
>
> I suppose that would be me.
>
> UCD is filled with problems. Here's a list.
>
>
> - User research is horribly unreliable, either because it's done poorly,
> not done to a great enough extent, or focused on the wrong people.
> - Focusing on niche groups can mean alienating audiences that could
> otherwise use the product but weren't part of the research.
> - User research can be horribly expensive and time-consuming, and I have
> yet to work for or with a web company who was willing to devote an
> appropriate amount of time to it. Companies with industrial products
> might
> be different (Apple is a notable exception, of course), but on the web,
> things move fast. Since the ability to iterate is built into the web, it
> makes far more sense, financially, to iterate continually rather than put
> great effort into research prior to the start of a project.
> - User research, as it's typically done, results in a set of persona
> descriptions, which are, well, less than useful as project deliverables.
> Managers care about results. Numbers. They want to see progress, not
> fictitious character descriptions. They hired you to design, not write
> movie
> scripts.
> - Far too many people seem to think you have to perform all new,
> app-specific research any time you start work on a new product.
> - Reliance on UCD methods can lead managers to mistrust a designer's
> instincts, and instincts are a huge part of design. I've seen managers on
> many occasions ask for all sorts of research-based validation on things
> that
> should not need it at all—the usability of a design pattern, the validity
> of
> a task flow decision, etc. It discounts the designer's experience, skill,
> knowledge, and talent. It turns designers into scientists, and designers
> don't make for very good scientists.
>
> I could go on.
>
> Even those who often advocate the practices included within UCD, such as
> Jared/UIE (who researched the best web teams to see what they have in
> common), fully admit that most of the time these things are done wrong, and
> done poorly.
>
> Usability testing has flaws as well, but should still definitely be done
> when it makes sense.
>
> For the record, none of this means a non-UCD designer has no understanding
> of human behavior on the web. I've personally sat through hundreds of hours
> of usability tests, study psychology in my spare time, constantly engage in
> conversations with people about their computing experiences, etc. I just
> think that it's far better to focus on activities rather than people.
>
> Yes, this can mean talking to people who perform the activities you're
> designing to support, but in many cases, you can become a SME on an
> activity
> without ever talking to another person—particularly when designing web
> apps.
>
> >From there, I rely heavily on metrics—click paths, click stats,
> etc.—combined with an iterative design process, to determine how people are
> using an app and improve upon it.
>
> No method is perfect, but in my experience, UCD has far too many flaws to
> come even close. And considering there are so many great apps out there
> designed and built without an ounce of app-specific user research, I think
> it's safe to say you can indeed create something wonderful by throwing
> traditional UCD methods entirely out the window.
>
> -r-
> ________________________________________________________________
> 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
>

24 Jun 2008 - 12:53pm
Charlie Kreitzberg
2008

Hi All:

In a reply on the original thread (IxDA), David Malouf said:

' UCD is a collection of methods, not the act of "thinking of users".'

I think that is the core of why this discussion goes on and on.

If all UCD is, is a collection of techniques then of course they will become
antiquated in time as the profession moves on.

However, I do not think of UCD as "a collection of techniques" or even the
'act of "thinking of users." To me it is a philosophy that grew out of the
dissatisfaction that many felt with the way software was being developed in
the early days of computing. Much software was (and sadly still is) designed
by programmers who were not successful in producing usable or desirable
products. Much design was also mandated by business people who made
decisions based on what pleased them or would forward their specific
business goals. Sadly, this too often happens.

UCD grew out of dissatisfaction with the outcomes of these development
practices and was much more than simply a collection of techniques. It was,
and is, a philosophy that argued that we need to focus on users' needs tasks
and activities, their mental models, minimizing their learning curve and
similar issues. The techniques that were developed over the years are ways
to implement this philosophy.

You would think that caring about the user would be a no brainer but that
was not, and still is often not, the case. Corporations are not relationship
oriented. They are not benevolent. They exist to make profit and pleasing
their customers and employees is a secondary consideration at best. So
getting attention for UCD has been a difficult process.

Today the web and the availability of mobile devices have fundamentally
changed things. As the web has become a major channel for connecting with
prospects and customers, there is much more awareness that you need to
please your users to succeed. That's a good thing.

The evolution of the web has also altered the way we think about user
interactions. It is no longer about one user in front of one computer
consuming the information parceled out by a centralized IT command and
control structure. We are much more about community, user generated
information, and complex social interactions. In that environment, there is
no doubt that we should rethink the techniques of UCD which are often
cumbersome and may not yield as much as we would like.

So, why is this all an issue?

We still have a long way to go in convincing the world of the importance of
what we do. We are finally getting some traction as the business world sees
advantage. We need to present a simple and comprehensible face to the
external world and focus on developing the field. Whatever differences we
may see between approaches like UCD, ACD, Ix, IA, Ux are only valuable when
they lead to clarity and common understanding, not when they lead to
confusion and hairsplitting.

In my opinion, every interactive design should be useful, usable and
desirable. Whatever techniques produce that result are worth understanding
and using.

So taking the position that UCD is just a collection of techniques and not a
philosophy about what's important to creating superb interactive products
will surely lead you to discount it over and over. Personally, I find that a
bit boring.

Charlie

===========================
Charles B. Kreitzberg, Ph.D.
CEO, Cognetics Corporation
============================

24 Jun 2008 - 1:05pm
Mark Schraad
2006

Reading this conversation is making my head hurt. It seems like a
waste of time debating the definition and importance of such a vague
term as UCD.

In my workplace people through our 'user centered' and 'user
experience' largely without any real thought or concern for the user.
Frankly, most of our initiatives are built with great user
indifference.

Some better questions to debate might be:

1 How do we accurately identify our users?

2 How do we get better, faster and more relevant data regarding what
will work for users?

3 To what extent should we consider the user? Certainly technical
constraints and business models must remain a concern. How to we blend
our user data with the other two and maintain singular vision for
product?

Lastly, and I guess I will put Robert on the spot here, if you don't
believe the current state of identifying, researching and applying
user data is up to snuff, then why not try to improve methods? An end
around the entire issue does not seem like a real solution. Given the
choice, is getting into shape not a better route than just waiting for
the double bypass?

Mark

On Tue, Jun 24, 2008 at 1:53 PM, Charles B. Kreitzberg
<charlie at cognetics.com> wrote:
> Hi All:
>
> In a reply on the original thread (IxDA), David Malouf said:
>
> ' UCD is a collection of methods, not the act of "thinking of users".'
>
> I think that is the core of why this discussion goes on and on.
>
> If all UCD is, is a collection of techniques then of course they will become
> antiquated in time as the profession moves on.
>
> However, I do not think of UCD as "a collection of techniques" or even the
> 'act of "thinking of users." To me it is a philosophy that grew out of the
> dissatisfaction that many felt with the way software was being developed in
> the early days of computing. Much software was (and sadly still is) designed
> by programmers who were not successful in producing usable or desirable
> products. Much design was also mandated by business people who made
> decisions based on what pleased them or would forward their specific
> business goals. Sadly, this too often happens.
>
> UCD grew out of dissatisfaction with the outcomes of these development
> practices and was much more than simply a collection of techniques. It was,
> and is, a philosophy that argued that we need to focus on users' needs tasks
> and activities, their mental models, minimizing their learning curve and
> similar issues. The techniques that were developed over the years are ways
> to implement this philosophy.
>
> You would think that caring about the user would be a no brainer but that
> was not, and still is often not, the case. Corporations are not relationship
> oriented. They are not benevolent. They exist to make profit and pleasing
> their customers and employees is a secondary consideration at best. So
> getting attention for UCD has been a difficult process.
>
> Today the web and the availability of mobile devices have fundamentally
> changed things. As the web has become a major channel for connecting with
> prospects and customers, there is much more awareness that you need to
> please your users to succeed. That's a good thing.
>
> The evolution of the web has also altered the way we think about user
> interactions. It is no longer about one user in front of one computer
> consuming the information parceled out by a centralized IT command and
> control structure. We are much more about community, user generated
> information, and complex social interactions. In that environment, there is
> no doubt that we should rethink the techniques of UCD which are often
> cumbersome and may not yield as much as we would like.
>
> So, why is this all an issue?
>
> We still have a long way to go in convincing the world of the importance of
> what we do. We are finally getting some traction as the business world sees
> advantage. We need to present a simple and comprehensible face to the
> external world and focus on developing the field. Whatever differences we
> may see between approaches like UCD, ACD, Ix, IA, Ux are only valuable when
> they lead to clarity and common understanding, not when they lead to
> confusion and hairsplitting.
>
> In my opinion, every interactive design should be useful, usable and
> desirable. Whatever techniques produce that result are worth understanding
> and using.
>
> So taking the position that UCD is just a collection of techniques and not a
> philosophy about what's important to creating superb interactive products
> will surely lead you to discount it over and over. Personally, I find that a
> bit boring.
>
> Charlie
>
> ===========================
> Charles B. Kreitzberg, Ph.D.
> CEO, Cognetics Corporation
> ============================
>
>
> ________________________________________________________________
> 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
>

24 Jun 2008 - 1:12pm
Robert Hoekman, Jr.
2005

>
> Lastly, and I guess I will put Robert on the spot here, if you don't
> believe the current state of identifying, researching and applying
> user data is up to snuff, then why not try to improve methods?

What makes you think I would do all this complaining without offering an
alternative?

http://www.peachpit.com/guides/content.aspx?g=webdesign&seqNum=352

Pick it apart all you want, but this approach has worked remarkably well for
me, my employers, and my clients, in project after project, for several
years now.

-r-

24 Jun 2008 - 1:16pm
Christine Boese
2006

To play Amen chorus to Charlie, with whom I strong agree, let me add one
more important thing UCD is, perhaps the most important thing:

UCD is a political stance, a position of political advocacy on behalf of
what some may call at worst an oppressed or often overlooked group or class
or people: users, co-authors, navigators, creators, etc.

And whenever you talk about political advocacy, POWER is part of the
equation. Add power to the mix, and the stakes go up, cuz you can give
nominal lip service to just about anything, but transferring REAL power,
well, that's a much more radical act. A collection of methods can be easily
de-fanged, made innocuous to any of the other existing power groups anxious
to hang on to their turf (engineers, advertisers, stakeholders, what have
you). A collection of methods can be hidden behind, like "Hey, we do UCD, we
did our due diligence!"

And UCD must then necessarily have, underlying everything, a position of
political advocacy, to find ways to give users voice, to bring users and
their empowered social groups into the conversations, to allow them to build
virtual worlds in their own image, and to advocate always on their behalf.
And more importantly, it must put its money where its mouth is, and make a
difference for users.

In the immortal words of Dr. Seuss from The Lorax:

"I am the Lorax, I speak for the Trees! [users!]"

Chris

On Tue, Jun 24, 2008 at 1:53 PM, Charles B. Kreitzberg <
charlie at cognetics.com> wrote:

> Hi All:
>
> In a reply on the original thread (IxDA), David Malouf said:
>
> ' UCD is a collection of methods, not the act of "thinking of users".'
>
> I think that is the core of why this discussion goes on and on.
>
> If all UCD is, is a collection of techniques then of course they will
> become
> antiquated in time as the profession moves on.
>
> However, I do not think of UCD as "a collection of techniques" or even the
> 'act of "thinking of users." To me it is a philosophy that grew out of the
> dissatisfaction that many felt with the way software was being developed in
> the early days of computing. Much software was (and sadly still is)
> designed
> by programmers who were not successful in producing usable or desirable
> products. Much design was also mandated by business people who made
> decisions based on what pleased them or would forward their specific
> business goals. Sadly, this too often happens.
>
> UCD grew out of dissatisfaction with the outcomes of these development
> practices and was much more than simply a collection of techniques. It was,
> and is, a philosophy that argued that we need to focus on users' needs
> tasks
> and activities, their mental models, minimizing their learning curve and
> similar issues. The techniques that were developed over the years are ways
> to implement this philosophy.
>
> You would think that caring about the user would be a no brainer but that
> was not, and still is often not, the case. Corporations are not
> relationship
> oriented. They are not benevolent. They exist to make profit and pleasing
> their customers and employees is a secondary consideration at best. So
> getting attention for UCD has been a difficult process.
>
> Today the web and the availability of mobile devices have fundamentally
> changed things. As the web has become a major channel for connecting with
> prospects and customers, there is much more awareness that you need to
> please your users to succeed. That's a good thing.
>
> The evolution of the web has also altered the way we think about user
> interactions. It is no longer about one user in front of one computer
> consuming the information parceled out by a centralized IT command and
> control structure. We are much more about community, user generated
> information, and complex social interactions. In that environment, there is
> no doubt that we should rethink the techniques of UCD which are often
> cumbersome and may not yield as much as we would like.
>
> So, why is this all an issue?
>
> We still have a long way to go in convincing the world of the importance of
> what we do. We are finally getting some traction as the business world sees
> advantage. We need to present a simple and comprehensible face to the
> external world and focus on developing the field. Whatever differences we
> may see between approaches like UCD, ACD, Ix, IA, Ux are only valuable when
> they lead to clarity and common understanding, not when they lead to
> confusion and hairsplitting.
>
> In my opinion, every interactive design should be useful, usable and
> desirable. Whatever techniques produce that result are worth understanding
> and using.
>
> So taking the position that UCD is just a collection of techniques and not
> a
> philosophy about what's important to creating superb interactive products
> will surely lead you to discount it over and over. Personally, I find that
> a
> bit boring.
>
> Charlie
>
> ===========================
> Charles B. Kreitzberg, Ph.D.
> CEO, Cognetics Corporation
> ============================
>
>
> ________________________________________________________________
> 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
>

24 Jun 2008 - 1:33pm
Mark Schraad
2006

Nice article, but it does not really address the primary problem with
the current state of design research.

You can not effectively 'gear up' and do user research in the web
world (or any other evolving moving market). It moves to damn fast.
And on one of the only issues that I will side with the agile folks,
big design up front is too slow when research is involved. I
understand that research is best when purposed and targeted to answer
specific problems. But business, across the board, does a terrible job
of knowing it's users.

No accounting department worth its crust waits until the end of the
reporting period to gather records.

User research should be an ongoing and exhaustive effort on the part
of any company introducing products into the marketplace.

1 That it seems expensive is not an excuse. User research is not a
cost. When done right it is an investment geared towards reducing risk
and increasing value - both are near and dear to most any MBA's sense
of self preservation.

2 That others don't do it does not fly either. User research leads
directly to opportunities for marketplace differentiation... which
leads to larger margins. Again, increased profit can be a pretty good
motivator for MBA's.

3 Most market leaders fall (when they fall) at the hands of disruptive
model upstarts. User research can expose features that users do not
have an interest in.

Mark

On Tue, Jun 24, 2008 at 2:12 PM, Robert Hoekman Jr <robert at rhjr.net> wrote:
>> Lastly, and I guess I will put Robert on the spot here, if you don't
>> believe the current state of identifying, researching and applying
>> user data is up to snuff, then why not try to improve methods?
>
> What makes you think I would do all this complaining without offering an
> alternative?
> http://www.peachpit.com/guides/content.aspx?g=webdesign&seqNum=352
> Pick it apart all you want, but this approach has worked remarkably well for
> me, my employers, and my clients, in project after project, for several
> years now.
> -r-

24 Jun 2008 - 2:39pm
Scott Berkun
2008

> Charles B. Kreitzberg wrote:
>
> However, I do not think of UCD as "a collection of techniques" or even the
> 'act of "thinking of users." To me it is a philosophy that grew out of the
> dissatisfaction that many felt with the way software was being developed
> in
> the early days of computing. Much software was (and sadly still is)
> designed
> by programmers who were not successful in producing usable or desirable
> products. Much design was also mandated by business people who made
> decisions based on what pleased them or would forward their specific
> business goals. Sadly, this too often happens.

I've been mistified by the last few threads here, and until Charles'
comments I wasn't entirely sure why.

It's worth nothing that a near majority of breakthroughs in what we consider
good interface design were driven by people with none of the trainings or
backgrounds we obsess about here. They would almost all describe themselves
primarily as programmers, engineers or entrepreneurs.

That list includes:

The Xerox Parc folks
The Macintosh Team
Tim Berners-Lee (Inventor of the web)
Doug Englebart (Inventor of the mouse)
The Mosaic team
The founders of Digg, Google, Facebook, Myspace, Youtube, ...
and on it goes

Yet somehow we're all still very fond of finding ways to exclude who should
be leading this or in charge of that, or decreeing what pile of methods and
degrees is best for creating the future that we want, despite tons of
evidence that great design movements were driven by people with none of
these things.

Yes, programmers and business people can mess things up - I do agree with
you Charles. But they're also on the list of people that made the big leaps
in design and UI happen. I find it hard to think of big moves forward in the
UI world led by people who would primarily call themselves designers, IAs,
IXDs, or whatever. (Anyone have a reference for a good history of UI
breakthroughs? that would prove me right or wrong quickly)

For a bunch of creatives we can be pretty damn narrow minded - there is
clearly a talent we don't talk about much than enables some people to find
great design insights without the 100 piece toolkit of methods and degrees
we obssess about. And these people without our pedigrees are highly
represented in the tradition we believe we'd like to follow.

But my point is not to throw the methods and degrees away. And I'm not
advocating that the answer is to bet everything on people with no training.

Instead my point is the fact that we have a system doesn't mean there aren't
other systems to achieve the same ends. Just because we prescribe a year of
usability studies and six interaction designers with masters degrees to
achieve a result, doesn't mean there aren't two very talented kids in a
basement who can't make something almost as good, or better in some ways, in
half the time.

We should be studying how people with little of *our* training and expertise
are able to achieve what they did - we might just learn ways to refine our
fancy IxDA/IA/UCD/HCI/XYZ view of the world into something closer to the
core of what makes great designs possible. We've become numerous enough now
to be highly specialized, and specialization serves incremental change, not
innovation. One reason the big historic moves are driven by people without
our expertise is they're less likely to be bound to a prescribed set of
ideas, roles or methods in the way many of us have become.

-Scott

Scott Berkun
www.scottberkun.com

24 Jun 2008 - 1:29pm
Eduardo Loureiro
2008

In my view, when we talk about UCD, we are talking about tools and as such
can be used for good or for bad. UCD makes sense when it comes to
interactive products, so we better know who will use the product and what it
really needs is essential, after all we are not working on something for his
own use. But UCD is just one of the possible approaches, can not be seen as
a rule.

Everything is relative.

--
Eduardo Loureiro
Interaction designer
http://eduardoloureiro.com
t: 55 31 8836.6520

Mapa Digital
http://mapadigital.net
t: 55 31 3291.5811

24 Jun 2008 - 3:45pm
Robert Hoekman, Jr.
2005

>
> Nice article, but it does not really address the primary problem with
> the current state of design research.

And that would be?

> You can not effectively 'gear up' and do user research in the web
> world (or any other evolving moving market). It moves to damn fast.

Agreed. Hence the discussion in Part 1 of the series about it taking too
much time.

1 That it seems expensive is not an excuse. User research is not a
>
cost. When done right it is an investment

Hmm. I'd rephrase that. Designing a high quality experience for a valuable
product is an investment, regardless of how you achieve it. User research by
itself is not an investment—it's a cost. If it's a cost that contributes to
the high quality user experience, then your right on, but it often doesn't.
In fact, it can have a negative affect on the user experience for people
outside the researched audience, and even those within it.

2 That others don't do it does not fly either. User research leads
> directly to opportunities for marketplace differentiation... which
> leads to larger margins. Again, increased profit can be a pretty good
> motivator for MBA's.

Sure, but there are other ways to achieve market differentiation. User
research is one way, not the only way.

> 3 Most market leaders fall (when they fall) at the hands of disruptive
> model upstarts. User research can expose features that users do not
> have an interest in.
>

Then how is it that these disruptive upstarts, who often have no time or
money for user research, are creating products so great that they're causing
market leaders to fall?

-r-

24 Jun 2008 - 3:53pm
Uday Gajendar
2007

I've written a post awhile back about UCD, citing some issues and how
it's more important to consider UCD as an overarching philosophy
balancing multiple centers, driven by the simple yet powerful premise
that people matter (it's quite shocking how many companies don't truly
get this). And hinting that there needs to be deeper conversation by
ixd folks around "(digital) product development", not just around UCD
in and of itself, but part of a much larger and more complex activity
and environment of practice.

http://www.ghostinthepixel.com/?p=95

More fuel for the fire... :-)

Uday Gajendar
Sr. Interaction Designer
Voice Technology Group
Cisco | San Jose

24 Jun 2008 - 3:57pm
Robert Hoekman, Jr.
2005

>
> It's worth nothing that a near majority of breakthroughs in what we
> consider good interface design were driven by people with none of the
> trainings or backgrounds we obsess about here. They would almost all
> describe themselves primarily as programmers, engineers or entrepreneurs.

Bravo, Scott. Your entire post is dead on.

I often wonder if some of these UCD practices exist primarily because there
aren't enough visionaries-slash-revolutionaries in the world. As in, these
practices are an attempt to provide a recipe for people who are not
necessarily chefs—so that a lot of people can produce good designs and
quality products instead of only those who are naturally great at it
(Jonathan Ives, for example).

There's a big difference between a "drummer" and "someone who plays drums".
There's also a big difference between a "master chef" and "someone who cooks
well". I'm sure you can see the analogy.

Scott also said, "We should be studying how people with little of *our*
training and expertise are able to achieve what they did".

I agree 100%, but I also wonder if this is how UCD, GDD, and others came
about in the first place

-r-

24 Jun 2008 - 4:22pm
Charlie Kreitzberg
2008

Mark:

Your comment...

"Yes, programmers and business people can mess things up - I do agree with
you Charles. But they're also on the list of people that made the big leaps
in design and UI happen."

...is completely on target. I started as a programmer and migrated to UX
because I was so enthralled by computers that I wanted to bring them to
everyone.

Sometimes I get frustrated by developers and by business people too. But
being married to a business thinker, I've also learned how much depth there
is to business as well.

I believe that the most progress will be made when business, technology and
user experience design are aligned and synergistic. That's why we need to
share our vision with others in a constructive way and learn from them as
well.

One of my professional goals is to help developers understand the UCD (or
whatever we want to call it) design approach. What I've realized is that to
teach developers what I know, I need to learn from them as well. It's been a
long time since I created code and the field has shifted so much that I've
become almost technically illiterate where I once was competent.

Like many on this list I value innovation. But I have learned, is that not
everyone is an innovator. There are many competent people who want to
understand how to do good design. They may not be breakthrough thinkers nor
do they aspire to be. A lot of business people fit into that category. They
want to do their job well and want to know how to measure success. Their
passion may lie elsewhere.

If you are a creative, passionate individual it is easy to discount these
people as uninspired. But that's not really fair. As Ambrose Little said
earlier in this thread:

"As for innovation...businesses can't bank on that, and even most who aspire
to that will fail....I don't think it's wise to...toss out process--the
point of which is to provide some repeatable consistency, even if imperfect
and not particularly sexy."

While I push back on those who say "UCD is Broken," I also listen to them
very carefully. I think that there is merit in their criticism and it does
spur me to rethink ideas that I may have held uncritically for some time.
What I don't agree with is the idea that you must discard the past to move
forward. For me, that's too cheap and easy an approach.

In the US, many of our folk heroes are mavericks who, without formal
schooling in the status quo, come up with a breakthrough idea that turns
everything on its head. Sometimes that model works and produces exciting
results. But what we forget is that most innovations come from people who
studied the process and were insightful enough to see beyond it. Beethoven
studied Bach. Picasso studied El Greco and Gauguin. Like Newton, they "saw
father than other because they stood on the shoulders of giants."

We need both rich process and breakthrough thinking. And understanding the
former is one of the best ways to achieve the latter.

Charlie

============================
Charles B. Kreitzberg, Ph.D.
CEO, Cognetics Corporation
============================

24 Jun 2008 - 4:40pm
Andrei Herasimchuk
2004

On Jun 24, 2008, at 1:57 PM, Robert Hoekman Jr wrote:

> I agree 100%, but I also wonder if this is how UCD, GDD, and others
> came
> about in the first place

http://en.wikipedia.org/wiki/User-centered_design

It's interesting to note how little there is about design in an entry
titled "user centered design." I will also note, that a statement like:

"In broad terms, user-centered design (UCD) is a design philosophy and
a process in which the needs, wants, and limitations of the end user
of an interface or document are given extensive attention at each
stage of the design process."

Could only come from a group of people with little industrial design
or graphic design training. Both ID and GD are rooted in things like
communication, context and audience. To ignore the audience or the
customer is inherently bad design process. In other words... UCD at
best is redundant as a concept and at worst, allows an opening to
engage in poor design practice by ignoring the balance that is need in
creating products between use, technology and commerce.

My experience has been that UCD came into being because too many
people without design backgrounds were thrust into an environment in
software and interface design where they had to go toe to toe with
hard-nosed engineers or business types. Since too many people lacked
design training or lacked the ability to work through the means to
communicate with those types of people who think in terms of pure
business or pure technology, early folks in this industry fell back to
what they knew since many of them came from backgrounds that were more
rooted in research or process: They invented a "process" that forces
the team back to consider the user at every stage to create the balance.

Good design assumes an understanding of audience, context and aims to
fully communicate and converse. And even so, good design is ultimately
a balancing act to address a large set of concerns, of which the user
is but one piece.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

24 Jun 2008 - 4:44pm
Robert Hoekman, Jr.
2005

>
> What I don't agree with is the idea that you must discard the past to move
> forward. For me, that's too cheap and easy an approach.
>

I greatly respect your willingness to pay close attention to and consider
opposing arguments, but this particular point bothers me.

"The past" is filled with far more examples of products, innovative
thinking, and success stories based on activity-centered research, magic,
genius design, and just plain luck than UCD can claim even on its best day.

What's cheap and easy is the idea that we can dissect a chef's work and call
it a recipe. That we can simply analyze genius and come out with a
one-size-fits-all plan for success.

-r-

24 Jun 2008 - 5:05pm
SemanticWill
2007

Here is my only problem with the discussion so far. It's at best anecdotal
based. (Robert - this isn't pointed at you - to the discussion, so no one
should take this personal).

"Most" "Many" etc when those are completely normative statements not backed
up by real numbers. I concede, heartily, that some of the most innovative,
cool, ground-breaking things that have come out in the last 10 years did not
use UCD by any stretch of the imagination. Maybe they went against every
tenant. Maybe the very best in the entire world worked on those projects.
But at the end of the day - for every phenomenal success that didn't use
UCD, let me show you 10, 50, 100, 1000 products that are complete and utter
disasters - that also didn't use UCD.
You can't (well you can - but you will have little legitamacy), argueing the
failure of UCD by pointing to the 1 in 1000 products that are amazing acts
of genius.

I think there are some great fundementals in UCD that can help make the
other 999 products a little less crappy, a little more humane - and the
truth of the matter is that you, me, and just about everyone on this list -
makes our bread and butter by working on those 999 products.

On Tue, Jun 24, 2008 at 5:44 PM, Robert Hoekman Jr <robert at rhjr.net> wrote:

> >
> > What I don't agree with is the idea that you must discard the past to
> move
> > forward. For me, that's too cheap and easy an approach.
> >
>
> I greatly respect your willingness to pay close attention to and consider
> opposing arguments, but this particular point bothers me.
>
> "The past" is filled with far more examples of products, innovative
> thinking, and success stories based on activity-centered research, magic,
> genius design, and just plain luck than UCD can claim even on its best day.
>
> What's cheap and easy is the idea that we can dissect a chef's work and
> call
> it a recipe. That we can simply analyze genius and come out with a
> one-size-fits-all plan for success.
>
> -r-
> ________________________________________________________________
> 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
>

--
~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"

---------------------------------------------------------------------------------------------
Will Evans | User Experience Architect
tel +1.617.281.1281 | will at semanticfoundry.com
twitter: https://twitter.com/semanticwill
---------------------------------------------------------------------------------------------

24 Jun 2008 - 7:26pm
Charlie Kreitzberg
2008

I know I shouldn’t get into another fruitless discussion with you but your
post is just too off base to ignore. I promise to the list this will be my
one and only post on your points.

I said:

What I don't agree with is the idea that you must discard the past to move
forward. For me, that's too cheap and easy an approach.

Your reply was:

"The past" is filled with far more examples of products, innovative
thinking, and success stories based on activity-centered research, magic,
genius design, and just plain luck than UCD can claim even on its best day.”

How do you know this? Where is your data? Do you know what UCD has
accomplished and how are you comparing it to magic?

You cite activity centered design as a “different thing” from user centered
design. For those readers who are not familiar with the background, in 1968
the computer scientist Edsger Dijkstra's wrote a letter in Communications of
the ACM titled "Go To Statement Considered Harmful.” This has become a
popular title for academic critical essays.

In 2005, Don Norman wrote an essay for Interactions (also published by ACM)
titled Human-Centered Design Considered Harmful. In this essay he stated
“The purpose of this essay is to provoke thought, discussion, and
reconsideration of some of the fundamental principles of Human-Centered
Design. These principles, I suggest, can be helpful, misleading, or wrong.
At times, they might even be harmful. Activity-Centered Design is superior.”
It’s worth reading the article and also the clarification in which he said:

“The problem, however, is that HCD has developed as a limited view of
design. Instead of looking at a person's entire activity, it has primarily
focused upon page-by-page analysis, screen-by-screen. As a result,
sequences, interruptions, ill-defined goals — all the aspects of real
activities, have been ignored. And error messages — there should not be any
error messages. All messages should contain explanations and offer
alternative ways of proceeding from the message itself.”

Now the title is cute and the point a really good one. I agree with it
completely. But to suggest that ACD is the “replacement” for 30 years of
development is really simplistic. Norman was doing exactly what I suggested
in my original post – suggesting how to improve on existing techniques. But
I doubt that he would seriously suggest that we need to abandon user
centricity as a goal. In fact, he said just the opposite.

Next you said:

“What's cheap and easy is the idea that we can dissect a chef's work and
call it a recipe. That we can simply analyze genius and come out with a
one-size-fits-all plan for success.”

Now I love genius chefs! I watch Iron Chef several times a week (both the
Japanese and American versions). But, Robert, how many cookbooks have been
published? I was going to ask chacha.com but my cell phone battery is about
dead. So instead I went to amazon.com and typed in “cookbook.” I realize
that this is an underestimate but I got back 78,981 results.

So guess what. Most of us, we will continue to cook with recipes. Some of us
will be pretty good cooks, some will be less good. I suspect that most of
the genius chefs honed their skills on lots of recipes. There may be someone
in a garage somewhere who is thinking out of the box, has never read a
cookbook or studied sautéing will come up with a great new way to prepare
food. But since I’m more of a journeyman cook, I’ll hang on to my Joy of
Cooking.

Here is what I propose:

1. Let’s agree that putting the user at the center of our thinking is
still a really good idea.

2. Let’s agree that the world has changed since 1982 when UCD was first
created and let’s expand and extend it with activity centered design and
every other good idea we can come up with so we create even better tools.

3. Let’s acknowledge the great contribution that design has made to the
process and work hard to integrate it into UCD (or whatever we want to call
it).

I think we should stop equating UCD (or whatever you want to call it), which
has 30 years of effort and research behind it as if it were irrelevant.
Personally, as long as the design approach creates a product that is useful
to the user and usable, I don’t care what name you give it.

Charlie

============================

Charles B. Kreitzberg, Ph.D.

CEO, Cognetics Corporation

============================

From: Robert Hoekman Jr [mailto:robert at rhjr.net]
Sent: Tuesday, June 24, 2008 5:44 PM
To: charlie at cognetics.com
Cc: Scott Berkun; IXDA list
Subject: Re: [IxDA Discuss] Is UCD Really Broken?

What I don't agree with is the idea that you must discard the past to move
forward. For me, that's too cheap and easy an approach.

I greatly respect your willingness to pay close attention to and consider
opposing arguments, but this particular point bothers me.

What's cheap and easy is the idea that we can dissect a chef's work and call
it a recipe. That we can simply analyze genius and come out with a
one-size-fits-all plan for success.

-r-

24 Jun 2008 - 8:06pm
Dave Malouf
2005

Hey! I 100% agree with Andrei.
What gets me about UX & UCD of late are the folks that jones Lowgren
calls out in the previously referenced article (different thread) the
HCI side of IxD.

Chsrlie, I'm picking on you b/c you outlined why UCD came into
being. UCD is an engineers answer to engineering problems. And I
think after living with design research imstead of user research for
awhile now I really see parallels (the thing we do at Moto on first
bluff would look like UCD) but there are deeper differences around
processes & methods, and the overarching spirit, strategy, goals &
end uses of the research that don't resemble anything you would find
@ CHI or UPA.

Further, what really gets me about Charlie's post which. think
Andrei talked about is the presumption that somehow users aren't
being considered by other design disciplines already. You talk about
not throwing away the past, but I feel you are ignoring the past b/c
of your unique point of view.

Look at the early IVD inventors from Norman to Nielsen and all the
early HF folks. These people were all engineers/scientists. They
noticed an impprtant problem & applied scientific methods to it,
while a host of others are now engaged in the same problem set using
non-rational, multi-linear processes applied to the same problem set,
that they've been applilyong for decades before the transister ever
existed.

I want to add that I really enjoyed Scott's approach. I would add
that often engineering leads innovation b/c of historical reasons.
Good reasons. But there is something about the relationship between
design & culture that I think makes it hard to be "disruptive" like
the examples we've mentioned.

If UCD is a philosophy though, I think it is weakened b/c of its
narrow scope. Focusing purely ok the user/human experience doesn't
always lead to what is beat for ALL humans.

- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from ixda.org (via iPhone)
http://www.ixda.org/discuss?post=30642

24 Jun 2008 - 11:15pm
ambroselittle
2008

First off, I have to say I was surprised in the directions this thread
took. Not quite what I expected, but it is certainly interesting. Thanks
to everyone who is participating. It is great to get different
perspectives.

On Tue, Jun 24, 2008 at 2:12 PM, Robert Hoekman Jr <robert at rhjr.net> wrote:

> What makes you think I would do all this complaining without offering an
> alternative?
>
> http://www.peachpit.com/guides/content.aspx?g=webdesign&seqNum=352
>
Hi Robert,

In the referenced article, you say: "Do you think Google's home page was
designed for a specific set of user types?"

At *An Event Apart* today, Jeffrey Veen said, essentially, yes--he didn't
show personas, per se, but he did show pictures of and described target user
types that sure sounded a lot like them. And in fact he said, and I quote,
"weaving all that [Google apps] together took a tremendous amount of
user-centered design." He mentioned lots of ethnography and anthropology.
He showed a really interesting chart that very simply illustrated the reason
to do user research--it is waay cheaper to change the (potential) design
(i.e., narrow the design options) prior to even designing anything by doing
research. He said that you do research to research the risk out of a
project and provide a creative base upon which to build the product.
[Sounds like Mark Schraad hit on some of the same points in this thread.]
(Thanks to Jeffrey for the presentation--it was a high point of today.)

I suppose we can all draw our own conclusions from this. At a minimum, it
appears that UCD is going strong at Google.

You mention the problem of getting unexpected user types on the Web, saying
that this invalidates designing for specific types of users (personas).
However, there is an adage that says you can't please everybody and that if
you try to please everybody, you won't please anybody. In fact, even for
the Web (with exceptions, of course), seems like most companies have an
expected target audience and no doubt they're somewhere near the mark--you
don't design a base camp expecting AARP members to show up and start using
it en masse.
I'm not really trying to change your mind, FWIW. You seem to have an
approach figured out that works for you, and I think that's great. I just
kind of wonder if it is necessary to lambast an approach to design that so
many successful companies (mentioned by others on this thread) use in order
to share what works for you in your experience.

I also loved what Will said:
"I think there are some great fundementals in UCD that can help make the
other 999 products a little less crappy, a little more humane - and the
truth of the matter is that you, me, and just about everyone on this list -
makes our bread and butter by working on those 999 products."

This is so painfully true, from my perspective. I think maybe the folks on
this list have a skewed vision of what goes on "out there" on (dare I say)
"most" <grin> software projects, i.e., most internal biz apps--not fancy Web
2 or big product shops, which are I think a very small portion of all
software being built. Project failures are very high; this is a well-known
fact supported by lots of research. A lot of these fail just by taking too
long/costing too much, which I think is symptomatic primarily of
overengineering, a lack of focus on what is actually important to users and
too much focus on fancy, "reusable" architectures that attempt to put
non-organic control structures on essentially organic, social problems.

Of those that are completed, many are essentially loathed by users because
of their terrible, terrible UIs. This is I think symptomatic of the utter
and complete lack of empathy on the part of the developers who see UI as
something to be slapped on at the end or, worse, auto-generated from a
database and a bit of metadata. And it is reinforced by biz interests who
don't understand and dismiss the value of some sort of investment in good
UX.

To address this, the Agile approach has been slowly but surely gaining
ground over the last decade or so, and Scott Ambler has been doing research
to support that it really is working to reduce project failures. The core
principle of Agile is iterative refinement of a design through direct,
regular interaction with the stakeholders who are, often, representatives
of (if not actually) the users. I see it is a kind of UCD. There's this
thing called Domain Driven Design that goes to the next level
by strategically focusing dev resources on the critical domain (called core
domain) and working towards a common language between the biz and devs
(called the ubiquitous language) that is carried through the entire process,
including into the code itself. In other words, it aims to greatly enhance
communication and reduce or altogether eliminate miscommunication caused by
translation between the business and dev. So far, I think it's about the
best engineer-developed software design approach.

The problem with Agile, even DDD, though, is that they are still not making
users a first class concept of their design--they're far more concerned with
abstract ideals of domain modeling, business rules, data storage and
retrieval, reusability, maintainability, etc. These are all important,
though, so I think figuring out a way to inject empathy for users into these
has the most promise for the average biz software dev team, with a view
towards shifting more into gaining a better understanding of users and their
needs as well as iterative prototyping prior to building to reduce cost of
change.

Certainly, one thing in the article that does resonate with me is the lack
of resources issue, but I think that doesn't really invalidate the
philosophy, it just changes your techniques, as Charlie said. To me it
makes perfect sense to adapt the level of research to the constraints of the
project, but centering your design on at least some semblance of a real user
is going to be better than just not thinking about the user at all or,
worse, thinking of the users as annoying morons which is an unfortunate
commonality among the devs who build so many business apps today and in the
past. (You have seen the t-shirt that says 'select * from users where clue
> 0; results - 0 rows' right? Very popular dev conceit...)

Yesterday, Jeffrey Zeldman emphasized the need for empathy in design. To
me, that seems to be the core of it. It matters a whole lot less how you
get empathy--just get it. User research and, specifically, personas seem to
be a great, common sensical, human way to get such empathy. Just spending
time with real users will do wonders, as I guess everyone here knows. Dave
and others suggest empathy is just common sense for those with a ID or GD
background. Good for them! Unfortunately, most software isn't created by
such enlightened folk, and, to be fair, I think there are plenty of GDs (at
least) who are more concerned with their own artistic expression than
getting empathy with users (or devs who need to build their design, for that
matter).

In the end, I find myself returning to, shall I say, my original hypothesis,
which is that UCD is not broken. It is a toolbox of techniques and a
general procedural framework for helping product creators gain empathy with
their users with a view to building the right thing, the right way. The
value it brings over the Genius-Centered Design (GCD [TM]) approach is that
of a far greater potential for reliable, repeatable results. It's no
guarantee, but it seems to make a lot more sense and show a lot more promise
than the other approaches to software design.

This is just my conclusion based on my experience, research, and discussions
thus far (and is subject to change pending new experience, info, &
reasoning). I'm not asking anyone to agree with me; I'm just throwing out
my thoughts as food for thought, for what they're worth. And I appreciate
that others have done the same. Thank you all again for the stimulating
discussion.

Now off to get some much needed shut eye!

--Ambrose

25 Jun 2008 - 2:06am
Janne Kaasalainen
2008

As a disclaimer, I've been recently working on consumer electronic space,
designing about 60% to the devices, 30% for web and remaining percentage
points for various other media. Why this is meaningful hopefully opens up
later on in the reply.
In any case, many of the "faults" in UCD that I've encountered are not often
the faults of UCD itself, but the way in which people try to follow the
taught methods. It's not uncommon to hear or see that something is done just
because it's "supposed" to be done, without questioning. Further, given that
many products fail, UCD undoubtedly has a place on many areas to increase
the probabilities to make a decent thing. Not all of us are Google or Apple,
and not all projects are there to change the world in fundamental ways. As
if that was not enough, a designer can end up working on area that s/he has
no previous knowledge of - in which case doing user research is more or less
fundamental even if done without adhering to "full" UCD cycles. Finally, the
benefits of UCD are more clearly seen in refinement iterations of your
projects.

Now, the good out of the way, there are some issues with many UCD practices,
even if not with the concept itself. One of my biggest issues is with the
kick-start of new projects. Moments when you don't know who your users are,
when you are working on areas that provide new models and break technical
barriers. The times that you just know that asking from the right users is
almost impossible or extremely hard. When there are no established
practices. It's not even that hard to come up with such stuff these days. In
some of these cases, user research findings can destroy good concepts that
haven't been explored deep enough yet. In some ways, ignorance can be a
blessing.

Users lie. They are unable to imagine themselves and the change in society.
They are in some ways fixed to their current practices, which themselves can
be a result of necessities, not optimal decisions. Thus, user-research can,
in some cases, prevent break-throughs.

After all this bashing, though, it would be good to remember that designers
are not always that much better. If design is separated from implementation
and engineering work, it is often easy to come up with unrealistic specs.
Lack of technical know-how can lead to wrong guesses of what is possible and
ignorance to the points where expanding what is possible would be within
reach. This is not as easily seen with web-stuff, given the relative stable
UI model. But there are times when you can work with the platform and make
the thing less involving just by technical advancements. UCD might not help
here, but neither would a purely designer-driven team either. The examples
earlier that showed engineers making breakthroughs fit this picture quite
well. And none of this should be any news, really.

In the end, I guess the question is a bit moot. UCD, in my view, faults in
that it is at times followed blindly. But it can be utilized in many
circumstances. Other methods exist as well, but such does not make UCD dead
. UCD is a bit like democracy - it's not perfect, but at least the chances
of achieving a mediocre thing are increased and avoiding disaster is made a
bit harder.

24 Jun 2008 - 7:29pm
kmohnkern
2008

While digging through this discussion I was wondering why someone
didn't say something like this:

On Tue, Jun 24, 2008 at 6:05 PM, Will Evans <will at semanticfoundry.com> wrote:
> I think there are some great fundementals in UCD that can help make the
> other 999 products a little less crappy, a little more humane - and the
> truth of the matter is that you, me, and just about everyone on this list -
> makes our bread and butter by working on those 999 products.

If you're lucky enough to work with Steve Jobs or the Google guys,
then good for you. But I've never worked with innovators (despite what
they might have thought). Much of my career has been spent trying to
make dumb-ass ideas and lazy implementations "a little more humane"
(excluding a project I'm currently working on, whose other members
read this list). And UCD, when I'm allowed to do it, helps me do that.

Blah blah two cents, and all that.
ken

25 Jun 2008 - 6:10am
Dave Malouf
2005

Ambrose, I think you are confusing BAD design with the fundamentals of
design. The same is true with BAD UX Pros.

There are even bad design schools for that matter.

Again, if all you want to think about is UCD as a philosophy of
empathy towards users than it needs to be considered as one part of
a greater whole of total design methods that have to include centers
of markets and technology as well. It is at least a 3 legged stool
and the designer needs to consider all of them.

Now not all UX Pros are designers so maybe they can focus on
evaluation of user success or do up front user research. But the
designer needs to be holistic and inclusive of the user perspective,
but not centered on it.

I still don't get this whole political/power thing.

-- dave

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

25 Jun 2008 - 8:33am
ambroselittle
2008

On Wed, Jun 25, 2008 at 7:10 AM, dave malouf <dave at ixda.org> wrote:

> Again, if all you want to think about is UCD as a philosophy of
> empathy towards users than it needs to be considered as one part of
> a greater whole of total design methods that have to include centers
> of markets and technology as well. It is at least a 3 legged stool
> and the designer needs to consider all of them.
>
Agreed, and that's exactly where I think things like DDD help, at least for
internal apps. For products, well, that's why you want to have product
managers and devs/architects participating in the research and design.

I wouldn't say UCD is just a philosophy; it's that but also a procedural
framework and set of techniques.

>
> Now not all UX Pros are designers so maybe they can focus on
> evaluation of user success or do up front user research. But the
> designer needs to be holistic and inclusive of the user perspective,
> but not centered on it.
>
If you don't know who your users are, what they want to do, and maybe
sometimes even how they like to do it, common sense seems to say you won't
be able to design successfully.

I'd love to just tell the business to "trust me," and some will (as no doubt
you've found). But that's just not going to fly with many, maybe most. At
least that's the feeling I have based on my gut. Just trust me on that. :)

Having some framework and set of standard techniques to add some
predictability and reliability is not only far more attractive to those
spending the money, but it is also helps guide designers to do the right
thing, especially less experienced ones.

I hear what you're saying about user centricity in that the user perspective
is one piece to the overall design puzzle. I agree. But I'm thinking if
something has to be at the center (and I tend to think our human nature will
make this so), maybe users are the best choice for building successful
things that are to be used.

> I still don't get this whole political/power thing.
>

My experience and current thinking is such that you need to try to get it to
function well in human society. The desire to control others seems to be
part of our DNA. I was just thinking about this yesterday as I suffered
through this talk on "Standards in the Enterprise." Standards.
Governance. Management. Process. Etiquette. So much of our social fabric
is permeated with control structures that, if looked at cynically, are all
about one person/org trying to control others, through money, through force,
or through social pressure.

Of course there are positive sides to most of it. Working towards the
shared good being at the core. Streamlining communication. Providing
safety and predictabiliy (even if only ephemeral).

But it does seem to be an inescapable reality, so factoring it into my
approach to life and, in particular, dealing with others, seems essential to
success.

(Sorry; don't give me any philosophical bait. :) )

Thanks for the thoughtful response, Dave.

--Ambrose

6 Jul 2008 - 9:14am
Petra Liverani
2008

Almost everything I've read in UI design until very recently was about
user-centered design. It seemed to make a lot of sense but then when I read
that there was a book "Designing the Obvious", by Robert Hoekman, and his
rather disparaging posts about user-centered design that also seemed to make
sense.

One thing I feel very strongly is that the user is not "other", that I am
such rearing-to-go user myself and I identify with other users. I mean, we
are all users and yet some of us are not able to put ourselves in the shoes
of other people using their systems when really in a lot of cases it can be
pretty straightforward to do so. I guess it's like we all have emotions and
yet some of us (well, not me) are much better at empathising with other
people's emotions. As we all do, I "use" a lot and I find so much of bad
user design seems to be just mind-boggling thoughtlessness. To give a couple
of examples:

Where I work, a scrollable text box that was known to often contain a lot of
text and was constantly scrolled by the users was reduced to three lines
"because of space constraints" - in fact it would've been very easy to
rearrange things on the interface to maintain the original size of the text
box. That text box deeply offended me and I often thought about it. I just
scratched my head and thought "How could you possibly do that? It's a total
pain." People say that users aren't considered - sometimes I wonder if some
people just like to torture them.

I have just spent two weeks at the Sydney Film Festival. On the website they
said that in response to feedback they had made it possible this year for
attenders to redeem tickets for voucher packages online. In past years, you
could buy single tickets online but for voucher packages you had to submit
each voucher at the venue in exchange for a ticket. Well, d'uh. They surely
didn't need feedback to know that a significant customer body will, of
course, want to be able to redeem vouchers online rather than wait in long
queues and panic about missing the beginning of their film. I bought a 50
voucher package and was delighted with this news - until I went to redeem my
first voucher. You seriously would not believe how many buttons I had to
press to get a single ticket (at least 15) and repeat exactly the same
process for the following 49. I even had to put in my name, address and
phone number for every single ticket. They said something on the website
about the process not being as "seamless" as they'd hoped. It was
RSI-inducing but I plowed on because once I'd started on the online path it
was actually a much slower process to redeem vouchers at the venue. I did
thoroughly enjoy the festival but I would've enjoyed that little bit more
without all the button pressing.

Regards,
Petra Liverani

25 Jun 2008 - 8:15am
Joshua Porter
2007

One of the problems I find with UCD is that it can be too
process-oriented. I think it has to do with our need to systematize
wins in order to recreate them again and again. I think we implicitly
assume that if we use the right processes at the right time then we
will somehow be able to guarantee success. But hasn't history shown
this to a wild goose chase?

We have to seriously ask: how many designers can consistently create
success? Even the companies mentioned, Google/Apple have failed as
much as they have succeeded. The difference is that their successes
make us forget about their failures.

And, to complicate things further, we judge design by different
criteria depending on which way the wind blows. Ask a designer about
how well the Google homepage is designed and you don't know what
you'll hear.

What the best designs do is that they focus solely on the end result.
Process doesn't matter, techniques don't matter, design deliverables
don't matter...the only thing that matters is does the software kick
ass. If nobody is using it or nobody cares about it, then it can't
kick ass. If lots of people are using it and are passionate about it,
then it kicks ass. (insert Kathy Sierra quote here)

While it's helpful to ask "what are the most successful designers
doing?", it seems less fruitful to generalize to hard-and-fast
rules. If there is one thing that design history has shown, is that
there are no hard-and-fast rules or processes by which to work. Just
focus like hell on the end result because that's all that matters.

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

25 Jun 2008 - 10:07am
Andrei Herasimchuk
2004

On Jun 25, 2008, at 6:33 AM, J. Ambrose Little wrote:

> Having some framework and set of standard techniques to add some
> predictability and reliability is not only far more attractive to
> those
> spending the money, but it is also helps guide designers to do the
> right
> thing, especially less experienced ones.

Design is not about having a set of standard techniques that you
follow blindly. Similarly, playing music is not about just hitting
notes on whatever instrument you play. If you want predictability or
reliability being a designer, then the only way you'll ever get that
is through practice and more practice. But following a process to get
reliability in design is like creating a player piano and then
listening to its music. At first, it's moderately interesting to hear
The Entertainer on it, but after a short while, it's both monotonous
and lacks any human touch.

You want a framework? Go take a design class. Simple as that as far as
I'm concerned.

As for the people who pay the checks? All they care about is getting a
great product. If you design great stuff they don't care how you did
it. Guaranteed.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

25 Jun 2008 - 10:07am
Donna Fritzsche
2005

Petra,
I think you are spot on. Some people naturally emphasize with the needs of
others. I think this is a key quality and explains how some people can design
quality systems without doing as much UCD research, etc.

Harvard psychologist Howard Gardner identifies 7 types of intelligence - one
of them describes "Interpersonal" skills.

>From http://professorlamp.com/ed/TAG/7_Intelligences.html
"Interpersonal"
"Children who are leaders among their peers, who are good at communicating
and who seem to understand others' feelings and motives possess interpersonal
intelligence."

Donna Fritzsche
Information Architect, Ontologist

> I guess it's like we all have emotions and yet some of us (well, not
> me) are much better at empathising with other people's emotions. As
> we all do, I "use" a lot and I find so much of bad user design seems
> to be just mind-boggling thoughtlessness.

25 Jun 2008 - 10:39am
Dave Malouf
2005

Nice Andrei.

Ambrose, I would ask you why have any sort of centrism at all?
I also think there is a big difference between ethics and design
methods frameworks, no? I may choose one based on my ethical
underpinnings, but first should come the ethics and then the
framework.

I do not believe that UCD frameworks are the only means towards an
ethical design philosophy.

BTW, I don't think that UCD is broken so much as I believe that UCD
is not THE answer, or always the right answer. In my mind I know what
UCD is and I have learned to use its tools and other tools I have
learned a long the way.

-- dave

-- dave

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

25 Jun 2008 - 11:38am
Marijke Rijsberman
2004

It seems we have to do the empathy thing like a periodic flare-up of the
plague. We might want to be a little more critical about the whole idea of
empathy and what it means to walk in someone else's shoes.

When we look at someone living in primitive conditions and say, "oh, my god,
those poor people!" then we are experiencing some kind of fellow-feeling,
for sure. But the fact is that we're not putting ourselves in their shoes,
we're putting them in our shoes. Did we ask how they are feeling? No. We
just jumped straight to the conclusion that they must be unhappy because we
would be unhappy. As long as we and the people to whom we are ascribing our
own feelings are very similar, everything's cool. Self-centeredness is not a
big deal when the other is just like you.

The psychological research understands empathy to be, on the other hand, not
the skill of saying, "oh, I know just what you mean!!" or "poor thing, I
feel for you!" but a cognitive skill of attentiveness to another person (a
_tangible_ person whom you can see, hear, or otherwise observe and not a
construct like "earthquake victims" or "shoppers" or "users") and
interpretation of the clues embedded in their behavior so as to enable you
to reconstruct what that other person is in fact experiencing. This is not
to substitute your own feeling for theirs, but to try to understand what
feeling or other experience that person is having. (A good intro to empathy
is Bill Ickes' Everyday Mindreading or you could try the older volume of
scholarly essays Empathic Accuracy that he edited.)

I certainly agree that there is a lot of bad design out there that no decent
designer needs to do any user research to fix or prevent. But it is really
hard to understand how to support the needs of people who don't know what
you know or whose values are different from yours, without observing them in
one way or another.

Let me just offer my favorite example, not from my design experience but
from my time teaching composition to inner-city African-American college
students. They faced an end-of-semester test that demanded they could
exhibit a solid grasp of standard English grammar (as opposed to the black
vernacular) even though nobody, in all their years in school, had ever
wanted to get anywhere near this thorny and politically sensitive issue. A
lot of people failed the test. Feeling bad for them, because in fact they
got shafted in the worst way, was a noble thing I'm sure. I did feel bad for
them. But it was much more important to finally figure out that the standard
instruction to teach subject-verb agreement ("the subject and the verb must
agree in person and in number" which they could all recite from memory) is
not only difficult to understand if nobody has taught you how to find
subjects and verbs in your sentences but is in fact arrant nonsense in and
of itself. It looks like English, but it isn't. You can only decipher it if
you know what "first-person plural" or "second-person singular" stands for.
And _that_ nobody had ever pointed out to my students. If I had to design
something to get them past the hurdle of the end-of-semester test, then I'd
have to know that last little bit, which is the little bit that nobody in
the composition program at my university or in the college-level composition
books had figured out was missing in the students' repertoire.

Feeling something on behalf of another person is easy compared to figuring
out what they know and don't know, what they need and don't need in terms of
their own value system (rather than in terms of your value system), and it
just can't be done by intuition. It takes knowledge, to be got from
research. It's not a design skill, although design skills are required to
come up with a solution that addresses the issues research can surface.

Of course, there's always a fall-back: before you design something for
someone else, walk a mile in their shoes. That way, you'll be a mile away
and you'll have their shoes.

Marijke Rijsberman
http://www.interfacility.com
http://landfill.wordpress.com

Donna said:
Some people naturally emphasize with the needs of
others. I think this is a key quality and explains how some people can
design
quality systems without doing as much UCD research, etc.

Petra said:
> I guess it's like we all have emotions and yet some of us (well, not
> me) are much better at empathising with other people's emotions. As
> we all do, I "use" a lot and I find so much of bad user design seems
> to be just mind-boggling thoughtlessness. To give a couple of examples:

25 Jun 2008 - 10:49am
Lee McIvor
2006

I find the responses of most on this thread a little surprising.

Many seem to hark back to the old reactions to UCD and other, similar processes - that it stunts creativity, makes it a slave to process etc etc.

Then of course there are the anecdotes that are getting thrown in as if they somehow disprove the theory and understanding behind the UCD approach. They're just that - anecdotes. I have plenty of anecdotes about poor design decisions taken in non-UCD projects, but they don't prove design "doesn't work"?

User centred design is an approach based on gaining genuine insight from potential or existing users of a system, to ensure that the planned system meets their needs. The exact methods and techniques used in that process vary, but the fundamental point here is that it facilitates design based on genuine understanding of what users need. If you're creating a software application for airline pilots isn't it a good idea to conduct some first-hand research with airline pilots to understand their particular circumstances or limitations? Or should we all just go home and knock out some software based on our personal "genius"?

Another common misunderstanding is that UCD means asking users what kind of system they want - this isn't UCD. We use contextual research to understand how users behave, then designers are still needed to develop a system that fits those needs. So the creativity is still there, but the research aids that creativity.

UCD is a process that aids creativity and avoids waste, no-one has ever claimed it's a guarantee of brilliant products - just the same as employing a designer doesn't guarantee good design.

__________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

25 Jun 2008 - 12:13pm
Robert Hoekman, Jr.
2005

>
> "The past" is filled with far more examples of products, innovative
> thinking, and success stories based on activity-centered research, magic,
> genius design, and just plain *luck* than UCD can claim even on its best
> day."
>
> How do you know this? Where is your data? Do you know what UCD has
> accomplished and how are you comparing it to magic?
>

UCD, as you pointed out yourself, is only 30 years old. "The past" is much,
much older. Did the guy who invented the first desk lamp think about his
users? Perhaps, but that doesn't make him a UCD practitioner.

> Now the title is cute and the point a really good one. I agree with it
> completely. But to suggest that ACD is the "replacement" for 30 years of
> development is really simplistic. Norman was doing exactly what I suggested
> in my original post – suggesting how to improve on existing techniques. But
> I doubt that he would seriously suggest that we need to abandon user
> centricity as a goal. In fact, he said just the opposite.
>
The best way I've found to improve on those techniques is to replace them,
and doing so has resulted in many successes for my clients and employers. Of
course, my ultimate goal is to design something that works great for users,
is valuable to them, and meets or exceeds the underlying business goals. But
I can achieve that any number of ways, and "the UCD way" has not worked, for
a myriad of reasons. It was because of this fact that I looked for new
solutions. And the new solutions worked. Hence, this debate.

> 2. Let's agree that the world has changed since 1982 when UCD was first
> created and let's expand and extend it with activity centered design and
> every other good idea we can come up with so we create even better tools.
>
Amen.

> I think we should stop equating UCD (or whatever you want to call it),
> which has 30 years of effort and research behind it as if it were
> irrelevant.
>
Many things with 30 years of development have been replaced. Vinyl records.
The horseless carriage. The steam engine. Sure, these things are still
around, but superior artifacts have long since replaced them as the dominant
choice. (Though, it has yet to be determined if a CD is in fact better than
vinyl, but that's a different story)

> Personally, as long as the design approach creates a product that is useful
> to the user and usable, I don't care what name you give it.
>
Nor do I. Honestly, I couldn't care less how you achieve the result as long
as it's achieved. But I've seen UCD fail time after time after time in real
business situations where deadlines are tight and money is short. I push ACD
because it has worked in all those situations where UCD wouldn't cut it.

Part of my motivation for writing that article series and for pushing ACD
all the time is to give people who are suffering the same fate a solution to
give to their managers (and themselves). One that gives them another way to
go—one that might succeed when UCD methods aren't an option.

-r-

25 Jun 2008 - 12:25pm
Andrei Herasimchuk
2004

On Jun 25, 2008, at 8:49 AM, Lee McIvor wrote:

> UCD is a process that aids creativity and avoids waste, no-one has
> ever claimed it's a guarantee of brilliant products - just the same
> as employing a designer doesn't guarantee good design.

I'm going to be blunt:

The only people I've ever met who need UCD processes as a means to
design are the exact people I think need to consider going back to
take a few good design classes in industrial or graphic design.
Preferably both.

You can shoot the messenger all you like.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

25 Jun 2008 - 12:25pm
Robert Hoekman, Jr.
2005

>
> In the referenced article, you say: "Do you think Google's home page was
> designed for a specific set of user types?"
>
> At *An Event Apart* today, Jeffrey Veen said, essentially, yes--he didn't
> show personas, per se, but he did show pictures of and described target user
> types that sure sounded a lot like them. And in fact he said, and I quote,
> "weaving all that [Google apps] together took a tremendous amount of
> user-centered design." [...]
>

Google's homepage was started long before its UX design team. It was
originally "designed", as the story goes, simply as a way to input tests for
the search engine.

As recently as 2 years ago, Google's UX team consisted of about 60 people,
out of about 10,000 employees. It took them several years to even start a UX
team, let alone work it into their process. It may (or may not) be going
strong now, but Google was certainly not built on a foundation of quality
interaction design.

Interesting side note: Veen first gave that talk back in 2005. He's modified
it over time (from what I've heard), but it's essentially the same talk he's
been giving for 3 years (I think before he joined Google). I don't know if
this affects the net sum of the talk, but it's interesting. (Any way you
look at it, Veen is an awesome speaker.)

-r-

25 Jun 2008 - 1:06pm
Andrei Herasimchuk
2004

On Jun 25, 2008, at 10:33 AM, Terry Fitzgerald wrote:

> Going back to school may improve their design skills. It certainly
> will not necessarily improve their understanding of what to design!

I'll let the folks who have taken heavy industrial design courses
defend themselves here. Every major design school I know of gets heavy
into research and ergonomics.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

25 Jun 2008 - 12:33pm
Terry Fitzgerald
2008

Going back to school may improve their design skills. It certainly will not
necessarily improve their understanding of what to design!

On 6/25/08, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
>
> On Jun 25, 2008, at 8:49 AM, Lee McIvor wrote:
>
> UCD is a process that aids creativity and avoids waste, no-one has ever
>> claimed it's a guarantee of brilliant products - just the same as employing
>> a designer doesn't guarantee good design.
>>
>
> I'm going to be blunt:
>
> The only people I've ever met who need UCD processes as a means to design
> are the exact people I think need to consider going back to take a few good
> design classes in industrial or graphic design. Preferably both.
>
> You can shoot the messenger all you like.
>
> --
> Andrei Herasimchuk
>
> Principal, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
> ________________________________________________________________
> 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
>

25 Jun 2008 - 3:17pm
Andrei Herasimchuk
2004

On Jun 25, 2008, at 12:35 PM, Terry Fitzgerald wrote:

> If I asked any of these folks or you to go out and buy me a car -
> could you decide without asking me (the U in UCD) what kind of car
> meets my needs?

You're missing the point.

Have you taken an industrial design class?

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

25 Jun 2008 - 2:35pm
Terry Fitzgerald
2008

If I asked any of these folks or you to go out and buy me a car - could you
decide without asking me (the U in UCD) what kind of car meets my needs?

On 6/25/08, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
>
> On Jun 25, 2008, at 10:33 AM, Terry Fitzgerald wrote:
>
> Going back to school may improve their design skills. It certainly will not
>> necessarily improve their understanding of what to design!
>>
>
> I'll let the folks who have taken heavy industrial design courses defend
> themselves here. Every major design school I know of gets heavy into
> research and ergonomics.
>
> --
> Andrei Herasimchuk
>
> Principal, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
>
> ________________________________________________________________
> 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
>

25 Jun 2008 - 4:32pm
Chris Hunter
2007

On Wed, Jun 25, 2008 at 3:17 PM, Andrei Herasimchuk <
andrei at involutionstudios.com> wrote:

>
> On Jun 25, 2008, at 12:35 PM, Terry Fitzgerald wrote:
>
> If I asked any of these folks or you to go out and buy me a car - could
>> you decide without asking me (the U in UCD) what kind of car meets my needs?
>>
>
> You're missing the point.
>
> Have you taken an industrial design class?
>

Andrei is spot on here. Any reputable design program (Industrial or Graphic)
will have significant emphasis on considering the user during the design
process. I know that mine (at the University of Washington) certainly did.
For example, one of our design projects involved designing a digital
thermometer. Every single student went out, observed and talked to
prospective users -- for some parents or home users, for me, doctors and
nurses -- and then used our findings in the design process.

If you go and examine the history of any of the existing design disciplines:
graphic design, industrial design or architecture, you will find a
consistent consideration for the people affected by design decisions. Not as
the only consideration certainly but as a significant and consistent one.

UCD just isn't necessary in addition to this already established design
behavior.

Chris Hunter
chunter at wondertwinpowers.net

25 Jun 2008 - 4:59pm
Uday Gajendar
2007

Yep. True... When I did my ID degree at Michigan, we took a Design
Research course, and the concerns of people-context-tasks were woven
into the studio projects, particularly the upper level ones (lower
level were typical form studies, tools/materials, shop experience).
Most of that involved Dreyfus and Eames of course. I'd think any
reputable ID program nowadays has this as a routine with perhaps even
broader knowledge bases today drawing upon pysch, anthro, and more,
beyond the typical/historical HF and ergo sources...

Hope this helps,

Uday Gajendar
Sr. Interaction Designer
Voice Technology Group
Cisco | San Jose

On Jun 25, 2008, at 11:06 AM, Andrei Herasimchuk wrote:

> On Jun 25, 2008, at 10:33 AM, Terry Fitzgerald wrote:
>
>> Going back to school may improve their design skills. It certainly
>> will not necessarily improve their understanding of what to design!
>
> I'll let the folks who have taken heavy industrial design courses
> defend themselves here. Every major design school I know of gets
> heavy into research and ergonomics.

25 Jun 2008 - 6:03pm
Uday Gajendar
2007

On Jun 25, 2008, at 8:07 AM, Andrei Herasimchuk wrote:
> You want a framework? Go take a design class. Simple as that as far
> as I'm concerned.
>

Two personal anecdotes from design school:

1) My first graphic design class, I remember trying to get the hang of
compositional space and laying out letters and image with the grid,
etc. And I was trying too hard to be artsy. Prof came over, moved the
elements around trying different arrangements (this is all paper
pieces with hand-drawn letters, btw). I was blown away. I asked her
what was she thinking about as she was organizing elements. And she
walked me through a "framework" of person/space/word/image (i forget
the actual words, but similar) which I found fascinating...That
there's a basic framework that guided her design actions in an
intuitive manner because it had become her habit and evolved with her
many years of experience, operating sub-consciously.

At that moment I realized that there is something specific and capable
of being articulated that really separated communicative design from
expressive art, which I found very powerful.

2) Dick Buchanan's graduate design seminar, he wrote out the steps of
a typical UCD process on the whiteboard, going on about the major
steps, etc. When he concluded, I raised my hand and asked, "So if
someone just walked in right now and memorized and did those steps, is
that person then a designer?" And Dick just smiled sneakily, hinting
something about the personal and the "noumenal"... hmmm!

I share these to show that designing actually balances both
"frameworks" and "ingenuity" or "talent" (for lack of a better word)
in a kind of back-and-forth dialogue, left/right brain if you will (a
dialectical method). What we must avoid is heavy handed bureaucracy
and stifling of creativity by forcing designers to march lockstep step
after step, all mandatory, all documented and codified, etc. Else it
becomes a crutch and kills inventive spirit, imho :-)

> As for the people who pay the checks? All they care about is getting
> a great product. If you design great stuff they don't care how you
> did it. Guaranteed.
>

Execs may care about great products (altho in enterprise i bet they
care more about sales contracts to drive more revenue for the
quarter :-) but I'd guess most designers work day-to-day making and
fighting decisions with middle managers who are much more concerned
about CYA, political power, ego and don't really care all that much
about great products...If they did, they wouldn't persist crappy
legacy tech or absurd features! There in it to protect themselves and
use "user experience" to blame sadly. So we end up pushing "standard
UCD process" with "repeatable methods" as a source of authority to
combat those folks and assert a design's legitimacy...Sucks but
that's reality I bet many designers confront daily.

Uday Gajendar
Sr. Interaction Designer
Voice Technology Group
Cisco | San Jose

25 Jun 2008 - 6:57pm
Jared M. Spool
2003

Damn.

I'm so glad I didn't get sucked into this discussion.

Since my name was cited in the original post, I did want to suggest
that I've been talking about this problem for years.

Most recently, I wrote about it here:
Surviving Our Success: Three Radical Recommendations
http://tinyurl.com/5z78qs
(Unfortunately, a bit hard to find on the unusable UPA web site.
And nobody can explain to me why it's a PDF.)

And I talked about it here:
IA Summit 2008 Keynote: Journey to the Center of Design
http://tinyurl.com/5kasbm
(Listen to the audio or the slides won't make sense.)

Basically, my thoughts are that, for many folks, UCD is a dogma. These
people treat it as the only viable way of thinking about product design.

However, there is no real evidence to suggest that following UCD
dogmatically produces any better designs than ignoring it dogmatically
(like Robert seems to want to do).

In fact, all the evidence seems to suggest that it's a gestalt effect
that any success is derived at all. In either of the above pieces,
you'll hear (or read) about my thoughts on how the techniques of UCD
are really just the stone in the soup. I believe that something else
-- something we never talk about -- is what actually provides the best
designs. (Just like it's something else that makes the soup, not the
stone.)

I'm way to busy this week to actually say anymore than this.

I'm glad there's a discussion. People should just consider whether
their personal dogmas are really what they think they are.

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

25 Jun 2008 - 8:54pm
ambroselittle
2008

On Wed, Jun 25, 2008 at 11:07 AM, Andrei Herasimchuk <
andrei at involutionstudios.com> wrote:

> Design is not about having a set of standard techniques that you follow
> blindly. Similarly, playing music is not about just hitting notes on
> whatever instrument you play. If you want predictability or reliability
> being a designer, then the only way you'll ever get that is through practice
> and more practice. But following a process to get reliability in design is
> like creating a player piano and then listening to its music. At first, it's
> moderately interesting to hear The Entertainer on it, but after a short
> while, it's both monotonous and lacks any human touch.
>
I'm really trying to believe you're not intentionally twisting words to
attack a straw man, but it is hard, nigh on impossible. In any case, I'm
not about to engage on an ephemeral debate about what design is or is not.
*There are more things in heaven and earth, Horatio, than are dreamt of in
your philosophy.*

Have fun with that.

>
> You want a framework? Go take a design class. Simple as that as far as I'm
> concerned.
>

*Businesses* want a framework. *Businesses* want reliability and
predictability and accountability. This is not a question of what I want.
I want folks to throw money at me and let me sit in a room and do whatever I
want all day, play violin, read, write, play chess, philosophize, make
stuff...

> As for the people who pay the checks? All they care about is getting a
> great product. If you design great stuff they don't care how you did it.
> Guaranteed.
>

Andrei, I caution you against making broad generalizations like this. The
software industry is way bigger than the few companies at the top who make
the great products. If that's all you want to care about, more power to
you. I'm interested in talking about how to make the other 99% of software
being developed better, not just what works for me.

--Ambrose

25 Jun 2008 - 9:31pm
ambroselittle
2008

On Wed, Jun 25, 2008 at 11:39 AM, dave malouf <dave.ixd at gmail.com> wrote:

> Ambrose, I would ask you why have any sort of centrism at all?
> I also think there is a big difference between ethics and design
> methods frameworks, no? I may choose one based on my ethical
> underpinnings, but first should come the ethics and then the
> framework.
>
Sounds like a personal question. :) Can I get away with "yes"?

>
> I do not believe that UCD frameworks are the only means towards an
> ethical design philosophy.
>
> BTW, I don't think that UCD is broken so much as I believe that UCD
> is not THE answer, or always the right answer. In my mind I know what
> UCD is and I have learned to use its tools and other tools I have
> learned a long the way.
Sounds like you and I can agree. I appreciate your nuanced thought in this matter.

--Ambrose

Syndicate content Get the feed