Last week I went for the first time to the Silicon Valley Product Management Association (SVPMA) monthly meeting. The topic for this first meeting of the year was about User eXperience and presented by Glen Lipka from Marketo. I guess slides will be available soon in the SVPMA archive (they are still not available at this time) and beyond the networking opportunity, here are the key points I retained.

• There is decision in any design process, actually design is just decisions and who is making these decisions really matters, it might be engineering people, an end-user, a manager or a researcher, etc. but at the end of the day the designer is the one who wrote the PRD (Product Document Requirement).
• UX designer and PM roles might overlap, it's fine, as long as PM stay focus; there are already many tasks under his responsability, he should be dedicated and works actively with marketing to get comprehensive MRDs (Marketing Requirement Document) including competive landscape, packaging, go to market strategy and research.
• Get a direct interaction with users, learn from them (e.g. make up-front call), understand their problems, what they are trying to achieve, why they didn't choose your product, etc. but don't let them define the actual requirements, people are terrible about their own perception... 
• "A picture is worth a thousand words" - we all knew that visual PRD helps to explain complex ideas or UI concepts but it also helps to convoy ergonomic features, hardly describalble with words but often critical for the user experience (e.g. moving / manipulate objects on a page)
• Don't put too much instructions in your product (users don't read) but pay attention to remove frictions that would require to read these instructions. 
• Address the overall user experience, from product design to support and observe well things when they go wrong - i.e. The way to handle things go wrong is way more important than the way to handle things go right.
• Because user don't have the same perspection as you, as the designer, more small improvements is often percieved as better than one big one, they usually don't know what was the work required 
• And last but not least, give yourself permission to put fun stuff in your product, messaging, etc. people wants to be treated has human being and if it's authentic they will adhere to it.

A bad UX design is a bug (picture from Flickr)

Early this year I followed a talk at Bay CHI from Udi Manber - VP Engineering for Core Search at Google - about The complexity and simplicity of the search experience. To introduce his presentation, Manber gave us this statement: "One tier of search queries that we get in any given day are unique and havent been seen before" and emphasis on the Google's User focused approach to handle these queries.

As we all know the Google search engine simplifies our lifes as much as possible, like using place of the query to make results more accurate, automatically spot and correct typo and spell. It's somehow Google that give us what we need, not what we said. They always assume that we are right, if the result is not what we are looking for then it's their problem and they don't fault somebody else. 

At Google, they have a kind of mantra to illustrate this approach. I didn't catch all of it*, but it sound like that:

The user don't know what he is looking for, it's our problem,
The user don't know how to spell his queries, it's our problem,
...

The advices I retain from a Product Management prospective are that to provide a great user experience we should not consider design as an afterthought... it's the heart of the problem. Start simple, get the maximum data from users, visit them, ask for feedback and why not include a "call home feature" in the product to collect usage statistics (anonymize data and get user agreement first of course).

It's also better to work with progression from simple to complex and add features separatly in order to not overload the product. A product can have tons of features so if the user needs more power then he can get it, but this is also critical to make sure they are not in the way for the average user. This rise a key issue that we have to address: How to make users discover new features? E.g. "tips of the day" or "what's new?".

We should not compromise on simplicity, everything in the product has to be very clear, should need a very short learning curve (who read manual?).

Manber concludes his talk we these advices:

"Best design are build with creativity, intuition and data. The key is to have clear goals, but be flexible how you get there. Data obtain from the web are short term and do not help to define strategic feature. However Get everyone to participate from day 1, Listen to everyone from day 1".

 This talk remind me this slide from Garr Reynold, we should not confuse Simplistic & Simplicity. 

* The podcast for this meeting is not available

Tonight I went to the BayCHI program meeting to see once again Nancy Duarte. She did an outstanding presentation and demonstrated in live how to connect with an audience and make a story resonate. Of course, I can only recommend her new book resonate. 

One of the funniest Nancy's advice : Don't start your presentation by talking about how awesome you are, give priority to humility and authenticity.

I already wrote about the power of sketching, so here is follow up and a good example of how visual communications really enhances the Daniel Pink's talk. I also really enjoyed it, especially because money is not what drives me to perform.

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.