When I read this title, the first thing I thought was, "Oh no, another poser telling the rest of us what to do based on what they <i>think</i>".<p>Boy was I wrong about that.  This is an excellent post that could have only been written by someone who has suffered in the trenches and knows what he's talking about.<p>Many of his points:<p><pre><code>  2. Get in bed with the business people 
  3. Ease their pain
  5. No one gives a rip what the artist thinks
  6. You get to control those lovely details
  7. Write it down, write it down, write it down
  8. Get in bed with the QA team
  9. You have to have a middle man
  10. Proximity breeds understanding
  11. Learn to articulate well
</code></pre>
emphasize that the people part of the process is just as important as the technical part.  This is easy to overlook and we need to be reminded every once in a while.  The main reason we do what we do is not because it's cool (it is), we do it for and with other people.<p>The only point I challenge is "4. Force business to iterate in design, not in development."  This is perplexing because it runs counter to most of his other points.  The reason people tend to iterate in development instead of design is because it's much easier.  They're not sure what they want, but once they see something, they know what they like and don't like about it.  I'd alter #4 to something like, "Learn to prototype well, so everyone is equally comfortable iterating toward the most desirable outcome."