Kathy's note: This is the fifth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
In my time as a UX professional, I’ve had numerous kickoff meetings, done a lot of collaboration, held a lot of reviews. The kickoff, collaboration and review area all part an overall communication strategy that gets people to agree to the user experience as soon as possible and to help it evolve quickly over time.
In content strategy, you’ll also need to have a kickoff, to collaborate and hold reviews. You can use the thoughts below to make your meetings and work more efficient and effective. The overall point of what I say below: don’t wait until you’re done with the deliverable to get feedback. Get feedback all along so what you present is on-the-mark (or darn near close).
Here’s some problems I’ve had and some proposed solutions for them.
In January 2011 I wrote a post on my own blog about kickoff meetings. In that blog post, I said,
In recent projects, I’ve been struggling to set the right tone for the project. I mean, the project goes well once we get going, but there isn’t the right kind of kickoff that 1) gets the client excited; 2) sets expectations; 3) educates everyone; 4) builds a team dynamic within this group.
I can’t say that since January I’ve had any further luck with kickoff meetings. I’ve even attended an IA/UX kickoff meeting where were spent 15 minutes on IA/UX and 1.5 hours on a website hosting issue!
What’s really important for UX is to have an actual UX kickoff meeting where the UX people set the agenda, invite the appropriate players, and do the appropriate exercises at the UX meeting. I can’t stress enough how important it is to set expectations up front, to control the agenda, to have something for people to *do* during the meeting, and to let people know ahead of time what is on the menu. Otherwise, people can co-opt the meeting, feel directionless, feel like they weren’t included. Kickoffs are about communication, about making people feel included and making them aware of what’s going on.
Here’s a great post on A List Apart by Kevin M. Hoffman: Kick Ass Kickoff Meetings.
Once you hold your kickoff, it’s time to collaborate. When I used to work in the waterfall development method, I’d sit in a cube for 2 weeks, write a 150 page document, present it for review, have it torn apart, go back to my cube for another 2 weeks and re-do the whole design. It was defeating, humbling, and discouraging.
Collaboration includes brainstorming, card sorting, affinity diagraming, design workshops, anything that moves you closer to understanding each other, getting ideas out there and vetted. You can collaborate in the kickoff meeting, in subsequent workshops, or ad-hoc in the office or over the phone.
When I stepped out of waterfall and became a consultant, I wanted to show my clients that I was working on something, so I started presenting my deliverables earlier and earlier in the design process. I got much needed feedback that I wouldn’t have gotten if I held onto the design till the formal review. I would have spent a lot of time and money doing the initial design, it might have been off base, and I would have spent a lot of time reworking the design (and not necessarily gotten paid for it).
For these reviews, I don’t schedule review meetings with all the stakeholders, but simply talk to other team members to discuss the design, take feedback, update the document. I would also show it to one or two of the more important stakeholders to get initial feedback.
Don’t wait until a design is almost final to present it. If changes are requested, they may not be able to be incorporated or they will take significantly longer to make. Sharing design is a great way to help people feel included and informed.
Reviews are tough. I’m an information architect who likes to present a deliverable, give explanations, then take feedback. But I’ve been in meetings where I’ve asked my clients to wait till the end to make comments and have then been told, “Yeah, I don’t work like that, I’m going to give feedback as we go along.” Invariably I get the question, “What about X?” and I say, “We’re just about to get to it.” I can’t communicate my vision, but some people don’t care about that.
Sometimes its best to just give up the explanation of the vision time. People attempting to use a website or web app don’t get an explanation, so if the deliverable can’t be understood without me, is it much good? (Sure sure, there are limits here, but think about the question and think about how you might improve your deliverables to communicate better without explanation.)
On my projects, I like to do paper sketching and silent review periods. I like to get peoples’ impressions without being able to explain myself.
In any case, reviews are meant to gather consensus on the deliverable. Set an agenda for the meeting, have someone take notes, don’t ask people to solution, just ask what they do and don’t like.
About the Author
Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis, she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.
Read all posts by Theresa.