Journals by RSS
Journals by EmailOur interaction design group holds regular design reviews. In these meetings, they show each other what they’re coming up with for the projects they’re working on and give each other feedback. A designer will generally put his designs up for scrutiny before he gets very far in his designs so that the others can ask questions and suggest additional factors to consider.
This is a great practice for technical communicators. This field involves designing the way a user interacts with content. I may be designing electronic or print materials, but holding reviews with fellow technical communicators before I go far down a particular path could only improve my thinking and save me work later. As with most things, the more eyes you have to give perspective on something, the better of it will be. We plan on beginning this in our team pretty soon.
Related entries (auto-generated):
Results of a Team Design Review: A Different Context-Sensitive Help Structure
Reviewing Projects and Deliverables as a User Education Team
Problem-Centered Design for Documentation
3 Comments to 'Team Documentation Design Reviews'
July 31, 2008
Definitely interested in hearing how this works out for you, as I’m struggling to see specific benefits.
Don’t you work with templates, don’t you have an agreed basic structure to which everyone contributed?
I’m sure you do, and it’s probably just because it’s early and I’ve only had one coffee, but this reads a little like you all do your own thing when it comes to content design. Which is, in my experience, odd!
Set me straight, please.
[Reply]
July 31, 2008
Gordon,
Our team is still young and small enough (speaking of the team itself, not necessarily the people in it
) that we have freedom to find what works best for us and our users. We do share templates with each other, but right now, we’re using the freedom allowed within our organization’s style guide to be creative and experiment. Print publishing goes all the way back to when our organization was founded, but its use of software is more recent, and the inclusion of professional writers for documentation newer still.
I’ll be glad to report on the results.
[Reply]
August 9, 2008
Sorry, I’m late to the party here, but I wanted to comment on Gordon’s statement that everyone doing their own thing is odd. I have worked for large and small companies and what Ben describes accords with my experience. Different designers doing their own thing is husbanded rather than frowned upon as it increases creativity (as Ben says). Yes, some basic guidelines do exist, but my current crew finds that so long as an individual design retains the look and feel of our application, anything that is effective is worthy of consideration.
Gary
[Reply]
Set Me Straight. Leave a Comment.