Rony,
These are some books I've read or am currently reading that directly relate
to what you're about to get into.

   - For creating good forms and managing documentation:
   Robert Hoeckman Jr., *Designing the
Obvious*<http://www.amazon.com/Designing-Obvious-Common-Approach-Application/dp/032145345X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204245575&sr=8-1>
   - For taming office politics and keeping the product focused:
   Indi Young, *Mental
Models*<http://www.amazon.com/Mental-Models-Aligning-strategy-behavior/dp/1933820063/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204245607&sr=8-1>
   - For dealing with the difficult situations you're going to encounter
   if your IT team is grounded in green-screen apps:
   David Platt, *Why Software Sucks and What You Can Do About
It<http://www.amazon.com/Why-Software-Sucks-What-About/dp/0321466756/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204245668&sr=8-1>
   .*

That's a lot of reading, but I read Robert's book in a weekend. I haven't
even gotten through the first chapter of Indi Young's book but I've already
gotten enough of the concept (and I attended her virtual seminar last week)
that I intend to try it in my next project. David's book is comic relief
backed up by solid insight.

Personal lessons I've learned from doing several green-screen-to-web app
conversions for a big corporation:

1. RESEARCH.
This is when good people skills come in really handy. Find a couple of
people who are the end users, give them fair warning that you may be
spending LOTS of time with them, and then stick on 'em like a reality-show
camera crew. You don't always get the opportunity to do this, so if you've
got that chance, recognize it for the gold that it is. It's a great way to
get to know people.

2. User task flows rock.
These are the best way I've found for flushing out unexpected surprises and
getting a true screen count, which in turn helps you develop a realistic
project schedule. There have been times when I've skipped this step, and
I've always regretted it later.

3. Just because they're I.T. doesn't mean they know web.
Perhaps my first and biggest mistake. I came to the bank assuming that
financial green-screen IT guys would be able to do all the same stuff as
dotcom programmers. That doesn't mean there isn't a willingness to try, but
be prepared to deal with some serious management-of-expectation issues.

4. Do not be alarmed by white space.
You do not need to fill every inch of space in order to convince someone
they're getting their money's worth. Where I work, it's actually the
marketing and business teams that are the most guilty of this; user research
is the crucifix for this particular vampire.

5. Prototypes, baby.
People -includes programmers- are visual creatures, and prototypes visually
communicate goals better than a 300-page requirements doc. Also, conducting
usability sessions on clickable prototypes and recording those sessions with
Morae is a powerful method for fast, iterative design.

Hope this helps! Please let me know if I can help you in any other way.
-Gloria
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

Reply via email to