[Sigia-l] 'Process+Tools+Guidelines' to do the right thing!

[Listera]

"prai at prady.com" wrote:

> I am in the middle of discussion with Engineering team at my new employer
> and the issue is arround following -

Ouch. I don't envy your position. Once fundamentalism (in the guise of a
specific technology, product or method) enters a company, it's pretty hard
to get reformation going.

The first thing you have to do is to change the terms of the argument.

1.  Decouple the prototype from the actual developmental model. As long as
the developers define the prototype as an adjunct process internal to them,
you've already lost the battle, you'll have to follow their lead.

2.  The prototype should demonstrate *functionality*, nothing more nothing
less. It should *not* be a functional model for development. As long as the
prototype communicates the intended functionality, user experience,
workflow, etc., it has fulfilled 100% of its mission.

3.  The prototype is *not* for the sole benefit of developers. Its scope
includes all stakeholders: management, key clients and even some users,
because they'll all make decisions/contributions via the prototype long
before any development can/should start.

4.  If you can, do the prototype with technology *different* from what the
actual product will use in order to dispel the notion that it's part of
development.

5.  You are not there to do the developers' job. The fact that the prototype
might help (at the code-level) any part of the development process should be
coincidental, not a prerequisite.

6.  You should create the prototype in whatever format you feel comfortable
with and the developers should then create their development model and code
based on it in whatever framework/language/platform they feel comfortable
with. If the two intersect, that's OK. But it should not be the goal.

7.  If the entire process of prototyping, documentation and discussion on
prototyping, documentation, methodology, etc., is taking up more time than
the actual UI design, you already know something is wrong. (In large
projects with one group or another taking a fundamentalist position, this is
often the case.)

8.  Don't get fixated on specific technology/product. Don't let others drag
you into it either. "UI design" was around long before RUP and it'll surely
survive it.

9.  What authoring tool to use should be left to those who will use it. If
they feel they have to use FrontPage (shrug) let'em use it. If they are not
the ones doing the HTML markup, they shouldn't care what authoring tool
generates it, as long as it's clean, valid markup.

10. Get everyone to understand what's important: the product and how it
serves the users. Anything else should be subservient. No one will care what
authoring tool/language/methodology was used; the user gets to experience
only the final product. So think of the process as reverse engineering that
final goal, hopefully, without letting specific products
distorting/derailing it.

The archives of this list alone is full of tales of developers dictating
terms and affecting the final product, essentially by intimidating the rest
of the team since they are the ones who will ultimately code the final
product. As an IA (or UX/ID) without technical knowledge, you may be at
their mercy. You can argue up to a point but as you're playing on their
terms you're most likely to lose the battle. That's why it's so important to
decouple the prototype from development.

Now, up to this point I seemed to have argued against developers. Since I've
been a designer and developer for well over a decade, I can see both sides
of the issue. And I can easily argue against some of the untenable issues
created by the front-end architects/designers/modelers who are clueless
about the technical ramifications of their specs. So it cuts both ways.

Finally, if anyone tells you UI design is a "science" and they have the
ultimate formula, run.

Ziya
Nullius in Verba