Interface Design - who does it?

[Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>]

Ruth, sorry for my slow reply.

> My company is in the process of defining development team roles for
> our upcoming project. . . some of the roles we've identified include:

We use similar roles (though I'm not sure what an Abstractionist does).

> My suspicion is that a number of technical writers participate to
> some degree in interface development.

Yep, that's me.

> What activities do they (UI designers) participate in? (usability
> testing, rapid prototyping?) What special skill set do they need?
> (human factors experience, design skills?) What are their
> deliverables? (the interface, etc.?)

All of these, plus:

- develop a style guide
- review prototypes (before any testing on other people)

. . .but the most important, I think, is:

- lead the team that develops the initial design, *before* any coding
  begins.

I just spent a few days reviewing three development projects. It became
frustratingly clear that you can't make great improvements half-way
through. Most of our discussions were about putting bandaids on problems
where radical surgery was called for. The sort of questions I put to the
developers -- who uses this? why? what do they already know? what do
they need to know? -- really needed to be asked at the beginning of the
project. Well begun is half done, as the old saying goes.

I suggest you pick a UI design *team* led by your UI designer, and
including the tech writer, a customer support person, and a developer.
Get them together to sketch out an initial design on paper.

> (BTW, we have a very technically oriented product architect here who
> believes he is best suited for this role.  I, however, maintain that
> someone with a more user-centered perspective is better suited - e.g.
> technical writer. Your thoughts?)

Aarrgh. In my wonderfully tactless way, I once told the senior developer/
architect here that he and his partner were the *least* qualified people
to design the UI. It's not that they are deficient in this area. In fact,
they're about as well-qualified as programmers can be. They're extremely
gifted at programming and program design, have experience in the subject
matter area, and are annoyingly smarter than me. Don't tell them I said
all this.

The problem is that good design and good implementation serve different
masters. The design should put the user at the centre. Developers, by
the nature of their job, have to put the software at the centre. When
compromises have to be made during the implementation, who is best
placed to decide? A design team, weighing up resources against users'
needs? Or a frustrated programmer facing up to a deadline?

We don't ask police during a siege to draft new laws.

Finally, Eric Haddock <eric -at- ENGAGENET -dot- COM> said:

> If the interface is truly user-friendly, than anyone should be able
> to walk up and start using the product.

I don't agree. What you're describing is not user-friendly, but person-
on-the-street-friendly. (Unless your users are traffic cops, street kids
and prostitutes ;^)

Just as you can't optimise file-compression utilities for both size AND
speed, I don't believe you can optimise an interface for beginners *and*
intermediate users *and* experts. You can look after all users, but you
can only optimise for one group. You have to choose, based on your
knowledge of your market.

If Adobe designs FrameMaker 6 to make it work marvellously for people
who don't know DTP, I'll be shopping for a new product.

> 1. Knowledge of user level
> 2. Knowledge of how the product will actually be used, as opposed to its
>    intended design

This is more like it.

Regards
---
Stuart Burnfield (slb -at- fs -dot- com -dot- au)        Voice: +61 9 328 8288
Functional Software Pty Ltd             Fax:   +61 9 328 8616

     Searchable archives located at http://www.documentation.com/
           ALL questions or problems concerning the list
      should go to the listowner, Eric Ray at ejray -at- ionet -dot- net -dot-