What’s often lacking from open source design discussions is how something *doesn’t work* in aggregate — from an overall, comprehensive user experience perspective.

That’s where the difference lies — in holistically approaching the development of a product rather than just ebbing away at bugs with patches.

”Most people make the mistake of thinking design is what it looks like,” says Steve Jobs, Apple’s C.E.O. ”People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.’

http://www.nytimes.com/2003/11/30/magazine/30IPOD.html

I actually think the more substantial conflict lies around your use of “intuitive.”

On the subject of tool support, a non-code example: attorneys developing contracts relying heavily on MS Word’s “Track Changes” feature:

http://www.shaunakelly.com/word/trackchanges/HowTrackChangesWorks.html

which is basically diff.

Thanks for all the interesting questions. I wasn’t aware of Magic Ink, so I’ll be giving it a read.

Chris,

Yes, I agree that this is a very serious matter for peer produced work in many domains, not just software. I also agree that the design process cannot be done by a large group of people.

The example of languages was aimed at the question of whether or not open source communities could operate with some restrictions on who was doing the design. I do agree that the closeness of the developers to the users (in this case developers) makes that particular situation easy.

Despite the history of free and open source software, I still think that we have much more to learn than we have already learned. We definitely have not arrived yet.

Are there design equivalents? If you asked 10 designers, how many answers would you get?

Part of my frustration with being an “open source” advocate (as you said — whatever that means these days) is the lack of obvious examples for how open source makes end users’ lives better. Surely having a commodity operating system and browser are good things for the marketplace, but I would take OS X and Safari’s user experience (whether their intuitiveness, consistency or speed) over their open source counterparts any day. Does that make me a hypocrite or just pragmatic?

Given my training in design, I was never taught how to “open up” my design process — or to act, as Leisa Reichelt has done so masterfully in the Drupal community, as a facilitator of a *design process*. Instead, we were taught to do our own work, and to act as individual authors and artists — and not to work in teams. Or, if we did work in teams, there would always be someone responsible for the final design because any other approach would just end up inconsistent.

I think your example of programming languages actually reinforces my point, since I’m largely thinking about intuitive, visual experiences, rather than coding or text-based experiences. I also think that the further the distance is between developer and user, the more work you have to do to integrate design methodology into development processes, if only to infuse empathy and pathos.

I think WordPress is the one stand-out example where open source and design have meshed well together, but that again illustrates my point, since design is consolidated into the hands of a few who work at Automattic and have a mandate to steer the direction of the platform. Drupal 7 will be a curious product to watch — because after more than a year spent on its design — the question will be how it makes incremental improvements towards Drupal 8 with fewer resources (presuming, of course, that once 7 comes out, the design team will move on to other clients or responsibilities).

Anyway, this is a very serious matter for the success of “peer produced work”. As I see the government, in particular, releasing more and more data openly, the challenge will not be so much what to build on top of those resources, but how to make the mashups and applications that use that data serve the widest possible audience — and to my knowledge — the best way to achieve that is through the application of a humanist design methodology.

(2) The “source” in “open source”, executable code, has a special property: it is self-describing. Most design work product is incomplete; we call it a “mockup.” Interestingly, both the FB process Chris links to and the Apple design process address this. From FB: “Mockups lie.” From Apple (see http://www.pragmaticmarketing.com/publications/magazine/6/4/you_cant_innovate_like_apple): “Pixel-perfect mockups are critical. This is hard work and requires an enormous amount of time, but is necessary to give the complete feeling for the entire product.”

Successful open source code bases can start “incomplete” in the senses of “buggy” and “not covering all use cases”, but the code always self-describes perfectly. You know where you are and where you aren’t. Conversely, incomplete design work product “lies.” (Side point: how?)

(3) Hypothesis: to make design work product more like executable code, you need a mechanism to replace the confrontation with reality that happens when code is executed. You would have to step out of the art-school tradition where a rough sketch is seen as an intermediate step between blank page and finished work. Perhaps the traditions of architecture or small craftsmanship might provide starting points.

(4) Even if (3) is wrong, I am confident software design will never improve by relying on the visual culture that many self-identified designers come from. As much as we’ve all learned from Apple, I think the way their culture fails to distinguish between the proper use of fonts and the proper working of software as a mechanism holds us back.

(5) If you haven’t yet read Magic Ink, you should. Victor closes with an attempt to square the circle of graphic designers developing executable mechanisms: http://worrydream.com/MagicInk/