Re: Design specs (Was: Design Methodology for GU I

30 Jul 2004 - 4:22am
515 reads
Narey, Kevin
2004

Interesting views. My 2p's worth...

I find it useful and productive to produce ui design
specifications/conceptual models written with 'qualification' of design
decisions. This is often an annotation of a screen layout which makes it's
way into a use-case down the line. What this tends to do is assure the
developers (naturally more receptive to factual logic rather than heuristic
logic) that decisions haven't been made on a 'because I said so' basis and
is a good way of communicating work flow and look and feel decisions in
context to each-other. No different from what's been mentioned before really
other than we call it 'qualification' as it's a little more neutral than
'justification'.

IMO most of this stuff is usually about gaining respect from your peers -
all of which involves too many environmental variables to become
standardised. However, I think that once the engineers (who generally aren't
paid to consider aesthetics or user-interaction choices) saw the value a
more aesthetic approach brought to their designs, they were more than happy
to accommodate usability considerations into projects. Nothing you haven't
heard before I'm afraid.

Kind regards

KN

-----Original Message-----
From: Martyn Jones BSc [mailto:martyn at kode.co.uk]
Sent: 30 July 2004 10:44
To: 'Jim Drew'; discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Re: Design specs (Was: Design Methodology for
GUI

>>Does every single interaction point have to have an explanation as to why
it's appropriate?

At present, working for a small company, I sometimes wear an Engineer's hat,
other times I focus more on best practices and storyboarding usability.
These comments might be slightly biased, as I am an Engineer first, and UI /
Usability Designer second.

When I'm playing the part of Programmer on our more complex projects, and am
not involved in the initial prototypes - I do like to see a justification
for design. More often than not, I have this justification - not through a
formal document, but because I am involved throughout the lifecycle of a
project. During initial brainstorming sessions, I can throw my concerns and
recommendations in. Those responsible for UI / Usability Design (if not
myself) can 'defend' / explain their reasoning. Most importantly I think
it's because I have a greater sense of involvement, that I am more content
to implement the design (not totally happy with this statement - don't want
to make it sound like I'll throw my toys if I'm not involved - had a better
stab at explaining it below :) ).

In cases where we work with an external design team, and I am asked to just
be a 'code-monkey' and implement - I have all sorts of issues. Entering the
project in the middle of it's development cycle, without any explanation for
why things are the way they are - I guess makes me feel as though I'm not
being given much respect. As if my opinion doesn't count. I imagine it's
mainly a physiological issue - one of power? That perhaps Engineers and
those involved in UI / Usability Design should sit at a similar level in the
'power' hierarchy of an organisation / project, but if the UI / Usability
Engineers are just dictating to the Engineers (without discussion between
the two parties), the Engineers probably feel 'power' is being taken away
from them (at least this is what I have felt, wearing my Engineer hat).

This is also part of an age old battle between techy people and arty
designers, and their possible lack of respect for each others disciplines.

For a handful of projects, we have been drafted in as the techy people for a
large localisation company. I think these projects worked particularly
well, as 'champions' from each discipline were involved throughout project
lifecycles (e.g. Chief Tester taking part in initial prototyping meetings).
I was then responsible for relaying suggestions / decisions / progress to my
development team. I think that when the time came to code, we all had a
better understanding of how / why / what to do.

Martyn

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Jim Drew
Sent: 29 July 2004 20:40
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Re: Design specs (Was: Design Methodology for GUI

Dave Collins <DCollins at phoenix-interactive.com> writes:

> >There's also the fact that, in practice, the spec and the product are
>>never the same. And further, a UI/usability/etc. spec is often even
>>further from the eventual reality; one of the developers I'm working
>>with on my current project said something to the effect of "The
>>Designer can put whatever he wants into the UI Spec, but what gets
>>into the product is ultimately my decision."
>>
>>(In this case, after UI spec review, he went to code the feature and
>>decided -- by fiat -- that some of what was spec'ed "didn't make
>>sense". So he changed it to what did make sense, and now we get to
>>fight about the usability implications of what he implemented rather
>>than what the team agreed on. Which isn't to say that he isn't
>>technically correct in his during-coding realizations. We'll see.)
>
>Not that this isn't obvious, but...
>This isn't your problem. This is a problem higher up. A supervisor has
>not made clear to everyone the roles and responsibilities (and the
>boundaries) involved, and the teamwork required.

I fear I made this sound more severe an issue than it actually is. I
don't consider the developer a primadonna, and the design wasn't
drastically change (it's probably 90%-plus intact; only a few of the
behaviors and appearances got thrashed on).

But you're right to identify that there are some chain of
command/communication issue here. By no means limited to the
particular event -- or even to this single project, or the company.
I have noticed an increase in lack of process, inadequate
communication, and fiefdom in many projects and companies over the
years.

(I would tend to target that mostly at the Tech Boom/Bust, which
encouraged some small teams to say "F-ck it, we'll do things our own
way!", and maybe mix in the current Tech Offshoring trend, which has
some people restricting openness in order to assure job security.)
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 07/20)
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Syndicate content Get the feed