Why hire an ID instead of a software developer?

26 May 2005 - 4:06pm
9 years ago
19 replies
590 reads
Jay Zipursky
2005

I'm about to challenge a project team to redefine an open position from
a software developer to an interaction designer. They are currently
looking for a person who can design a GUI and write code -- always a
tough position to fill.

I'm meeting with the team to convince them to go the ID route and not
require coding skills. However, I work in a very engineering-centric
organization where lines of code are *the* basis of productivity. The
team is about to embark on the development of a new version, though, so
the timing is right. Has anyone ever successfully made this case
before? What are your most persuasive arguments?

I look forward to the discussion.

Regards,
Jay

Creo
Jay Zipursky | Tel: +01.604.451.2720 ext: 2204 |
www.creo.com
Team Leader, Usability | Cel: +01.604.418.2238
Printing Workflow Solutions | Fax: +01.604.437.9891
3755 Willingdon Avenue | jay.zipursky at creo.com
Burnaby, BC V5G 3H3
Canada

IMAGINE CREATE BELIEVE

Comments

26 May 2005 - 4:47pm
Tanya Rabourn
2004

On Thu, 26 May 2005, Jay Zipursky wrote:
> I'm about to challenge a project team to redefine an open
> position from a software developer to an interaction
> designer. They are currently looking for a person who can
> design a GUI and write code -- always a tough position to
> fill.

One argument, outlined in the paper "Why good engineers
(sometimes) create bad interfaces"[1] explains that a good
developer's (engineer's) conception of the system is usually
based on its underlying mechanism. When a developer designs
the user interface, it reflects this point of view. However,
users more often benefit from an interface that is modeled
according to the task they want to complete and not on the
system's underlying mechanism.

Of course this argument doesn't preclude the UI designer
from having coding skills. The author is advocating having
someone on the team dedicated soley to the UI. But as you
point out, it's rare to find both skill sets in one person.

1.Proceedings of the SIGCHI conference on Human factors in
computing systems 1990
http://doi.acm.org/10.1145/97243.97287

-Tanya

27 May 2005 - 3:11am
Petteri Hiisilä
2004

> I'm meeting with the team to convince them to go the ID route and not
> require coding skills. However, I work in a very engineering-centric
> organization where lines of code are *the* basis of productivity. The
> team is about to embark on the development of a new version, though, so
> the timing is right. Has anyone ever successfully made this case
> before? What are your most persuasive arguments?

Don't just convince the team. Convince their boss! Get someone who
values the user (or customer) and their money more than the cool
technology that you're using.

Check these out. You'll find plenty of arguments:

http://www.cooper.com/content/insights/newsletters/2003_08/Can_Programmers_Do_Interaction_Design.asp

http://www.cooper.com/newsletters/2002_01/bridging_the_gap.htm

http://www.cooper.com/newsletters/2001_06/so_you_want_to_be_an_interaction_designer.htm

http://www.cooper.com/content/insights/newsletters/2004_issue04/Ten_ways_to_kill_design.asp

Please read The Inmates are Running the Asylum. That's a truckload of
arguments. Buy one for yourself and one for your boss.

One of the most effective arguments for our developers has been the
fact, that once they get the specs from (a competent) interaction
designer, only interesting, challenging _technical_ problems are left.
All human-related nonsense has been solved, and the requirements won't
change! They're actually going to build something that people will like
to use.

They're not going to believe this proposition at first (they've heard it
so many times before), but they will understand it's value. "If that's
true, then it's a good thing." Because it is.

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"I was told there's a miracle for each day that I try"
- John Petrucci

27 May 2005 - 3:41am
Lada Gorlenko
2004

PH> One of the most effective arguments for our developers has been the
PH> fact, that once they get the specs from (a competent) interaction
PH> designer, only interesting, challenging _technical_ problems are left.
PH> All human-related nonsense has been solved, and the requirements won't
PH> change! They're actually going to build something that people will like
PH> to use.

I found this argument to be the weakest one in the Cooper's book (mind
you, I am a big fun of his work) and frequently contradicting my
personal experience. Everyone tends to see himself an expert in human
nonsense, that's why developers [I dealt with] rarely acknowledge its
existense at all. When they do consider it a problem, they are more
than willing to form partnership with human nonsense specialists. The
biggest challenge for me is to persuade the development team that the
nonsense exists. The rest (taking it away from them) is peanuts.

Does Alan's argument cited above work for you?

Lada

27 May 2005 - 4:21am
Suresh JV
2004

Developer/Engineer
- Engineer is taught to follow the rules and conventions
- Engineer thinks "Because the technology works this way, let the user
work that way"
- Engineer builds with featuristic vision
- Engineer thinks with left brain [Logical, Rational]
- Always a Technology centric approach

Designer
- Designer is taught to break the rules and conventions and go beyond.
- Designer thinks "Because the User wants it this way, let the technology
work that way"
- Designer builds with a futuristic vision
- Designers thinks with right brain [Creative, emotional]
- Always a User centric Approach

Bottomline: Even if a software system is architected in such a way that
its internal structure and operations are efficient, elegant and correct,
ultimately, it's the interface by which the end user judges its Usefulness.
[Source Unknown] - Think Google, IPod..

Regards,
Suresh JV.

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.com]On Behalf Of Jay Zipursky
> Sent: Friday, May 27, 2005 3:37 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] Why hire an ID instead of a software developer?
>
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I'm about to challenge a project team to redefine an open position from
> a software developer to an interaction designer. They are currently
> looking for a person who can design a GUI and write code -- always a
> tough position to fill.
>
> I'm meeting with the team to convince them to go the ID route and not
> require coding skills. However, I work in a very engineering-centric
> organization where lines of code are *the* basis of productivity. The
> team is about to embark on the development of a new version, though, so
> the timing is right. Has anyone ever successfully made this case
> before? What are your most persuasive arguments?
>
> I look forward to the discussion.
>
> Regards,
> Jay
>
> Creo
> Jay Zipursky | Tel: +01.604.451.2720 ext: 2204 |
> www.creo.com
> Team Leader, Usability | Cel: +01.604.418.2238
> Printing Workflow Solutions | Fax: +01.604.437.9891
> 3755 Willingdon Avenue | jay.zipursky at creo.com
> Burnaby, BC V5G 3H3
> Canada
>
> IMAGINE CREATE BELIEVE
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/

27 May 2005 - 4:21am
Petteri Hiisilä
2004

Lada Gorlenko wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> PH> One of the most effective arguments for our developers has been the
> PH> fact, that once they get the specs from (a competent) interaction
> PH> designer, only interesting, challenging _technical_ problems are left.
> PH> All human-related nonsense has been solved, and the requirements won't
> PH> change! They're actually going to build something that people will like
> PH> to use.
>
> I found this argument to be the weakest one in the Cooper's book (mind
> you, I am a big fun of his work) and frequently contradicting my
> personal experience. Everyone tends to see himself an expert in human
> nonsense, that's why developers [I dealt with] rarely acknowledge its
> existense at all. When they do consider it a problem, they are more
> than willing to form partnership with human nonsense specialists. The
> biggest challenge for me is to persuade the development team that the
> nonsense exists. The rest (taking it away from them) is peanuts.
>
> Does Alan's argument cited above work for you?

Usually it does. Not as the only argument, but it is a good one. The
last time I used it was yesterday, and got a new customer.

Granted, step one is to make the developers understand that there is a
problem.

1. One way is to show a difference between a good UI and a bad UI of
some other products. I've used the Windows XP photo-printing wizard vs.
my own photo-printing wizard as an example (when I'm the candidate who
wants to take the design job). The first one has 20+ screens, mine has
two. A more public example might be a promotional video from
http://www.sketchup.com/, and compare that to AutoCAD. Make them laugh
at the bad UI's. Don't laugh at _their_ UI. They have to understand it
themselves, otherwise they might consider you a selfish bully. Not good.

Of course there are some boneheads who completely fail to see the
problem. I don't waste my energy with them, but with their bosses. But I
try to stay friends with them, since often those same people can do
tremendous algorithm work, or they can be database gurus, who can make
your design fly.

2. Once the developers understand the problem, it's important to make
them understand the conflict of interest between design, engineering and
construction. Prosecutor vs. defence. Architect vs. engineer vs. iron
worker. Insider's holdings. There are plenty of real-world examples of
the conflict of interest. After the discussion I try to make them think,
that _if_ they could design the UI without the worries of actually
coding it themselves, the UI would become better. What would the dream
UI accomplish? I ask them to think about some previous projects, and how
much time they would have saved, if they or someone else would have had
a good usability tested blueprint of the UI before the large-scale
coding begins.

3. And once they understand the conflict, then it's time to tell that
there are people whose speciality is UI design (in the beginning they're
usually more comfortable with this term), and they don't design things
that aren't feasible. It's important to tell that interaction designers
have a solid understanding what's feasible.

This is a topic that I'd love to discuss face-to-face in a pub
atmoshpere. Unfortunately I live in Finland.

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"I was told there's a miracle for each day that I try"
- John Petrucci

27 May 2005 - 4:22am
Petteri Hiisilä
2004

Very well put. This will find its way to one of my powerpoint slides :)

Thank you,
- Petteri

Suresh JV wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Developer/Engineer
> - Engineer is taught to follow the rules and conventions
> - Engineer thinks "Because the technology works this way, let the user
> work that way"
> - Engineer builds with featuristic vision
> - Engineer thinks with left brain [Logical, Rational]
> - Always a Technology centric approach
>
> Designer
> - Designer is taught to break the rules and conventions and go beyond.
> - Designer thinks "Because the User wants it this way, let the technology
> work that way"
> - Designer builds with a futuristic vision
> - Designers thinks with right brain [Creative, emotional]
> - Always a User centric Approach
>
>
> Bottomline: Even if a software system is architected in such a way that
> its internal structure and operations are efficient, elegant and correct,
> ultimately, it's the interface by which the end user judges its Usefulness.
> [Source Unknown] - Think Google, IPod..
>
>
>
> Regards,
> Suresh JV.
>
>
>
>>-----Original Message-----
>>From:
>>discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>>[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
>>ers.com]On Behalf Of Jay Zipursky
>>Sent: Friday, May 27, 2005 3:37 AM
>>To: discuss-interactiondesigners.com at lists.interactiondesigners.com
>>Subject: [ID Discuss] Why hire an ID instead of a software developer?
>>
>>
>>[Please voluntarily trim replies to include only relevant quoted
>>material.]
>>
>>I'm about to challenge a project team to redefine an open position from
>>a software developer to an interaction designer. They are currently
>>looking for a person who can design a GUI and write code -- always a
>>tough position to fill.
>>
>>I'm meeting with the team to convince them to go the ID route and not
>>require coding skills. However, I work in a very engineering-centric
>>organization where lines of code are *the* basis of productivity. The
>>team is about to embark on the development of a new version, though, so
>>the timing is right. Has anyone ever successfully made this case
>>before? What are your most persuasive arguments?
>>
>>I look forward to the discussion.
>>
>>Regards,
>>Jay
>>
>>Creo
>>Jay Zipursky | Tel: +01.604.451.2720 ext: 2204 |
>>www.creo.com
>>Team Leader, Usability | Cel: +01.604.418.2238
>>Printing Workflow Solutions | Fax: +01.604.437.9891
>>3755 Willingdon Avenue | jay.zipursky at creo.com
>>Burnaby, BC V5G 3H3
>>Canada
>>
>>IMAGINE CREATE BELIEVE
>>
>>_______________________________________________
>>Welcome to the Interaction Design Group!
>>To post to this list ....... discuss at ixdg.org
>>(Un)Subscription Options ... http://discuss.ixdg.org/
>>Announcements List ......... http://subscribe-announce.ixdg.org/
>>Questions .................. lists at ixdg.org
>>Home ....................... http://ixdg.org/
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"I was told there's a miracle for each day that I try"
- John Petrucci

27 May 2005 - 7:32am
sylvania
2005

I'd also like to add that, given the right person, a certain degree of
coding skills can be taught but design talent is more of an innate
thing. True, it is difficult to find both skill sets in one person, but
it is often easier for the right ID person to learn to code than to
instil in an engineer an eye for design. (...assuming that your
organization refuses to separate ID into its own role.)
If you do believe that an ID will be a tough sell, it may be best to
bring 2 plans to the table: Plan A, go the ID route and not require
coding skills; Plan B, look for an ID who does have coding skills or
wants to learn. First get some members of the team on-board for plan A,
then present both plans to the boss, pushing for plan A but also
"willing to compromise" with plan B. Having other members of the team
on-board will give your arguments more validity, and having a backup
plan increases your odds.

Cheers!

27 May 2005 - 7:48am
Gerard Torenvliet
2004

Jay,

In my opinion, you have a number of good arguments to deliver:

1. The responsibility for writing code actually clouds creativity for
designing interfaces.

2. In a heavily code-centric organization, it is difficult to ensure
that a co-branded designer / developer doesn't end up being evaluated
only on the basis of code production, and so actually ends up doing no
design.

3. Good designers reduce late-cycle churn in a development process by
ensuring that the design is fleshed out long before the software
freezes. This de-risks the software development process.

4. Good designers come up with innovative solutions that are more
compact and elegant and extensible, with fewer warts. This means that
a good designer will raise the effective coding productivity both in
the short term (by ensuring that coders are working on the right
problems, and so do less re-work or useless work) and in the long term
(because a good extensible design will mean less re-work when adding
features later on).

My $.02.

-Gerard

--
Gerard Torenvliet
g.torenvliet at gmail.com

27 May 2005 - 9:55am
Josh Seiden
2003

In my experience, one good way to do this is by
testimonial.

Find an engineering manager with some street cred who
has worked on projects with and without interaction
design. Those who have had the experience of working
with good interaction design are rarely willing to go
back, and often make wonderful advocates.

They will describe the benefits that we all
understand, but will do without seeming as if they are
serving their own self-interest.

And by the way, this "innate talent" that we designers
possess? I think this needlessly mystifies what we do.
Design is a process that can be taught and learned.
Sure some folks will be better than others because of
what they bring to the table. But wrapping design in a
cloak of mystery and fuzziness rarely works when
selling to hard-nosed engineering organizations.

Thanks,
JS

> I'd also like to add that, given the right person, a
> certain degree of
> coding skills can be taught but design talent is
> more of an innate
> thing.

27 May 2005 - 11:37am
Wendy Fischer
2004

hah, but isn't that what we are here for, to kill the fun and creativity for the developers (hmm...wait I think I'm already doing that for the graphic designers...)

I have the exact opposite problem....at my current company we have Technical Product Managers in Product Management that write specs and have been doing mockups in the past, and continue doing mockups since there is only one of me. The Director of PM held up a spec to me and thought what the TPM was doing was visual design. His exact words were: "The TPM is doing visual design; look at the mockups."

My reply was that it wasn't visual design but that I was sure that development would implement it exactly the way the TPM has designed it.

They would like more TPM's that write specs, have an understanding of technology and can do mockups (most of the TPM's seem to come from a software developer background)...I am trying to make a case for getting more interaction designers so the TPM can focus on other things, rather than mockups and usability.

-Wendy

Lada Gorlenko <lada at acm.org> wrote:
[Please voluntarily trim replies to include only relevant quoted material.]

PH> One of the most effective arguments for our developers has been the
PH> fact, that once they get the specs from (a competent) interaction
PH> designer, only interesting, challenging _technical_ problems are left.
PH> All human-related nonsense has been solved, and the requirements won't
PH> change! They're actually going to build something that people will like
PH> to use.

I found this argument to be the weakest one in the Cooper's book (mind
you, I am a big fun of his work) and frequently contradicting my
personal experience. Everyone tends to see himself an expert in human
nonsense, that's why developers [I dealt with] rarely acknowledge its
existense at all. When they do consider it a problem, they are more
than willing to form partnership with human nonsense specialists. The
biggest challenge for me is to persuade the development team that the
nonsense exists. The rest (taking it away from them) is peanuts.

Does Alan's argument cited above work for you?

Lada

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

27 May 2005 - 2:20pm
ldebett
2004

Hi Jay-

I used to work for Scitex (prior to the Creo-Scitex merger) as an
Applications Engineer for Leaf and Agfa as an Apps Engineer for scanners and
color management and I can absolutely understand your situation. The
printing world is tough - I lived it for 7 years, and spent most of my time
fixing bottlenecks due to the UI design rather than bugs, color issues or
other technical problems. That's how/when/why I transitioned into full-time
UI design. ;-)

If I could have added up the amount of money these companies spent flying me
around the globe in response to the big print houses calling up screaming
about our software "not working right" or because someone ELSE needed to be
trained to use the software, it would have absolutely paid for a full time
UI designers. That would have freed me up to actually work on real technical
issues.

The s/w engineers were great people - don't get me wrong. They just simply
wanted to put controls on the UI to manage every single variable in the
software - not thinking about how they were going to be used in a
high-pressure, high-productivity environment. The kids the print houses (our
customers) were hiring for $12/hour out of high school to run these $50k
machines were having a tough time with the software, and the printer's
productivity slowed way down. These kids weren't 1/4 as educated about color
RGB->CMYK + USM, UCR, GCR, local color, global color, etc., etc., etc. as
our software engineers were, so what they needed were automation tools. A UI
designer/researcher could have spent the time to go out and visit these
customer sites to *understand* what these print shops needed and designed
for that. S/W engineers couldn't visit customers - they had code to write
and deadlines to meet!!

I don't know if any of that helps... but just getting out to talk to
customers is worth a UI designer's weight in gold in that industry. It also
opens up a huge opportunity for future innovations for your company - all
that observation and talking with end users can give you so many new ideas
for innovative product solutions that are *real* and *needed* - not
Marketing hype or laundry lists of "what the competitors are doing".

Cheers,
Lisa

27 May 2005 - 7:44am
hj
2005

Also think of how far the ID can go to help the programmers. If they can
deliver designs to the programmers in a form such as Visual Studio, then
this itself could remove some work from the programmers as they could take
that and at least not have to worry too much about putting the widgets in
the right place.

Best,
- h

3 Jun 2005 - 1:11pm
John Vaughan - ...
2004

Jay

The presumption that "one guy does it all" is a little naive, but - as you
say - it's an engineering-centric org. Don't know that there is a
compelling argument that'll resonate in that environment. Often they come
around only after messing up - assuming that they recognize that a) they've
messed up and b) why.

Here's the approximate flow of the "common sense" arguments I've tried:

Coder perspective is "inside-out" (machine centic), whereas ID perspective
is "outside-in" (human-centric). Coder style is literal, whereas IxD style
is interpretive. For one person to try to embrace both is schizophrenic.

You already have a well-defined, well-positioned coding team. You need a
strong, articulate human factors liaison to leverage your existing skill
base into "usability". It's a valid perspective and we need it.

The main difference between a competent conventional IT shop and a
professional, competitive shrink-wrapped software operation is the level of
investment in IxD.

Best of luck
John

> I'm meeting with the team to convince them to go the ID route and not
> require coding skills.
Has anyone ever successfully made this case
> before? What are your most persuasive arguments?

3 Jun 2005 - 4:59pm
Jenifer Tidwell
2003

On 6/3/05, John Vaughan <vaughan1 at optonline.net> wrote:
>
> Coder perspective is "inside-out" (machine centic), whereas ID perspective
> is "outside-in" (human-centric). Coder style is literal, whereas IxD style
> is interpretive. For one person to try to embrace both is schizophrenic.

Why?

I understand that beliefs like this are not uncommon, but it disturbs
me a little bit. There's no reason why one person can't learn both
approaches (other than the hard work and time required). A single
person is likely to be better at one than the other -- due to
training, or natural ability, or both -- but seriously, why would it
make one "schizophrenic" to learn different ways of thinking?

I've always thought that the ability to see a problem from different
points of view is one hallmark of a good designer. And of a good
engineer, as well.

There's a healthy tension between UX-centric and code-centric
thinking, I'll grant you that. It often happens that in design
meetings I'm in, people take one side or the other while hashing out a
design problem. But that doesn't mean that any one person can't see
both sides, say, "Yep, there's conflict here," and then try to devise
a solution that works for both sides. A compromise, usually, but
sometimes "win-win" (sorry, I hate that phrase too). :-)

- Jenifer

3 Jun 2005 - 7:30pm
Dave Malouf
2005

> > is interpretive. For one person to try to embrace both is
> schizophrenic.
>
> Why?

I think that one person can be both an engineer and a designer. However, I
believe that for a project to run well, you need two different heads here. I
believe there is more than just a "tension" between the two but rather a
"conflict of interest" that is difficult, and worrisome for a single mind to
mitigate.

If a really good person had the skills, can they do it if they had to? Sure.
It is not impossible. I know I've been put in that position before. But it
is actually better for the design creativity to actually have two minds that
can engage each other in this tension. It is very difficult to do that in a
single mind (w/o a little dual personality stuff going on).

-- dave

3 Jun 2005 - 7:47pm
Lilly Irani
2004

> Bottomline: Even if a software system is architected in such a way that
> its internal structure and operations are efficient, elegant and correct,
> ultimately, it's the interface by which the end user judges its
> Usefulness.
> [Source Unknown] - Think Google, IPod..

That's not entirely true. The Google interface on awful search results
wouldn't be terribly useful. And for me, the magic of Google News are the
clustering algorithms. The interface doesn't get in the way. Those
algorithms were designed by awesome engineers thinking in user-centered
ways.

In my work, I've found the assumption that engineers don't care about users
to be harmful in starting the relationship with an antagonistic note. Of
course, there really are engineers that don't care, but treating them with
the expectation out of hand is insulting and you lose the ally you need to
materialize your vision.

Regards,
> Suresh JV.
>
>
> > -----Original Message-----
> > From:
> > discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> > [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> > ers.com <http://ers.com>]On Behalf Of Jay Zipursky
> > Sent: Friday, May 27, 2005 3:37 AM
> > To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> > Subject: [ID Discuss] Why hire an ID instead of a software developer?
> >
> >
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > I'm about to challenge a project team to redefine an open position from
> > a software developer to an interaction designer. They are currently
> > looking for a person who can design a GUI and write code -- always a
> > tough position to fill.
> >
> > I'm meeting with the team to convince them to go the ID route and not
> > require coding skills. However, I work in a very engineering-centric
> > organization where lines of code are *the* basis of productivity. The
> > team is about to embark on the development of a new version, though, so
> > the timing is right. Has anyone ever successfully made this case
> > before? What are your most persuasive arguments?
> >
> > I look forward to the discussion.
> >
> > Regards,
> > Jay
> >
> > Creo
> > Jay Zipursky | Tel: +01.604.451.2720 ext: 2204 |
> > www.creo.com <http://www.creo.com>
> > Team Leader, Usability | Cel: +01.604.418.2238
> > Printing Workflow Solutions | Fax: +01.604.437.9891
> > 3755 Willingdon Avenue | jay.zipursky at creo.com
> > Burnaby, BC V5G 3H3
> > Canada
> >
> > IMAGINE CREATE BELIEVE
> >
> > _______________________________________________
> > Welcome to the Interaction Design Group!
> > To post to this list ....... discuss at ixdg.org
> > (Un)Subscription Options ... http://discuss.ixdg.org/
> > Announcements List ......... http://subscribe-announce.ixdg.org/
> > Questions .................. lists at ixdg.org
> > Home ....................... http://ixdg.org/
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

5 Jun 2005 - 10:48am
John Vaughan - ...
2004

Jenifer and Dave both said something along the line of:

> There's a healthy tension between UX-centric and code-centric
> thinking, I'll grant you that. It often happens that in design
> meetings I'm in, people take one side or the other while hashing out a
> design problem. But that doesn't mean that any one person can't see
> both sides, say, "Yep, there's conflict here," and then try to devise
> a solution that works for both sides.

First of all: Yup, yup, yup. I agree wholeheartedly. And I think that's
what I said:
"You need a strong, articulate human factors liaison <LIAISON> to leverage
your existing skill
base into "usability". It's a valid perspective and we need it."

Jenifer and Dave seem to be concerned about the "schizo-word" and the
implication that we just can't handle it. On the contrary, I don't think WE
have any problem with being "jacks/jills-of-all-trades". I take it as a
given that we (IxD folks) are - by definition and by temperment -
"slash"-type polymorphs:
artist/psychologist/engineer/documenter/evangelist/etcetera.

I agree: My"literal" (logical) coding skill helps me to describe how to
accomplish the "interpretive" (ease of use) effect. And my coding skill
gives me *street credibility* when trying to influence the
programming-centric coder-dominated environment. That often ain't easy, is
it, my friends?

Jay described a "very engineering-centric organization where lines of code
are *the* basis of productivity" (Sound familiar?). Jay has an opportunity
to confirm that coding technical expertise is valuable and that an IxD
expert will use that expertise to provide the client the UX help they need.
At the same time he has an opportunity to emphasize that the UX expert is a
UX expert first and foremost.

Here's another one-liner that sometimes helps:
"Coding is on my resume, too, but I consider it to be a skill rather than a
job description." i.e., Yes, I can do programming, too, but is it:
a) Something you really NEED? (You've already got a flock of very skilled
coders working on this)
b) The best use of what I have to offer? (If you just want another coder,
why bother?)

Hey, I LOVE it that conventional IT shops are willing to allow
"coders-who-are-design-hobbyists" to build their systems. Most of us make
our living off fixing up the mess when they finally realize that nobody
wants to use their 50,000 lines of code. That's when they are willing to
hire a "designer-who-is-a-coding-hobbyist" like you and me. And that's the
appropriate moment to have a hard-nosed discussion with them about
professional roles. And skills. And techniques. And process.

5 Jun 2005 - 11:32am
Lada Gorlenko
2004

JV> Hey, I LOVE it that conventional IT shops are willing to allow
JV> "coders-who-are-design-hobbyists" to build their systems. Most of us make
JV> our living off fixing up the mess when they finally realize that nobody
JV> wants to use their 50,000 lines of code. That's when they are willing to
JV> hire a "designer-who-is-a-coding-hobbyist" like you and me. And that's the
JV> appropriate moment to have a hard-nosed discussion with them about
JV> professional roles. And skills. And techniques. And process.

Sounds to me as if a surgeon was admitting his love for war because
the casualties are numerous, the patients are harsh, the wounds are
deep, the variety of cases is wide, the absence of antiseptics is
challenging, the sound of mosquitos is comforting and overall it's
much more fun than being a general practitioner in a happy healthy
place where the biggest medical intrigue is prescribing allergy pills
and treating hemorrhoid....

Lada

5 Jun 2005 - 11:59am
John Vaughan - ...
2004

> Sounds to me as if a surgeon was admitting his love for war because...

You betcha! Need I remind you that Daddy was a career US Marine and I
decided to become an effete touchy-feelie nerd (during my formative years)
only whilst absorbing a big ole' helpin' of UX whupass from a scarheaded
jarhead at scenic locations like Parris Island, & Quantico? Now THERE's
some insights on persona.

Us arteeests need adversity to fuel the creative spirit. It's what makes us
"special", y'know...

----- Original Message -----
From: "Lada Gorlenko" <lada at acm.org>
To: <discuss-interactiondesigners.com at lists.interactiondesigners.com>
Sent: Sunday, June 05, 2005 1:32 PM
Subject: Re: [ID Discuss] Why hire an ID instead of a software developer?

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> JV> Hey, I LOVE it that conventional IT shops are willing to allow
> JV> "coders-who-are-design-hobbyists" to build their systems. Most of us
> make
> JV> our living off fixing up the mess when they finally realize that
> nobody
> JV> wants to use their 50,000 lines of code. That's when they are willing
> to
> JV> hire a "designer-who-is-a-coding-hobbyist" like you and me. And
> that's the
> JV> appropriate moment to have a hard-nosed discussion with them about
> JV> professional roles. And skills. And techniques. And process.
>

> the casualties are numerous, the patients are harsh, the wounds are
> deep, the variety of cases is wide, the absence of antiseptics is
> challenging, the sound of mosquitos is comforting and overall it's
> much more fun than being a general practitioner in a happy healthy
> place where the biggest medical intrigue is prescribing allergy pills
> and treating hemorrhoid....
>
> Lada
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

Syndicate content Get the feed