Ryan Ripley 04 Apr 06
I can’t think of anything more “risk mitigating” than a working prototype. Ruby …point forward your conversations with the client changes from haggling over bulletpoints to discussing the features that are right in front of their faces…Seems much safer that way to me…

Wilson Miner 04 Apr 06
What I realized was that most of the documentation that I assumed was required for a project was just a replacement for good communication. If I do my homework, do the work and keep the client updated on the project (with actual designs instead of documents about designs) things move faster and everybody ends up happier.

R. Marie Cox 04 Apr 06
What it boils down to is that there’s more risk in believing you can document every single detail of an application in one fell-swoop before you’ve written a single line of code than there is in understanding that issues will materialize, preparing yourself to handle them for when they do and getting started soon enough so you have more time dedicated to the actual development in order to correct them as early on in the project as possible.

� On Veen/Google Getting Real?

Dan Saffer 05 Apr 06
Unlike many firms, we don’t have a set process that we put all projects through. We figure out what tools work best for a particular project and use them…There’s a simple reason why we do documentation: we don’t always build what we design, so the organizations and developers we work with need to know what the design is and how it works. And often why we made the choices we did. This delivers value for our clients.

Jeffrey Veen 05 Apr 06
I still do a tremendous amount of sketching, writing, and diagraming in my work, but the level of detail required to obsessively illustrate ever possible state an Ajax interaction can take is beyond my stunted attention span…If “Getting Real” means collaborating and communicating in the most effective way makes sense for a team in context, then I guess I’m all for it. But if the definition includes “documentation is for suckers” then I’d agree that it might be a bit shallow.

JF 05 Apr 06
Big teams, lots of paperwork, and layers of process should be the exception, not the norm. 80% of the people are building much simpler sites, projects, and products. So we’re advocating a system for those folks that let’s them dive in and start building real stuff now instead of when the ink dries later.

� On Good stuff to hear/watch

RS 06 Apr 06
I loved this bit from Godin’s talk:

“I don’t think people surf the web. I think this whole idea of surfing the web is a little bit of a fraud. Cuz when you surf you’re effortlessly — if you’re good at it — effortlessly going from side to side and thing to thing. That’s not what people really do. What they do is they poke. They poke around a lot.”

� On Three diagrams

Mark Gallagher 06 Apr 06
Scott Adams totally nailed the value of all flow charts (and consultants) in this old cartoon.

� On Fly on the Wall: “too many Web developers are swatting flies with bulldozers”

SU 07 Apr 06
To truly affect change, you need to start with the business people — the problems with online banking run far deeper than design. The real win would be to get buy-in high up within these businesses that design means more than styling — that design must be involved when the banks first decide how they will put their business online. All too often, designers are consulted after those decisions have been made.

Jared White 07 Apr 06
There are two bank UIs I actually like now. Chase is the best — their credit card/mortgage site was recently redesigned, and I love it. It’s beautiful, dead simple to read, easy to navigate, and fast. Wells Fargo is easy to navigate as well, but the graphics design is rather dull, and it’s slower. But still pretty good. And both of them work perfectly fine in Safari. (I’ll never do business with anyone that doesn’t support Safari.)