Tom Johnson and Paul Pehrson posted recently about our team design reviews. These have started to turn into what we might call project reviews. In our team meetings, we usually brief each other on what we’re working on. In these project reviews, a couple of team members will go into more detail about their projects.

Going beyond the design review idea, where we would demonstrate our deliverables and get feedback, we also talk about the challenges we’re facing and receive suggestions for managing those challenges.

The Design Side of the Review

A few weeks ago, I showed a quick reference guide I had created. Tom’s recent post talked about how beneficial it can be to review your deliverables early on so that you can correct things earlier and save time. I missed the first review where I was going to show this due to illness, and then the next one was canceled. So by the time we reviewed this guide, it had already been reviewed by the interaction designer and the lead developer and was finished. With limited time left to work on the documentation for that particular project, unfortunately there isn’t much I can do at this point to incorporate the team’s feedback.

But I wholeheartedly encourage reviewing your work with your technical writing peers if you have them in your organization. While members of the project team are concerned with accuracy of information, your tech comm peers will give you feedback about their first impressions from the presentation and design of the information.

Reviewing design together can also help you arrive at a consistent general style across deliverables. It’s a natural byproduct of seeing each other’s work and giving each other feedback.

The Project Side of the Review

Talking about our projects helps us see our project management styles and learn from each other. In our last review, one of our team members explained some challenges he has encountered in the project he is assigned to. He is managing it well, so we didn’t have a lot of advice to give him. However, the main thing I took away from the discussion was a matrix he put together regarding single sourcing.

I’ll talk more about my opinion on single sourcing in another post, but the thing that struck me about this matrix was the detailed breakdown with types of information on the Y axis and deliverables on the X axis. He had marked which types of information in his help authoring tool would fit in different outputs like user guides and quick reference guides. I was impressed by this kind of matrix that is applicable across projects and can be added to our team’s general resources.

Wrap-up

An hour every other week gives us an adequate amount of time to talk about our work with our eight-member team in some depth. It’s a chance for us to help each other improve and continually come closer to a consistent design across our projects in spite of our different backgrounds and a lack of an overall design style guide. Reviewing design and projects as a team reduces the need to lock all design down in a style guide.

Related entries (auto-generated):

Team Documentation Design Reviews

Results of a Team Design Review: A Different Context-Sensitive Help Structure

Five Skills for Managing Documentation Projects in an Agile Environment

Offering a Menu of Tech Comm Deliverables

A Team Member with the Heart of a Technical Communicator