Designing for interaction…

So, the Tuesday just gone I attended the Web Directions conference (see interacting with the world for an intro). I went with collegues from work and between the three of us we make up the design department. The workshop we went to was Designing for Interaction and the speaker was Dan Saffer from Adaptive Path. (Ed- A good article to see where Dan is coming from, is Everything you wanted to know about designers).

Asked by my boss what I thought about the workshop, and I rated it as follows : 65% quite good/very interesting, 15% good, and the remaining coverring topics I didn’t engage with. So let’s start with the unengaging stuff…

Wireframing
I don’t think I found this part of the workshops intresting, because as an Interactive Designer I do this every day, and also teach it to students at UTS… so for me at least, there was very little to be gained from a discussion about it – and in particular because the discussion came directly after lunch, and went for a solid hour and a half. I think, for those that hadn’t been exposed to it as a concept, or had heard of it, but didn’t know really what it was all about, it might have held more interest and been more benefitial.

History, future and implications of interaction design
Now this was more like it. As Dan spoke, and raised examples of the rich history of interaction design, I found I was really quite interested. He touched on ethics, as described by the cautionary tale of the IBM designers who came up with the numberring system used by the Nazis in WWII. This raised the question of personal responsibility in design, and the suggestion that as interaction designer’s we should start from the position of “first, do no harm”.

The tale of the designer who makes the button in the elevator that lights up when it breaks down was interesting as well, as it highlighted that our role as an interaction designer does not stop with the design of the button – but must by its very nature encompass all that surrounds the button. In this example, it would include the service that supports the elevator when it breaks down – so that not only will the button light up, but someone will actually come and rescue the person stuck in the lift.

Moving into the future, these tales really worked well when discussing ubicomp, because by their very nature they encompass a multitude of scenarios and events that really need extra care and consideration given to them so that the user isn’t left in the dark, and to make best use of the technologies and interfaces available, for a variety of situations.

Tasks
These were good, but not always compelling. Dan at various points in time gave us tasks to do in groups. For example : design an interface for an elevator in a building with 1000 floors. I quite enjoyed these exercises, as I went into them with my ubicomp hat on, and suggested interfaces that were more discreet, more decentralised, and that required little thought because the systems around us would do most of the work.

So for example, in the elevator task, I suggested that a device like the PDA or mobile phone could be storing your most frequented levels. And as you approach the elevator, you choose the level from the device. Backed on to that, if you didn’t know the level, at the concierge or on each floor, there could be an interface (in the traditional sense of the word) to filter searches etc, and that passes this informaiton onto your portable device. In this instance, the elevator’s task is not to be the interface, but the carrier. Of course, there remains many questions, but you can see the kind of mind benders small tasks like this can instigate. Very enjoyable.

Overall
It was nice to get a sense of “other people are thinking about the same things I am”. It reinforced, rather than astounded. But I suspect if id been to the same conference 3 years ago, I would have been a convert, and not a companion. If you think you might be interested, Dan’s book Designing for interaction is an extended version of this discussion, and is worth a read.

8/10

  • dan

    So, had some space now between the WOrkshops and the post, back into the swing of everyday work, and I have to make one edit to my post above – and that is that even though I found the wireframing part of the talk less than engaging, something stuck in my head.

    And that is documenting wireframes. Job no., author, date. Something im now putting into practice in a more in-depth way than before. I always do this kind of stuff when coding, and to a degree I did it when wireframing before – but now im just adding a little more to each wireframe.