Dialogue through Documentation
It’s ... a challenge to illustrate a holistic view of a site that has a nontraditional navigational structure." from Is The Sitemap Loosing Its Client Facing Steam by Vincent Au from UXMag.com.
This is a great article that makes you question about the value of traditional site-maps and UX documentation. I have been thinking about this a lot recently, since I am transitioning from a team that works with a different larger dev group to a smaller more agile one. I am not yet sure how UX documentation falls into the picture, but I do know that all very successful meetings I have presented at, have had some type of support documentation tailored to the goal of the meeting. This makes me feel confident that some level of static documentation will live on if not only for means on in-person communication and decision making.
The level of formality of a design presentation or meeting can vary greatly depending on who your client is. At an internal agency this holds true as well. With many different teams in a corporate environment, there are many different types of presentations and brainstorming sessions which occur. Creating documentation that can both be presented formally in a meeting to stakeholders, as well as live on as the building block for development documentation can be a way of keeping track of decisions made as well as framiliarizing different teams with the evolution of the design.
When creating documentation for a meeting I like to start with the following basic outline for the slides:
1. The Opener
Questions, open issues, related projects, goal of designs. For visual support it can be great to diagram out the different things that are open and who the related teams or stakeholders are that need to weigh in or if the project is further along, open issues, questions, or timelines.
2. The Design Schema
This is completely dependent on the audience. By schema I mean to include either a IA map of some kind for a business stakeholder responsible for menu structures, a diagram of features for a stakeholder responsible for the product definition, or the core wireframe templates called out by name for an internal design review. The point is, you have to identify what are the key decisions you make in your design that your audience will care about. A developer may not care about what the menu options are called, whereas a content programmer will.
3. Detailed Designs
In the later sections is where I show more detailed wireframes or visuals only after the design system or schema has been presented. Often times if you start with this the meeting goes slower because you have not laid out a foundation yet, even when discussing internally.
If you have such a document for a presentation or meeting, it can easily evolve into the development documentation. Even if designs are prototyped quite quickly, you still have a record of the decisions made and questions considered.