When I posted my missive about mashups last week, I should’ve known others were saying much of the same stuff at least a week earlier.

Adam Greenfield has a great post explaining how you have to design with the assumption that your creation will be remixed and retrofitted into a larger context:
Two things product designers and manufacturers need to know « Speedbird

You can no longer safely assume that your product will stand alone. One way or another, it will be subsumed into an ecosystem, an information ecology.

His ‘second’ thing product designers need to know is that your product has to make clear what it is and how to use it — and he delves into the subtleties of affordance vs. ‘perceived‘ affordance. And that’s a great point as well — as I said in my post, each bit you create needs to somehow bring some context and meaning along with it, and I suppose that also includes an acknowledgment that it will be used by people in ways you didn’t perhaps intend, but that perhaps you can at least forecast.

But in addition to this idea that the product needs to lend itself to the systems into which it is released, there is the idea that we should be designing ‘systems’ rather than merely products. In fact, Peter Merholz goes so far as to say “Stop designing products!”

That’s a fun, provocative way to get people to come see your presentation! But the idea is actually less radical than it sounds. (Which is fine.) Basically, they’re saying that when you have the capability you should design for as much of the context as you can. His examples range from Kodak’s early approach of designing everything: the film, paper and camera, as well as the “Photo Spots” and a whole culture of consumer photography. In recent times, there’s the perpetual poster-boy, the iPod and iTunes.

Frog Design’s Adam Richardson is part of this meme as well, and writes about Why Designing Systems is Difficult. One of his best points is that systems cross over organizational boundaries, which are very hard to breach in most organizations. They have more silos than Lancaster County, PA (and if you’ve never drive on the turnpike through Lancaster, just imagine seeing more farm silos than road signs for about 50 miles straight). Organizations are congenitally adverse to having their membranes crossed; managers have their fiefdoms and have made their careers on what they’ve accomplished there, and it’s very hard to get them to share and play well with others. Much less the cultures and processes of each of those silos.

In a sense, though, I think a lot of this is ‘object-oriented‘ (OO) thinking writ large as design philosophy. Essentially, OO thinking follows the premise that designed objects (chunks of code, usually, but imagine this as ‘products’) should lend themselves to whole systems, and not be created so as to be proprietary and self-limiting. They should be pluggable and easily recontextualized. Even in software development shops, this is still a somewhat new concept; most people, organizations or departments want to put their stamp on something, and they want to make it so their product keeps the customer or user coming back for more rather than being able to take it away and plug it into something else.

I understand the idea that, if you’re a corporation with a website and services to many sets of constituents, you shouldn’t just design one widget after another, but think of your whole ‘system’ and what that means to your customers. That just seems common sense at this point: that ‘brand’ is about all the touchpoints with your customers and partners, not just your logo, and not just the latest RIA gewgaw on your homepage.

But beyond that, the tools you provide your customers need to be created with an inherent awareness of the larger world, and the ways in which people might rather use what you’ve delivered to them.

As for creating whole soup-to-nuts systems like Kodak or Apple: If you can get so far on top of something and control the market in a way that you don’t much have to worry about interoperability with other systems, then creating a whole, walled-garden system is probably fine. At least for a while, until the inexorable entropy of ‘openness’ forces you to start breaking down your walls and being a part of the rest of the world (see AOL and Internet Explorer…which is only starting to show signs of learning this lesson).

I think the opportunity to actually design a whole system is becoming more and more rare these days. The better lesson may be: stop designing products, start designing objects *for* systems, the more open, the better.