Sunday, April 15, 2007

Designing for Interaction

I just finished "Designing for Interaction" and will say it was a really good and relatively fast read.

Most of the content should be known to most of you. Like chapter 6 that goes through various controls and their usages. The author does however draw some good analogies between physical and digital controls.

Interesting moments of the book:

The epiphany in chapter 4 on design research. I keep calling us a "design team" even though I know it annoys some of our user researchers. I think it would make sense to rename the user research profession in MS to Design Research. What we ultimately do is to conduct the research necessary to drive, inform, and challenge the design. A lot of that has to do with users, but not all of it. I think renaming it to Design Research would change the focus and expand the focus in a healthy way.

Chapter 7 and the discussion of "hackability" and of "adaptive" UI. It was an interesting read in general and furthered my long held belief that "you are always designing a platform" i.e. you have to assume that your product will be used in ways you did not imagine and you should embrace that and encourage that. Offhand (and I would be happy to discuss off-line) it led me to some thought about how we need a community around Models (additions and changes to CML) and how we can (mis-)use the CMDB and the Local CMDB to move personalizations, explicit and implicit, around in an environment. Suffice to say it could be done with policies J

Chapter 8 on Service Design is really interesting from the perspective of what the UX discipline could ultimately become once we start being more active in the design of how we sell servers, the SKUs, and all that stuff.

Throughout the book there is food for thought on the difference between user centered design (personas), activity based design (scenarios), and I must say, that I currently believe in the role based design approach , and I see that as a good unifier for user & activity based design. User centered design is too concerned with the goal of the user and activity based design is too concerned with the scenario sans-role. My role is Exchange admin. Because of that, I have some goals and some activities I need to complete. But sometimes my role changes to just ordinary server admin or to security admin and those secondary roles require a different UI for me than they would for a person with the primary role of server admin or security admin.