Yesterday I attended DCamp, a gathering comprised mostly of user interface researchers and designers. I lead a discussion on “Design for Appropriation,” inspired by a talk that took place at UC Berkeley, which I’ve written about before.
Our discussion was wide-ranging, and I didn’t take notes, so I can’t capture much of it. One of the most salient points was that there seems to be a cultural shift towards appropriation being acceptable, and Pete Stahl reminded us that most of us got into web design and development through browser-supported appropriation — the ability to “View Source.”
For me, the big question continues to be, “if we are designing things for our users/participants/customers/whathaveyou to appropriate, than what are we designing?” What is the *thing* that we point to and say, “I made that”?
I guess I’ve come away with two answers to the question. The first, and the easier answer, is that we are designing the frame, the container, the shell, within which users create and appropriate.
The second, and harder answer, is that it’s not about designing a thing, an artifact (even digital) at all. That that is a trap of legacy thinking. That we as designers need to think about how we design, or use design tools and methods, to address aspects that aren’t about the artifact. This puts me in the mind of Doblin’s Innovation Landscapes , which help remind me that the “offering” is only one part of considering the product, and that there are many other aspects (business model, processes, channel, customer experience, etc.) that designers should address.
The other major concept that I kept coming back to was trust, and how trust gets associated with transparency and authenticity. But it does so in a funny way. Users tend to place a lot of trust in systems that are transparent and appropriate-able (such as Flickr) because we see the mechanisms by which things work, and that gives us comfort. We also, though, have a lot of trust (in fact, all we have is trust) in systems that are utterly opaque, such as financial service firms — I don’t want Schwab’s systems to be appropriate-able.
As in the UC Berkeley conversation, I definitely come away from these discussions with more questions than answers. Suffice to say we design in interesting times.