Design Reviews and Posting Without Answers

by Tom Johnson on Nov 8, 2009
categories: technical-writing

Recently our technical writing team at work (Information Strategies and Design) started holding regular design reviews. The review sessions are patterned after meetings that our interaction designers hold regularly, in which they get together and critique each others designs and approaches toward user interfaces.

In our design review sessions, a couple of members from our eight-person team share what they're working on and ask questions about challenges they're facing. We provide feedback and critique their project.

These design review sessions are one of the coolest things we've done as a team. We don't have a strict team style guide or set of standard deliverables. (We do follow the Microsoft Style Guide and, at times, a thin organizational style guide.) But as far as branding the help material, there can be a lot of variation among the online help files, quick reference guides, landing pages, context-sensitive help, interface text, e-learning, video tutorials, or other help materials we create.

If you've ever participated in a creative writing group, the design review works similarly. Team members use common sense and experience to guide their questions and reviews. Somewhat in contrast to a creative writing group, though, you don't have to bring a finished piece to share.

For example, the other week I was coordinating who would share materials for our design review, and one of our team members told me he wasn't ready to show it. What? I said. The design review is not about showing finished material. It's better, in fact, to show what you're currently working on, while it's still early in the process, before you've cemented everything. Oh, he said. In that case, yes.

Parallels with Blogging

I find that the same mindset works with blogging as well. Often times we think we can't publish a post until we've finished a cool thought, or until we've finalized a solution to something. But this past week, I added a couple of posts in which I wasn't quite sure what I thought. In my Theme Parks and External and Internal Input post, I was only part way into a thought. Commenters added to the discussion and helped me better see insights and perspectives on the issue.

I also wrote a post on working with wikis, A Few Surprises in Using a Wiki for Documentation. I'm not an expert on wikis, especially Mediawiki, and there are many things about wiki authoring that I need to learn. But this didn't stop me from posting about it. Instead, I shared some of the challenges and issues I was facing. And some of the commenters added information that proved incredibly helpful. For example, see this informative comment by Amalia.

Had I waited until I finished in putting together an entire strategy and methodology for authoring on Mediawiki before posting about it, I would have missed out on the guidance and direction early on. It's from the helpful information early in the process, particularly with challenges I'm facing, that comments on a blog become the most useful. A blog is, remember, a journal, so it contains thoughts and ideas and experiments in progress -- not always finished solutions, completed ideas, or tried-and-true methodologies.

What's true in design review is just as true in blogging. Sharing the current challenges you're facing will make your experience in the blogosphere or design review process more helpful and rewarding.