Do Engineers Understand UX documents? (was "Alan Cooper on Software...")

31 Oct 2007 - 8:16am
7 years ago
17 replies
986 reads
Christopher Fahey
2005

On Oct 30, 2007, at 4:23 PM, Rich Rogan wrote:
> Cooper states "engineers don't know/ can't follow design", ID
> design in
> particular.

This also struck me when I read the article -- the implication that
engineers don't "get" UXD documents. Others have repeated this in
this thread as well.

This, too, I disagree with. In fact, I have consistently found
exactly the opposite to be true.

A high-fidelity wireframe or UI design specification makes the
engineer's job *way* easier in terms of delivering exactly what the
business and user requires. They are short and sweet. They are
visual. The readability and understandability of UI specs (especially
compared to old-school functional specs) are usually crystal clear:
"See this? Build it." If what they build doesn't match what our docs
say, then they built it wrong. How hard is that?

Many engineers have, when working with a firm like mine for the first
time, thought of our UI specs as a godsend. They see it as a radical
improvement in the whole software engineering process, because it
leaves so little to guesswork or ad hoc filling in the gaps. They
know that senior management has signed off on the specs, that users
have seen them, that the UI design work has already been figured out.

Some, of course, see it as a turf encroachment because our documents
tend to leave little wiggle room for backing off from difficult
features, and they often require engineers to "push back" in places
where our easy-to-build wireframes require months of work to actually
build. They also sometimes risk curtailing engineering innovation by
leaving little wiggle room in the positive direction, too.

But I've never, ever heard that UXD documents are hard to understand!

In what ways do engineers find UXD documentation hard to follow?

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

>
> I don't think anyone writing in this thread feel Cooper is
> attacking ID,
> rather he seems to be rehashing very old "positive" concepts on ID,
> without
> considering massive advances the ID field has experienced in the
> past 10
> years +, (note without a doubt Mr Cooper can take credit for many
> advances).
>
>
> His comments seem very relevant if it were say, 1995, but it's 2007
> and
> there are more involved issues with design and development then
> development
> simply being ignorant of design.
> _____________________________________________________________
>
> Regarding Katie's comment:
>
> "It seems that you believe that there once was a tendency for
> builders to
> start building before the underlying work of the designer was in
> place, but
> that that no longer happens in today's good companies."
>
>
>
> My point of what troubles IxDA designers, and me in particular, was
> a little
> more nuanced then either above black and white statements. The main
> issues I
> deal with today are not when engineers don't know or can't follow
> ID design,
> but rather when there are many factors in the mix, which necessitate
> multi-facteted solutions rather then "all would be good if
> engineers just
> "got" design".
>
> What are some of these factors, Katie does a decent job listing a
> few, such
> as "time constraints", "resource constraints", "engineers design
> limitations", etc.
>
> This list goes on and on. Add in lots of business problems that
> might come
> up, these are the issues I deal with every day and need solutions
> to, as
> well as engineers that "get it", "don't get it", "don't want to get
> it", and
> "are trying to compete to get it".
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help

Comments

31 Oct 2007 - 8:58am
Janna DeVylder
2006

On 10/31/07, Christopher Fahey <chris.fahey at behaviordesign.com> wrote:
>
>
> Some, of course, see it as a turf encroachment because our documents
> tend to leave little wiggle room for backing off from difficult
> features, and they often require engineers to "push back" in places
> where our easy-to-build wireframes require months of work to actually
> build. They also sometimes risk curtailing engineering innovation by
> leaving little wiggle room in the positive direction, too.

At the end of the day, we need to be thinking of the consumers of our
documentation. If engineers, UI teams, or business folks don't *get* our
documentation, why are we creating it?

Another thing I'd add is that while we may be the owners of our documents, I
feel we should be consulting with engineers, design, product, business,
etc., during document creation as much as possible. Let expertise reign
where appropriate.

janna

31 Oct 2007 - 9:40am
Josh
2006

The question of whether or not engineers understand interaction design
is interesting in that it seems to be putting the responsibility of
understanding on the engineers. In my opinion, it's not the engineers
fault if they don't get it. It's the interaction designers duty to
communicate the interaction. If the engineers don't "get it" the
interaction designer needs to to a better job.

Oh yea and if the "final" interaction docs and specs are the first
thing the engineers see then it's wonder they don't all go on strike
and leave us with nice specs and wireframes but no software.

- Josh Viney
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

31 Oct 2007 - 10:44am
Joseph Selbie
2007

"Another thing I'd add is that while we may be the owners of our documents,
I
feel we should be consulting with engineers, design, product, business,
etc., during document creation as much as possible. Let expertise reign
where appropriate."

Janna,

I couldn't agree more. If the programmers can't understand our final
deliverables I feel that our process has failed. I am happy to say that we
almost never have significant problems in this regard. Our success comes
from insisting that the programmers who will be responsible for building the
application we design are represented in the design process from the
beginning. We insist on participation in workshops, iterative approval
processes and rough prototypes. By the time we finish our process the
programming team usually knows and understands the design as fully as we do
(maybe not quite as fully but close).

Designing software apart from programmer input and participation is, in my
experience, asking for trouble. 1.) What you design may not be able to be
built -- period. 2.) Programmers may have tremendous resistance to the
design (which could have been overcome if they were included in the design
process). 3.) The design is accepted but suffers the death of a thousand
cuts as many "little" changes are deemed necessary during the build process.

In my experience, methodical collaboration with the right mix of roles
creates a shared, holistic understanding of the project that no amount of
exactitude in design deliverables can ever achieve on its own.

Joseph Selbie
Founder, CEO Tristream
Web Application Design
http://www.tristream.com

31 Oct 2007 - 1:09pm
Dave Malouf
2005

I have found that the only true artifact a developer understands is
coded interactive prototype. W/o one there is always ambiguity left
for "cultural" interpretation.

But I do think there is a difference between "understanding" and
"valuing".

for example in our current studio I was sitting with an industrial
designer who said something that I say everyday. Basically, "I hate
working with engineers." Yup, its horrible, but true, but in many
cultural environments there is a real problem in the sub-position
that states that he who builds or he who buys has the final say. Now
the latter one I get, though it doesn't promote a very good
collaborative environment. But heck there are business run (bottom
line) run companies out there that are a pain to work for for both
designer and engineer (my previous employer for example.) But there
is also that case where engineers in many design environments take
the point of view of design as "suggestion" and they will build it
as they way.

This isn't about "understanding", but it is about "valuing". The
example my colleague was discussing was contrasting how an engineer
feels they can say, "I can't do that." and there should be no
further discussion about it, but when I designer says, "This is the
design," it means that this is a start for negotiation.

Blah!

Josh V. I disagree w/ you. Yes, in any 2-way relationship everyone is
responsible for communicating, but in every 2-way relationship
everyone is responsible for being respectful and being engaged. To me
we have our burden, but they have theirs as well.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22000

1 Nov 2007 - 8:39am
Parth Upadhye
2007

Facilitating discussion is what I would like to happen in F2F events
here in Toronto. Well, the first one did not quite become a F2F,
we'll try again :)
Referring to the departmental conflicts ... teamwork and ownership
gets foggy and lost whenever groups get beyond a certain number (I
don't know this magic number). So even in a team of two or three
(very crucial for larger groups), ownership and flat-playing field
HAS to be encouraged. Just like this discussion forum, engineers,
designers, and MBAs and whoever else or whatever the title have to be
EQUAL. Human beings have a super propensity for hierarchy and worse
politics. hierarchy get work done, but politics makes it mediocre.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22000

1 Nov 2007 - 9:52am
jrrogan
2005

Dumping Agile in the mix...

My overwhelming experience has been that regardless of what design
deliverable ID's creates, having proximity, dialogue and iteration with
various stakeholders, during the design cycles is the key to success.

Throwing design deliverables "over the wall", regardless of how great these
deliverables are tends to lead to disaster.

These collaborative, proximal and iterative aspects of Agile processes aides
design as well as development, I think it would probably aide the design of
most things period.

Rich

1 Nov 2007 - 10:16am
Christopher Fahey
2005

Lots of good answers here... but so far not one person has said that,
in their experience, engineers don't understand UXD documentation.
David's distinction between "value" and "understand" is good: do
engineers understand our documents but still dislike them?

This is what I really wanted to know, because, again, in my
experience the opposite -- that they totally "get" and greatly
appreciate our documentation -- is decidedly true.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

1 Nov 2007 - 10:45am
Dan Brown
2004

I can't help but plug my book here, Communicating Design. It covers 10
different UX documents, and is written in part from the perspective
mentioned earlier in this thread: we need to apply user-centered
design techniques to our own artifacts.

More info at: www.communicatingdesign.com

We now return you to our regularly scheduled discussion...

-- Dan

On 11/1/07, Christopher Fahey <chris.fahey at behaviordesign.com> wrote:
> Lots of good answers here... but so far not one person has said that,
> in their experience, engineers don't understand UXD documentation.
> David's distinction between "value" and "understand" is good: do
> engineers understand our documents but still dislike them?
>
> This is what I really wanted to know, because, again, in my
> experience the opposite -- that they totally "get" and greatly
> appreciate our documentation -- is decidedly true.
>
> -Cf
>
> Christopher Fahey
> ____________________________
> Behavior
> biz: http://www.behaviordesign.com
> me: http://www.graphpaper.com
>
>
>
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help
>

--
| work: eightshapes.com
| book: communicatingdesign.com
| blog: greenonions.com
| talk: +1 (301) 801-4850

1 Nov 2007 - 10:49am
Joseph Selbie
2007

Christopher,

My previous answer to your question was that getting the engineers to
participate in the design process was essential to them "getting" the
essence of the project -- a holistic understanding without which they may
easily stray during the development phase. To answer your question more
pointedly, I'd say that engineers will "get" many types of documentation
(perhaps all types) as long as they have participated in the process that
led to the documentation. But if they don't participate, no particular
documentation type will insure that they "get" it.

Joseph Selbie
Founder, CEO Tristream
Web Application Design
http://www.tristream.com

Lots of good answers here... but so far not one person has said that,
in their experience, engineers don't understand UXD documentation.
David's distinction between "value" and "understand" is good: do
engineers understand our documents but still dislike them?

This is what I really wanted to know, because, again, in my
experience the opposite -- that they totally "get" and greatly
appreciate our documentation -- is decidedly true.

-Cf

Christopher Fahey

1 Nov 2007 - 12:22pm
Matt Nish-Lapidus
2007

Agreed! Anybody, developers or otherwise, will better understand the
project if involved to some degree at each stage. "Throwing over the
wall" never works, in any circumstance. At my office, a medium
agency, we build project teams and try to keep all team member
involved from the very beginning. Not only does that help each person
understand their role, but sometimes great ideas come from people you
wouldn't think of as "creative."

Sorry, I know this veers off topic a little. In the end,
developers/engineers will always better understand the design
requirements if they're involved in creating them.

The other side to this is the idea that developers are inherently
different than designers, which I think is false. Each person has a
specialized skill, but on a good team there should be a certain amount
of skill overlap. If the developer has an interest in design then
he/she will take more care to follow the design while deving the
interface.

Matt.

On 11/1/07, Joseph Selbie <jselbie at tristream.com> wrote:
> Christopher,
>
> My previous answer to your question was that getting the engineers to
> participate in the design process was essential to them "getting" the
> essence of the project -- a holistic understanding without which they may
> easily stray during the development phase. To answer your question more
> pointedly, I'd say that engineers will "get" many types of documentation
> (perhaps all types) as long as they have participated in the process that
> led to the documentation. But if they don't participate, no particular
> documentation type will insure that they "get" it.
>
> Joseph Selbie
> Founder, CEO Tristream
> Web Application Design
> http://www.tristream.com
>
>
> Lots of good answers here... but so far not one person has said that,
> in their experience, engineers don't understand UXD documentation.
> David's distinction between "value" and "understand" is good: do
> engineers understand our documents but still dislike them?
>
> This is what I really wanted to know, because, again, in my
> experience the opposite -- that they totally "get" and greatly
> appreciate our documentation -- is decidedly true.
>
> -Cf
>
> Christopher Fahey

--
Matt Nish-Lapidus
email/gtalk: mattnl at gmail.com
++
LinkedIn: http://www.linkedin.com/in/mattnl
Home: http://www.nishlapidus.com

1 Nov 2007 - 12:49pm
Todd Warfel
2003

I think part of this is driven by the quality of the artifact itself.
We've actually done usability testing on our artifacts with the
engineers and visual designers using them to find out how we can
improve them. After all, our artifacts are the product/service we're
creating for our clients, just like their hardware/software/service is
the thing they're producing for their customers.

On Nov 1, 2007, at 12:16 PM, Christopher Fahey wrote:

> This is what I really wanted to know, because, again, in my
> experience the opposite -- that they totally "get" and greatly
> appreciate our documentation -- is decidedly true.

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
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

2 Nov 2007 - 3:56am
Bruno Figueiredo
2007

I think that we need several things so that the documentation we
produce is fully understood by our fellow engineers. I'm an
architect by education so please bear with my analogies.

1) We need a standardized visual language so that whenever we change
jobs we don't need to learn yet another way to document things.
Architects have their own visual language and it's consistent from
the US to Japan. Any engineer or builder can pick up an architect's
drawing and start building straight-away.

2) We need interactive prototypes for more complex interactions. Even
with a nice set of blueprints, without a cardboard or 3d model no one
would understand how to build a Frank Gehry building. It's just too
complex just for blueprints.

3) We need a clear set of standardized and simple deliverables. A
blueprint has most of what anyone needs to know about a particular
floor in a building. It has links to other drawings as well. But
everything lies mostly on one page. Sometimes UX documentation is
just too scattered (interaction guidelines, wireframes, detailed
object interactions). Put yourself on an engineers shoes. Would you
bother going through a pile of documents just to build the simplest
of things? That's why most of what engineers build upon what we
deliver them is so off on the first iteration.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22000

2 Nov 2007 - 8:41am
Joseph Selbie
2007

I love analogies between architecture and IX. I think there are many
similarities, but there are some significant differences that tend to work
against your point:

3) We need a clear set of standardized and simple deliverables. A
blueprint has most of what anyone needs to know about a particular
floor in a building. It has links to other drawings as well. But
everything lies mostly on one page. Sometimes UX documentation is
just too scattered (interaction guidelines, wireframes, detailed
object interactions). Put yourself on an engineers shoes. Would you
bother going through a pile of documents just to build the simplest
of things? That's why most of what engineers build upon what we
deliver them is so off on the first iteration.

Architecture is 3D and lends itself to diagrammatic representation. IX
design, in my opinion is 4D. The fourth dimension is time. Interactions are
by their very nature a series of events that take place on the time axis.
Representing the interactions that take place in time in a primary document
has always been a challenge -- thus story boards, annotations, prototypes,
etc. are necessary to communicate (at times poorly) the dynamic elements of
the project.

I would love to see standardization also, but I don't expect it soon.
Architecture has had 5 millennia to evolve some standards, software has had
5 decades :).

Joseph Selbie
Founder, CEO Tristream
Web Application Design
http://www.tristream.com

2 Nov 2007 - 9:07am
Bruno Figueiredo
2007

As Bruno Zevi once wrote, Architecture is indeed 4D. You can't
develop your perception of a building without walking through it.
That's the 4th dimension and why 3D walkthroughs are so popular.

Yes, architecture had a lot of time to develop standards, but mankind
as produced more information on the last decade than all of the
previous centuries combined. To achieve standardization we have to
communicate, and communication is as easy as ever.

What we have to do is to take clues from existing 4D representations.
And build upon what each one of us had to develop for our own
projects. If we managed to come up with solutions for our problems by
ourselves, just imagine what we could do together.

Jesse James Garret already started this whit a basic set of visual
representations. We just have to improve upon it.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22000

2 Nov 2007 - 11:15am
Joseph Selbie
2007

Bruno,

I too am hopeful that it won't take 5000 years to develop standards for IX
design :).

I just don't think it is simply a matter of agreeing on *existing*
standards. What we are designing is rapidly evolving, which is requiring an
equally rapid evolution of the tools we use to design. I can imagine a day
in the not too distant future where we have one type of design tool that
outputs any kind of documentation -- one to many, not many to one. If you
want to see the design as a working prototype it could give it to you -- in
any of a variety of standards. If you want to see the design as a series of
schematic drawings it could give it to you -- in any of a variety of
standards. We see glimpses of this kind of tool in some of the
interoperations between programs such as Photoshop and Dreamweaver or
Fireworks and Flash -- but these are just the beginning. Someday we'll have
our version of AutoCAD Inventor.

As to architecture being 4D, I think this is a bit disingenuous. Everything
is in fact 4D. The universe we inhabit is 4D. And of course any design
process, architecture or any other, necessarily requires an awareness of
this reality. But an architect only needs to take into account the *fact*
that people will interact with the building. With IXD it is necessary to
*design* the way people can interact with an application, or website, or OS
with a moment by moment, click by click level of detail and accuracy.

I'm sure one can make a case that people interact with buildings. But I
think it is also fair to say that nearly all of those interactions are
commonly understood and accepted. The interactions that we in our profession
are designing are often completely new, and cannot rely on accepted
understanding to be communicated -- thus the need for the current complexity
of design documentation.

Joseph Selbie
Founder, CEO Tristream
Web Application Design
http://www.tristream.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Bruno
Figueiredo
Sent: Friday, November 02, 2007 8:08 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Do Engineers Understand UX documents? (was "Alan
Cooper on Software...")

As Bruno Zevi once wrote, Architecture is indeed 4D. You can't
develop your perception of a building without walking through it.
That's the 4th dimension and why 3D walkthroughs are so popular.

Yes, architecture had a lot of time to develop standards, but mankind
as produced more information on the last decade than all of the
previous centuries combined. To achieve standardization we have to
communicate, and communication is as easy as ever.

What we have to do is to take clues from existing 4D representations.
And build upon what each one of us had to develop for our own
projects. If we managed to come up with solutions for our problems by
ourselves, just imagine what we could do together.

Jesse James Garret already started this whit a basic set of visual
representations. We just have to improve upon it.

2 Nov 2007 - 10:13am
Daniel Yang
2007

Due to this thread, I decided to just directly ask the developers I
work with what they thought. Since I work so closely with them daily,
if there's a doubt or question they just ask me. I realize that in
larger organizations, there is more isolation between groups so the
documents have to speak for themselves. Thus I also asked my developer
friend at Yahoo for that perspective. For the most part, annotated
wireframes, concise written explanations, and a complete set of visual
designs is sufficient for most things. Unless the interaction is
completely new or unusual, the (good) developers know how to build
common UI elements (think typical suburban home vs. Gehry building).

However, I did find that one developer preferred if everything was
spelled out in a sort of a tech. spec list fashion (hex colors, fonts
sizes, dimensions) for the visual stuff. While another preferred to
ignore those indications and go into the PSD files and measure it
himself. The reason for the latter being that the direct translation
of those specs aren't perfect when implemented in code, so he is doing
a semantic translation. This is probably why it's important to have
all of these different document forms saying the same thing
differently. Different developers work in different ways just like
everybody else. As long as the end results are what I planned, I don't
really care too much about their particular process for getting there.

FYI, I export all my spec docs to Wiki-style HTML after writing them
in VoodooPad. I try to indicate whenever things are being shared
between web pages so the developer doesn't start building the same
thing twice. I also try to include as many "See: [link]" and other
crosslinks so the developers don't have to poke around the document to
find relevant information. It's all in one huge document with links
from page to related page.

I'll continue to do my informal interviewing of developers and report
if I find anything interesting.

-Dan

On Nov 2, 2007, at 2:56 AM, Bruno Figueiredo wrote:

> 1) We need a standardized visual language so that whenever we change
> jobs we don't need to learn yet another way to document things.
> Architects have their own visual language and it's consistent from
> the US to Japan. Any engineer or builder can pick up an architect's
> drawing and start building straight-away.

5 Dec 2007 - 12:08pm
Pedro Neves
2007

Yes in fact the D's are more than 3 and everywhere, and Architecture
as IX are part of the same global project in direction of a better
world, let's have standards so they can be broken.

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

Syndicate content Get the feed