I was talking to my friend Blondeau about the oddball glory of the Brompton foldable bike, and I found myself saying something that seems worth keeping:

The belief in absolute perfection — perfection without compromise — is the death of design. Design is the art of relative perfection — perfection within constraints for some limited purpose.

I intended to link Brompton to my description of how foldable bikes design always involves stark tradeoffs, optimized to some purpose, and sacrificing other desirable qualities, and how this constraint, precisely, is what makes foldable bike design beautiful. Except, it turns out I never posted on this subject. So I will dig through old emails and texts and try to patch together a post I should have written years ago.

I guess I’ll start with an email I wrote Blondeau.

One word of warning: If you get a Brompton, you’ll never be able to do without one again, especially if you’re living nomadically. Any Brompton-less bike stable will feel incomplete.

What sold me on Brompton was looking at the design problem different foldables tried to solve. Each optimizes for some purpose.

Some are all about easy shipping of mostly-normal bikes from one location to another. Set up and breakdown requires significant effort. Once the bicycle arrives at a location, you set it up, and leave it set up. The design is optimized solely for providing a conventional cycling experience, and ease and speed of folding and unfolding is sacrificed.

Brompton is designed for multimodal transportation. It breaks down and sets up in about 1 minute. The folding-unfolding is assumed to happens one or more times in the course of a trip. You set out for a train station on the Brompton. There you fold it down and carry it onto the train. When you arrive at your stop you unfold the Brompton and ride it to your hotel. There you fold it down again and take it up to your room. If you are Eurailing around the continent and want cycling to be part of how you get around, you cannot beat Brompton. They make all the right tradeoffs for that style of getting around, and I love that.

If you just want to have a bike with you in Spain and maybe other places you visit having a normal bike that folds might be better. You’ll get a smoother, more refined ride.

Brompton is pure quirk. 

Another design that made clear, decisive tradeoffs is the Mazda MX-5 Miata. The origin story of the Miata is one of clarity of vision and refusal to blur it in order to live up to the bland ideal of meeting the expectations of most people for most purposes. The product managers, designers and engineers behind that car sacrificed passenger and storage space and engine power for a very specific roadster driving experience. They knew exactly what the car was for, and what it was not for, and every decision was driven by that clarity.

Another beautiful story of tradeoffs was the development of the Palm Pilot. That team watched Sculley-era Apple try to brute-force design the first PDA (Personal Digital Assistant), the Apple Newton. The device tried to be a handheld computer that could do anything. Consequently it did nothing well. It was too big, so it did not fit in a pocket. It tried to recognize natural handwriting, but failed comically most of the time. It supported syncing with computers, but the process was similar to a data backup procedure. Palm optimized its device for data lookup. It assumed most data would be entered on a computer and synced to the device. They devised a clumsy but reliable text entry scheme called Graffiti instead of relying on immature handwriting recognition technology. Best of all, the device was tiny and pocketable. And it came with a syncing cradle that supported one-button sync. The product took off, despite being vastly less advanced that the doomed Apple Newton.

If you read these two case stories, you’ll notice crude prototypes play a central role in refinement of the product, but also in building alignment around the vision, and enthusiasm for that vision.

Funny. I’ve been watching videos and listening to audiobooks by product management guru, Marty Cagan. I’ve been thoroughly unimpressed. What he describes as a revolution is stuff we’ve been doing for the last 30 years in UX and Human Centered Design.

But today I’m wondering if the problem is that designers try to do this work from a position of weakness. Maybe when we do this work from a position of strength, and take responsibility not only for the user experience, but also the feasibility and viability of the product (all power entails responsibility!), we are no longer just designers. We become product managers.

I wonder if that is the profession I should have pursued? I love tools. I love beautiful, clearly-conceived, faithfully executed products. But this difficult work cannot be done by charm, influence and lobbying alone. It requires power.

Hmm.

(Now I’m thinking about the app reviews I’ve written over the last decade. The majority of them are addressed to the product management — usually bad — of the app, not the features or the design. I get angriest at the product management philosophy behind wrongheaded design decisions.)