Designer as facilitator: meetups, teamwork, and deliverables
Tonight’s Agile UX meetup was a good demo of how to collect and address the issues of a large group. The meetup itself was agile :) After a short presentation, the hosts led a few exercises that determined — and answered — the group’s most popular questions.
1-on-1s: Find someone you don’t know and tell them why you’re at the meeting. Write each major question on a sticky note.
Card sorting: Hosts: call for the first pressing question. Collect similar questions, and group them on the board as a topic. Repeat until all important questions have been collected.
Dot voting: Each person gets X votes, to mark as dots next to the topic(s) they want to discuss. People can use all their votes on one topic, or spread them around. (Occupy would do this with uptwinkles and downtwinkles :)
Fishbowl discussion: Five minutes, four chairs, three panelists. Start with someone who asked the selected question, and someone who has an answer. If you want to talk, take the empty chair, and whoever’s been there the longest departs.
It was a bit slow, since we had 70 people in a new space, but as people warmed up they started contributing more and the flow got better. We ended up with a variety of insights on two popular questions:
What’s the best way to get designers and developers to work together?
More valuable than any certain tool is an initial in-person get-together, to break the ice in each partnership. Good communication often occurs naturally afterwards.
Try a code design exercise at the outset: ask engineers what they think the product should be, have them work through solutions. Often brings up their issues very early.
Keep design (rough) a sprint ahead of development. Then, at the feature kickoff, get feedback and more detailed information.
Google Hangout all day long; just seeing those faces all day keeps the feeling of teamwork.
Best tool: a printer. Keep everything visible for review and discussion.
What are the most valuable (or efficient) deliverables from user research?
Fastest: have everyone there for the testing. No one wants to write up or read the report anyways. Livestream it. Very hard to argue with a video of the user’s experience.
Traditional research happens before development, provides lots of data. Remember that Agile UX proposes a new model: doing research on the product itself.
Twitter is a great place for fast, informal research on a topic you know nothing about. You can see the schema people have for talking about the topic, and how they respond to your ideas.
Sales demos are great user testing opportunities.
And a couple notes from two of the hosts:
Jonathan Berger: Meetup does a great job on user research. They schedule three testers every Thursday, so it’s in everyone’s routine. It started as one developer watching, eventually the whole dev team wanted to watch so they screenshare the test and have a chatroom where the developers can ask the researcher what else they’d like to see in the test. The deck by Andres Glusman is great.
Steve Berry demoed a new tool ballot.io, for quick votes and comments on a question
This open, collaborative, designer-as-facilitator approach is kind of a pain, but it’s seeming unavoidable with large teams or complex projects. I’m happiest when making things (i.e. mockups or code or outlines), so I’m always impatient to get back to the ACTUAL DESIGNING, but I realized that in this type of group work, you’re just designing the product in your head. You’re going through iterations mentally, based on live feedback (as much as you can). Abstract design?
Designing the interactions that lead to the design…
