One of the other things to come out in my visit to Malcolm’s class is an awareness of a certain difference in styles between School of Information, HCI/user-centered-design project presentations and architecture project presentations. Basically, teams of SI students or mostly-SI students presented projects as a bit of a “pitch” — this is why our idea is great and should be pursued — while teams with students from architecture tended to present projects ideas as a bit less positive, including at least one presentation of an idea as leading to a very dystopian world. One of the other visitors, an architect, reflected at the end on how strange it felt to have had three hours of mostly back-to-back pitches rather than discussions about what it would be like to “live with” a system.
This prompted some reactions from the SI folks, some of which got posted to Twitter, e.g., “shouldn’t a concept have a compelling use- or who would use it, and why?” and “there was an arch guy who was shocked by the idea of considering users.” I can understand these reactions, but as someone with less skin in the game (no project to pitch), I think I had a more moderated reaction. After reflecting a bit, I want to write down some thoughts about this difference and start a discussion.
The difference that I saw in the presentations was that the “pitches” showed use cases with no downsides, or only technical obstacles. The “live with” presentations showed a vision that was more rounded and showed pros as well as some very serious cons, particularly for people who would be affected by but may not choose to use the system. In comparison to the “live with” presentations, the pitches seemed a bit naïve or even dishonest, while the “live with” presentations felt incomplete: given such obvious problems, why not change the idea?
So, where does this difference come from? Of course architects consider the people who will be affected by their creations — and not just the “users” — so it’s not that. And of course things should have a compelling use. Something that has a compelling use for some people, though, may still create a less than pleasant experience for others who it affects. This is particularly true for architecture projects — everyone in a neighborhood has to live with a building, not just its occupants — so I can see how that would lead to a certain style of presentation or discussion of a proposal. This is not, however, unique to buildings; groupware and social software certainly affect people who may not opt in, and some persuasive technology is designed specifically to influence people who do not opt in, and so maybe it would be good for some HCI presentations to take a bit more of a humble tone that acknowledges potential downsides.
On the other hand, it’s also often fairly easy to prototype and even do large-scale test deployments of software (i.e., try living with) in a way that simply isn’t possible with large buildings or urban development projects. These prototypes and field tests often let designers learn many of the unintended consequences. (Of course, you only learn about the group you test the app with.)
This assuredness of early feedback on software products, as well as the ability to iterate rapidly after deployment to correct for problems or take advantage of newfound opportunities, makes many software presentations more about why something is worth starting this process of building, releasing, and refining, rather than a discussion about building and living with fairly immutable and durable creation, and I think that motivates a lot of the difference in styles. I’m not completely sure that software designers can continue with this attitude as software becomes more social and hooking up system A to system B can lead to information disclosures with long lasting effects.
Other thoughts?
{ 2 } Comments