Should interaction designer produce code... (Formally: Open Position: Sr. Interaction Designer @ MITRE)

18 Oct 2004 - 3:34pm
9 years ago
17 replies
708 reads
Petteri Hiisilä
2004

> Technical background is a good requirement; experience in a specific
> language development environment raises some red flags for me: is this
> *really* a design position? would the ID report to engineering? would
> the ID end up responsible for fixing bugs and QA?

Yeah, red is the color.

If you're da bossa and want to burn your interaction designers out
quickly, get a passionate in-house interaction designer who has to write
code too (after all, some of them can) and, of course, conduct all the
usability tests.

Plus, let the senior engineer have the final word on every design decision.

What's the color that comes after red?-)

- Petteri

Comments

18 Oct 2004 - 3:49pm
Petteri Hiisilä
2004

> Technical background is a good requirement; experience in a specific
> language development environment raises some red flags for me:

The other side of the coin: if you're an in-house designer and all your
developers do Java, you'd better be good at it too.

You still shouldn't code it, but if you aren't good at it, you might not
know where, how and why to stretch the limits. When the senior engineer
says "impossible" he usually means "sounds a bit tricky".

That's why I have this thing called "credits". If I invent something
that is really tricky to implement, I have to consume some credits to
get it built.

:)

If I want to earn credits, I have to find another part of the product
where to cut some corners and make the developers' life easier. Most
often that means dropping out some unessential features that can be left
in the next version.

Sometimes I'm in the marketing camp, talking to engineers: we need this
feature to make sales. I know it's difficult to build, but it's very
important.

Sometimes I'm in the developer camp, talking to marketers: we don't want
all these features. I know they sound simple to build and competitors
have them, but they still take time and are not really that important.

- Petteri, an in-house designer from Finland

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

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

18 Oct 2004 - 3:54pm
vutpakdi
2003

--- Petteri Hiisilä <petteri.hiisila at almamedia.fi> wrote:
> > Technical background is a good requirement; experience in a specific
> > language development environment raises some red flags for me:
>
> The other side of the coin: if you're an in-house designer and all your
> developers do Java, you'd better be good at it too.
>
> You still shouldn't code it, but if you aren't good at it, you might not
> know where, how and why to stretch the limits. When the senior engineer
> says "impossible" he usually means "sounds a bit tricky".

I don't know about having to be "good at it" since being really good at
development does take some time. A little knowledge can be a dangerous
thing.

On the other hand, I've found it very helpful to be able to say "bullshit!"
(though more politely) and back up my statement when a developer says
something can't be done (and it's worth fighting about).

So, knowing how to develop can be quite useful, and you should know at
least something. But, being able to get a job as a developer in your own
right can be asking a bit much.

>
> That's why I have this thing called "credits". If I invent something
> that is really tricky to implement, I have to consume some credits to
> get it built.
>

Or, alternately, build it yourself (or at least get a first pass done),
like I've done a couple of times with some specialized widgets.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

18 Oct 2004 - 8:19pm
Thomas Vander Wal
2004

On Mon, 18 Oct 2004 13:54:22 -0700 (PDT), Ron Vutpakdi
<vutpakdi at yahoo.com> wrote:
> --- Petteri Hiisilä <petteri.hiisila at almamedia.fi> wrote:
> > > Technical background is a good requirement; experience in a specific
> > > language development environment raises some red flags for me:
> >
> > The other side of the coin: if you're an in-house designer and all your
> > developers do Java, you'd better be good at it too.
> >
> > You still shouldn't code it, but if you aren't good at it, you might not
> > know where, how and why to stretch the limits. When the senior engineer
> > says "impossible" he usually means "sounds a bit tricky".
>
> I don't know about having to be "good at it" since being really good at
> development does take some time. A little knowledge can be a dangerous
> thing.
>
> On the other hand, I've found it very helpful to be able to say "bullshit!"
> (though more politely) and back up my statement when a developer says
> something can't be done (and it's worth fighting about).

I never was trained as a programmer, but on many occasions I have
proven to senior engineers that the better way to build a tool that
will help the user will acutally work. Knowing enough to code a
functional prototype *should* be in any interaction designers
toolbelt. The problem gets to being doing all the coding once you have
proven your point and provided a template (I have been down this path
too many times and have ended up leading the application development).
I have been trying to shake the *technical* label for years that
companies that think their designers should only know how to design,
this is foolish for companies to consider a designer should not know
the *technical* side.

Getting the engineers to take the designer seriously is extremely
important as it knowing the technical limitations of the design.
Having coding skills really helps to get this respect.

One thing the interaction designer should never do is think of the
limitations first. Don't even consider the limitations. Think
solutions and then work back from there. Technology changes rather
rapidly and what did not work two years ago, or even six months ago
may work now.

> So, knowing how to develop can be quite useful, and you should know at
> least something. But, being able to get a job as a developer in your own
> right can be asking a bit much.
>
> >
> > That's why I have this thing called "credits". If I invent something
> > that is really tricky to implement, I have to consume some credits to
> > get it built.
> >
>
> Or, alternately, build it yourself (or at least get a first pass done),
> like I've done a couple of times with some specialized widgets.

This is a great approach and it usually jump starts development down
the right path.

All the best,
Thomas

19 Oct 2004 - 2:14am
Petteri Hiisilä
2004

>>>That's why I have this thing called "credits". If I invent something
>>>that is really tricky to implement, I have to consume some credits to
>>>get it built.
>>>
>>Or, alternately, build it yourself (or at least get a first pass done),
>>like I've done a couple of times with some specialized widgets.
>
> This is a great approach and it usually jump starts development down
> the right path.
>

Yeah, that usually works too, but that still uses credits. I believe
this is partially dependent on culture, but I don't advertise to anybody
that I can code. It's not good in the long run. I stay on my side of the
yard, and that's design.

I just use my coding skills to talk their language. For persuasion
purposes. While making them feel competent and good.

Many programmers, especially younger ones, may feel belittled if an
"user interface designer" steps on their shoes and starts coding in
PERL. It's just not right. They might respect you, but deep in their
hearts they hate you for stepping on their feet. You use your credits.

Best,
Petteri

19 Oct 2004 - 2:31am
Listera
2004

Petteri Hiisilä:

> Many programmers, especially younger ones, may feel belittled if an
> "user interface designer" steps on their shoes and starts coding in
> PERL. It's just not right. They might respect you, but deep in their
> hearts they hate you for stepping on their feet. You use your credits.

Yes, that may be entirely true, but there's a solution. You can tell the
young developer that you can code but that you will not code *for* him, just
for your own prototype that will/should never go into production. That's why
it's a good idea to prototype in a language/platform that's sufficiently
different than the production code.

Conflict arises if there's an overlap of functions/responsibilities. If
developers don't get involved in prototyping and designers don't get
involved in production code (as God intended:-), then at least the rational
basis for personal entanglement is eliminated.

Designers should design, developers should implement the prototype.
Deviations from this natural order of affairs is what produces floods,
hurricanes and all forms of pestilence. :-)

Ziya
Nullius in Verba

19 Oct 2004 - 4:10am
Petteri Hiisilä
2004

> Conflict arises if there's an overlap of functions/responsibilities. If
> developers don't get involved in prototyping and designers don't get
> involved in production code (as God intended:-), then at least the rational
> basis for personal entanglement is eliminated.

Actually, god also intended that developers are divided in two groups:
engineers and programmers. This is a very natural division.

1. Designers design for humans (and create specs)
2. Engineers design for CPU (and create prototypes)
3. Programmers construct for shipment (and create production code)

To be a great designer, you also have to be a good engineer.
To be a great engineer, you also have to be a good programmer.
To be a great programmer, you also have to be a good engineer.

I've heard that the big C might publish his next book about this.
http://www.ftponline.com/vsm/2003_09_14th/magazine/departments/softwarearchitect/default_pf.aspx

You might ask: should a designer even do HTML or VB? Well, why not. But
it's still better to let someone else do that. Save that time to create
even better design.

Petteri

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

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

19 Oct 2004 - 8:21am
bill pawlak
2004

> Yes, that may be entirely true, but there's a solution. You can tell
> the
> young developer that you can code but that you will not code *for*
> him, just
> for your own prototype that will/should never go into production.
> That's why
> it's a good idea to prototype in a language/platform that's
> sufficiently
> different than the production code.

We design user interfaces using an iterative prototyping process, as
well. We code in .asp, .jsp, .php, perl, MySQL, HTML, Javascript,
CSS... _anything_ that helps us get our message across to the client,
the developers, the marketing team, etc.

A second goal is to use whatever tools are available to us to help
speed up the development of the prototype (hence, .asp to include
things like navigation, etc.)

We typically address not stepping on developers' toes by sticking to
one platform for development. Usually, it's Windows & IE6.0. Some
scripts are external to the file, some are inline, some .css is
declared externally, some inline (the horror!). It doesn't matter.
The purpose of the prototype is to illustrate and elaborate on the
design direction.

We begin each design demo meeting with a "stern" warning to developers
that the code they are about to witeness can, in many places, be quite
nasty. It's their job to develop clean, lean code that works across
browsers, validates in .css, etc.

But my opinion is that we *need* to understand the development
language, at least at some level, in order to be effective in our
roles. Maybe we don't code ecommerce sites from the ground up in
valid, 508-friendly php, but we sure as heck need to know that whatever
we come up with design-wise *can* be implemented.

Otherwise, I think we lose a lot of "street cred" on the team.

bill

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

19 Oct 2004 - 5:37pm
subimage interactive
2004

Just thought I'd throw my $.02 in since this is a topic dear to my heart.

I agree with some of the statements above regarding designers
producing prototype code that shouldn't be used, but in most real
world situations I've seen that same prototype code is snatched up and
used as production code - or at least a basis for production code.

Working as a solo contracter most of the time I seem to get a lot more
jobs when the boss knows I'm willing to "dig in" and help with the
coding effort. Again, it's been said, but it really helps to be able
to call "bullshit" and "put up or shut up" when suggesting uncommon UI
features/widgets/whatever. In most scenarios I find it helps me more
than it hurts that I can code just as well as the engineers on the
team in the language they're using.

That all being said, I'd love to move towards a more design-centered
approach with less coding. I bet I could get more jobs and balance
them all better that way if I were focused on just the interaction
design and not the coding specifics. Does anyone have tips for doing
such a thing without losing jobs?

- s

19 Oct 2004 - 10:08pm
Listera
2004

subimage interactive:

> Does anyone have tips for doing such a thing without losing jobs?

If at all possible, do your prototype in a language/platform that's not the
same as the production code.

Ziya
Nullius in Verba

20 Oct 2004 - 8:23am
vutpakdi
2003

--- Listera <listera at rcn.com> wrote:
> > Does anyone have tips for doing such a thing without losing jobs?
>
> If at all possible, do your prototype in a language/platform that's not
> the
> same as the production code.

Good in theory, and I've done it in practice. *But* depending on the team
you are working with, this approach can backfire in terms of the team's
perception of you and their working relationship with you. Also, you have
to be careful not to do anything that is easy in the prototype language but
hard in the production code.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

20 Oct 2004 - 1:22pm
Listera
2004

Ron Vutpakdi:

> *But* depending on the team you are working with, this approach can backfire
> in terms of the team's perception of you and their working relationship with
> you.

Why?

> Also, you have to be careful not to do anything that is easy in the prototype
> language but hard in the production code.

Difficulty of production code should have nothing to do with the choice of
prototyping tools. Some things will often be much simpler to accomplish with
prototyping tools (that's why they are used) than with production tools,
such as UI generation: a simple drag of a widget on a window and binding it
to a datasource with a single click will often require pages of code in a
procedural language. So what?

Prototype has one purpose and one purpose only: to demonstrate
functionality. In other words, how an app would work, not how difficult it
would be to make it so. The latter may be another type of prototype that
developers may choose to build to test their own ideas, using whatever
(different) tools they prefer.

Not confusing this is utterly central to the notion of designers designing
and developers implementing.

Ziya
Nullius in Verba

20 Oct 2004 - 1:41pm
vutpakdi
2003

--- Listera <listera at rcn.com> wrote:
> Ron Vutpakdi:
> > *But* depending on the team you are working with, this approach can
> backfire
> > in terms of the team's perception of you and their working relationship
> with
> > you.
>
> Why?

Using a different prototyping language can backfire on a couple of
different levels. First, the team (more likely the project manager) might
be under the mistaken impression that if the prototype had just been in the
same language, they'd be able to easily take the prototype and massage it
into the real thing (as if that were a good idea). Since the prototype is
in a different language, the project manager is annoyed since she sees the
prototype as slightly wasted effort.

Second, if they think that the prototype takes advantage of things that are
easy to do in the prototyping language but hard to do in production code,
the developers can walk away with the impression that the designer is being
unreasonable and unpleasant to work with. As a result, they're less likely
to want to work with the designer or listen to his suggestions.

I've had both happen to me. If you are working with a development team
that is either more mature or with which you have a better working
relationship, your results may be better.

>
> > Also, you have to be careful not to do anything that is easy in the
> prototype
> > language but hard in the production code.
>
> Difficulty of production code should have nothing to do with the choice
> of
> prototyping tools. Some things will often be much simpler to accomplish
> with
> prototyping tools (that's why they are used) than with production tools,
> such as UI generation: a simple drag of a widget on a window and binding
> it
> to a datasource with a single click will often require pages of code in a
> procedural language. So what?
>

I'm not talking about a simple drag vs. a page of code. I'm talking about
something that may take say 5 min to do for the prototype and several weeks
(or more) in the production code. Same order of magnitude, not a big deal.
An order of magnitude or more, a considerable issue.

Again, it comes down to perception and the quality of your working
relationship with the development team. Not having a good feel for the
implementation difficulty of what you are proposing can easily lead to a
rejection of *all* of your ideas as well as a poisoned working
relationship. Do it often enough, and the development team and others in
the company won't want to work with you.

As designers, we are (generally) ultimately reliant on others to implement
what we design. Sure, you might have a situation where some boss orders
the development team to implement exactly what you've designed. But, it
seems far more likely that there is a considerable degree of latitude given
to the developers, so we'll be more effective if we maintain a good working
relationship with the development team. Being a bit of a prima donna and
telling the developers: "It's DESIGN. I don't care if it's easy for you to
implement or not, just do it!" isn't generally going to be conducive to the
working relationship.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

20 Oct 2004 - 3:37pm
Listera
2004

Ron Vutpakdi:

> First, the team (more likely the project manager) might be under the mistaken
> impression that if the prototype had just been in the same language, they'd be
> able to easily take the prototype and massage it into the real thing (as if
> that were a good idea).

Well, explain it to her then.

> Since the prototype is in a different language, the project manager is annoyed
> since she sees the prototype as slightly wasted effort.

It's a designer's responsibility to clearly explain from minute one what a
prototype is for, if that's needed.

> Second, if they think that the prototype takes advantage of things that are
> easy to do in the prototyping language but hard to do in production code,
> the developers can walk away with the impression that the designer is being
> unreasonable and unpleasant to work with.

Again, this is a colossal misunderstanding of the purpose of the prototype.
Someone needs to explain.

> As a result, they're less likely to want to work with the designer or listen
> to his suggestions.

Developers should not be in the business of designing IA/UI/UX, period. A
designer should not be put into a position of "suggesting" to developers
what the product will do, it's the designer's *principal* job. Developers
are there to implement (the functionality demonstrated by the prototype).

> I'm not talking about a simple drag vs. a page of code. I'm talking about
> something that may take say 5 min to do for the prototype and several weeks
> (or more) in the production code.

That's almost always the case, so what? Again, the prototype demonstrates
functionality, it doesn't address issues of production, maintainability,
scalability, compatibility, etc.

> Same order of magnitude, not a big deal.
> An order of magnitude or more, a considerable issue.

No, it absolutely is not. You could spec a functionality that'll take months
to code verbally, in an email, with a Visio drawing, on a PostIt note, with
crayons or wet spaghetti. The fact that you prototyped it in one language or
another should have zero effect. Prototype demonstrates functionality.

> Again, it comes down to perception and the quality of your working
> relationship with the development team.

Certainly.

> Not having a good feel for the implementation difficulty of what you are
> proposing can easily lead to a rejection of *all* of your ideas as well as a
> poisoned working relationship.

This is very much a different issue. And it has nothing to do with the
selection of a language/platform for the prototype. I agree that designers
should absolutely know the technical ramifications of their design choices
(which has been my mantra for over 15 years as both a designer and a
developer), but that really has nothing to do with prototype vs. production
language issue.

> As designers, we are (generally) ultimately reliant on others to implement
> what we design.

Not generally, but always. Designers should not be in the implementation
business at all, just as I ask developers to stay away from designing.

> Sure, you might have a situation where some boss orders
> the development team to implement exactly what you've designed. But, it
> seems far more likely that there is a considerable degree of latitude given
> to the developers,

Yes, you are describing recent and current reality, which must change for
the industry to move forward in the direction of UCD. We empirically know
what happened for about a decade when developers played designers!
Personally, I make a living doing IA/UI/UX surgery on such efforts, but I'm
willing to sacrifice myself for the higher good.:-)

> so we'll be more effective if we maintain a good working
> relationship with the development team.

At some point in one's career one has to figure out if wantonly kowtowing to
developers is more important than serving customers, or not.

> Being a bit of a prima donna and telling the developers: "It's DESIGN. I
> don't care if it's easy for you to implement or not, just do it!" isn't
> generally going to be conducive to the working relationship.

Sure, but that characterization grossly misses the true nature and purpose
of a designer.

Ziya
Nullius in Verba

20 Oct 2004 - 4:12pm
vutpakdi
2003

--- Listera <listera at rcn.com> wrote:
> > so we'll be more effective if we maintain a good working
> > relationship with the development team.
>
> At some point in one's career one has to figure out if wantonly kowtowing
> to
> developers is more important than serving customers, or not.
>
I said maintaining a good working relationship with developers for the sake
of the bigger picture and nothing about kowtowing to developers.

As a designer, my effectiveness in terms of getting designs implemented
which serve the *user* is near zero and my job life expectancy isn't much
better if I don't have a good working relationship with my coworkers since
I am dependent on them to implement and support me. That doesn't mean
kowtowing to developers, but it does mean adapting/modifying my approach
and how "hard" or "soft" I'll be depending on the situation and my
relationship with those involved. If that approach makes you think that
I'm not a "real" designer, I can live with that opinion.

I think that we'll just have to agree to disagree. It appears to me that
we have a considerable difference of opinion and that I see shades of gray
where things are black and white for you.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

20 Oct 2004 - 5:28pm
Listera
2004

Ron Vutpakdi:

> I think that we'll just have to agree to disagree. It appears to me that
> we have a considerable difference of opinion and that I see shades of gray
> where things are black and white for you.

Fair enough. I'm wearing my advocate hat here. I've identified a long time
ago that the single most important thing the design community can do to
raise its profile and best serve users is to end the domination of
programmers in the product development process. Nothing else even comes
close. Yes, I am for separation of powers: designers should design,
developers should implement. As strident as it sounds, therein lies our
deliverance. :-)

One of the things that needs to happen is for the design to team to acquire
a much better understanding of the technical ramifications of their design
choices and the know-how to be able to produce their own prototypes, which
best describe their intentions. I see absolutely nothing wrong with
employing *a* developer or two to help with the prototype under the
direction of designers, but abdicating that responsibility entirely to the
development *team* is putting CPU before UCD.

----
Ziya

When 2+2=4, it's development,
When 2+2 > 4, it's design.

20 Oct 2004 - 9:31pm
Pradyot Rai
2004

Listera <listera at rcn.com> wrote --
> One of the things that needs to happen is for the design to team to acquire
> a much better understanding of the technical ramifications of their design
> choices and the know-how to be able to produce their own prototypes, which
> best describe their intentions. I see absolutely nothing wrong with
> employing *a* developer or two to help with the prototype under the
> direction of designers, but abdicating that responsibility entirely to the
> development *team* is putting CPU before UCD.

One of the problem for designers is that they are held responsible for
designing something that developers can't thrash by providing absurd
"level of efforts" estimation. Many a time when designers are given
these challenges, it is assumed that you will prototype your
recomendations that is feasible withing the budget. To counter that
the only thing, I can guess, designers can do is to gain more and more
control on the UI development, hence prototyping with common
technology, or policing the UI development seems inevitable ?!

So, I hear you advocating the same thing that Interaction Designers
should control developers, in all those situations? Where's the
conflict?

Prady

20 Oct 2004 - 10:56pm
Listera
2004

Prady Rai:
> So, I hear you advocating the same thing that Interaction Designers
> should control developers, in all those situations? Where's the
> conflict?

Let me get at this from an historical perspective: what are the trends?

On the one side, we have IDEs that make it increasingly easier for
developers to create UIs. On the other side, we have tools that allow
designers to prototype evermore complex apps.

The former, unfortunately, lulls developers and managers alike into thinking
that putting widgets on a window pretty much amounts to app/interaction
design. That's the genesis for all the thousands of VB-based intranet apps
and the gazillion ads you see for Java GUI Designers who'll spend 95% of
their time coding UI components. The fact that there's much, much more to
UCD than UI coding escapes this contingent.

The latter group is in turn hampered by the slow progression of prototyping
tools and designers' general lack of understanding of technical issues.

For the first decade of the web, the former group absolutely dominated the
scene. I'm arguing that we won't get to the promised UCD land by making
"designers" out of developers. I'm betting on designers getting technical
enough to do their own prototypes and understanding production constraints.

We have historical examples for this. Many print designers and film editors,
to cite two recent ones, had a hard time at the start of the DTP and digital
video revolutions: the technical people at the production-end of the design
process often dictated the terms. Slowly, tools became more friendly and
designers themselves came to understand technical constraints far better.
Today the design process at a publishing house or an ad agency doesn't start
with a discussion on pre-press or post-production editing issues, with a
tech guy telling them what they should be doing.

Now, I'm *not* saying that "Interaction Designers should control developers"
at all. The manager of developers should control developers. Designers
should drive the design process from concept to prototype. That's a matter
of vision, focus and priorities more than anything else.

Ziya
Nullius in Verba

Syndicate content Get the feed