Do UX designers suffer from perfectionism?

1 Dec 2005 - 11:20pm
8 years ago
24 replies
505 reads
Wendy Fischer
2004

I am just wondering if any of you have ever been accused of suffering from perfectionism when you're designing and working on projects. Somebody just told me that many usability folks suffer from perfectionism and it's their biggest downfall.

I'd like to think that I am flexible and that I am open to suggestions when collaborating with engineering. However, when it actually comes to deploying a build to an actual client, part of my process is to go through the build before it goes to QA and then beta to get the UX and the aesthetic fixed so that the product reflects the specs that were created and that the little things are caught so we don't have to go back and file a bug later or have usability issues pointed out and then have them take forever to get fixed.

Should I just quit worrying about what goes out the door and leave it in somebody else's hands? I didn't think I was that focused on perfectionism in products (I'm not really that anal retentive).

What are others' experience with reviewing builds and customer deployments and get issues fixed?

-Wendy

Comments

1 Dec 2005 - 11:28pm
Donna Maurer
2003

I thought that's why they hired me ;)

There is a difference between wanting to make sure the product
that is shipping is as good as possible within all the practical
constraints; and fighting to make it perfectly usable. I suspect
that's what your colleague may have been talking about - a
usability person who wants it to be perfectly usable (an
unattainable and undefinable goal anyway). I give in on plenty of
things to get an app to be usable in a way that is practical for
the whole project, and pay a lot of attention to detail on those
aspects (the UI) that no-one else cares about...

Donna

On Thu Dec 01 20:20:56 PST 2005, Wendy Fischer
<erpdesigner at yahoo.com> wrote:

>
> I am just wondering if any of you have ever been accused of
> suffering from perfectionism when you're designing and working
> on projects. Somebody just told me that many usability folks
> suffer from perfectionism and it's their biggest downfall.
>

1 Dec 2005 - 11:38pm
Dave Malouf
2005

> I am just wondering if any of you have ever been accused of
> suffering from perfectionism when you're designing and
> working on projects. Somebody just told me that many
> usability folks suffer from perfectionism and it's their
> biggest downfall.

Hi Wendy,

I've been accused of similar things. Here's the way I think of it.
Our job is evangelist and advocate. B/c almost every project you work on
will be weighted too much towards tech or business, we need to be the
sticklers who want to bring the user back into the picture. It sometimes
means we are the bad cop.

What I have tried to do is be a diplomat more than a stickler and I feel it
has been working. What I do is acknowledge technical constraints and try to
create plans for compromise by building value statements. The first part is
that production people are overworked and usually underpaid for what they
pull off. They just don't like the knitpicking and want to be done. "Change"
is their enemy. So we need to be sensitive to that, while fighting for the
value we believe we are offering all the stakeholders.

I have been known to throw my hands up in the air and just say, "its out of
my hands" at that stage when I know change is not going to happen any more.
But up till that point, I usually play a mix of hard-ball with some honey
coating. :)

- dave

2 Dec 2005 - 12:11am
penguinstorm
2005

On Dec-1-2005, at 8:20 PM, Wendy Fischer wrote:

> I am just wondering if any of you have ever been accused of
> suffering from perfectionism when you're designing and working on
> projects. Somebody just told me that many usability folks suffer
> from perfectionism and it's their biggest downfall.

I don't think it's purely a fault of UX designers. Graphic designers,
architects and others could be said to suffer the same thing.

I tend to think that there's a gap created when people's job
descriptions don't require them to execute. When you're not the
person who needs the thing to ship, it's a lot easier to be a
perfectionist.

I don't think this is a bad thing either: I think it's important. It
can create tension and cause grief, but it can also result in
substantially better products. Perfection is an enviable goal.
--
Scott Nelson
skot (at) penguinstorm (dot) com
http://www.penguinstorm.com/

skype. skot.nelson

2 Dec 2005 - 12:19am
leo.frishberg a...
2005

Wendy,

> I'd like to think that I am flexible and that I am open to
>suggestions when collaborating with engineering. However,
>when it actually comes to deploying a build to an actual
>client, part of my process is to go through the build before
>it goes to QA and then beta to get the UX and the aesthetic
>fixed so that the product reflects the specs that were
>created and that the little things are caught so we don't have
>to go back and file a bug later or have usability issues
>pointed out and then have them take forever to get fixed.

I don't think UX designers have a monopoly on "perfectionism."
Designers in general, at least the ones I have had the pleasure of
knowing, care deeply that their work is implemented with the same care
they spent designing it.

It is part of our job to hold the line on design integrity.

There is a way to help reduce the "bad cop" dynamic however. In my
"professional practices" course during my architectural studies, the
professor related the problem of having a contractor build a brick wall
that had to have a specific pattern. With the risk of building the wall
incorrectly high, and the expense to correct it well beyond the
contractor's resources, architects developed a prototyping method called
the "test wall." The contractor is paid to build a small section of
wall which the architect is responsible for critiquing and ultimately
approving. Then, when the final wall is built, the test wall is rolled
in front of it. If the final wall doesn't match the test wall, all the
architect has to do is say: "Hmmm...it doesn't match the test wall."

No emotion. All the rules are transparent and everyone knows the risks
of non-performance up front. When the cost for failure can be many
hundreds of thousands of dollars, finding business-like procedures like
this is absolutely required.

I have tried to take these kinds of approaches in my design work so that
when the time comes for final approval, there are objective methods to
reduce the potential for acrimony.

Keep up the energy - if you don't care, no one else will, and to
paraphrase the sage, if not now, when?

Leo

2 Dec 2005 - 12:17am
livlab
2003

This speaks to roles and responsibilities.

If you are ultimately responsible for the user experience (or whoever
is), I'd expect you to be thorough and point out as much as you can at
that pre-QA stage (and before, and after) about any user-impacting
issues - as you pointed out, the sooner, the better. But there is a
difference between being thorough and being a perfectionist. I often
find that people who are more traditionaly used to software development
processes that are technology-driven in nature and don't explicitly
embrace user-centered approaches, have a hard time understanding that
scrutinizing the little things is what can make or break a good user
experience to the end user. 'Little things' are perceived as
time-consuming, not time-saving when the goal is to have a "functional"
product.

If the quality of the user experience is not embraced across roles and
is not a shared responsibility, it will always be the tug-of-war that
breaks project timelines and egos. I feel that to quit worrying about
what goes out the door and leave it in somebody else's hands is
irresponsible. If people mistake being thorough and user-focused with
being perfectionist or anal retentitive or what have you, they are the
ones failing to see the shared goal.

But it all depends on your organization's/product's/project's goals
(provide a good user experience or ship software fast?), design and
development process (adaptive or predictive?) and roles &
responsibilities inherent to these.

LL

Wendy Fischer wrote:

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>I am just wondering if any of you have ever been accused of suffering from perfectionism when you're designing and working on projects. Somebody just told me that many usability folks suffer from perfectionism and it's their biggest downfall.
>
> I'd like to think that I am flexible and that I am open to suggestions when collaborating with engineering. However, when it actually comes to deploying a build to an actual client, part of my process is to go through the build before it goes to QA and then beta to get the UX and the aesthetic fixed so that the product reflects the specs that were created and that the little things are caught so we don't have to go back and file a bug later or have usability issues pointed out and then have them take forever to get fixed.
>
> Should I just quit worrying about what goes out the door and leave it in somebody else's hands? I didn't think I was that focused on perfectionism in products (I'm not really that anal retentive).
>
> What are others' experience with reviewing builds and customer deployments and get issues fixed?
>
> -Wendy
>
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>(Un)Subscription Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org
>
>

2 Dec 2005 - 12:20am
Vishal Subraman...
2005

I think there is a line beyond which perfectionism isn't enviable
anymore (becomes a type of neuroticism). A place where I tread often.
And I hate myself for it. Like I once spent a few hours fixing an off
pixel in a diagram.

In theory, I'm a firm believer of the law of marginal utility...but as
Skot said, I don't know if designers (researchers too) are capable of it.

I guess the key is balance. Perfectionism within limits rocks.

Vishal
http://vishaliyer.com

Skot Nelson wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> On Dec-1-2005, at 8:20 PM, Wendy Fischer wrote:
>
>
>>I am just wondering if any of you have ever been accused of
>>suffering from perfectionism when you're designing and working on
>>projects. Somebody just told me that many usability folks suffer
>>from perfectionism and it's their biggest downfall.
>
>
> I don't think it's purely a fault of UX designers. Graphic designers,
> architects and others could be said to suffer the same thing.
>
> I tend to think that there's a gap created when people's job
> descriptions don't require them to execute. When you're not the
> person who needs the thing to ship, it's a lot easier to be a
> perfectionist.
>
> I don't think this is a bad thing either: I think it's important. It
> can create tension and cause grief, but it can also result in
> substantially better products. Perfection is an enviable goal.
> --
> Scott Nelson
> skot (at) penguinstorm (dot) com
> http://www.penguinstorm.com/
>
> skype. skot.nelson
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

2 Dec 2005 - 12:36am
Wendy Fischer
2004

I will definitely say I'm not a perfectionist nor overly anal retentive.

I have worked with designers who will work for hours to find just the "right" color and kern themselves to death in order to get the fonts perfect. I worked for one Director of UX Design that was extremely anal retentive--designers would get points off for not having their specs looking a certain way, not posting under the right category on the UX intranet or not having the right amount of pixel spacing in a final mockup (she counted pixels when mockups were posted).

When I look at UX, I'm looking at 1) how does the interface look in several mobile phones 2) did the developer follow the specs and if he didn't a) is his solution improving the usability or b) is there a reason that he did something different and should we fix it and 3) I'm looking at the aesthetic to make sure that there's consistency in naming, colors, bolding, etc and looking for things the developer missed to make sure that the design looks nice before it goes out to a customer..I'd like to think that there's a certain minimum threshold of quality that should go into a product before it launches for a customer, particularly in one that generates revenue for the company.

-wendy

Vishal iyer <iyervish at msu.edu> wrote: I think there is a line beyond which perfectionism isn't enviable
anymore (becomes a type of neuroticism). A place where I tread often.
And I hate myself for it. Like I once spent a few hours fixing an off
pixel in a diagram.

In theory, I'm a firm believer of the law of marginal utility...but as
Skot said, I don't know if designers (researchers too) are capable of it.

I guess the key is balance. Perfectionism within limits rocks.

Vishal
http://vishaliyer.com

Skot Nelson wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> On Dec-1-2005, at 8:20 PM, Wendy Fischer wrote:
>
>
>>I am just wondering if any of you have ever been accused of
>>suffering from perfectionism when you're designing and working on
>>projects. Somebody just told me that many usability folks suffer
>>from perfectionism and it's their biggest downfall.
>
>
> I don't think it's purely a fault of UX designers. Graphic designers,
> architects and others could be said to suffer the same thing.
>
> I tend to think that there's a gap created when people's job
> descriptions don't require them to execute. When you're not the
> person who needs the thing to ship, it's a lot easier to be a
> perfectionist.
>
> I don't think this is a bad thing either: I think it's important. It
> can create tension and cause grief, but it can also result in
> substantially better products. Perfection is an enviable goal.
> --
> Scott Nelson
> skot (at) penguinstorm (dot) com
> http://www.penguinstorm.com/
>
> skype. skot.nelson
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

2 Dec 2005 - 12:42am
Todd Warfel
2003

Strive for perfection, but have a plan B.

On Dec 1, 2005, at 11:20 PM, Wendy Fischer wrote:

> Should I just quit worrying about what goes out the door and
> leave it in somebody else's hands? I didn't think I was that
> focused on perfectionism in products (I'm not really that anal
> retentive).
>
> What are others' experience with reviewing builds and customer
> deployments and get issues fixed?

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

2 Dec 2005 - 11:31am
david gee
2004

Wendy Fischer wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I am just wondering if any of you have ever been accused of suffering from perfectionism when you're designing and working on projects. Somebody just told me that many usability folks suffer from perfectionism and it's their biggest downfall.
>
I consider being a stubborn, cranky perfectionist to be a major part of
my job. I've found that making this clear to the people I work with, and
being able to let go and move on with a smile on your face when you lose
a battle goes a long way. I think the push/pull between engineering and
design is a good thing, so long as you don't allow yourself to become
personally invested in the outcome.

--
david gee ::: david at mode3.com ::: http://www.mode3.com/david

2 Dec 2005 - 11:34am
jrrogan
2005

QA is your friend, and the proper way to identify and prioritize bugs.
Iterative development is another good buddy, and plays very well with QA.

During Development for sure it's valuable to review incremental builds with
developers, (collaborative design and dev is another friend), but when the
build is completed in a good enough fashion for engineering, why would you
want to do extensive review before build is submitted to QA?

The "Grim Prospects of Management Reality" is a common to experience in not
respecting lower level bugs; most experience/layout/graphical bugs come in
at 3's and 4's. This issue has to be identified for what it really is and
that is a Management issue, or it will never be fixed.

These management issues can be resolved through effective iterative
development and QA review, which involve reprioritizing lower level bugs to
ensure they get fixed.

Iterative design/dev/QA helps a lot in allowing the level 1's and 2's to get
fixed then escalate the 3's and 4's. It is Ixd's responsibility to determine
the "Usability Risk Assessment" and articulate this to the team.

You've got to call a spade a spade, Management is the only entity that can
step up to the task and raise usability bugs, or else "Risk of Product
Failure" will increase.

2 Dec 2005 - 11:48am
penguinstorm
2005

On Dec-2-2005, at 8:34 AM, Rich Rogan wrote:

> QA is your friend, and the proper way to identify and prioritize bugs.
> Iterative development is another good buddy, and plays very well
> with QA.

Absolutely. I'm astonished that people see QA as catching bugs at the
end of development and before launch.

QA is a critical role throughout the development cycle, and working
with them is the best way to get a product shipped on time.
--
Scott Nelson
skot (at) penguinstorm (dot) com
http://www.penguinstorm.com/

skype. skot.nelson

2 Dec 2005 - 2:49pm
cfmdesigns
2004

Wendy Fischer <erpdesigner at yahoo.com> writes:

> I'd like to think that I am flexible and that I am open to
>suggestions when collaborating with engineering. However, when it
>actually comes to deploying a build to an actual client, part of my
>process is to go through the build before it goes to QA and then
>beta to get the UX and the aesthetic fixed so that the product
>reflects the specs that were created and that the little things are
>caught so we don't have to go back and file a bug later or have
>usability issues pointed out and then have them take forever to get
>fixed.

Ideally, you should have skilled UI QA folks involved. These people
(hey, like me!) should be involved in reviewing the UI specs before
things ever start to get implemented. They will be looking at how
they are going to test the design, and thus the first stage of how
real users will use it. (QA are "fake" users: we often test things
in ways that no real users ever would, as well as trying to test
viable workflows.)

The biggest roadbump I encounter as UI QA is that other facets of the
team don't want to trust my insights and opinions. Time after time,
I've fought back and forth with a programmer, passed things off to
the UI designer for an answer, and had the answer come back that the
UI QA is right. (Not that I am 100% right, but more often than I'm
not!) Or worse, I identify an issue, it gets slapped down, and then
real users complain -- and then it gets addressed, but of course not
until a year or two after I talked about it. (And you know, the "I
told you so" dance only soothes the damaged soul so much.) Needless
to say, I've learned about CYA over the years: remember those bug
reports and be able to find them again later when someone wails "Why
didn't we catch and fix this?"

The interesting side angle is that a focus on the fine-grain details
doesn't mean that my testing misses the larger issues. Historical
looks in the bug databases have shown that my bug reporting tends to
find basically the same percentage of crashers and other serious bugs
as the testing of other QA folks, despite the seeming horde of
"nitpick" bugs. (Which I assume few here think are really
"nitpicks".)

(All of that said: definitely any version of software should have
some vetting done by the person immediately responsible for it before
releasing it to QA or others. "Uni testing" being the typical term,
but it's designed usually to catch the gross bugs, not work out all
the UX kinks.)
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 11/05)

2 Dec 2005 - 2:56pm
cfmdesigns
2004

Livia Labate <liv at livlab.com> writes:

>I often find that people who are more traditionaly used to software
>development processes that are technology-driven in nature and
>don't explicitly embrace user-centered approaches, have a hard time
>understanding that scrutinizing the little things is what can make
>or break a good user experience to the end user. 'Little things' are
>perceived as time-consuming, not time-saving when the goal is to
>have a "functional" product.

A-men. I wish, I wish, I wish that teams would have a dedicated
development resource just for those hordes of low-level bugs which
add up to large user experience effects. Someone whose job is to
sweat about the pixel alignments and the line breaks and the
differences in Polish plurality between "a few" and "many".

On one project, as UI QA, they put me in charge of editing all the
English string files before sending them off to translation services.
(I was the squeaky wheel.) So I reviewed about 350 pages of strings
from dozens of modules on several platforms created over a decade by
a hundred programmers, and made lots and lots and lots of edits.
Probably the most consistent and correct dialog and alert strings on
a project that size ever. Also the happiest QA engineer you can
imagine, since so many of my bug reports got fixed. <grin>
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 11/05)

2 Dec 2005 - 5:15pm
Jared M. Spool
2003

At 11:31 AM 12/2/2005, David Gee wrote:
>I consider being a stubborn, cranky perfectionist to be a major part of my
>job.

You're kidding, right?

Is this really a rewarding way to build a collaborative team?

Jared

Jared M. Spool, Founding Principal, User Interface Engineering
4 Lookout Lane, Unit 4d, Middleton, MA 01949
978 777-9123 jspool at uie.com http://www.uie.com
Blog: http://www.uie.com/brainsparks

2 Dec 2005 - 5:45pm
cherylkimble
2005

i think what was meant is that being a "perfectionist" (stubborn,
cranky, pain in the *ss, take your pick) is a common misconception
about who we are and what we do.

in corporate america your not a "team player" if you don't allow
product, engineering, usability, design and the ceo's wife to put
their thumbprint all over the info arch. i'm not suggesting that good
ideas are ignored because they came from outside of ux, but i can't
do my job without having ownership. i am the "expert" afterall.
(isn't that why they hired me?)

this is also a particularly corporate outlook. when i worked for
small design shops, i had the complete trust of my team, including my
bosses, and was able to do some of the best work of my career.

so my question, jared, is what exactly is your idea of collaboration?
how far does it extend into the process?

best,

cheryl kimble

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>At 11:31 AM 12/2/2005, David Gee wrote:
>>I consider being a stubborn, cranky perfectionist to be a major part of my
>>job.
>
>You're kidding, right?
>
>Is this really a rewarding way to build a collaborative team?
>
>Jared

5 Dec 2005 - 3:32pm
cfmdesigns
2004

>(All of that said: definitely any version of software should have
>some vetting done by the person immediately responsible for it before
>releasing it to QA or others. "Uni testing" being the typical term,
>but it's designed usually to catch the gross bugs, not work out all
>the UX kinks.)

Foo. "Unit Testing", that is.

I don't recommend testing the unicorn pet from the old Dungeons &
Dragons cartoon. Unless you're a virgin, of course.

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 11/05)

5 Dec 2005 - 6:31pm
Jared M. Spool
2003

At 05:45 PM 12/2/2005, cheryl kimble wrote:
>so my question, jared, is what exactly is your idea of collaboration?

This is a large topic. Not something that can easily be discussed in a
simple response. However, I'll do my best to give a short summary:

We've been studying how UX professionals work within design teams, looking
at dozens of organizations for a variety of different products and
applications. (This is an ongoing research project, now in it's fourth year.)

So far, our research has determined that you can classify UX group
approaches into three major categories:

1) Consulting - where the UX group produces every UI design for every project
2) Review & Approve - where the UX group lets non-UX professionals produce
designs, but they review and approve (or reject) them.
3) Educate & Administrate - where the UX group facilitates non-UX
professionals to produce design by educating them on design technique and
administrating various processes (such as providing usability evaluation
services on demand).

Our early results seem to indicate that, by far, the third category
(Educate & Administrate) is far more likely to produce repeated usable
designs than the other two. (The first -- Consulting -- works for very
small groups who produce a very limited number of designs per year. But it
doesn't scale well at all. The second -- Review & Approve -- has an initial
positive effect, but after a period of a 6-months to a year, also suffers
from a scaling issue.)

We've met a lot of people who believe that a confrontational approach works
well in the review & approve category. Of course, it doesn't work well for
long, so they find themselves struggling.

We haven't met *anyone* who has succeeded in the educate & administrate
category with a confrontational approach. For the people who have succeeded
there, they've found that collaboration with the other design agents
(people who influence design in the organization) is far more effective.

>how far does it extend into the process?

Very far. Our findings are that the most successful organizations are those
that make this collaborative approach very cultural. It forms the basis of
how people approach the design task and how they dovetail into the rest of
the organization.

As I said, our research is ongoing and I have a lot more I can say on the
topic, but, unfortunately, I need to go home and feed my son. We're going
to be discussing some of the preliminary findings on our blog over the next
few weeks and we'll talk about some of it at our upcoming six-city roadshow.

Hope this is helpful,

Jared

Jared M. Spool, Founding Principal, User Interface Engineering
4 Lookout Lane, Unit 4d, Middleton, MA 01949
978 777-9123 jspool at uie.com http://www.uie.com
Blog: http://www.uie.com/brainsparks

7 Dec 2005 - 3:02pm
Robert Reimann
2003

Jared,

Thanks for posting these interesting results.

I believe that a lot of what makes the Consulting model work
is having a very well-defined design process that is followed by
practitioners and is well-communicated to the rest of the org.
The UX process also needs to interleave effectively with other
functional processes in the organization.

This is critical not only for effective and efficient work
within the UX organization (and in its touch points with other
functions), but it is also typically a requirement for the UX
group to get the resources it needs to scale properly with the
growing demand for its services.

I completely agree that a "confrontational" approach to dealing
with other functions in any of these models is counterproductive
at best, and disastrous at worst, and that cross-functional buy-in
and collaboration are critical to UX's success, no matter which
model is chosen.

Robert.

---

Robert Reimann
President, IxDA

Manager, UI Design and Research
Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Jared M. Spool
Sent: Monday, December 05, 2005 6:31 PM
To: cheryl kimble
Cc: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Do UX designers suffer from perfectionism?

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

At 05:45 PM 12/2/2005, cheryl kimble wrote:
>so my question, jared, is what exactly is your idea of collaboration?

This is a large topic. Not something that can easily be discussed in a
simple response. However, I'll do my best to give a short summary:

We've been studying how UX professionals work within design teams,
looking
at dozens of organizations for a variety of different products and
applications. (This is an ongoing research project, now in it's fourth
year.)

So far, our research has determined that you can classify UX group
approaches into three major categories:

1) Consulting - where the UX group produces every UI design for every
project
2) Review & Approve - where the UX group lets non-UX professionals
produce
designs, but they review and approve (or reject) them.
3) Educate & Administrate - where the UX group facilitates non-UX
professionals to produce design by educating them on design technique
and
administrating various processes (such as providing usability evaluation

services on demand).

Our early results seem to indicate that, by far, the third category
(Educate & Administrate) is far more likely to produce repeated usable
designs than the other two. (The first -- Consulting -- works for very
small groups who produce a very limited number of designs per year. But
it
doesn't scale well at all. The second -- Review & Approve -- has an
initial
positive effect, but after a period of a 6-months to a year, also
suffers
from a scaling issue.)

We've met a lot of people who believe that a confrontational approach
works
well in the review & approve category. Of course, it doesn't work well
for
long, so they find themselves struggling.

We haven't met *anyone* who has succeeded in the educate & administrate
category with a confrontational approach. For the people who have
succeeded
there, they've found that collaboration with the other design agents
(people who influence design in the organization) is far more effective.

>how far does it extend into the process?

Very far. Our findings are that the most successful organizations are
those
that make this collaborative approach very cultural. It forms the basis
of
how people approach the design task and how they dovetail into the rest
of
the organization.

As I said, our research is ongoing and I have a lot more I can say on
the
topic, but, unfortunately, I need to go home and feed my son. We're
going
to be discussing some of the preliminary findings on our blog over the
next
few weeks and we'll talk about some of it at our upcoming six-city
roadshow.

Hope this is helpful,

Jared

Jared M. Spool, Founding Principal, User Interface Engineering 4 Lookout
Lane, Unit 4d, Middleton, MA 01949
978 777-9123 jspool at uie.com http://www.uie.com
Blog: http://www.uie.com/brainsparks

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

7 Dec 2005 - 4:55pm
niklasw
2005

Interesting facts Jared. I can only confirm and as I'm reading it, it
strikes me:

I've been in several different UX related positions at my current
employer for about 5 years now. A ~9000 people telecoms operator in
Sweden with a development department of about ~600 people. As a matter
a fact in some ways our internal UX team, ~13 people depending on how
you count (actually UX teams initially) has migrated through all three
categories during a four year period. We have now ended up being a
group primarily working with incorporating "design and usability -
D&U" related processes and methods (as we have chosen to communicate
it) into the company's common development process. So now we have
projects managing their D&U related issues on their own but with the
guidance and support of our UX team. Our strongest 'ammunition' is
being part of the decision point quality review council where we have
veto to stop projects based on 'poor' D&U performance.

I'd also like to bring up in relation to this is the, in our case,
almost collective and unaware frustration before accepting the fact
that we as a group belong to the third category. Which we in some
cases still are struggling with accepting. In my case and several with
me joined the company as specialists to do hands on interaction
design, usability evaluations or any other UX related tasks and now
after a couple of years find ourselves mainly mentoring or managing
instead.

Maybe this is a manifestation of our perfectionism?

--Niklas

Interaction designer at TeliaSonera
http://www.teliasonera.com

> So far, our research has determined that you can classify UX group
> approaches into three major categories:
>
> 1) Consulting - where the UX group produces every UI design for every project
> 2) Review & Approve - where the UX group lets non-UX professionals produce
> designs, but they review and approve (or reject) them.
> 3) Educate & Administrate - where the UX group facilitates non-UX
> professionals to produce design by educating them on design technique and
> administrating various processes (such as providing usability evaluation
> services on demand).
>
> Our early results seem to indicate that, by far, the third category
> (Educate & Administrate) is far more likely to produce repeated usable
> designs than the other two. (The first -- Consulting -- works for very
> small groups who produce a very limited number of designs per year. But it
> doesn't scale well at all. The second -- Review & Approve -- has an initial
> positive effect, but after a period of a 6-months to a year, also suffers
> from a scaling issue.)

7 Dec 2005 - 3:49pm
cherylkimble
2005

i guess i'd like to know what the definition of "confrontational" is.
isn't it our job as information architects to be the hole-pokers? and
if what jared states is true, that the job has now turned into an
"educational role" isn't that usability and not ia? and how does this
work in a corporate environment where ux is under the thumb of
another department (namely product or marketing) and they simply
ignore or discount your advice and then, of course, expect you to
create all the documentation?

i, for one, refuse to become a doc jockey, unless of course i'm a
highly paid one...

best,

cheryl

>
>I completely agree that a "confrontational" approach to dealing
>with other functions in any of these models is counterproductive
>at best, and disastrous at worst, and that cross-functional buy-in
>and collaboration are critical to UX's success, no matter which
>model is chosen.
>

7 Dec 2005 - 6:11pm
jstanford
2003

I have some thoughts about confrontational approach. Overall, I feel like it
does a disservice not only to yourself or your organization, but also
negatively impacts the profession overall. Very frequently, when I work with
the engineering team at a new client site, I have to overcome the initial
objections of the engineers against UI design assistance because they have
had a poor interaction with an overlly confrontational UI designer in the
past. I call this phenomenon "Every engineer has been beaten by the UI
designer as a child."

Usually, the first steps in my relationship with a new engineering team are
a sort of psychotherapy approach where I work hard to subtly convince them
of three things:

1) I'm reasonable and will not be confrontational.
2) I respect them, their profession, and all of their ideas.
3) I am smart and will not suggest crazy things that can never be
implemented.

Often this is very hard because members of the team have had recent bad
experiences with a designer.

Unfortunately, once someone has had an experience with someone who is
confrontational, does not appear to respect ideas (even if the ideas do seem
pretty poor on the surface), and frequently suggests things that engineers
don't believe can be implemented without any caveats, this results in a
bitter angry engineer who is going to take this baggage to their next
experience with an interaction designer much in the same way that people who
are abused carry their baggage around with them to different relationships.

I propose that you can accomplish the same success in creating an excellent
user experience without being confrontational, even in very sticky
situtions. If you are snippety and appear inflexible, then in the long run
people will remember your behavior and generalize on the whole profession as
opposed to remembering how awesome the design was in the end. By prototyping
someone's weird idea which they keep pushing and showing it around to a
couple of folks in tandem with your idea, you'll end up getting your way in
the end anyway and everyone will be happy because they'll feel like they
were heard.

Two cents from someone who doesn't like carrying other people's baggage. :-)

_____________________________________
Julie Stanford
Principal, Sliced Bread Design | www.slicedbreaddesign.com
650-799-7225

> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On
> Behalf Of Reimann, Robert
> Sent: Wednesday, December 07, 2005 12:02 PM
> To: discuss at ixdg.org
> Subject: Re: [IxDA Discuss] Do UX designers suffer from perfectionism?
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
>
> Jared,
>
> Thanks for posting these interesting results.
>
> I believe that a lot of what makes the Consulting model work
> is having a very well-defined design process that is followed
> by practitioners and is well-communicated to the rest of the org.
> The UX process also needs to interleave effectively with
> other functional processes in the organization.
>
> This is critical not only for effective and efficient work
> within the UX organization (and in its touch points with
> other functions), but it is also typically a requirement for
> the UX group to get the resources it needs to scale properly
> with the growing demand for its services.
>
> I completely agree that a "confrontational" approach to
> dealing with other functions in any of these models is
> counterproductive at best, and disastrous at worst, and that
> cross-functional buy-in and collaboration are critical to
> UX's success, no matter which model is chosen.
>
> Robert.
>
> ---
>
> Robert Reimann
> President, IxDA
>
> Manager, UI Design and Research
> Bose Corporation
> The Mountain
> Framingham, MA 01701
>
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On
> Behalf Of Jared M. Spool
> Sent: Monday, December 05, 2005 6:31 PM
> To: cheryl kimble
> Cc: discuss at lists.interactiondesigners.com
> Subject: Re: [IxDA Discuss] Do UX designers suffer from perfectionism?
>
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
> At 05:45 PM 12/2/2005, cheryl kimble wrote:
> >so my question, jared, is what exactly is your idea of collaboration?
>
> This is a large topic. Not something that can easily be
> discussed in a simple response. However, I'll do my best to
> give a short summary:
>
> We've been studying how UX professionals work within design
> teams, looking at dozens of organizations for a variety of
> different products and applications. (This is an ongoing
> research project, now in it's fourth
> year.)
>
> So far, our research has determined that you can classify UX
> group approaches into three major categories:
>
> 1) Consulting - where the UX group produces every UI design
> for every project
> 2) Review & Approve - where the UX group lets non-UX
> professionals produce designs, but they review and approve
> (or reject) them.
> 3) Educate & Administrate - where the UX group facilitates
> non-UX professionals to produce design by educating them on
> design technique and administrating various processes (such
> as providing usability evaluation
>
> services on demand).
>
> Our early results seem to indicate that, by far, the third
> category (Educate & Administrate) is far more likely to
> produce repeated usable designs than the other two. (The
> first -- Consulting -- works for very small groups who
> produce a very limited number of designs per year. But it
> doesn't scale well at all. The second -- Review & Approve --
> has an initial positive effect, but after a period of a
> 6-months to a year, also suffers from a scaling issue.)
>
> We've met a lot of people who believe that a confrontational
> approach works well in the review & approve category. Of
> course, it doesn't work well for long, so they find
> themselves struggling.
>
> We haven't met *anyone* who has succeeded in the educate &
> administrate category with a confrontational approach. For
> the people who have succeeded there, they've found that
> collaboration with the other design agents (people who
> influence design in the organization) is far more effective.
>
> >how far does it extend into the process?
>
> Very far. Our findings are that the most successful
> organizations are those that make this collaborative approach
> very cultural. It forms the basis of how people approach the
> design task and how they dovetail into the rest of the organization.
>
> As I said, our research is ongoing and I have a lot more I
> can say on the topic, but, unfortunately, I need to go home
> and feed my son. We're going to be discussing some of the
> preliminary findings on our blog over the next few weeks and
> we'll talk about some of it at our upcoming six-city roadshow.
>
> Hope this is helpful,
>
> Jared
>
>
> Jared M. Spool, Founding Principal, User Interface
> Engineering 4 Lookout Lane, Unit 4d, Middleton, MA 01949
> 978 777-9123 jspool at uie.com http://www.uie.com
> Blog: http://www.uie.com/brainsparks
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org Home
> ....................... http://ixda.org/ Resource Library
> ........... http://resources.ixda.org
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org List Guidelines
> ............ http://listguide.ixda.org/ List Help
> .................. http://listhelp.ixda.org/ (Un)Subscription
> Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org Home
> ....................... http://ixda.org/ Resource Library
> ........... http://resources.ixda.org
>

9 Dec 2005 - 9:16am
ldebett
2004

This is great:

"Every engineer has been beaten by the UI designer as a child."

In my previous position, I couldn't figure out if this was the case or if
the engineers had been doing UI for so long that they resented the fact that
I was "taking away the fun part of their job", since I heard that often too.
Some engineers couldn't get over my existence, but the ones that were more
receptive, I made sure to listen to their ideas and discuss the technical
roadblocks facing design implementation to brainstorm ideas around them.
There were still cases of engineers implementing what they wanted regardless
of the design, but I came to see that as a failure in the culture that
forgave that disrespectful behavior.

Currently, I also try to practice Julie's 3 points of psychotherapy:

1) I'm reasonable and will not be confrontational.
2) I respect them, their profession, and all of their ideas.
3) I am smart and will not suggest crazy things that can never be
implemented.

and add one more:
4) I want to continue our working relationship after this meeting/event/day
and will therefore behave accordingly.

~Lisa

18 Dec 2005 - 4:46pm
penguinstorm
2005

On Dec-7-2005, at 12:49 PM, cheryl kimble wrote:

> know what the definition of "confrontational" is.
> isn't it our job as information architects to be the hole-pokers?

Sure. But you can poke holes with your index finger, or you can poke
holes with a razor sharp knife. The result tends to be different.

The definition of confrontational can be too, so it's going to vary
from person to person.
--
Scott Nelson
skot (at) penguinstorm (dot) com
http://www.penguinstorm.com/

skype. skot.nelson

24 Jan 2006 - 9:06pm
Greg Phillips
2006

I like to think of it in terms of the Japanese principle of Kaizen --
the art of continual refinement. This removes the stigma and
goal-oriented nature of "perfectionism" and focuses on process and
improvement -- which is all any of us can really do in the long run.
It's the journey, not the destination, as they say!

Also, I try to think like a good film editor when it comes to the
ultimate pursuit of this refinement: knowing what scenes to cut and what
to keep. The combination of diplomacy and creative discretion is
important in my work, since there is a lot of give-and-take between
interaction design (IA), tech and business. Having sat on all sides at
various times in my career, I find I am more able to navigate and
understand the various needs of each, and thus choose my battles more
wisely.

Greg Phillips ~ Sr. Information Architect
Walt Disney Parks and Resorts Online

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
David Heller
Sent: Thursday, December 01, 2005 8:39 PM
To: discuss at ixdg.org
Subject: Re: [IxDA Discuss] Do UX designers suffer from perfectionism?
[Please voluntarily trim replies to include only relevant quoted
material.]

> I am just wondering if any of you have ever been accused of suffering
> from perfectionism when you're designing and working on projects.
> Somebody just told me that many usability folks suffer from
> perfectionism and it's their biggest downfall.

Syndicate content Get the feed