lanehalley

 

Notes from Bill Buxton Keynote
Interaction Design Association Interaction 08, Savannah GA
Sunday, February 10, 2008
View video here

The anatomy of sketching
- Quick/Timely Inexpensive/Disposable
- Plentiful
- Clear vocabulary
- No higher resolution than required to communicate the intended purpose/concept
- Resolution of the rendering does not suggest a degree of refinement or the concept that exceeds its actual state
- Suggest and explore rather than confirm
- Ambiguous

There is no such thing as a hi fidelity or low fidelity prototype, there is only right fidelity and wrong fidelity.

Movement from sketching to prototyping is similar to progress from ideation to testing and usability. 

My friend Liya Zheng posted about a recent IxDA design studio in NYC.

"On October 25, I helped the IxDA NYC group put together an event we called “IxDA Studio”. The concept of the event was to bring together experts/design masters working directly with a group of design professionals in a studio/crit setting (like back in design school!). We wanted a place to design together outside of work and to learn new ways of approaching problems from our peers as well as from seasoned design masters. We found ourselves 2 masters to help us: Josh Seiden, Design Manager at Liquidnet and Ted Booth, Interaction Design Director at Smart Design."

I love this idea and want to bring it to SF. Working to see if we can host it at Cooper. Anyone want to play?

At the IxDA Interaction '08 event in Savannah, I heard many stories about how interaction designers are taking stakeholders out on customer site visits, doing collaborative synthesis, working through design problems with developers. Why? Business stakeholders and developers don't have the same skill set or motivations as interaction designers, but there's something about using our methods to work through problems together that helps everyone be on the same page. They don't have to learn to be interaction designers to benefit from the techniques we use.

Interaction design provides great solutions, but it also is necessary to facilitate those solutions into the organization. I don't believe that the people who provide those solutions should be the "boss," they have to be the guide, leading people to the right place. Just as we can't justify our design decisions "because we think so" we also can't own the design, it has to be a owned by everyone who contributes to solution we're building. Interaction designers must use our skills to identify the problem, find a workable solution and get it all into peoples' heads before anything will happen. We have to engage and inspire the organization to get something good built.

In this spirit, I like the idea of figuring out how IxDs can collaborate more with developers because it helps create better understanding of the design and sense of ownership. Now, exactly what "collaborative design" means and where it fits in the process is open for debate, but I feel there's something in there that could work. The "big design doc" approach is problematic for many companies, and I'm thinking about ways we could do it better. It worked well in a recent project where the document followed the design, rather than the other way 'round. I think we could use more collaboration time with the development team on most of our projects, starting as early as the framework. I think there's great value in communicating more about the problems our framework is trying to solve, and leaving some of the implementation details up for healthy discussion. I think we could meet with different stakeholder groups separately to address different concerns, as well as together to build mindshare.

So...I guess at the root I see this as a design communication problem. How do we get developers to understand and believe in our designs so things are built properly? Part of the solution may be to facilitate them into it, rather than dictate to them.

The videos from the IxDA Interactions '08 conference in Savannah are up!

Click here!