Visio practically groaned as I opened the wireframes for my current project, which were in something like the twentieth revision. It was the usual story—poorly defined requirements and business rules—and my project folder was fast becoming the poster child for Feature Creep Flu.
I’ve heard of a fantastic land far, far away where magical people called “project managers” collect something called “requirements.” These requirements so clearly, concisely, and completely describe work to be done that all the villagers involved share a common understanding of a project’s goals.
In October 2000, Jesse James Garrett introduced a site architecture documentation standard called the Visual Vocabulary. Since then, it has become widely adopted among information architects and user experience professionals.
Wireframes: At once a singular composition and a collaborative expression, communicating the vision of both an individual and a team. As a result, they can be stacked with an enormous amount of detail. Are we becoming victims of information pollution in our own wireframes?
To date this column has focused on how to make deliverables more effective, either through their content or through the tools to create them. For this issue, I would like to explore the relationship between deliverables and methodology. Unfortunately, this calls for a definition of IA methodology, which may challenge the definition of IA as the hardest question in our field.
Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.
Now that you’ve figured out the navigation, placed the content, and figured out page flows, it’s time to explain just what exactly that collection of “Lorum ipsum” greeking, HTML widgets, and X-ed out boxes are, how they work, and how they meet the site goals.
In this column, you’ll find an overview of three IA books from a deliverables point of view. The purpose of this article is not to say whether one book is better than another, or even to comment on the overall quality of the books, but to provide a guide to what kind of deliverables information you can find in each book, and where.
Building architects don’t have to think much about what the actual deliverables are to contractors and their clients, because their industry has traditions and standards for blueprints, balsa wood models, and computer-generated renderings. As user interface consultants, we have to think about this anew for every project.
We need a way to document and express mental models that is as simple and robust as personas for user profiles and scenarios for tasks. By laying out users’ current mental models and a target mental model, we can clarify our thinking and communication about the user interface’s objects, metaphors, and interaction.