AndyToo 05 Apr 06

Surely it could just be that Veen has experienced the same pain as 37s and come up with the same answer? (rather than ‘Veen is a GR aficionado’)

Des Traynor 05 Apr 06

To be fair AndyToo, I don’t think that Jason meant Jeff had bought the book and was now a convert of the 37s way of life.

I think he was just saying “Here is another person who seems to have arrived at our way of thinking, as a result of trying to do things other ways and seeing the problems”

Jeff Croft 05 Apr 06

Seems like a perfect excuse for another link to the “book” to me.

Chris 05 Apr 06

Jeff, Is it really that bad if they provide evidence for their philosophy? It is a good excuse to link to the book, because it shows that real value exists for it.

Randal "sw0rdfish" Santia 05 Apr 06

Is is unfair to think that a company isn’t allowed to market it’s own product on it’s own website? Jeff, you post anything positive around here?

Jonathan M 05 Apr 06

When you take a stance on an issue, any issue, there will be people ‘for’ and ‘against’ you. That’s just how human nature or the world works.

An ex-CEO of HP once reply to reporters that her fear was not not making a mistake but not making a decision. I am glad that 37s has decided to take a stance on something they feel passionate about, made it work, and share it with us. Although I am sure it is not entirely a ‘selfless’ act :-), I’ve personally gained great insights from it.

JM

Michal Migurski 05 Apr 06

*Sigh*

Apparently 20+ years of GUI interaction design history isn’t worth a whole lot. Extensive interaction documentation gets you Apple’s Human Interface Guidelines (http://tinyurl.com/vgge) and a largely self-consistent operating system. No documentation gets you Windows, where every application sets its own arbitrary standard.

Ajax is new for now. Expect to see the wild west flavor subside within a year or two, and guidelines such as Apple’s appear once the shine wears off and people get tired of having to re-learn form widgets for every site.

Dan Saffer 05 Apr 06

“The kings of formal process and documentation?” Please. Yes, we do wireframes. And sketches. And prototypes. And even the occasional mental model. But only when the project requires it. We don’t do them just to do them. 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.

What I’m guessing Jeff was noting was the difficulty in documenting Ajax applications, not that all documentation is useless. Documenting applications is something we’re all wrestling with, and we’ve experimented with alternate forms of presenting designs like storyboards, cartoons, and lo-fi animations. We need to figure out ways of demonstrating designs that work for all sorts of companies, not just those that are structured like 37signals.

BTW, AP is half women, so technically it would be kings and queens of process and documentation, were that true.

sean coon 05 Apr 06

c’mon, guys. take some of your own advise and get real.

jeff is now at google, the epitome of an anti-user research software design company (they’ve been “getting real” for a while now). rapid iteration is key to them, but from what i know of jeff, he’s a rather big proponent of modeling design personas and scenarios to generate interface requirements.

your quote deals with only the tactical, design communication process of IxD, something that is completely flexible based on organizational dependencies (team makeup)

if there are available programmers to prototype, documenting AJAX behaviors is absolutely a complete waste of time. but jeff said nothing about scrapping the user-centered method for uncovering the necessary interface scenarios to support via AJAX in the first place… or can i not read?

Anonymous Coward 05 Apr 06

Dan I remember Peterme saying that 37signals methods are “shallow” so it’s interesting to see Jeff Veen using some of the same methods 37signals uses.

Michal Migurski 05 Apr 06

AC, Peter said the “views and rhetoric” were shallow. There is a difference. ;)

Anonymous Coward 05 Apr 06

“Views” ? Meaning methods and ideas.

Dan Saffer 05 Apr 06

37signals has patented sketching?!? OMG!

Seriously, the reason Jeff (and 37signals) could work like this is because he was working with a small integrated team of designers and developers on a relatively small product. It’s a great way to work, and I’ve done it myself. It’s excellent for products with a small feature set (what 37signals advocates).

But in the world I live in, that’s not the only kind of product there is, nor is this small team structure the only kind of team structure there is, or should be. You can make beautiful houses with small teams, but to make skyscrapers or cathedrals, you need large teams, following a plan (documentation, in other words). You can make a Basecamp, a Flickr or a Measure Map with a small team. You can’t make a wellsfargo.com or a Yahoo (in its current incarnation) or an Amazon the same way. There are too many moving parts, too much data (both input and output) to be managed. And while you could argue that these sites shouldn’t exist or should only do one or two things, you’d be pissing in the wind. I want my banking site to be a robust platform that lets me do a lot of things with my money and my account.

Those things, those features, take time and effort (by people) to design and build. Each feature might have a small, 37signals-sized team on it. And that would be fine, of course, in the same way that there were specialists working on the stained glass at Notre Dame. But in general, the structure of a large, rich digital product like NYTimes.com cannot be created or maintained by a small team. The legal team alone at most financial services sites are probably larger than 37signals.

I’m just not ready to give up large, multi-use products just yet. Nor are the tens of millions of MySpace users either, apparently.

Jeffrey Veen 05 Apr 06

Well, the key point there was, as Dan pointed out, that I’ve been frustrated “trying to document Ajax interactions.” 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. Yes, Apple and others have done amazing work in documenting and developing complex interactions. More power to them - too Type A for me.

So, for example, when we were developing Measure Map, we would collaborate on these sort of interactions on the whiteboard. From there, I’d take them in to wireframes and work through the visual representation we’d begun collectively. And then (and this is important, so pay attention) I’d talk through how it worked in detail with whomever would be building it. We’d discuss every possible aspect of how it should work - clicks, timing, results, states - everything. In some organizations, people spend the time to write all this down. We were fortunate enough be small and quick, and none of us really had the patience. We just built it and iterated until it was right. Ironically, we did a lot of this over IM, so we did write it down, just one line at a time in synchronous communication.

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.

But like most things, I suspect the reality is a lot more nuanced than a catch-phrase can capture.

Arik 05 Apr 06

The current state of the development process is completely sluggish and fat. Getting Real is web development at the local Fitness center. I honestly believe getting real is a web-wide transition from projects that take months to complete to projects that take days or even hours to complete. Large firms with huge processes now have something to worry about. Getting Real is the anthem of little guys everywhere. A way of thinking that is acceptable and retains that professional shine.

Anonymous Coward 05 Apr 06

I don’t believe that 37s every suggested “documentation is for suckers.” I think they believe too much time spent up front on documentation isn’t time as well spent as it could be. They suggest that documentation is making assumptions that can’t be proven until you get real with it, so they suggest to get real with it at the start and test your theories all the time instead of testing them later.

Anonymous Coward 05 Apr 06

i think we all know the truth here… design firms only do all this extra stuff to pad their quotes. they don’t think clients will pay the big bucks unless they get a stack of paper, fancy diagrams, and long timelines. i’ve been on both sides, i know. seen it for years. it’s a shame, really. no wonder neither side trusts each other.

xian 05 Apr 06

If my bank’s account mgmt site was as disjointed and semi-useful as the 37s products I’ve tried I’d be looking for a different bank.

Solving your own problems for yourself is great, up to a point. It’s also a recipe for solipsism.

Don’t get me wrong, from what I can tell Basecamp is way better than a lot of PM stuff out there, but I’d rather use a decent wiki than Writeboard any day. Then again, Socialtext seems pretty agile to me, so maybe it’s not the size of the team but the attention span of the developers.

J 05 Apr 06

…but I�d rather use a decent wiki than Writeboard any day

Maybe that’s because you need a wiki. Writeboard isn’t a wiki. Socialtext is a wiki.

xian 05 Apr 06

Oh, right. It’s Basecamp that has the review quoted on the site calling it a “wiki without the wacky,” right?

And tadalist’s have no dates. If you want a to-do list with dates, then please do use a to-do list with dates.

etc.

xian 05 Apr 06

my bad, it’s Backpack… But if you want pockets, get a “real” backpack…

J 05 Apr 06

Someone sounds bitter now. True colors have come out.

xian 05 Apr 06

Not bitter! You guys rock. Just hoping you don’t subsist on your own kool-aid 24/7.

(Amused to see the reframing, though. To me wikis are more about collaborative writing than easy linking, but that’s cool.)

Anyway, I’ve taken your philosophy a step further and done away with computers and code entirely. (They are abstractions, after all!)

Jeff Croft 06 Apr 06

“Jeff, Is it really that bad if they provide evidence for their philosophy?”

Did I say it was bad? I don’t have a problem with it at all. I said it was a “perfect” reason to pimp the book, right?

“Jeff, you post anything positive around here?”

I used to. I’ll still be happy to when there is something positive that needs to be said. But this blog, which used to be one of the most interesting, informative, and insightful on the entire Internet, has become a semi-daily advertisment for 37signals. It’s their blog, so it’s absolutley their right to make it that, but it’s also my right to be negative about it. :)

I use and enjoy several of 37signals’ products as well as many components of their “philosophy,” so I have nothing but respect for what the guys have done. I just miss the great discussions of user experience, interface design, customer service, and business philosophy that used to go on here, that’s all.

Anonymous Coward 06 Apr 06

Jeff, when you put “book” in “quotes” you are being snarky. Don’t act like you don’t know that.

Jeff Croft 06 Apr 06

I’m not making any bones about the fact that I prefered the design-talk SvN to the “here’s why we’re cool” version. I’ve also not made any bones about the fact that, at least in my mind, compliling a group of blog posts into a PDF does not a book make (that having been said, it does make a perfectly reasonable product to package up and sell on your website — it’s just not a book).

I put quotes around “book” because I don’t really consider it to be a book. If that makes it snarky, then yes, it was snarky.

Dismissed 07 Apr 06

I am involved in designing interfaces for banking applications. You just can’t go that way, Jason. I understand your philosophy and I agree that for most applications small teams will do.

But a bank is so much more complicated. You have legacy issues. You just can’t switch the systems off and do it all over again. You have huge business requirements and you have to do things that are consistent with the bank’s image.

But you have lots of systems interweaved. And you have to think about all of them. You just can’t do it in a small team. It’s too complex. So there are a bunch of small teams there. You can work inside them with Getting Real techniques. But you have to produce documentation to communicate between them. There’s no way around it.

And what happened if we strictly followed the no documentation path? What if the people developing the product were gone for some reason? Nobody could follow their work. It’s like having an author’s edition of a book with a single copy? What happens to the knowledge there if it’s gone?

So I believe in documentation, but just enough to get the job done.

Dismissed 07 Apr 06

Yes, you are absolutely right about that. Indeed, I am fortunate enough to be the only person setting the guidelines for the UI for a bank with more than 5 million clients. What I meant is that I have to document what I do. I just can’t sit days on end with the programmers, the designers and the software architects tweaking it to shape. It’s simply not pratical.

So, I document it barely enough, Jason. I believe in what you said the other day about deliverables: deliver less, document less, but document.

Kevin Steele 03 May 06

I�m late to this. I used to create interfaces inprograms like HyperCard with very little orthodoxy (wireframes, ha!) to rely on, then I experienced the discovery of the need for process as my business scaled up. I loved making awesome design documents, but there was no substitute for prototyping when it came to interface design. Later I worked as a creative director in a couple of fairly mainstream web agency environments, including being involved on a number of banking projects.

I think it�s a bit ironic seeing smart people realize that the processes that evolved from the big suck that the early web was have little to do with making complex interactive experiences.

The early web was conveniently broken into pages by the technology. The units of the experience were predefined, and the units themselves were just simple collections of content and links. What power we could wield over such projects with awesome process and diagrams! Not just in the studio, but in the boardroom with our clients. And people could actually design a site in Photoshop (even though I think it is a terrible tool for such a task).

But the web does not break down into pages anymore. Often our biggest constraints now are CMS and other container systems built to automate the early web.

It�s no surprise that the best way to create experiences is different from the best ways we developed to create collections of linked pages. Personally, I am relieved that a lot of my preweb experiences are being validated and are relevant again.