Wireframes Brainstorming
My main responsibility at work is to put together wireframes–a document of diagrams and annotations detailing different specs and interactions about each page of a site. It may involve deriving the functionality, flushing out the content, deciding what the content is, and how each component behaves. This document then gets passed around between the client, the creative, and the development teams. For the most part, it’s a lot of fun.
However, because the wireframes are used by everyone, deciding what information to put on it and where that information should go (to ensure everyone gets what they need out of it) becomes a challenge. Documentation becomes extremely important because we want to make sure everyone is on the same page, but if they can’t find that data or if they don’t read it, the vision falls apart.
While we’re waiting on the new projects to go into production, my manager and I had a brainstorming session to figure out a new wireframe template. The information that we need to include are:
- Project title
- Version and edit control: what version of the wireframes we’re using, and what has been changed since the last version
- Page number
- Page reference: different from page number because page numbers are variables, and not necessarily the same across all copies which makes referencing difficult
- Page title: e.g. homepage, sitemap, contact page
- Documentation/Page modification date
- Reference: sites that have the interaction that we want to develop
- Source: if the project is a redesign, and we’re designing off an existing page then that page would be considered the source
- Template: e.g. A (one column), B (two column 75/25), etc
- Annotations: reinforces the interactions that the diagram illustrates
- Client feedback: comments, approval status, etc
- Callouts to the client/creative/development
The designs that I came up with before the brainstorming session look like this:
When I was working on wireframes in the last two weeks, I had a lot issues with the ratio that came with a landscape orientation. If the pages are long–and pages are often longer than they are wide (even though screens are wider than they are long)–I find myself trying to cramp everything together. For example, I would shrink a textarea to look like a text field so that I can fit in a submit button. So we spent a good amount of time trying to decide whether we should go portrait or landscape, legal or letter.
Some conclusions
Actually, not really conclusions but things that we’re going to test with the next set of wires:
- Two different scaling of wireframes: one portrait to be used for sites with long pages, one landscape for sites with short pages.
- Annotations take up a substantial amount of time. Taking the idea from OLM, if we develop a library of reusable annotations that we can just drag and drop onto the diagram, it might save us some time. Especially if we reuse interactions like the accordion or the flyout.
- Have a change log to keep track of revisions and client approval.
- Reference numbers at the top left hand corner to be screen friendly and the bottom right hand corner to be print friendly.
- A mini sitemap visualization on all pages to put current page into context. This requires a lot of effort to maintain, and we’re not sure whether it’s worth the reward. If we change the site map, we’d have to update every page.
- Reserve certain colours/styles for annotations.
My task for tomorrow will be designing the change log page.
