What to do in an environment run by engineers??

25 Jan 2009 - 4:12pm
5 years ago
49 replies
969 reads
Ali Naqvi
2008

As a User Centered Design graduate I find it quite irritating to be
working in an environment where engineers run everything. My position does
not allow me to say much yet as a Tech Writer/Project Manager assisting
the engineers on usability issues I have had it!
They all believe that designing for the end users only involve usability
issues... Should I send them a copy of Allan Cooper's "The Inmates are
running the asylum"? :)
Few of them have taken some HCI courses and THATS IT!
There is NO qualitative research and both hardware-/software engineers
think that their own opinion about the products matter.

Comments

25 Jan 2009 - 5:03pm
Jay Morgan
2006

Time to work on your persuasion skills, patience, and what Peter Merholtz
refers to IA (in this case, IxD) Judo. And, use Stephen Anderson's
"Eye-Candy is a Critical Business Requirement" to build your case,
http://www.slideshare.net/stephenpa/eye-candy-is-a-critical-business-requirement.<http://www.slideshare.net/stephenpa/eye-candy-is-a-critical-business-requirement>
It's not they're engineers that makes them this way - feeling unswayed by
arguments beyond their own opinion. This tends to be the case when one group
dominates. They're not accustomed to being challenged or questioned, and
they probably don't realize that you're trying to make an impact. In the
early days, you're likely more a pest to them than one who is bringing valid
arguments for product improvement.

I've had similar experience is creative-dominated organizations and
merchant-dominated organizations. Those groups matured long before the
front-end was a substantial part of the work, so they were settled and
stubborn. To me, it seemed like they didn't care at all. In fact, they just
cared about things that were at first not visible to me. In order to become
part of the team, I had to first get a glimpse of what was important to
them. In some ways it's like going to a new high school and having to
infiltrate a new clique. I've just joined a new, creative-dominated group
and am experiencing the same challenge all over again.

First, show them that you can work with them, on their terms. Your goals
would be keeping up and still adding value while swallowing your pride.
You've learned a lot in school, so you feel like you know how to fix their
problems. But, they've been doing their stuff for a while too, and no one
likes to have a newcomer who thinks they have all the answers. You have to
pay your dues, earn your chops.
Next, find partners, whether they're inside or outside the engineering
group. Make a connection with those people, learn from their mistakes and
successes so you can move faster and smarter. Sometimes friends can vouch
for you when you're not there, but would want someone to support you. For
instance, when project teams are being formed, or when there's a new problem
to be solved.
Then, work on something of your own that is a strong statement of your
UX/IxD skills and is *not* a challenge to their way of doing things. For
instance, maybe a ux-oriented process improvement for a problem that's been
bothering the engineering team. In the merchant-oriented business, going
from static wireframes to interactive prototypes showed them results faster
so they could make decisions faster and with less ambiguity. That made me
look valuable in a way that helped them.

I hope this helps. The culture is significant determinant of the quality of
the product. I consider it a major component of my job to to improve the
culture I work in, just as much as I improve the quality of the products.
Roughly quoting Hackos and Redish, "usability is about improving the quality
of the product...and improving the quality of the process by which products
are made."

-Jay
On Sun, Jan 25, 2009 at 4:12 PM, Ali Amrohvi <ali at amroha.dk> wrote:

> As a User Centered Design graduate I find it quite irritating to be
> working in an environment where engineers run everything. My position does
> not allow me to say much yet as a Tech Writer/Project Manager assisting
> the engineers on usability issues I have had it!
> They all believe that designing for the end users only involve usability
> issues... Should I send them a copy of Allan Cooper's "The Inmates are
> running the asylum"? :)
> Few of them have taken some HCI courses and THATS IT!
> There is NO qualitative research and both hardware-/software engineers
> think that their own opinion about the products matter.
>
>
>
>
>
> ________________________________________________________________
> 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
>

--
------------------------------------------------------------
Jay A. Morgan
Director, UX at Gage in Minneapolis

twitter.com/jayamorgan
google talk: jayamorgan
skype: jaytheia

------------------------------------------------------------

25 Jan 2009 - 5:49pm
Alex ONeal
2008

Ali,

I sympathize. What Jay recommends is excellent advice for grappling with
any overly strong and unreflective group, but there are more specific
approaches that work best with engineers and similar personality types.
Occasionally there are even advantages in having such a group.

There are two issues with engineer-driven environments.

- *Persuasion.* Building relationships and a business case is helpful.
Focus on using data that appeals to the scientific part of their brains.
Their logic and vanity will both appreciate that. I find any relevant
neuroscience data very helpful, as well as analysis that incorporates
different user types, including their type. So, have a smart engineer
persona and what works for them (probably what they're recommending), and
then explain the other types and needs, and how your approach meets them
all.
- *Development style. * More and more engineering-driven places are using
Agile and Agile-esque approaches such as Scrum for development. This can
make it challenging to meet big-picture needs such as UX & IA. It is indeed
possible, however.

First, establish public best practices and "what works" tips, and where
possible train all teams in the basics.

Second, establish UX as part of an integration team, and let them track
all the separate project streams in one place, to see overlap and conflict.

Lastly - and this isn't necessary, it just helps me personally - remember
that Agile & Scrum are basically the creative process writ large, applied to
technical development. The very act of working this way makes engineers and
developers more accessible to alternative approaches - and makes the design
people more immediately aware of dev needs, too.

I said it could help at times, too. I worked at Texas Instruments for a
while, and it's a very engineer-driven environment. However, the audience
was just over 80% engineer as well. So we could turn to our own engineers
as well as user engineers for research and testing, and happily design
primarily *to* engineers, which is a rare joy in UX. The focus is clear and
there's very little confusion as to what works and what doesn't, although
there are a few differences with the rest of the world. (For example, for
something like training informaiton, engineers prefer one long page that's
well-anchored internally, rather than multiple pages to keep most content
above the fold.)

So, those are my comments on dealing with the engineering mind set. Hope
they're useful to you!

bests,
Alex O'Neal
ux manager/social network analyst

--
The best time to plant a tree is twenty years ago. The next best time is
now.

25 Jan 2009 - 6:00pm
dirtandrust
2008

Ask them how many engineers use their software.

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

25 Jan 2009 - 6:12pm
dirtandrust
2008

"*Development style. * More and more engineering-driven places are
using Agile and Agile-esque approaches such as Scrum for development.
This can make it challenging to meet big-picture needs such as UX &
IA. It is indeed possible, however."

I'd love to learn more about this; maybe I'll start another thread?
The Dev team at my company is Agile/Scrum all the way and we're
trying, as a Design Team, to insert ourself much earlier in the
process. It's tough to get ahead of it!

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

25 Jan 2009 - 7:00pm
Janna DeVylder
2006

In work environments like this, I have found that forcing our discipline
into the process is the least effective... the "you MUST work with us"
mantra will fall on deaf ears. It's often relationship building, one person
at a time. Get one or two engineers who have seen the positive impact your
perspective has on the end product become your advocates.

Also no one likes to feel like a dumb ass. Everyone wants to feel like they
know what they're doing. So consider how you can approach the challenge as
less a Debbie (or Donnie) Downer [ie. here are all the things that are wrong
with what you've made], and more how you can make them feel like the
perspective you brought made their work better. May seem easier said than
done, but I think most of the battle is getting someone to feel like you're
a needed resource because they couldn't possibly do the work as well without
you.

janna

On Sun, Jan 25, 2009 at 5:12 PM, Ali Amrohvi <ali at amroha.dk> wrote:

> As a User Centered Design graduate I find it quite irritating to be
> working in an environment where engineers run everything.
>
>

25 Jan 2009 - 7:10pm
Angel Marquez
2008

I think that is great advice. I like it. But their are some enormous A-holes
that engineer.
I think every department should have one person from another department on
that team as a liaison. The last four or so gigs I've had have been on
engineering teams and it is not my background. What brought me to it is that
as a designer you hit road blocks when someone says 'You can't', 'Don't',
etc...
It is often b*ll sh*t and the engineers are operating behind a curtain like
the wizard of OZ.

With the last PM I worked with I said 'if you can explain it we can make it
happen.'

I don't think a good engineer says it cannot be done. I've also worked with
stellar engineers and I always make it a point to ask what is a good
deliverable for you (why) and the good ones have sent me exactly what they
want and why they want it that way. The others riddle off reasons why they
are of a superior breed and the like, they usually couldn't engineer their
way out of a wet paper bag...

On Sun, Jan 25, 2009 at 5:00 PM, Janna Hicks DeVylder <janna at devylder.com>wrote:

> In work environments like this, I have found that forcing our discipline
> into the process is the least effective... the "you MUST work with us"
> mantra will fall on deaf ears. It's often relationship building, one person
> at a time. Get one or two engineers who have seen the positive impact your
> perspective has on the end product become your advocates.
>
> Also no one likes to feel like a dumb ass. Everyone wants to feel like they
> know what they're doing. So consider how you can approach the challenge as
> less a Debbie (or Donnie) Downer [ie. here are all the things that are
> wrong
> with what you've made], and more how you can make them feel like the
> perspective you brought made their work better. May seem easier said than
> done, but I think most of the battle is getting someone to feel like you're
> a needed resource because they couldn't possibly do the work as well
> without
> you.
>
> janna
>
> On Sun, Jan 25, 2009 at 5:12 PM, Ali Amrohvi <ali at amroha.dk> wrote:
>
> > As a User Centered Design graduate I find it quite irritating to be
> > working in an environment where engineers run everything.
> >
> >
> ________________________________________________________________
> 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 Jan 2009 - 7:25pm
Jarod Tang
2007

Hi Janna,

> Also no one likes to feel like a dumb ass. Everyone wants to feel like they
> know what they're doing. So consider how you can approach the challenge as
> less a Debbie (or Donnie) Downer [ie. here are all the things that are wrong
> with what you've made], and more how you can make them feel like the
> perspective you brought made their work better. May seem easier said than
> done, but I think most of the battle is getting someone to feel like you're
> a needed resource because they couldn't possibly do the work as well without
> you.

Thanks for your inspiration. Yes, designers job is judged by what
they can build instead of insist by words.

Thanks,
Jarod
--
http://designforuse.blogspot.com/

25 Jan 2009 - 9:41pm
Gavin Burke
2008

You have to understand also the engineers perspective. From their
perspective they are the most important part of the process, without
them there would be no product just fresh air. So they feel they own
it in a way. Underneath the interface is a whole different world of
complexity. If an interface designer comes up to their desk while they
are working and tells them "I think the "ok" button needs to be more
over to the left so the user doesn't get confused", its like a voice
from another plant. Add on top of this the pressure of scrum or a
difficult project that is make or break on a technical level and you
won't get a look in.

With good product management this should never happen but the way
things are going with shorter and shorter development cycles and its
associated pressures this type of situation is inevitable.

My advice is to wait around, cut your teeth abit more and when your in
a more senior position use what you are going through now as a way of
improving things for everyone, user, engineer and yourself.

On 26 Jan 2009, at 01:10, Angel Marquez wrote:

> I think that is great advice. I like it. But their are some enormous
> A-holes
> that engineer.
> I think every department should have one person from another
> department on
> that team as a liaison. The last four or so gigs I've had have been on
> engineering teams and it is not my background. What brought me to it
> is that
> as a designer you hit road blocks when someone says 'You can't',
> 'Don't',
> etc...
> It is often b*ll sh*t and the engineers are operating behind a
> curtain like
> the wizard of OZ.
>
> With the last PM I worked with I said 'if you can explain it we can
> make it
> happen.'
>
> I don't think a good engineer says it cannot be done. I've also
> worked with
> stellar engineers and I always make it a point to ask what is a good
> deliverable for you (why) and the good ones have sent me exactly
> what they
> want and why they want it that way. The others riddle off reasons
> why they
> are of a superior breed and the like, they usually couldn't engineer
> their
> way out of a wet paper bag...
>
>
> On Sun, Jan 25, 2009 at 5:00 PM, Janna Hicks DeVylder <janna at devylder.com
> >wrote:
>
>> In work environments like this, I have found that forcing our
>> discipline
>> into the process is the least effective... the "you MUST work with
>> us"
>> mantra will fall on deaf ears.
>>
>>> As a User Centered Design graduate I find it quite irritating to be
>>> working in an environment where engineers run everything.
>>>

25 Jan 2009 - 11:29pm
Jared M. Spool
2003

On Jan 25, 2009, at 7:41 PM, gavin burke|FAW wrote:

> You have to understand also the engineers perspective. From their
> perspective they are the most important part of the process, without
> them there would be no product just fresh air.

[...]

> My advice is to wait around, cut your teeth abit more and when your
> in a more senior position use what you are going through now as a
> way of improving things for everyone, user, engineer and yourself.
>
> On 26 Jan 2009, at 01:10, Angel Marquez wrote:
>
>> I think that is great advice. I like it. But their are some
>> enormous A-holes
>> that engineer.

Wow. This Us vs. Them shit is really a bit disturbing.

There are workplaces where people collaborate well. There are
workplaces where they don't. It has nothing to do with job titles,
schooling, or base training.

While there are engineers that are assholes, there are also designers
that are assholes. And managers. And customer service people. And just
about every other job.

Creating stereotypes by job description isn't any better than creating
them by race or religion or sexual preference.

Personally, I'd like to see this conversation move to something
constructive without the bigoted tone.

To answer the crux of Ali's question about what to do:

I always recommend that you follow the money. If there are usability
problems with a product, that means that there are people who are
frustrated.

In my experience, whenever someone is frustrated, that frustration
shows itself on the organization's bottom line. Either customers are
moving to competitor's products, or they are filling up the support
lines, or the developers are wasting time redoing designs because they
got it wrong the first time.

If you look for how the frustration is impacting the bottom line,
you'll often find someone in charge of making that problem go away.
That person is likely to be a huge champion for any UX work that can
fix their problem. Tell them that you know how to fix their problem in
cost-effective manner and you'll get their attention.

If there is no pain -- inotherwords, if the organization can't feel
how their hard-to-use product is hurting them -- then there is
probably nothing you can do. (Remember the first law of consulting:
You can't stop people from sticking beans up their nose.)

In this case, if you find this frustrating, you should consider
looking for an organization that does get it. There are more and more
of those every day and it'll be a better fit for your personality.

I wrote about this in more detail here: http://is.gd/heqq

Hope that helps,

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 Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

25 Jan 2009 - 11:37pm
Angel Marquez
2008

Dude(s),I've worked for number 1 in the nation marketing and advertising
agencies.
Start ups
Freelance

In a variety of industries.

If you are asking your engineers to change something like moving a button
your process needs to be revised.

Ideal is you slowly iterate and shave off the input as the design goes down
the pipe. Check done, pass, check, done pass, oh we have a request, sorry to
late next time, check done, done, done.

Yea right! That never happens. The more process you involve and the more
people you involve the more entropy creeps into the system
and wackiness occurs.

Trying to make people understand is a waste of time. If they are able to
understand than they already do and they are using it as leverage for
whatever motivates them.

I just had this discussion with a friend that wanted to offer me some
unsolicited advice on some lame design I did and I was all hey give me a
break. I would love to provide everyone with some custom work of art; but,
c'mon! Trying to maneuver someone into a well thought out plan is like
trying to get my cats in their carrier when they know I'm taking em to the
vet! It's near impossible with trickery, chasing, them while closing and
locking doors to corner them. I can't even shake their treats to get them
from hiding when they know it's time. I also was all you have different
types of customers. Some customers 1.) you are going to stretch your own
canvas, make your own brushes, mix your own oil paints, do some studies,
sketch, paint, hand craft a complimentary frame and voila 2.) or you are
going to get a lot of pre made canvases, throw down some acrylics, whip it
out, put into one of those nice packaged frames and be done with it. 3.) or
you are going to have some ready to go out the door packaged done pieces
they can throw on the wall of their hotel lobby and collect the ambience
fee. It is our job when to know when to offer what to whom.

I also just had a convo with a client that is having photo shoot. As a
future reference measure I wanted to point out to the client how the photo
shoot goes. I asked, why did you pic the photographer and how much is it
costing you? She said she is allowing me to take as many poses as I want,
whatever. But I know it is 1 day and 1 day only and once that lady prints
and shows her what she has to choose from the show is over! She's not going
to go on photo shoot part 2 unless you pay for part 2. That is the same way
any design process should roll...

right? am I wrong. Am I missing something?

On Sun, Jan 25, 2009 at 7:41 PM, gavin burke|FAW <
gavin.burke at futureaudioworkshop.com> wrote:

> You have to understand also the engineers perspective. From their
> perspective they are the most important part of the process, without them
> there would be no product just fresh air. So they feel they own it in a way.
> Underneath the interface is a whole different world of complexity. If an
> interface designer comes up to their desk while they are working and tells
> them "I think the "ok" button needs to be more over to the left so the user
> doesn't get confused", its like a voice from another plant. Add on top of
> this the pressure of scrum or a difficult project that is make or break on a
> technical level and you won't get a look in.
>
> With good product management this should never happen but the way things
> are going with shorter and shorter development cycles and its associated
> pressures this type of situation is inevitable.
>
> My advice is to wait around, cut your teeth abit more and when your in a
> more senior position use what you are going through now as a way of
> improving things for everyone, user, engineer and yourself.
>
>
> On 26 Jan 2009, at 01:10, Angel Marquez wrote:
>
> I think that is great advice. I like it. But their are some enormous
>> A-holes
>> that engineer.
>> I think every department should have one person from another department on
>> that team as a liaison. The last four or so gigs I've had have been on
>> engineering teams and it is not my background. What brought me to it is
>> that
>> as a designer you hit road blocks when someone says 'You can't', 'Don't',
>> etc...
>> It is often b*ll sh*t and the engineers are operating behind a curtain
>> like
>> the wizard of OZ.
>>
>> With the last PM I worked with I said 'if you can explain it we can make
>> it
>> happen.'
>>
>> I don't think a good engineer says it cannot be done. I've also worked
>> with
>> stellar engineers and I always make it a point to ask what is a good
>> deliverable for you (why) and the good ones have sent me exactly what they
>> want and why they want it that way. The others riddle off reasons why they
>> are of a superior breed and the like, they usually couldn't engineer their
>> way out of a wet paper bag...
>>
>>
>> On Sun, Jan 25, 2009 at 5:00 PM, Janna Hicks DeVylder <janna at devylder.com
>> >wrote:
>>
>> In work environments like this, I have found that forcing our discipline
>>> into the process is the least effective... the "you MUST work with us"
>>> mantra will fall on deaf ears.
>>>
>>> As a User Centered Design graduate I find it quite irritating to be
>>>> working in an environment where engineers run everything.
>>>>
>>>>
> ________________________________________________________________
> 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
>

26 Jan 2009 - 1:45am
mcaskey
2008

<Mike pulls the bean from his nose>

Ahhh, that's better. But it sure would have been less painful of
someone could have stopped me before I did it!

I can't count the number of times I have seen pain and suffering as a
result of features that went live before they were "designed".

And each time, I got to say "I told you so" right before I got cracking
on the fix.

And each time, the fix directly and immediately improved the bottom
line, and relieved the swelling.

Long story made short: I agree. Follow the money. Follow the pain.
Find a friend. Or find a better fit (which I'm working on right now) :)

Mike Caskey

Jared Spool wrote:
>
> On Jan 25, 2009, at 7:41 PM, gavin burke|FAW wrote:
>
>> You have to understand also the engineers perspective. From their
>> perspective they are the most important part of the process, without
>> them there would be no product just fresh air.
>
> [...]
>
>> My advice is to wait around, cut your teeth abit more and when your
>> in a more senior position use what you are going through now as a way
>> of improving things for everyone, user, engineer and yourself.
>>
>> On 26 Jan 2009, at 01:10, Angel Marquez wrote:
>>
>>> I think that is great advice. I like it. But their are some enormous
>>> A-holes
>>> that engineer.
>
> Wow. This Us vs. Them shit is really a bit disturbing.
>
> There are workplaces where people collaborate well. There are
> workplaces where they don't. It has nothing to do with job titles,
> schooling, or base training.
>
> While there are engineers that are assholes, there are also designers
> that are assholes. And managers. And customer service people. And just
> about every other job.
>
> Creating stereotypes by job description isn't any better than creating
> them by race or religion or sexual preference.
>
> Personally, I'd like to see this conversation move to something
> constructive without the bigoted tone.
>
> To answer the crux of Ali's question about what to do:
>
> I always recommend that you follow the money. If there are usability
> problems with a product, that means that there are people who are
> frustrated.
>
> In my experience, whenever someone is frustrated, that frustration
> shows itself on the organization's bottom line. Either customers are
> moving to competitor's products, or they are filling up the support
> lines, or the developers are wasting time redoing designs because they
> got it wrong the first time.
>
> If you look for how the frustration is impacting the bottom line,
> you'll often find someone in charge of making that problem go away.
> That person is likely to be a huge champion for any UX work that can
> fix their problem. Tell them that you know how to fix their problem in
> cost-effective manner and you'll get their attention.
>
> If there is no pain -- inotherwords, if the organization can't feel
> how their hard-to-use product is hurting them -- then there is
> probably nothing you can do. (Remember the first law of consulting:
> You can't stop people from sticking beans up their nose.)
>
> In this case, if you find this frustrating, you should consider
> looking for an organization that does get it. There are more and more
> of those every day and it'll be a better fit for your personality.
>
> I wrote about this in more detail here: http://is.gd/heqq
>
> Hope that helps,
>
> 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 Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
> ________________________________________________________________
> 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
>

26 Jan 2009 - 1:50am
mcaskey
2008

Ideally (my ideal), the process would pay, through each iteration.

There have been a handful of occasions when I had guaranteed some aspect
of the project to meet some unknown level of approval for some unknown
feature. Nightmarish, at best, those occasions.

I'm personally getting better at managing the process, and in
particular... change.

Angel Marquez wrote:
> Dude(s),I've worked for number 1 in the nation marketing and advertising
> agencies.
> Start ups
> Freelance
>
> In a variety of industries.
>
> If you are asking your engineers to change something like moving a button
> your process needs to be revised.
>
> Ideal is you slowly iterate and shave off the input as the design goes down
> the pipe. Check done, pass, check, done pass, oh we have a request, sorry to
> late next time, check done, done, done.
>
> Yea right! That never happens. The more process you involve and the more
> people you involve the more entropy creeps into the system
> and wackiness occurs.
>
> Trying to make people understand is a waste of time. If they are able to
> understand than they already do and they are using it as leverage for
> whatever motivates them.
>
> I just had this discussion with a friend that wanted to offer me some
> unsolicited advice on some lame design I did and I was all hey give me a
> break. I would love to provide everyone with some custom work of art; but,
> c'mon! Trying to maneuver someone into a well thought out plan is like
> trying to get my cats in their carrier when they know I'm taking em to the
> vet! It's near impossible with trickery, chasing, them while closing and
> locking doors to corner them. I can't even shake their treats to get them
> from hiding when they know it's time. I also was all you have different
> types of customers. Some customers 1.) you are going to stretch your own
> canvas, make your own brushes, mix your own oil paints, do some studies,
> sketch, paint, hand craft a complimentary frame and voila 2.) or you are
> going to get a lot of pre made canvases, throw down some acrylics, whip it
> out, put into one of those nice packaged frames and be done with it. 3.) or
> you are going to have some ready to go out the door packaged done pieces
> they can throw on the wall of their hotel lobby and collect the ambience
> fee. It is our job when to know when to offer what to whom.
>
> I also just had a convo with a client that is having photo shoot. As a
> future reference measure I wanted to point out to the client how the photo
> shoot goes. I asked, why did you pic the photographer and how much is it
> costing you? She said she is allowing me to take as many poses as I want,
> whatever. But I know it is 1 day and 1 day only and once that lady prints
> and shows her what she has to choose from the show is over! She's not going
> to go on photo shoot part 2 unless you pay for part 2. That is the same way
> any design process should roll...
>
> right? am I wrong. Am I missing something?
>
> On Sun, Jan 25, 2009 at 7:41 PM, gavin burke|FAW <
> gavin.burke at futureaudioworkshop.com> wrote:
>
>
>> You have to understand also the engineers perspective. From their
>> perspective they are the most important part of the process, without them
>> there would be no product just fresh air. So they feel they own it in a way.
>> Underneath the interface is a whole different world of complexity. If an
>> interface designer comes up to their desk while they are working and tells
>> them "I think the "ok" button needs to be more over to the left so the user
>> doesn't get confused", its like a voice from another plant. Add on top of
>> this the pressure of scrum or a difficult project that is make or break on a
>> technical level and you won't get a look in.
>>
>> With good product management this should never happen but the way things
>> are going with shorter and shorter development cycles and its associated
>> pressures this type of situation is inevitable.
>>
>> My advice is to wait around, cut your teeth abit more and when your in a
>> more senior position use what you are going through now as a way of
>> improving things for everyone, user, engineer and yourself.
>>
>>
>> On 26 Jan 2009, at 01:10, Angel Marquez wrote:
>>
>> I think that is great advice. I like it. But their are some enormous
>>
>>> A-holes
>>> that engineer.
>>> I think every department should have one person from another department on
>>> that team as a liaison. The last four or so gigs I've had have been on
>>> engineering teams and it is not my background. What brought me to it is
>>> that
>>> as a designer you hit road blocks when someone says 'You can't', 'Don't',
>>> etc...
>>> It is often b*ll sh*t and the engineers are operating behind a curtain
>>> like
>>> the wizard of OZ.
>>>
>>> With the last PM I worked with I said 'if you can explain it we can make
>>> it
>>> happen.'
>>>
>>> I don't think a good engineer says it cannot be done. I've also worked
>>> with
>>> stellar engineers and I always make it a point to ask what is a good
>>> deliverable for you (why) and the good ones have sent me exactly what they
>>> want and why they want it that way. The others riddle off reasons why they
>>> are of a superior breed and the like, they usually couldn't engineer their
>>> way out of a wet paper bag...
>>>
>>>
>>> On Sun, Jan 25, 2009 at 5:00 PM, Janna Hicks DeVylder <janna at devylder.com
>>>
>>>> wrote:
>>>>
>>> In work environments like this, I have found that forcing our discipline
>>>
>>>> into the process is the least effective... the "you MUST work with us"
>>>> mantra will fall on deaf ears.
>>>>
>>>> As a User Centered Design graduate I find it quite irritating to be
>>>>
>>>>> working in an environment where engineers run everything.
>>>>>
>>>>>
>>>>>
>> ________________________________________________________________
>> 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
>>
>>
> ________________________________________________________________
> 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 Jan 2009 - 8:45pm
Matthew Loff
2007

Unfortunately, there is a strong us-vs-them mentality among engineers.

There's also a resistance to accept aesthetics as relevant to a
product's success. Part of this is due to the misconception that
"because I can write UI code, I can also design it adequately."

Engineers tend to assemble UIs sequentially--they see the process as
adding one widget at a time until paths exist to each
software/hardware feature. The concept of envisioning/visualizing
the full, final product ahead of time is foreign to most.

I get a lot of funny looks when I focus on pixel-perfect accuracy
when designing UIs-- but folks are always impressed with the
refinement of the final product.

Engaging your engineering counterparts in the early stages of a
design/redesign process may help:

** involve them in creating paper prototypes
** give constructive feedback for their work (not just "this looks
wrong/bad/confusing"... you know why it's a poor choice, but they
may not)
** cite real-world examples (web sites, software products, etc.) when
explaining your design choices

Good luck!

Matt L.
Software Engineer

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

25 Jan 2009 - 4:37pm
Jeremy Johnson
2009

I have found that in a situation like this the best defense you have
is to clarify your job description with your manager or CTO. By
having your responsibilities defined in "writing" you hold the pass
key to throw your weight around in the fighting ring especially when
it comes to issues that directly coincide with your expertise.

Once you have the authority make sure that when a project is planned
out, anything you feel that should be necessary is planned into the
Functional Requirements Documentation, such as; "Qualitative
research", as you mentioned. You'll find that once it is in writing
you'll have "a foot in the door". It then comes down to relying on
your research and reason to sway the team in one direction or
another.

Hope that helps. Good Luck!

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

25 Jan 2009 - 8:26pm
chris finlay
2009

People are best at doing things they know already works.

Learn their language and then figure out a simple translation so you can
help them see how their "already great work" could be added to.

Find a willing partner (one of "them) to work through what you are thinking
with.

When there is time inviting people into the process rather than challenging
will always yield better results.

Chris Finlay
www.twitter.com/chrisfinlay

26 Jan 2009 - 2:19am
mcaskey
2008

I totally agree... involved them early. And... not just the
engineers... get one or two people from every stakeholder's department,
and then some, involved as early as possible, in as many stages as
possible. By the time you go to launch, everyone has had a hand in the
product and feels some level of ownership, making the next project even
easier.

Matt L. wrote:
> Unfortunately, there is a strong us-vs-them mentality among engineers.
>
>
> There's also a resistance to accept aesthetics as relevant to a
> product's success. Part of this is due to the misconception that
> "because I can write UI code, I can also design it adequately."
>
> Engineers tend to assemble UIs sequentially--they see the process as
> adding one widget at a time until paths exist to each
> software/hardware feature. The concept of envisioning/visualizing
> the full, final product ahead of time is foreign to most.
>
> I get a lot of funny looks when I focus on pixel-perfect accuracy
> when designing UIs-- but folks are always impressed with the
> refinement of the final product.
>
> Engaging your engineering counterparts in the early stages of a
> design/redesign process may help:
>
> ** involve them in creating paper prototypes
> ** give constructive feedback for their work (not just "this looks
> wrong/bad/confusing"... you know why it's a poor choice, but they
> may not)
> ** cite real-world examples (web sites, software products, etc.) when
> explaining your design choices
>
> Good luck!
>
> Matt L.
> Software Engineer
>
>
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37605
>
>
> ________________________________________________________________
> 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
>
>

26 Jan 2009 - 4:28am
Jens Meiert
2004

> There is NO qualitative research and both hardware-/software engineers
> think that their own opinion about the products matter.

As a side note, on an "abstraction layer" for developers/engineers:
<http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html>.

--
Jens Meiert
http://meiert.com/en/

26 Jan 2009 - 10:47am
Samantha LeVan
2009

I think it's time to let the engineers observe representative users
with their product. When you've gotten to the point of frustration
and feel like your opinion isn't respected, back it up with user
data. Schedule a few informal usability tests and let the engineers
watch users struggle. I've seen this work in a number of
environments - it makes a huge difference in understanding that there
is a problem when you see it for yourself.

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

26 Jan 2009 - 12:20pm
Andrei Herasimchuk
2004

On Jan 25, 2009, at 2:12 PM, Ali Amrohvi wrote:

> They all believe that designing for the end users only involve
> usability
> issues... Should I send them a copy of Allan Cooper's "The Inmates are
> running the asylum"? :)

How about you send them a better design, prove it's better through
whatever means you need to, and start acting like a designer.

Good designers know that good design will prevail when presented. Good
design always prevails because in the end, it's easier to build,
easier to maintain, easier to use and maximizes ROI for the business.
What does not prevail are people talking about good design, or
posturing their degrees around as if a piece of paper will
miraculously create good design.

Have you created a new design, complete with new aesthetics and pixel-
perfect mockups, new information design that is clear and succinct,
simpler interactions or workflows, and built a prototype that makes
all of this obvious beyond a shadow of a doubt? If not, then might I
suggest you get to work and stop complaining about engineers not
getting it.

NOTE: Until designers do all of the above, engineers have every right
to be suspicious of anything you claim will be better.

> There is NO qualitative research and both hardware-/software engineers
> think that their own opinion about the products matter.

Their opinion does matter. That you think it doesn't is the crux of
your problem.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

26 Jan 2009 - 12:44pm
russwilson
2005

And how do you objectively prove it's better? Short of testing
alternatives you have a very subjective problem.

Russ
http://www.dexodesign.com

Sent from my iPhone

On Jan 26, 2009, at 12:20 PM, Andrei Herasimchuk <aherasimchuk at involutionstudios.com
> wrote:

> On Jan 25, 2009, at 2:12 PM, Ali Amrohvi wrote:
>
>> They all believe that designing for the end users only involve
>> usability
>> issues... Should I send them a copy of Allan Cooper's "The Inmates
>> are
>> running the asylum"? :)
>
> How about you send them a better design, prove it's better through
> whatever means you need to, and start acting like a designer.
>
> Good designers know that good design will prevail when presented.
> Good design always prevails because in the end, it's easier to
> build, easier to maintain, easier to use and maximizes ROI for the
> business. What does not prevail are people talking about good
> design, or posturing their degrees around as if a piece of paper
> will miraculously create good design.
>
> Have you created a new design, complete with new aesthetics and
> pixel-perfect mockups, new information design that is clear and
> succinct, simpler interactions or workflows, and built a prototype
> that makes all of this obvious beyond a shadow of a doubt? If not,
> then might I suggest you get to work and stop complaining about
> engineers not getting it.
>
> NOTE: Until designers do all of the above, engineers have every
> right to be suspicious of anything you claim will be better.
>
>> There is NO qualitative research and both hardware-/software
>> engineers
>> think that their own opinion about the products matter.
>
> Their opinion does matter. That you think it doesn't is the crux of
> your problem.
>
> --
> 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

26 Jan 2009 - 3:22pm
Andrei Herasimchuk
2004

On Jan 26, 2009, at 10:44 AM, Russell Wilson wrote:

> And how do you objectively prove it's better? Short of testing
> alternatives you have a very subjective problem.

It is possible to objectively test any design problem, as long as one
remembers that the definition of the problem is largely subjective, or
at least arbitrary. You have to measure against the definition of the
problem, not some arbitrary set of alternatives for the sake of A/B
testing or whatnot.

Further, there is rarely if ever "one" perfect design solution, but
many very good solutions possible; any and all of which work well
enough within reason and to varying degrees. This makes it more
important to define your ranges and criteria of a problem and measure
against that. "Objectively" is relative then to how well you've
defined the problem in the first place.

Think of it this way: Is there only one man or woman for you in the
world to fall in love with? If you believe so, good luck finding that
person out of the 8+ billion on the planet. Most who try live a life
of constantly striving for some ideal of perfection that forces
standards on their companions which are both unfair and often
untenable tend to be disappointed. However, if you approach the
problem reasonably, you'll know there's a range of possible people as
defined by yourself. Once you find someone in that range, you can date
(or do whatever it is you do) to test it out then fall in love and
become soulmates forever, and even then, you have to evolve with each
other year after year.

Finding the right design for any problem is often the same kind of
task. You "objectively prove" something is better by measuring against
a variety of agreed criteria, and analyze the results based on
tangible data. Things like: Less line noise, a request to use fewer
colors in the display palette, fewer keystrokes required for task A,
solving the problem of allowing 12 tabs on screen simultaneously with
text strings of 30 or fewer characters in them, working in an
interaction model similar to something else in the target user's
mental model so that keyboard shortcuts match what they are used to,
customer testing that yields positive feedback, proof of shorter
development cycles from engineering, etc. The criteria is completely
arbitrary by the way but always specific, defined by someone on the
team or the team collectively. Once you find a design that works with
the criteria -- not the perfect design, just one that works by some
set of standards -- you can work towards making it yours, own it for
all it's pros and cons, and evolve with it as time moves on.

There's nothing strictly "objective" about it until you have defined
the problem with some level of specificity. And measuring against it
is often a range of pros and cons. The definition and criteria of the
problem is all that matters. And I stipulate a lot of the problem
between designers and engineers is that they both tend to define the
"problem" differently. If you have a team all treating the problem in
different ways, the first thing that you do as a designer or team lead
is baseline the problem so everyone understands the definition or a
new definition is built that covers everyone's criteria. If you don't,
what you wind up having is a discussion based on some people liking
blondes and others preferring brunettes, and both treating the issue
as if it's a religious discussion, which leads to bickering and
arguing over useless details that will never see resolution.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

26 Jan 2009 - 2:02am
usabilitycounts
2008

Get used to it. ;)

It's the real world. Your job is to sell them on it. Sounds tough, but
it's true.

On Jan 25, 2009, at 2:12 PM, Ali Amrohvi wrote:

> As a User Centered Design graduate I find it quite irritating to be
> working in an environment where engineers run everything
> ...
> Few of them have taken some HCI courses and THATS IT!
> There is NO qualitative research and both hardware-/software engineers
> think that their own opinion about the products matter.
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=37605
>
> ________________________________________________________________
> 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

Patrick

email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
cell: (562) 508-1750 | office: (562) 612-3346 | skype: (562) 219-3348

26 Jan 2009 - 12:54pm
Austin Govella
2004

On Jan 26, 2009, at 12:44 PM, Russell Wilson wrote:
> And how do you objectively prove it's better? Short of testing
> alternatives you have a very subjective problem.

Not true. Often the real problem is everyone sees the problem
differently, so you're never really having the same conversation.

If you can get everyone to share the vision of the problem, then you
can have (more) objective discussions about how different solutions
solve or don't solve the problem. Collaborative whiteboarding, user
modeling, and task analysis are good ways to get everyone on the same
page.

--
Austin Govella
User Experience

Work: http://www.grafofini.com
Blog: http://www.thinkingandmaking.com
Book: http://www.blueprintsfortheweb.com

austin at grafofini.com
215-240-1265

Upcoming speaking engagements:

1. FEB 4: Redefining Search Design Using Mental Models
Taxonomy Community of Practice presentation for the call series hosted
by Earley and Associates:
* http://www.earley.com/_February2009.asp

2. MAR 20-22: UX Health Check
IA Summit presentation with Livia Labate (Principal IA, Comcast
Interactive Media) in Memphis, TN:
* http://iasummit.org/2009/

26 Jan 2009 - 4:47pm
russwilson
2005

> And how do you objectively prove it's better? Short of testing
>> alternatives you have a very subjective problem.
>>
>
> Further, there is rarely if ever "one" perfect design solution, but many
> very good solutions possible; any and all of which work well enough within
> reason and to varying degrees. This makes it more important to define your
> ranges and criteria of a problem and measure against that. "Objectively" is
> relative then to how well you've defined the problem in the first place.
>

Exactly my point. Given that there are 1+ equally viable design solutions,
it may be impossible to prove that "yours" is
better.

26 Jan 2009 - 5:01pm
Jared M. Spool
2003

On Jan 26, 2009, at 2:47 PM, Russell Wilson wrote:

>> And how do you objectively prove it's better? Short of testing
>>> alternatives you have a very subjective problem.
>>>
>>
>> Further, there is rarely if ever "one" perfect design solution, but
>> many
>> very good solutions possible; any and all of which work well enough
>> within
>> reason and to varying degrees. This makes it more important to
>> define your
>> ranges and criteria of a problem and measure against that.
>> "Objectively" is
>> relative then to how well you've defined the problem in the first
>> place.
>>
>
> Exactly my point. Given that there are 1+ equally viable design
> solutions,
> it may be impossible to prove that "yours" is
> better.

Who cares?

You're really trying to find a good solution (and in Ali's case, have
a conversation about what makes some solutions better than others).

If you have a criteria by which you and the team can decide if a
solution is good enough or not, who cares if there's more than one?

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 Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

26 Jan 2009 - 5:14pm
Todd Warfel
2003

On Jan 26, 2009, at 5:47 PM, Russell Wilson wrote:

> Exactly my point. Given that there are 1+ equally viable design
> solutions, it may be impossible to prove that "yours" is better.

1. Better can be both subjective and provable.
2. If you want to pursue multiple design solutions, then do so.
3. Establish criteria for how you'll measure better (e.g. time,
effort, satisfaction, error prevention)
4. Work through them to see which ones are better based on your
criteria.
5. Test them with end users/consumers/customers to see which ones are
better based on your criteria.

It's entirely possible. We do it regularly.

And to Jared's point, the fact is that it's really about which
solution will do the trick. Someone can always one-up you, or you can
one-up yourself.

Good enough is often good enough.

It's better to get something good enough out, then make iterative
changes to improve it than it is to wait to put anything out until
you've achieved nirvana or perfection—those two don't really exist in
systems.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

26 Jan 2009 - 5:16pm
Jared M. Spool
2003

On Jan 26, 2009, at 12:02 AM, Patrick wrote:

> Get used to it. ;)
>
> It's the real world. Your job is to sell them on it. Sounds tough,
> but it's true.
>
> On Jan 25, 2009, at 2:12 PM, Ali Amrohvi wrote:
>
>> As a User Centered Design graduate I find it quite irritating to be
>> working in an environment where engineers run everything
>> ...
>> Few of them have taken some HCI courses and THATS IT!
>> There is NO qualitative research and both hardware-/software
>> engineers
>> think that their own opinion about the products matter.

Patrick, I respectfully disagree.

Ali, if you do what Patrick suggests, you'll not only fail, but you'll
have a miserable time doing so.

Your job isn't to *sell* your teammates on anything. It's about
teamwork. Find out what the objectives and long-term vision of the
team is. Work from there.

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 Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

26 Jan 2009 - 5:51pm
Josh Evnin
2005

Jared said:

Ali, if you do what Patrick suggests, you'll not only fail, but you'll have
a miserable time doing so.

Your job isn't to *sell* your teammates on anything. It's about teamwork.
Find out what the objectives and long-term vision of the team is. Work from
there.

I've got to agree with Jared here. I've made myself blue in the face trying
to convince both clients and coworkers (simultaneously, mind you) of the
value of IxD-related activities "in general." It nearly always fails until I
am able to understand my clients' needs and then tailor my design approach
directly to them.

For example, I ranted and raved for a while that we needed to bootstrap all
of our project efforts with a Contextual Inquiry approach so that we could
get a glimpse of user needs as they exist "on the factory floor" rather than
coming up with perceived problems out of thin air. At my organization, where
user research is not the norm, this approach was met with deaf ears. It was
not until I spoke with a client that already had many of their technical
needs met, but acknowledged that they still weren't solving their customers'
problems after many product releases that I realized that *this* was a great
candidate for my preferred CI approach. It didn't take much convincing that
this approach would work, and when it succeeded, it bought me at least a
little leverage within my organization to try other approaches with other
clients.

So Ali, if I were to give any advice it would be this: instead of thinking
about how you would change the whole process (or the engineers' mindsets) in
your organization, pick a few smaller issues that you see, and then make it
your goal to solve them in a way that works within the organization's
context. But remember: you should provide value to your organization every
step of the way. Ask for feedback regularly, especially from the engineers
you work with. Be just as user centered in your approach to organizational
change as you would be to your product's design. Celebrate your small wins,
don't sweat the losses (but make it a point to learn from them), and keep a
keen eye out for opportunities where your skills will be helpful and valued.

Most of all, relax, and try to have fun. Merely being calm in the situation
you are currently in will win you some credibility, and the value you
provide will buy you a ton more.

Josh

On Mon, Jan 26, 2009 at 5:16 PM, Jared Spool <jspool at uie.com> wrote:

>
> On Jan 26, 2009, at 12:02 AM, Patrick wrote:
>
> Get used to it. ;)
>>
>> It's the real world. Your job is to sell them on it. Sounds tough, but
>> it's true.
>>
>> On Jan 25, 2009, at 2:12 PM, Ali Amrohvi wrote:
>>
>> As a User Centered Design graduate I find it quite irritating to be
>>> working in an environment where engineers run everything
>>> ...
>>> Few of them have taken some HCI courses and THATS IT!
>>> There is NO qualitative research and both hardware-/software engineers
>>> think that their own opinion about the products matter.
>>>
>>
> Patrick, I respectfully disagree.
>
> Ali, if you do what Patrick suggests, you'll not only fail, but you'll have
> a miserable time doing so.
>
> Your job isn't to *sell* your teammates on anything. It's about teamwork.
> Find out what the objectives and long-term vision of the team is. Work from
> there.
>
> 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 Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
> ________________________________________________________________
> 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
>

--
http://josh.ev9.org/weblog

26 Jan 2009 - 6:04pm
Samantha LeVan
2009

I agree with Jared and Josh. There's no use arguing back and forth.
Stop and take a deep breath and think about the other side. Rather
than presenting a new idea as being better, ask the engineers about
their ideas. What do they believe works best and why? Getting to
their rationale might inspire an entirely new idea that was a
collaborative effort, one that can be shared and embraced by the team
instead of an idea from one side to the other.

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

26 Jan 2009 - 7:23pm
Chauncey Wilson
2007

I agree with Jared's comment that we should not be demonizing developers and
engaging in an us versus them battle. I spent a few years as a development
manager and during my first week on the job when I reviewed my developers'
performance goals, discovered that there was not a single goal about good
design or usability - they were judged on good technical code, knowledge of
new software technologies, how well they fixed bugs, and how well they kept
to schedules. I changed the job descriptions and performance goals of my
team and found that my developers became much more in tune with good design
and the importance of sketching and rough prototypes and usability issues
when the job performance had design and usability goals. If we demonize a
group and use language that views that group as unchangeable, then we have
little hope of ever collaborating well because personality traits are
perceived by most people as less malleable than external factors like how
people are measured (this is spelled out in much research in social
psychology in the area of attribution theory).
Chauncey

On Mon, Jan 26, 2009 at 7:04 PM, Samantha LeVan <tigerfork at gmail.com> wrote:

> I agree with Jared and Josh. There's no use arguing back and forth.
> Stop and take a deep breath and think about the other side. Rather
> than presenting a new idea as being better, ask the engineers about
> their ideas. What do they believe works best and why? Getting to
> their rationale might inspire an entirely new idea that was a
> collaborative effort, one that can be shared and embraced by the team
> instead of an idea from one side to the other.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37605
>
>
> ________________________________________________________________
> 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
>

26 Jan 2009 - 7:58pm
Andrei Herasimchuk
2004

On Jan 26, 2009, at 2:47 PM, Russell Wilson wrote:

> Exactly my point. Given that there are 1+ equally viable design
> solutions, it may be impossible to prove that "yours" is
> better.

That's not correct. It is very possible to prove any number of designs
are BETTER than PREVIOUS DESIGNS as long as you know what it is that
defines the problem. Using the definition of the problem allows you to
measure it with existing versus proposed solutions. It's not about
various quantities of solutions, nor is it about ownership of the
solution in the end.

But if some designer wants to prove theirs is the only solution, good
luck and learn how to be a good salesman. If some designer wants to
make their solution the final decision over any number of completely
viable design solutions, then do what I did: Start your own design
firm and pay the bills.

(Like my Dad always said, as long as you live in my house, then you go
by my rules. Don't like the rules? Go buy your own house.)

Anyway, it is very possible to prove a design is better than an
existing one. My original point by the way requires that the person
who believes their solution is better has the onus put on on them to
create a real life prototype, mockup or functional product that can be
tested and measured to back up their assertions about their design
solution. Trust me... executives and engineers never say no to good
design, because in the end, it solves their problems and will make
more money at the same time it solves customer problems. You put good
design in front of someone's face, they will say yes. Not theoretical
design where someone has to put faith in whatever thing some workflow
diagram is supposed to represent will just magically work... but
honest to goodness I can see the difference and experience the change
of a prototype or complete set of a pixel perfect mockups that tell
the whole story.

That was the larger point.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

26 Jan 2009 - 8:49pm
russwilson
2005

So what are the criteria? That's what I'm after. (and don't say "it
depends") :-)

It's easy to say "everyone's opinion counts", "there's more than one good
solution", "we should all work together", etc.
And we do just that... But when it comes to deciding on a particular
solution and moving forward, "someone" or some panel has
to make a decision (depending on where your thinking is between a single
vision/conceptual integrity versus design by committee).

Assuming there are multiple solutions that are equally "good", how do you
decide on one? What are some examples of
criteria used? In some cases we have tested multiple designs and had
inconclusive results (1+ designs tested equally well).

Best regards,
Russ

Russell Wilson
Vice President of Product Design, NetQoS
Blog: http://www.dexodesign.com

Exactly my point. Given that there are 1+ equally viable design solutions,
>> it may be impossible to prove that "yours" is
>> better.
>>
>
> Who cares?
>
> You're really trying to find a good solution (and in Ali's case, have a
> conversation about what makes some solutions better than others).
>
> If you have a criteria by which you and the team can decide if a solution
> is good enough or not, who cares if there's more than one?
>
>
> 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 Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>

26 Jan 2009 - 9:12pm
Angel Marquez
2008

Finally.
That is the question.

All the research, design concepts and theories can be blown into oblivion in
one instance.

I could tell you what I think. I could tell you what I've experienced. I
could tell you it doesn't depend.

But, I'll tell you a story instead.

When I first moved to LA I was in a band with this guy. This guy's brother
worked for a recording studio. He told me that his brother was part of
recording some well known artist etc. One story was about Tom Petty. He said
before Petty recorded at his bro's studio TP went to another studio and
after his band had unloaded all of their equipment and they were plugged in
and ready to take 1 TP lit up a cigarette. The studio owner told Petty to
put it out, no smoking. Petty told everyone to pack it up we are not
recording here left and went elsewhere.

In my humblest respectful opinion Petty did 2 very outstanding things here.

1. He shielded his band from a non nurturing environment.
2. He did not support a system that did not support him.

Sure you can speculate 'oh smokings bad', 'that guy could of recorded Tom's
greatest album', 'we should all join hands and do the robot dance'.

Assuming the best or worst won't fix anything. Ignoring the problem will
only make it worse.

Make a choice and make it a good one.

On Mon, Jan 26, 2009 at 6:49 PM, Russell Wilson <russ.wilson at gmail.com>wrote:

> So what are the criteria? That's what I'm after. (and don't say "it
> depends") :-)
>
> It's easy to say "everyone's opinion counts", "there's more than one good
> solution", "we should all work together", etc.
> And we do just that... But when it comes to deciding on a particular
> solution and moving forward, "someone" or some panel has
> to make a decision (depending on where your thinking is between a single
> vision/conceptual integrity versus design by committee).
>
> Assuming there are multiple solutions that are equally "good", how do you
> decide on one? What are some examples of
> criteria used? In some cases we have tested multiple designs and had
> inconclusive results (1+ designs tested equally well).
>
> Best regards,
> Russ
>
> Russell Wilson
> Vice President of Product Design, NetQoS
> Blog: http://www.dexodesign.com
>
>
>
> Exactly my point. Given that there are 1+ equally viable design solutions,
> >> it may be impossible to prove that "yours" is
> >> better.
> >>
> >
> > Who cares?
> >
> > You're really trying to find a good solution (and in Ali's case, have a
> > conversation about what makes some solutions better than others).
> >
> > If you have a criteria by which you and the team can decide if a solution
> > is good enough or not, who cares if there's more than one?
> >
> >
> > 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 Twitter: jmspool
> > UIE Web App Summit, 4/19-4/22: http://webappsummit.com
> >
> ________________________________________________________________
> 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
>

26 Jan 2009 - 5:44pm
usabilitycounts
2008

>>>

When talking about what we care about, aren't we really selling? And
the best selling involves using others to sell what we believe in?

There are many, many environments that we all work in, but I'm going
to generalize into two -- one that's UX focused, and the other than is
not.

By the time that someone that's a "recognized UX expert" walks in the
door at a client, usually they are already UX focused, or know they
need to be because nothing else has worked. You're recognized as a
leader in the field, so they're willing to spend some money to listen
to your approach. Usually, they are sold because they've read a book
or a blog. Sometimes, like places I worked at, we're able to place
some simple processes in place, and the process sells it self through
higher profitability of the product.

There are many, many environments where UX isn't the focus, and even
if they have hired someone in that field, they don't know what to do
with that person, or the developers aren't interested in UX because it
gets in the way of them not being on board. I agree here it needs a
team, but again, it's all dependent on the politics of the situation.
Most of us haven't written books or blogs, so we don't have that part
sold already. I would guess most of us have worked in situations like
this, and as one UX friend of mine said, "You know, sometimes you just
document it, and hope someone pays attention."

I guess sometimes we think the process supersedes the results, when
all the client or company cares about is the results.

But that's just my opinion, experience.

Comments?

Patrick

...

> Patrick, I respectfully disagree.
>
> Ali, if you do what Patrick suggests, you'll not only fail, but
> you'll have a miserable time doing so.
>
> Your job isn't to *sell* your teammates on anything. It's about
> teamwork. Find out what the objectives and long-term vision of the
> team is. Work from there.
>
> Jared

Patrick

email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
cell: (562) 508-1750 | office: (562) 612-3346 | skype: (562) 219-3348

Click here for the last UX books you'll ever need.

26 Jan 2009 - 9:22pm
usabilitycounts
2008

On Jan 26, 2009, at 3:44 PM, Patrick wrote:

>>>>
>
> When talking about what we care about, aren't we really selling? And
> the best selling involves using others to sell what we believe in?
>
> There are many, many environments that we all work in, but I'm going
> to generalize into two -- one that's UX focused, and the other than
> is not.
>
> By the time that someone that's a "recognized UX expert" walks in
> the door at a client, usually they are already UX focused, or know
> they need to be because nothing else has worked. You're recognized
> as a leader in the field, so they're willing to spend some money to
> listen to your approach. Usually, they are sold because they've read
> a book or a blog. Sometimes, like places I worked at, we're able to
> place some simple processes in place, and the process sells it self
> through higher profitability of the product.
>
> There are many, many environments where UX isn't the focus, and even
> if they have hired someone in that field, they don't know what to do
> with that person, or the developers aren't interested in UX because
> it gets in the way of them not being on board. I agree here it needs
> a team, but again, it's all dependent on the politics of the
> situation. Most of us haven't written books or blogs, so we don't
> have that part sold already. I would guess most of us have worked in
> situations like this, and as one UX friend of mine said, "You know,
> sometimes you just document it, and hope someone pays attention."
>
> I guess sometimes we think the process supersedes the results, when
> all the client or company cares about is the results. And we'd all
> like to believe everyone wants to be on a team, but that's not
> always the case.
>
> But that's just my opinion, experience.
>
> Comments?
>
> Patrick
>
> ...
>
>> Patrick, I respectfully disagree.
>>
>> Ali, if you do what Patrick suggests, you'll not only fail, but
>> you'll have a miserable time doing so.
>>
>> Your job isn't to *sell* your teammates on anything. It's about
>> teamwork. Find out what the objectives and long-term vision of the
>> team is. Work from there.
>>
>> Jared
>
> Patrick
>
> email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
> cell: (562) 508-1750 | office: (562) 612-3346 | skype: (562) 219-3348
>
> Click here for the last UX books you'll ever need.
>
>
>

Patrick

email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
cell: (562) 508-1750 | office: (562) 612-3346 | skype: (562) 219-3348

Click here for the last UX books you'll ever need.

26 Jan 2009 - 5:58pm
usabilitycounts
2008

On Jan 26, 2009, at 3:51 PM, Josh Evnin wrote:

> It didn't take much convincing that this approach would work, and
> when it succeeded, it bought me at least a little leverage within my
> organization to try other approaches with other clients.

...and that's selling. You identify a situation where you have an
opening, and take it.
>

Patrick

email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
cell: (562) 508-1750 | office: (562) 612-3346 | skype: (562) 219-3348

Click here for the last UX books you'll ever need.

27 Jan 2009 - 6:38am
Ali Naqvi
2008

Interesting comments from all of you. Thank you.
I have had a few conversations with the department managers, other
co-workers and even prepared a powerpoint presentation for my first
kickoff, (many of the attendants are engineers) wherein I will stress
the importance of user Centered Design (OOBE, IX,UX, Usability etc)

I have noticed that they all think that usability is enough... I'll
change their views.... :)

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

27 Jan 2009 - 9:31am
Michael Micheletti
2006

Hi Ali,

Hope I'm not stepping in too late here. I've made something of a career of
being "the designer on the development team". Although I once was "the
developer on the design team" which might even have been a bit stranger.
Here are some approaches that have worked for me:

- Volunteer to write the spec, of whatever it is being built. Do a great
job. Lead the discussions. Incorporate wireframe sketches. The engineers may
drift from what you sketched, but at least they have a starting point to
consider. With time, you will become the person whom everyone looks to for
initial specifications and design artifacts, sometimes even for technical
internals code. This is because (warning generalization follows) Engineers
love specification documents, but don't usually like to write them.

- Become handy around the shop. You'll want to volunteer to help test code,
to visit with customers, to create prototypes, to help with technical
recruiting - to do whatever you can to make your engineering team
successful. Another generalization: Engineers respect people who work hard
to make the team a success. You want the respect of your team. When your
team respects you, you will be listened to.

- Be very patient. I try to "plant the seed" of an idea early, then help it
grow quietly. I know the time is right when I hear engineers and business
people saying it's time to do this thing, as if it was a new idea they just
thought of. This is a wonderful moment, because you can smile and say
"that's a great idea, let's do this" and all of a sudden you have allies in
a strategic design project. I'm working on one of these now. It took more
than a year to sprout.

- Bear with me here a minute. There's a financial trading term I think is
called a "negative indicator". A funny application of this is there are some
people who always pick stocks just before they fall (oh wait, that's all of
us). Time Magazine covers are a negative indicator - by the time a company
shows up there, it's at the peak. Sports Illustrated covers another. Madden
football game covers also - the player on the cover will underwhelm the next
season. I've heard of traders who kept an eye on negative indicator (people)
as a sort of reality-check on market direction. Ok now back to our story.
There will likely be one very senior engineer on your development team who
is a negative indicator for design. You know, the "let's just add another
checkbox" type. This guy (I haven't met the female version yet, although
maybe she's out there) will be a very skillful coder with deep knowledge of
your system and the respect of all of the engineers on the team. This is the
hard part: you want to partner with this guy. You want to work with him as
closely as you can. He will understand the system very deeply. You will
understand design patterns and be able to make his system more usable and
attractive. Together you will create far better applications than either of
you could do on your own.

- Create paper prototypes. Engineers immediately understand these. Bring
your paper, colored pens, and scissors to prototype working sessions and
everybody will be cutting out shapes like crazy to try different things. You
can advance the design a great deal in an hour of collaborative work with a
crude prototype.

I hope these suggestions are helpful, have fun,

Michael Micheletti

On Tue, Jan 27, 2009 at 4:38 AM, ali naqvi <ali at amroha.dk> wrote:

> Interesting comments from all of you. Thank you.
> I have had a few conversations with the department managers, other
> co-workers and even prepared a powerpoint presentation for my first
> kickoff, (many of the attendants are engineers) wherein I will stress
> the importance of user Centered Design (OOBE, IX,UX, Usability etc)
>
> I have noticed that they all think that usability is enough... I'll
> change their views.... :)
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37605
>
>
> ________________________________________________________________
> 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
>

27 Jan 2009 - 11:06am
Jack L. Moffett
2005

I just wanted to second what Michael said (especially his first
suggestion about spec writing), and add a couple things. I too have
made a career as the designer among engineers.

Developers tend to not like having to work out the details of a UI
layout. If it is a web app, provide them with the HTML and CSS. If you
can't provide the code for the front end display, provide detailed
specs that include colors, type sizes, dimensions, etc. In my
experience, a developer would much rather be working out engineering
problems then futzing with layout, and the easier you can make it for
them, the more likely you'll be satisfied with the results.

Don't be a loner. Just because you have a different job description
and a different focus doesn't mean you should be a hermit. I'm good
friends with a number of the developers in my firm. I eat lunch with
them, joke with them, play World of Warcraft with them. They are your
co-workers, after all. I've even been attending and participating in
their "continuing education" lunches (e.g. studying for
certifications, sharing new technologies). It was at one such lunch
that I presented a presentation titled UI Design First Aid.

Best,
Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

To design is much more than simply
to assemble, to order, or even to edit;
it is to add value and meaning,
to illuminate, to simplify, to clarify,
to modify, to dignify, to dramatize,
to persuade, and perhaps even to amuse.

- Paul Rand

27 Jan 2009 - 2:01pm
Eva Kaniasty
2007

I think the key here is to step back to the highest level first before
getting mired in specifics.

Presumably whatever it is you are designing is designed for some
purpose, and to meet either business goals or user goals. The
business goals tend to be much better defined at companies, or one
should hope so. As far as user goals, that's something that falls
within our purview, and something that you can tease out, define, and
agree on through research and conversation. And yeah, this is a
process that involves some negotiation, and something you need to be
flexible and build consensus around.

Once you have those general goals, you can take it down to a specific
level, i.e. maximizing conversion, reducing user abandonment,
stickiness, engagement, what have you. By doing this you ally
yourself with the business and marketing functions of your
organization, which gives you more power to fight the purely
engineering approach. These goals are also testable, and if your
solution is indeed better, you can actually gather data to prove it
down the road.

The next step is to start advocating for your solutions by saying
things like: well, we want to give emphasis to X because it will help
us reach goal Y, and this is how we'll do that within this specific
design. The arguments become less religious, and it is no longer
about (excuse the vulgarity) a pissing contest, but about trying to
find the best solution that meets a shared goal.

-eva

On Mon, Jan 26, 2009 at 9:49 PM, Russell Wilson <russ.wilson at gmail.com> wrote:
> So what are the criteria? That's what I'm after. (and don't say "it
> depends") :-)
>
> It's easy to say "everyone's opinion counts", "there's more than one good
> solution", "we should all work together", etc.
> And we do just that... But when it comes to deciding on a particular
> solution and moving forward, "someone" or some panel has
> to make a decision (depending on where your thinking is between a single
> vision/conceptual integrity versus design by committee).
>
> Assuming there are multiple solutions that are equally "good", how do you
> decide on one? What are some examples of
> criteria used? In some cases we have tested multiple designs and had
> inconclusive results (1+ designs tested equally well).

27 Jan 2009 - 3:51pm
Jared M. Spool
2003

On Jan 26, 2009, at 6:49 PM, Russell Wilson wrote:

> So what are the criteria? That's what I'm after. (and don't say
> "it depends") :-)
>
>
> It's easy to say "everyone's opinion counts", "there's more than one
> good solution", "we should all work together", etc.
> And we do just that... But when it comes to deciding on a particular
> solution and moving forward, "someone" or some panel has
> to make a decision (depending on where your thinking is between a
> single vision/conceptual integrity versus design by committee).
>
> Assuming there are multiple solutions that are equally "good", how
> do you decide on one? What are some examples of
> criteria used? In some cases we have tested multiple designs and
> had inconclusive results (1+ designs tested equally well).

If they are truly equal, then it's a coin flip, since, being equal, it
won't matter which one you pick.

If they have different pros and cons, but at first glance it's hard to
pick one that stands out, there are a variety of analysis tools to
help a team decide on the best alternative: pugh charts, weighted
matrices, and the ever-so-fun "House of Quality" are three of my
favorites.

The criteria that you'll use in the analysis have to be specific to
the long- and short-term success criteria of the organization. There
is no generic set of criteria that works for all designs.

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 Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

27 Jan 2009 - 3:59pm
Jared M. Spool
2003

On Jan 26, 2009, at 3:44 PM, Patrick wrote:

> There are many, many environments where UX isn't the focus, and even
> if they have hired someone in that field, they don't know what to do
> with that person, or the developers aren't interested in UX because
> it gets in the way of them not being on board. I agree here it needs
> a team, but again, it's all dependent on the politics of the
> situation. Most of us haven't written books or blogs, so we don't
> have that part sold already. I would guess most of us have worked in
> situations like this, and as one UX friend of mine said, "You know,
> sometimes you just document it, and hope someone pays attention."

I work with organizations in these situations all the time. In my
experience, "selling" doesn't help them move the argument forward,
because with every forward push there's an equal and justified push-
back. It just results in conflict and frustration for all around.

I have yet to meet anyone on the development or engineering side of
the operation who doesn't understand that a usable design is better.
However, not all designs need to be usable to be successful, and since
making something usable is often an added expense, it's hard to justify.

Even when it's clear that a more usable design will win in the
marketplace (or whatever the organizational goals are), as Chauncey
rightly pointed out, if the reward structure for the developers
doesn't take that into account, no amount of "selling" will move in
that direction.

In my experience, unusable designs rarely exist due to team ignorance
of the value of a great experience. There are often many other factors
that the team is battling and making something more usable is a place
where the battle is lost. Standing on a soapbox yelling to the gods
that this is a crime against humanity rarely does anything other than
cause one to lose their voice.

Don't judge an engineer until you've walked a mile in their shoes.
(Because then you'll be a mile away and you'll have their shoes.)

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 Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

27 Jan 2009 - 1:16pm
Heather Searl
2008

Ali,

It sounds to me like you want to build a collaborative environment
where you have opinion is respected. So share your toys and invite
them to play with you.

If you want qualitative research make it happen somehow. If you
don't have a budget, arrange for people as close to your target user
as possible to run through some tasks with the product. Do this by
using other people in the company or friends and family if you can --
and compensate them by buying them lunch. Invite people to observe
the testing, and record the sessions for others to watch. (Kill 2
birds with one stone by asking the engineers to be the videographer
to get them into the room with you). Nothing makes people believe in
qualitative research like seeing someone work with their product and
react to it.

Something else that has worked well for me in the past when I needed
to build respect and build a collaborative environment is to set up a
cross-functional design/brainstorming meeting. Invite a cross
functional set of people to attend a meeting where the objective is
to come up with 3 different solutions. Make it a structured (but fun
and creative ) meeting where everyone has an opportunity to contribute
what they know at all stages. Organize the meeting around a series of
topcis like:
What do we know about the problem?
What do we know about the users?
How can we solve the solution? Aim for at least 3.
What would each potential solution look like? (high level design
ideas)
What are the strengths and weaknesses for each propose solution?
What could be done to fix the weaknesses in each proposal?
At the end of the meeting offer to take the couple strongest ideas
away and develop them further and then bring them back to the team to
review.

In doing something like that, you have the opportunity to participate
and show that you have valuable contributions, but everyone else also
gets a chance to be heard. I always find I come out of these meetings
with great new ideas, and a few people in the organization more
willing to include me and my thoughts in the future.

A bonus to the cross-functional meeting -- I very seldom have to
ever argue against an idea %u2013 someone else in the meeting does it
for me. I can just support the best ideas on the table. %uF04A

Heather Searl
User Experience Consultant
www.heathersearl.com

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

28 Jan 2009 - 3:15am
Ali Naqvi
2008

Again, thank you for contributing to this topic.
My kickoff went really well and I was able to convince the "brain"
behind the project. (An engineer)
User tests will be conducted and I might be able to do them much
earlier than planned. (These people have already created much of the
HW/SF products and hence a usability test at THIS stage is considered
LATE)
These people do not involve real users AT all. Its all made by
engineers and tested by engineers. Some of these guys are proud of
using "Man Machine Interaction", which still isn't enough AT ALL.
Usability, usability usability.... WHERE ARE THE INTERACTION
DESIGNERS??? "Its about money" I've been told... "Ali remember,
most of our users will receive training so why use money on all these
qualitative researchers?? If we do, we will have to fire the training
personnel"... JEEEEZ!

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

28 Jan 2009 - 4:53am
Jim Leftwich
2004

Michael Micheletti makes some astoundingly insightful points above.
All very good and effective advice for the situation being discussed
here.

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

28 Jan 2009 - 8:31am
Benjamin Ho
2007

[Jared wrote: I have yet to meet anyone on the development or
engineering side of the operation who doesn't understand that a
usable design is better. However, not all designs need to be usable
to be successful, and since making something usable is often an added
expense, it's hard to justify.]

I'd like to introduce to you a few people from our organization that
think usability is unnecessary. The flipside is that there are many
that are "coming around" just because of exposure.

[Jared wrote: Even when it's clear that a more usable design will
win in the marketplace (or whatever the organizational goals are), as
Chauncey rightly pointed out, if the reward structure for the
developers doesn't take that into account, no amount of "selling"
will move in that direction.]

The other way of UX exposure is to create a UX Group. We created a
UX Group in our organization because we felt it was important to
expose usability and design principles to everyone, not just the
developers. They get involved in projects that will affect the
organization, not just us. And some of the managers make it known to
their developers that if they haven't gone to our group or core team
for any feedback, then they're missing out on a big opportunity.
The key thing here is that this wouldn't be possible at all without
an Executive Champion.

[Jared wrote: In my experience, unusable designs rarely exist due to
team ignorance of the value of a great experience. There are often
many other factors that the team is battling and making something
more usable is a place where the battle is lost. Standing on a
soapbox yelling to the gods that this is a crime against humanity
rarely does anything other than cause one to lose their voice. ]

Before me and some of my predecessors, there was no usability. And
the organization's designs were horrid - or so I was told and IMO.
I was surprised that anyone could use them at all. Soapboxes are of
little use if you don't have people listening. Get people engaged
in useful projects that anyone can contribute. I think that's the
key for anyone to understand what UX/IxD etc. is all about.

Hope this helps.

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

28 Jan 2009 - 4:08pm
Scott Berkun
2008

> Ali wrote:
>
> As a User Centered Design graduate I find it quite irritating to
> be working in an environment where engineers run everything.
> My position does not allow me to say much yet as a Tech Writer/Project
> Manager assisting the engineers on usability issues I have had it!

All the responses I've seen so far have been very supportive and kind, which
is cool - but it also compels me to say the unpleasant (but critical) things
that have gone unmentioned.

You have to take some responsibility here. You picked the company. You
picked the job. As engineering driven as it is, and as evil or stubborn the
people might be, you still chose to go to work there. Some of the
responsibility is yours, and the sooner you take some responsibility,
instead of blaming others, the faster you will sort this out. If you were
misled about the job, that's unfortunate, but now you know some new things
to look out for in the next one.

Many of the suggestions I've seen on this thread are familiar and fine, but
take a design centric approach. Which in this case is all wrong. You are in
an engineering environment and you appear to have little power. This means
you need to make arguments in a way engineers will respond to, and you need
to seek out sources of power to support your arguments. You are on their
turf. This doesn't mean be a whuss, but it does mean BE A DESIGNER. Think
about what approaches fit the culture, attitude and environment you're in.
You should be good at this, it's a kind of problem solving, which is what
designers do. If those approaches bore you or take too much time for your
liking, then it's time to go elsewhere. But the culture you're in is the
culture you're in. If you go to Iceland, and complain about how it's not
Hawaii, don't expect much sympathy from the Icelandians, much less for them
to help you make Iceland more like Hawaii.

One of the worst things to do in this situation is to call a big
presentation together where you more or less tell a room full of people how
wrong they are, how bad what they've made is (ignoring completely that to
them it's their pride and joy), and why things should be done how you want
them to be. You will be oh so easy to ignore after this as your reputation
as a frustrated/bitter designer will be sealed forever (Many many many
designers have this reputation). If I've only been in a culture a month,
It'd be very difficult to know how to talk to such a large group. I'd be
shooting in the dark.

It's much smarter to find your supporters are and start with them. This
probably means whoever wrote your job description and hired you. Clearly
they are interested in what they can do to make you more successful. Then
look at all the programmers, or the managers - which one is least
close-minded? Least resistant? How much of your view of things do they
share? 50%? 75%? 5%? Even on the worst team in the world there has to be
someone who sucks the least. Start there. Find the sweet spot for change
where you have the most support and the greatest opportunity. Your
supporters are locals in the culture and can advise on steps to take, get
you a friendlier ear from other possible allies, and your planning begins.
Only then would I consider approaching larger groups, advocating changes,
etc.

Keep in mind as a new person you have zero credibility. Especially if you
are the first Designer they've ever worked with. Hell, many people are
probably afraid of you. They fear you will want to take some of the fun
parts of their jobs away (which in fact, is probably true). So until people
hear you saying smart things, being of use in a daily sense (even if it's
just finding bugs, giving good comments on spec reviews), and delivering on
things you promise to do, you will have little credibility, and will have
earned little trust. If you stay an untrusted outsider, it's impossible to
do much of anything in an environment like yours. In fact I'd say goal #1 is
to earn the trust and respect of the key people in your smallest circle of
work.

This might be of use as well: Designing in hostile territory.
http://www.businessweek.com/innovate/content/nov2005/id20051116_109051.htm

-Scott

Scott Berkun
www.scottberkun.com

29 Jan 2009 - 5:43am
James Page
2008

Ali,

As Scott said

Think about what approaches fit the culture, attitude and environment you're
in.
You should be good at this, it's a kind of problem solving, which is what
designers do.

I have written on my blog
http://blog.feralabs.com/2008/12/why-i-started-webnographer/ the attitudes
of one programmer to Usability. Maybe this will help build an understanding.

I would very much recommend not showing them Allan Cooper's "The Inmates are
running the asylum", it would be as effective as throwing a brick at them.

As Jared Spool said :-

Creating stereotypes by job description isn't any better than creating them
> by race or religion or sexual preference.

One book that may help you is "How to win friends and influence them."

Build friends first.

Don't go negative. Focus on the positives, and as many people have said
above the shared vision. Tell them what you think works for the current
product? Ask them what you can do for them. What do they think needs
improving?

Find out why do they program. For me it was coolness of having millions of
people use the code that I was writing. If the product was not usable then I
would not have had that ego boost.

People naturally form themselves into tribes. East vs West, or Left vs
Right, or Apple vs Windows. At the moment there are two tribes in your
organisation you and the Engineers. Move the focus of the "them" to the
competition. Look at how Apple does it with the other side being Windows.

All of this takes time, but far less time, then if a Us vs Them battle
starts.

Good luck

James

2009/1/28 Scott Berkun <info at scottberkun.com>

> > Ali wrote:
> >
> > As a User Centered Design graduate I find it quite irritating to
> > be working in an environment where engineers run everything.
> > My position does not allow me to say much yet as a Tech Writer/Project
> > Manager assisting the engineers on usability issues I have had it!
>
> All the responses I've seen so far have been very supportive and kind,
> which
> is cool - but it also compels me to say the unpleasant (but critical)
> things
> that have gone unmentioned.
>
> You have to take some responsibility here. You picked the company. You
> picked the job. As engineering driven as it is, and as evil or stubborn the
> people might be, you still chose to go to work there. Some of the
> responsibility is yours, and the sooner you take some responsibility,
> instead of blaming others, the faster you will sort this out. If you were
> misled about the job, that's unfortunate, but now you know some new things
> to look out for in the next one.
>
> Many of the suggestions I've seen on this thread are familiar and fine, but
> take a design centric approach. Which in this case is all wrong. You are in
> an engineering environment and you appear to have little power. This means
> you need to make arguments in a way engineers will respond to, and you need
> to seek out sources of power to support your arguments. You are on their
> turf. This doesn't mean be a whuss, but it does mean BE A DESIGNER. Think
> about what approaches fit the culture, attitude and environment you're in.
> You should be good at this, it's a kind of problem solving, which is what
> designers do. If those approaches bore you or take too much time for your
> liking, then it's time to go elsewhere. But the culture you're in is the
> culture you're in. If you go to Iceland, and complain about how it's not
> Hawaii, don't expect much sympathy from the Icelandians, much less for them
> to help you make Iceland more like Hawaii.
>
> One of the worst things to do in this situation is to call a big
> presentation together where you more or less tell a room full of people how
> wrong they are, how bad what they've made is (ignoring completely that to
> them it's their pride and joy), and why things should be done how you want
> them to be. You will be oh so easy to ignore after this as your reputation
> as a frustrated/bitter designer will be sealed forever (Many many many
> designers have this reputation). If I've only been in a culture a month,
> It'd be very difficult to know how to talk to such a large group. I'd be
> shooting in the dark.
>
> It's much smarter to find your supporters are and start with them. This
> probably means whoever wrote your job description and hired you. Clearly
> they are interested in what they can do to make you more successful. Then
> look at all the programmers, or the managers - which one is least
> close-minded? Least resistant? How much of your view of things do they
> share? 50%? 75%? 5%? Even on the worst team in the world there has to be
> someone who sucks the least. Start there. Find the sweet spot for change
> where you have the most support and the greatest opportunity. Your
> supporters are locals in the culture and can advise on steps to take, get
> you a friendlier ear from other possible allies, and your planning begins.
> Only then would I consider approaching larger groups, advocating changes,
> etc.
>
> Keep in mind as a new person you have zero credibility. Especially if you
> are the first Designer they've ever worked with. Hell, many people are
> probably afraid of you. They fear you will want to take some of the fun
> parts of their jobs away (which in fact, is probably true). So until people
> hear you saying smart things, being of use in a daily sense (even if it's
> just finding bugs, giving good comments on spec reviews), and delivering on
> things you promise to do, you will have little credibility, and will have
> earned little trust. If you stay an untrusted outsider, it's impossible to
> do much of anything in an environment like yours. In fact I'd say goal #1
> is
> to earn the trust and respect of the key people in your smallest circle of
> work.
>
> This might be of use as well: Designing in hostile territory.
> http://www.businessweek.com/innovate/content/nov2005/id20051116_109051.htm
>
> -Scott
>
> Scott Berkun
> www.scottberkun.com
>
> ________________________________________________________________
> 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
>

30 Jan 2009 - 2:55pm
dszuc
2005

Hi Ali:

Good question.

Agree with this:

"If there is no pain %u2014 inotherwords, if the organization can't
feel how their hard-to-use product is hurting them %u2014 then there
is probably nothing you can do." - Jared Spool

and this ...

"I've made myself blue in the face trying to convince both clients
and coworkers (simultaneously, mind you) of the value of IxD-related
activities "in general." It nearly always fails until I am able to
understand my clients' needs and then tailor my design approach
directly to them." - Josh Evnin

Both talk to an environment being receptive to the UX message. Or I
call we call this "organization ripeness".

We talk to some of this here -- Selling UX -
http://www.uxmatters.com/mt/archives/2008/10/selling-ux.php and here
-
http://www.slideshare.net/dszuc/selling-usability-in-organizations-presentation

Quick tips:

* Start with 1-2 engineers at a time (test your assumptions)
* Don't try and sell the whole UCD process (it takes too long) and
you will probably be pushing in "jargon" they may not have heard
before.
* Show how your UI/product improvements resulted in an improvement to
business results (and share the joy with the team)

Build from there ...

rgds,
Dan

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

Syndicate content Get the feed