Pants. I put them on every weekday

 

I’d forgotten about the creative tradition of crits until I saw an article yesterday about How To Do Crits In Your Studio. I read it. I thought about it for a minute. And then I was irritated. 

 

For those who haven’t suffered through these monuments to head-up-your-own-ass pretense, crits (aka “critiques”) come out of the art school world. On a regular basis in almost every class, art students present their work to their peers and then suffer through interminable feedback sessions. This tradition has been perpetuated in the ad world. And, unfortunately, it malingers in the software design world. Some of the feedback is useless but well-intentioned. Some of it is pointless, self-indulgent pontification. Some of it is selfishlessly malicious. Some of it is thoughtful, relevant, and valuable. The quality of the feedback is a variable that can be controlled through training and is the focus of any discussion about doing “better” crits.

 

It doesn’t matter how well you do it. I think that it’s fundamentally the wrong paradigm. Crits are oriented around two basic assumptions: 1) there is an “artist” who is the singular owner and executor of an artist vision whose work may be improved by feedback from an external group and 2) artistic quality is an inherent good to be pursued. These are both flawed assumptions for software. 

 

The designer as artiste model is how you wind up with people tossing work over the wall. It’s a terrible model of working and results in broken processes, disrupted workflows, and bad (but sometimes uselessly pretty) user experiences. And intolerable fights over ownership. The power dynamic of crits structurally reinforces this unhealthy model. Moreover, the crit model is inherently teleological; it’s iteratively working towards some ultimate, refined end expression of the artist’s vision. What we should be doing is making highly usable software and then moving on. Does a design solve the users’ problems? Does it meet the business’s needs? Is it implementable by engineering? My goal is to exceed a threshold, not to achieve an end state. 

 

Feedback is useful. But there’s a bunch of different kinds of feedback for different purposes. I highly encourage designers to do ad hoc 1×1 show and tells with one another to get a new set of eyes on work. There are process-based ways of getting engineering’s feedback on feasibility like presenting designs in backlog grooming or in specific engineering+design reviews. Sometimes management needs eyes on things as part of a process. Sometimes workshops are a good way to get a group of designers working together on a problem. I prefer almost anything to the vainglorious auto-da-fé of a crit.