boxing UCD

13 Feb 2005 - 5:05am
9 years ago
19 replies
369 reads
kjnarey
2004

I've had a few conversations over the last couple of weeks about whether or
not UCD (or what ever you like to call it) adds cost to a project -
therefore making us less competitive in the estimation that we give to a
customer.

The argument is with technocrats who believe that on a five day project,
four days would be development (i.e. bashing out the features as best as
they can) and the last day for testing. In my experience this is where the
proliferation of poor practices start.

I argue that with one day's design up front, sat with the user, iterating
through the few possibilities, a model could be built (lets say a form on a
web page) to communicate what needs to be done to programmers, where the
major design decisions have been distilled from the logic and a process of
'hooking up' is required. That means IMO that four days development would
turn into one day of design and three days development, therefore adding no
extra cost to the project.

There is no question however of the value of UCD in a large project in my
company, where best practice is perceived to add more value to the product
than using best practice on a small five day-er. I beg to differ. I believe
it's a case of all or nothing.

SO! Is UCD scalable enough at a small project level to integrate it into all
processes? Well I believe that it is, but it requires responsible selling
and that's perceived as a problem to those who sell.

Kevin

Comments

13 Feb 2005 - 12:02pm
Jared M. Spool
2003

At 04:05 AM 2/13/2005, kjnarey wrote:
>I've had a few conversations over the last couple of weeks about whether or
>not UCD (or what ever you like to call it) adds cost to a project -
>therefore making us less competitive in the estimation that we give to a
>customer.

Kevin,

You've hit on something I've been giving a lot of thought about lately.

Most UCD practices are tremendously expensive. Even just taking a day up
front to sit with the users and work up a model to give to the developers
can have tremendous administrative and logistical costs.

To really do this well (particularly in an agency environment) requires
that you can amortize the logistical fixed costs over the entire project.
For example, the recruitment of users for the study needs to 90% complete
before the project is even conceived, by already having a database of
qualified, pre-screened participants who are ready to show on a moment's
notice.

I believe that if you on the same project over a long period of time, these
economies of scale can play out, even for the short mini-projects. But, I'm
concerned about very short projects (less than 2 months from womb to tomb),
where every expense counts and the returns of resource costs (particularly
the time delays) will be way to expensive to justify.

UCD practices, as the exist today, are very narrow in their thinking of how
the costs as accrued in a project. I think we need to do a lot more
research in coming up with new ways to leverage the ever growing knowledge
base we're gaining, so we can calculate that in the investment equation.
Otherwise, as projects get shorter, we may find that we are not flexible
enough to plug ourselves in.

That's my take,

Jared

Jared M. Spool User Interface Engineering
http://www.uie.com jspool at uie.com

Join us for UIE's extremely popular Roadshow event
Know Your Users: http://www.UIERoadShow.com
Minneapolis, Denver, Seattle, DC Winter 2005

14 Feb 2005 - 8:45am
ralph lord
2004

Jared wrote:

"I think we need to do a lot more research in coming up with new ways to
leverage the ever growing knowledge base we're gaining, so we can
calculate that in the investment equation. Otherwise, as projects get
shorter, we may find that we are not flexible enough to plug ourselves
in."

We "leverage the ever growing knowledge base we're gaining" by selling
our design services as those of professionals in practice who are both
trained and experienced. Our clients expect us not to have to
test/research/study every aspect of their needs but to bring our
experience with other clients to bear on their problem.

I argue that the focus must be on big-D "Design" first and UCD second
and let the budget/timeframe of the project dictate how much you can do.

In ALL cases any time spent on Design - UCD or not - pays off in reduced
dev time, less rework and a higher success rate in front of
customers/users.

If you know what you're doing, be confident and assertive and act like
the professional you are. Why can older doctors run fewer tests than
younger ones? They can "leveraging their knowledge base".

RL

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Jared M. Spool
Sent: Sunday, February 13, 2005 12:03 PM
To: kjnarey; 'IxD Discussion'
Subject: Re: [ID Discuss] boxing UCD

[Please voluntarily trim replies to include only relevant quoted
material.]

At 04:05 AM 2/13/2005, kjnarey wrote:
>I've had a few conversations over the last couple of weeks about
whether or
>not UCD (or what ever you like to call it) adds cost to a project -
>therefore making us less competitive in the estimation that we give to
a
>customer.

Kevin,

You've hit on something I've been giving a lot of thought about lately.

Most UCD practices are tremendously expensive. Even just taking a day up

front to sit with the users and work up a model to give to the
developers
can have tremendous administrative and logistical costs.

To really do this well (particularly in an agency environment) requires
that you can amortize the logistical fixed costs over the entire
project.
For example, the recruitment of users for the study needs to 90%
complete
before the project is even conceived, by already having a database of
qualified, pre-screened participants who are ready to show on a moment's

notice.

I believe that if you on the same project over a long period of time,
these
economies of scale can play out, even for the short mini-projects. But,
I'm
concerned about very short projects (less than 2 months from womb to
tomb),
where every expense counts and the returns of resource costs
(particularly
the time delays) will be way to expensive to justify.

UCD practices, as the exist today, are very narrow in their thinking of
how
the costs as accrued in a project. I think we need to do a lot more
research in coming up with new ways to leverage the ever growing
knowledge
base we're gaining, so we can calculate that in the investment equation.

Otherwise, as projects get shorter, we may find that we are not flexible

enough to plug ourselves in.

That's my take,

Jared

Jared M. Spool User Interface Engineering
http://www.uie.com jspool at uie.com

Join us for UIE's extremely popular Roadshow event
Know Your Users: http://www.UIERoadShow.com
Minneapolis, Denver, Seattle, DC Winter 2005

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

14 Feb 2005 - 8:56am
Peter Boersma
2003

Jared, in his reply to Kevin, wrote:
> Otherwise, as projects get shorter, we may find that we are not flexible
> enough to plug ourselves in.

What would you consider to be flexible?

Is that flexibility in terms of being able to ramp up & down quickly (you
mentioned the time/cost related to the recruitment of users) or in
perfoming/not performing certain activities (optional vs. mandatory
methods/deliverables).

The first version requires a certain degree of preparedness, i.e. being
ready for "it" all the time, and updating that situation all the time.
The second version requires a deep insight into what methods or deliverables
are necessary in a given situation, i.e. being able to build on a wealth of
experience (your own or others') and the capability to analyse the situation
quickly.

Would you consider one type of flexibility more important than the other, or
do you have your own definition of flexible (which wouldn't surprise me
:-))?

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

14 Feb 2005 - 9:01am
Peter Boersma
2003

Kevin,

> The argument is with technocrats who believe that on a five day project,
> four days would be development (i.e. bashing out the features as best as
> they can) and the last day for testing. In my experience this is where the
> proliferation of poor practices start.

This is where the definition of a project is wrong. Analysis of what is
required, and designing a fitting solution (requirements gathering,
designing, and evaluating the design) is half the work. Implementing and
making sure the implementation works in the right environment (development
and testing) is another half.

There may be other halves that I'm fogetting now, but this is an important
oversight in your technocrats' view on projects.

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

14 Feb 2005 - 9:09am
Welie, Martijn van
2005

> -----Original Message-----
> From: Jared M. Spool [mailto:jspool at uie.com]
>
> You've hit on something I've been giving a lot of thought
> about lately.
>
> Most UCD practices are tremendously expensive. Even just
> taking a day up
> front to sit with the users and work up a model to give to
> the developers
> can have tremendous administrative and logistical costs.

Recently we had presentations of IA's and Interaction Designers at one Peter
Boersma's drinks. One of the outcomes of the evening was that there was a
HUGE DIFFERENCE in the amount of time the IA/ID's had to do their work.

At one extreme, one ID had to do the design, visual design and building the
site in one week typically. On the other end there were people who could
spend 3-6 months on a project.

So, what can you do if you have 1 week to do the interaction design? Can you
do user analysis in that timeframe? If not what are alternative techniques
to help designers? I recently read in an article somewhere that you
typically need 4-6 weeks to create a set of persona's for your site. That is
about twice the amount of time I normally have to do an entire project!!!!
So what does that say about the value of such a technique?

Perhaps we can try to create a table with techniques on one axis and
available time on the other.....

Martijn

14 Feb 2005 - 11:20am
Narey, Kevin
2004

Jared wrote:

>Most UCD practices are tremendously expensive.

This isn't a status quo Jared, I think you'll agree. It's our responsibility
to find 'workable' and dare I say it, 'alternative' way's of applying UCD
method so as not to cause too much , if any, disruption to the IT sales
process. The current perception of expense is, I fear, the main contributor
to our acceptance difficulties. It doesn't have to be that way. By
attempting to prove that UCD needs to be an integral cross phase activity in
the local software development process and on every project we can apply it
at every level. This isn't easy, but has the effect of changing cultures
rather than exacerbating cost issues.

>.... pre-screened participants who are ready to show on a moment's
>notice.

I think it is generally understood that this activity is largely unrealistic
and impractical on five day projects, except perhaps when the project
sponsor is the actual user. Perhaps bought knowledge (cheap) of similar
historical user research can be applied from a centralised industry
resource? Similar to Gartner reports, but a standardised user research
resource? I realise the finer grained user-related/contextual design
problems with this, but it's better than nothing on a one week project if we
could have the choice of whether to use it or not. Just thoughts anyway.
Bullet proof vest is now secured.....

>I'm concerned about very short projects (less than 2 months from womb
>to tomb),
>where every expense counts and the returns of resource costs (particularly
>the time delays) will be way too expensive to justify.

It's these 'short' projects that will prove UCD/IxD/UX/UE as a business
proposition to all UCD buyers in the future. It's at this very scale of
project that UCD methods can truly be proved as having worth as every
project could start as a five-dayer, even if they later turn out to be a
five year long project. If UCD cannot be *seen* to be scalable, then it will
always appear as an expendable 'quality criterion' to the money-folk and
estimate co-ordinators. This is exactly the reason why I have insisted that
UCD is not separated out as an activity in our estimates to customers.
Internally it can be seen as a fixed cost (a difficult enough task in
itself) to the sales folk who have to sell the proposal, but that's it. The
customer need not know about it if they're new, and existing customers see
it as a refreshing and innovative method that helps them visualise and
further understand their problem - they experience it through great feedback
from their end-users, they don't expect it. They thought they were getting a
good deal before when the programmer was seen to 'do the whole lot', but
they now start to see the 'value-add' in looking at the problem in a new way
and the cost is largely the same. This is contextual however, with many
outstanding factors going unmentioned.

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

14 Feb 2005 - 2:22pm
Dave Malouf
2005

How has all this happened?

Would a contractor or civil engineer ever begin building a physical product
without a plan? A blue print? Technical specifications?

The reality is that code is NOT cheap to change, and understanding the
design is as important for virtual objects as it is for physical ones. Yet
we still live in an environment where the myth of "code is cheap" is still
believed.

This seems to me to be a huge mission for all digital/software designers.

-- dave

14 Feb 2005 - 3:05pm
Welie, Martijn van
2005

David Heller wrote:

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>This seems to me to be a huge mission for all digital/software designers.
>
>
Well, I think the most important thing that we UCD-people need to
realize is that we MUST SELL OURSELVES. Lesson number one in sales is
'think as your customer'!!!!. It doesn't matter whether or not we a
right and that we know exactly how 'it should be done'......and that
there are other fields such as Architecture where similar practices have
been accepted for ages. Comparisons are simply not very strong arguments
when you are making a case for yourself because they will always answer
that IT is different and the comparison therefore doesn't apply.

If we cannot convince others with with arguments that make sense in
THEIR WORLD, we will not succede. They care about costs and they already
have difficulty keeping costs down as it is. Then come the UCD people
and say that even more time must be spend on 'vague
activities'.......although it might be good for the end-users, they
simply have budget-responsibility for the project and therefore do not
(really) care for the end-users. Their own ass is on the line here.....

It is very difficult to improve this situation. Making (very) small
steps forward is the only way to go in my opinion.....but I am still
looking for the grail as well....;-)

Martijn

14 Feb 2005 - 4:45pm
Billie Mandel
2005

I'm with Dave here. In both design-speak and management-speak there
are two choices: pay for (at least some) design time up front, or
spend the remainder of the product's life cycle chasing around after
messy code and interaction with a push broom. In my experience, at
least, the latter is far more costly, both in quantitative terms (net
cash flow out the window) and in qualitative terms (morale/retention
rate of engineers/designers/project managers, as well as customer
loyalty).

I suppose that it also depends on the intended life cycle of the
product - if it's a quick fix that the product managers intend to
jettison and rebuild anyway, design becomes less important (though as
our esteemed Messrs. Cooper and Reimann have reminded us, this is
exactly how some large companies have come to build empires upon
houses of cards).

I think one major key is that we need to dispel any perception (on our
management and engineering compatriots' part *or* on our own) that our
work is comprised of "vague activities." Our methods might be
inscrutable to those outside our profession, but our purpose is
specific, and can save a company money, even if only employed on a
small scale.

- Billie

On Mon, 14 Feb 2005 21:05:53 +0100, Martijn van Welie
<martijn.van.welie at satama.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> David Heller wrote:
>
> >[Please voluntarily trim replies to include only relevant quoted material.]
> >
> >This seems to me to be a huge mission for all digital/software designers.
> >
> >
> Well, I think the most important thing that we UCD-people need to
> realize is that we MUST SELL OURSELVES. Lesson number one in sales is
> 'think as your customer'!!!!. It doesn't matter whether or not we a
> right and that we know exactly how 'it should be done'......and that
> there are other fields such as Architecture where similar practices have
> been accepted for ages. Comparisons are simply not very strong arguments
> when you are making a case for yourself because they will always answer
> that IT is different and the comparison therefore doesn't apply.
>
> If we cannot convince others with with arguments that make sense in
> THEIR WORLD, we will not succede. They care about costs and they already
> have difficulty keeping costs down as it is. Then come the UCD people
> and say that even more time must be spend on 'vague
> activities'.......although it might be good for the end-users, they
> simply have budget-responsibility for the project and therefore do not
> (really) care for the end-users. Their own ass is on the line here.....
>
> It is very difficult to improve this situation. Making (very) small
> steps forward is the only way to go in my opinion.....but I am still
> looking for the grail as well....;-)
>
> Martijn
>
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

14 Feb 2005 - 4:48pm
Andrei Herasimchuk
2004

On Feb 14, 2005, at 12:05 PM, Martijn van Welie wrote:

> If we cannot convince others with with arguments that make sense in
> THEIR WORLD, we will not succede. They care about costs and they
> already have difficulty keeping costs down as it is. Then come the UCD
> people and say that even more time must be spend on 'vague
> activities'...

Which begs the question if "UCD" is really the bees knees.

I mean, when I see UCD processes, I see less and less work spent on the
things that actually go into the final design or end-product, and even
worse, a lot less time spent on what the technology is and can do. It's
not all about users when it comes to creating digital products. It
really isn't. Further, it's not all about research deliverables. But
when I see UCD processes, I see more and more research, less design,
and not enough focus on what technology can do.

Andrei

14 Feb 2005 - 5:02pm
Dave Malouf
2005

On 2/14/05 4:48 PM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> Which begs the question if "UCD" is really the bees knees.
>
> I mean, when I see UCD processes, I see less and less work spent on the
> things that actually go into the final design or end-product, and even
> worse, a lot less time spent on what the technology is and can do. It's
> not all about users when it comes to creating digital products. It
> really isn't. Further, it's not all about research deliverables. But
> when I see UCD processes, I see more and more research, less design,
> and not enough focus on what technology can do.
>
> Andrei

First off UCD means lots of different things to lots of different people.
But I agree with Andrei that when UCD is translated to mean analysis without
design then it is problematic, but to me UCD means get data from users,
design the product, validate product with users. Of course you can do a lot
in each one of those phases. Sometimes you'll have lots of time for all 3,
and others you can just design the product (my current world), and others
you get to design and validated, but I do agree that in all three the focus
does need to be ucD and not Ucd. You do have to create something.

That being said though the more you know up front, the better chances of
success with minimal pain downstream.

-- dave

14 Feb 2005 - 6:23pm
Andrei Herasimchuk
2004

David Heller wrote:

> First off UCD means lots of different things to lots of different people.

Problem #1. What's the baseline definition? I always assumed the IBM one
was what most people think of when they hear "UCD."

http://www-306.ibm.com/ibm/easy/eou_ext.nsf/publish/2

> But I agree with Andrei that when UCD is translated to mean analysis without
> design then it is problematic.

Problem #2. Currently, most UCD processes do result in an end design, so
I don't want to give the impression I think they don't.

The issue I have is how much work goes into the "research" aspect of the
end user needs and business sides of a project versus the technology
aspect. I see far too often designers/researchers falling into the trap
of asking engineers to do "design x" based on "what users need to do"
and the engineers come back and say "design x" is not possible due to
"reasons y and z."

As with anything... it's a balance. In the game of high tech design,
that balance for me is a mix of user needs, business requirements and
technological constraints/possibilities.

Heck, even the name "user centered design" is imbalanced in that regard.

> but to me UCD means get data from users,
> design the product, validate product with users.

And at what point do you evaluate the possibilities of technology? What
the engine can and cannot do?

> I do agree that in all three the focus
> does need to be ucD and not Ucd. You do have to create something.

At some point, maybe it'll come back to just D. UCD to me is an
incomplete process or methodology imho. It's got the right intent behind
it,but right now I'm not sure how useful it is in real world terms, both
in regard to my concerns with it and the concern you raise about
time/money issues.

> That being said though the more you know up front, the better chances of
> success with minimal pain downstream.

Certainly can't disagree with that.

Andrei

14 Feb 2005 - 6:42pm
Tadej Maligoj
2004

I am an Architect (in real world) and now I am working as an
information architect (in non-real world).

Do not have illusions that architects in physical worlds has less
problems with the clients. It is much the same. Every building needs
Bob (the builder ... ;+), most of them need an architect (at least to
sign the papers), but there are few to be worth looking at or to live
in. And it is not just the architect's fault.

My advice: be good, find a good client and stick to it. You can make
good projects with a good client. You can't make a bad client any
better with your good work.

Tadej

On Mon, 14 Feb 2005 21:05:53 +0100, Martijn van Welie
<martijn.van.welie at satama.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> David Heller wrote:
>
> >[Please voluntarily trim replies to include only relevant quoted material.]
> >
> >This seems to me to be a huge mission for all digital/software designers.
> >
> >
> Well, I think the most important thing that we UCD-people need to
> realize is that we MUST SELL OURSELVES. Lesson number one in sales is
> 'think as your customer'!!!!. It doesn't matter whether or not we a
> right and that we know exactly how 'it should be done'......and that
> there are other fields such as Architecture where similar practices have
> been accepted for ages. Comparisons are simply not very strong arguments
> when you are making a case for yourself because they will always answer
> that IT is different and the comparison therefore doesn't apply.
>
> If we cannot convince others with with arguments that make sense in
> THEIR WORLD, we will not succede. They care about costs and they already
> have difficulty keeping costs down as it is. Then come the UCD people
> and say that even more time must be spend on 'vague
> activities'.......although it might be good for the end-users, they
> simply have budget-responsibility for the project and therefore do not
> (really) care for the end-users. Their own ass is on the line here.....
>
> It is very difficult to improve this situation. Making (very) small
> steps forward is the only way to go in my opinion.....but I am still
> looking for the grail as well....;-)
>
> Martijn
>
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj at gmail.com
e2: studio at maligoj.com
m: 031 306 986
w: www.maligoj.com

14 Feb 2005 - 7:04pm
Dave Malouf
2005

> The issue I have is how much work goes into the "research"
> aspect of the
> end user needs and business sides of a project versus the technology
> aspect. I see far too often designers/researchers falling
> into the trap
> of asking engineers to do "design x" based on "what users need to do"
> and the engineers come back and say "design x" is not possible due to
> "reasons y and z."

To be honest, Technology is the least of my concerns. There is so little
that can't be done by technology these days. Usually it comes down to cost
and resources way way way way way (did I say "way") before a technical
problem and I would much much much much much rather ere on the side of being
too advanced (technologically speaking) than not. Unless you are working in
a medium that has not been done to death and quite frankly most of us are:
software, web, networked clients, even hardware, or you yourself are in the
business of innovation (and I hope you are; unlike me), then technology
should not come up as a real problem area. If it does then your technology
is faulty or your x-functional team processes are faulty.

The 3 point plan I put up there before get user data, do design, validate
design with users was curt on purpose and obviously full of wholes. "do
design" IMHO is led by designers but not only done by designers. A
x-functional team would be with you during design so that business,
technology and operational (quite frankly this is much more important than
technology) concerns like fulfillment, support, etc. can get their say so
during the design process. Their data points also enter the requirements
periods as much as user data points and inform the design all the way
through the process.

NO! this is not design by committee. This is x-functional design, led by a
strong design lead. If you can't get your team to work w/ you you have
another set of big problems.

-- dave

14 Feb 2005 - 7:30pm
Andrei Herasimchuk
2004

David Heller wrote:

> then technology should not come up as a real problem area.

Then why does it, time and time again? (I'm not saying it does for
"you," just that it does generally speaking from my experience.)

Even the types of discussions we've had in this list over issue of
desktop client versus browser based apps seem to be brimming with
technological overtones to suggest technology is still very much at
issue as part of the design process.

And FWIW, when I say "research technology," I mean having an
understanding of it at the same conceptual level as engineers do, even
if you can't code it yourself. I for one can't code C+ not because I
don't understand it, but because I haven't invested enough time to turn
myself into someone who can code C+ even at a basic level. If I don't
understand MySQL and a project requires using it, I try and make time to
make sure I understand everything the engineers know about MySQL at a
functional, technical level, or as much as my fried brain can handle.

The times I find I have the hardest on a project are the times when I
lack understanding at a technical level. That and working with product
managers who want to be interface designers.

> The 3 point plan I put up there before get user data, do design, validate
> design with users was curt on purpose and obviously full of wholes.

That process is actually closer to what I do: research for long as I can
get away with (includes: users, business, technology), design, iterate,
test, redesign, iterate, test, etc.

Full of holes? Not as many as I think you might believe.

Andrei

14 Feb 2005 - 7:39pm
Dan Saffer
2003

Is UCD a methodology or a philosophy of designing? It seems like we're
mixing and matching the two interpretations.

If it's a methodology, I think its limitations are fairly obvious
(scaling, for example). But if we instead treat it as a philosophy (ie
users first, technology and business will follow) with many different
methodologies beneath it, it begins to make more sense (to me anyway).

Thus, if you think a particular methodology (eg collaborative
designing) has too strong a research component, you could still call
yourself a follower of UCD if your philosophical point of departure is
that as designers we should consider the users and their needs first.

This is, of course, not the only way to approach the design of
something. You can, of course, approach a problem by considering the
technology involved first. But this, imho, has even more problems than
UCD. Technology can sometimes be more malleable than the people who
have to use it. Which is not to say that technology shouldn't be
considered--knowing the probable limits of the medium(s) you work in is
part of the job of the designer after all. But those limits change
frequently and great developers and form-makers push the limits all the
time.

I think there's a great discussion waiting to happen here on other
systems of designing (like systems design) that go beyond UCD.

Dan Saffer
Instructor, School of Design
Carnegie Mellon University
http://www.odannyboy.com/vid05

14 Feb 2005 - 8:22pm
Andrei Herasimchuk
2004

Dan Saffer wrote:

> Is UCD a methodology or a philosophy of designing? It seems like we're
> mixing and matching the two interpretations.

From all discussions I've seen and had around it, I've seen people
treat it primarily as the former.

> Thus, if you think a particular methodology (eg collaborative designing)
> has too strong a research component, you could still call yourself a
> follower of UCD if your philosophical point of departure is that as
> designers we should consider the users and their needs first.

Even if you do subscribe that line of thinking, it then begs the
question how is it that users and their needs come first? Should they?

(Random side question: Does one think that God, the ultimate Designer,
cared about "user needs" when designing the universe or our bodies as we
inhabit it? From the issues I've encountered while being alive in this
universe, I'm not convinced he did. I mean... the awkwardness of
puberty, sexual encounters, the need to relieve the body of waste, pain
in general... the whole lot of it doesn't feel like my needs coming
first in terms of how I should be designed. But maybe that's all just an
argument for the need for UCD. Ok... back to the discussion.)

As a philosophical design pov, I don't subscribe to the notion that
users *always* come first. Maybe a good deal of the time, but always? I
find it gets one into trouble often when it clashes headlong into
business/technology issues. I understand the intent behind it, but in
practice I'm not convinced it's the most effective approach to high-tech
design problems.

> You can, of course, approach a problem by considering the
> technology involved first.

You can also approach a problem as an even mix of user needs, business
requirements and technological constraints/possibilities. That seems a
far healthier an approach to me.

The hardest aspect of the discussion for me is where to begin as a
designer, because you have to begin somewhere. And then, how do you
avoid the pitfalls and traps of letting your starting point color or
blind you to everything else you might need to do on a project?

UCD starts with answering the question "who is your user" and seems to
work out from there. I find that sometimes I can start there, but some
times I need to start elsewhere.

> I think there's a great discussion waiting to happen here on other
> systems of designing (like systems design) that go beyond UCD.

Indeed. Systems design and architectural frameworks definitely feel like
they are short-changed in all the talk over UCD.

Further, discussion on how to break new ground also seems to be missing
in the conversation. How does something like the iPod, Google's
minimalist Search field at a time when crowded portals were the rage,
Graffiti for the Palm Pilot, email clients, even the mouse... how does
one account for these in UCD practices?

Andrei

15 Feb 2005 - 3:43am
Narey, Kevin
2004

Billie wrote:

>pay for (at least some) design time up front, or spend the remainder
>of the product's life cycle chasing around after messy code and interaction
with a push broom.

Why give management/customers that option? Why do they need to know that
it's an option? Why not scale down all activities proportionally
(design/development/testing etc) on a 'reduced quality' basis if the costs
are an issue (I.e. less time you pay for, lower the quality).

If UCD (or the activities that we all practice) is a default in the software
development process of the service provider, why does the customer need to
know? They're only interested in solving their business problem with the
minimal amount of cost possible. They don't care too much how we do it, they
just want the problem solved.

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

15 Feb 2005 - 9:48am
Coryndon Luxmoore
2004

Andrei said:
> As a philosophical design pov, I don't subscribe to the notion that
> users *always* come first. Maybe a good deal of the time, but always? I
> find it gets one into trouble often when it clashes headlong into
> business/technology issues. I understand the intent behind it, but in
> practice I'm not convinced it's the most effective approach to high-tech
> design problems.

I agree and disagree if I may ;)

When we talk about users we tend to focus on the people in front of the screen. I personally see the business as equal or greater user and find that an effective design has to be driven by this user as much or more than the actual person in front of the screen. Failing to treat the business as an end user IMHO tends to doom a project and a design faster than the most usable application.

We generally only do work because we are being asked to meet the needs of an organization. Each of these have drivers that are frequently different than the end user. Sometimes the needs of the business align with the need to create a great user experience and sometimes not. Recognizing the extent of the alignment, I have found, helps you scale the components of your approach appropriately.

This is a task that I frequently see skipped by those in the design profession and it can doom your estimation and approach. When a business sees you understand thier drivers and you explicitly map those drivers to your approach you will find the cost, time, and process much easier to sell.

As a side benefit this task is frequently not done by the technologists on the project either. So taking the time to do this can place you at an advantage when you are fighing for a feature or behavior because you are more likely to have the support of the business due to your understanding of thier needs and drivers.

Andrei said:
> Further, discussion on how to break new ground also seems to be missing
> in the conversation. How does something like the iPod, Google's
> minimalist Search field at a time when crowded portals were the rage,
> Graffiti for the Palm Pilot, email clients, even the mouse... how does
> one account for these in UCD practices?

While at Sapient I was privileged to see many user research techniques used to help drive innovative ideas and approaches. They used extensive anthropological research, field observation, user journals, etc to get wonderful insights into the end user's mind and approach to problems and products.

I have also seen the opposite. Where an inspired individual comes up with an idea instinctually without that kind of input. Though that is rarer in my experience.

--Coryndon

Syndicate content Get the feed