Why sketching is agile
Since last year I'm a loyal follower of the Bay CHI monthly program meetings. When I saw that they organized a tutorial in partnership with Bryan Zmijewski and Jeremy Britton from the design company Zurb, I wanted to be part of it. This workshop was about website and user interface design from analog sketching to the implementation phase. Each time I go to this kind of workshop (I attended Presentation Reboot last year with Garr Reynolds and Nancy Duarte) I came away filled with a wealth of new ideas and approaches for enhancing my design and delivery skills.
We began by thinking about thinking and how to produce good ideas by digging a problem. The first practical exercise makes me realized that people usually start to build a story to get solve a given problem instead of exploring all possibilities around it by asking more questions... Before trying to find a solution it's actually better to really understand the problem by itself (speaking from experience ;-). From a product management perspective, understanding the problem space is obviously the starting point for building a new product. It's an analytic step that requires to identify the target user group: You should listen to them (customers, engineering, prospects, industry analysts, competitive analysis, sales, partners) and describe the context or the situation where the problem exists. Until it becomes clear you should ask "why?".

We covered the brainstorming rules and methodology but we dove head first into why sketching is a great helper for design thinking. As people are open mind and receptive, it's a powerful language that bring the right brain into play and facilitate the understanding of the problem's solution space. Bold and simple sketches smooth assimilation of concepts and help to put yourself in the user shoes, sketching a workflow for instance encourages the designer to focus on the goal of the user (user experience) rather than thinking about an organizational structure or hierarchy of the product, interface, etc.

Another exercise we did during this workshop was about feedback - how to solicit and interpret it. I retain six key points (among others):
- Beforehand asking the feedback, build a consensus around the idea, guide the discussion, your goal is obviously not to start a flood of criticism nor lost the control of the discussion
- Be accurate and highlight the answer you want by asking specific questions to specific people
- Create a positive momentum around the idea
- Define a timeline, even for a small decision, it's always good to train people to get a timeline and above all it helps to do rapid iteration
- Analyze the first reaction (watch their eyes, etc.)
- Apply the reflective listening: Repeat back to the person you talk to in order to grasp the full content of the feedback

Bryan mentioned some tools he uses to implementation his ideas. OmniGraffle seems to be his favorite (it's mine as well), Balsamiq Mockups, by doing like you are drawing, is as well a good tool. Of course Visio on a PC is also a great application, but please forget PowerPoint... Zurb is using also an interesting homemade tool to automate change on a web site prototype like adding an user status, changing skin, customize content options, etc. and get their customers feedback in realtime.
I share Zurb's vision of design and business: the purpose of designing is to get thing done and not only find ideas. The last advice they gave sounds "agile": sketch - prototype - get feedback but move fast, do rapid iteration and keep pushing... Is that the way you work? Feel free to leave a comment.