Boxes And Arrows : The Design Behind the Design

Representing Content and Data in Wireframes: Special Deliverable #10

by Dan Brown on 2004/08/16 | [10 Comments]

Anyway, as meticulous as the project manager and I were in going through the wireframes to ensure they looked “clean,” things are always dirtier in the cold light of day (read: during the presentation to the client). Although it went well enough, the hang-ups in this meeting were over the examples used in the wireframes, requiring additional explanations to clarify functionality. Until that moment, I had not given much thought to the kinds of sample data and content I used the in wireframes.

Typically, sample data and content in wireframes is repetitive and invented:

During my presentation, a table similar to this one stopped the client in his tracks. Is it a list of the same address over and over? Given the circumstances—and that the requirements had changed so much—this was not an unreasonable question.

Information architects sometimes do not repeat data but invent more of it, so the address book above might also contain entries for Jane Doe, Homer Simpson, and Mickey Mouse. Invented data or content is essentially meaningless, representing an archetype of the kinds of information expected to appear in different areas.

Using repetitive and/or invented data, however, can confuse and mislead stakeholder in five different ways.

• Misrepresent rules and behavior
• Misrepresent what the user sees
• Shift focus from the design
• Misrepresent the data’s impact on the page layout
• Misrepresent the scope of the fields

To illustrate all these, we’ll look at one of the most data-rich screens available on the Web: the shopping cart.

1. Misrepresenting rules and behavior:
   In a word, the math in our shopping cart doesn’t add up.


2. Misrepresenting what the user sees:
   This order has two destinations and users can click the second destination to see what’s going there. Because the dummy address is repeated, however, it does not accurately illustrate what the user will see.


3. Shifting focus from design:
   If dummy data ends up being inaccurate (“Hey, widgets don’t come in black!”) stakeholders can be more focused on the data than on the architecture.


4. Misrepresenting data’s impact on page layout:
   Using exclusively short examples does not accurately show the designer what he or she will have to accommodate in the page layout. Frequently this leads to some dummy data like, “ThisIsAVeryLongNameToShowWhatLongNamesLookLike.” Which is just weird.


5. Misrepresenting field scope:
   An address field can take so many different forms (apartment numbers, international addresses, ZIP+4, etc) and no dummy data can accurately capture all the variations.

No doubt each of these problems can be solved individually: use numbers that add up, use two different dummy addresses, etc. But coming up with a comprehensive, unified strategy to represent data and content can make wireframes easier to create and present. That is, the examples selected for a wireframe should tell a single, complete story.

The Universe of Sample Data
A cursory review of some wireframes out there reveals five different kinds of sample data and content, listed here from the most concrete to the most abstract:

No one kind of sample data is better than any other kind. Indeed, like most things, it depends. In this case, the type of information, the disposition of the client, and the amount of detail required would all influence how examples are displayed.

With the universe of sample data codified, information architects need only a mechanism for deciding which type is best for different applications. A hard-and-fast formula is perhaps not appropriate, but I’ve devised four strategies for typical documentation problems.

Prose
Greek text is most appropriate for representing long blocks of prose. Where description of the content is necessary, I justify and dim the greek while superimposing copy direction over it.

Tables and Lists
Because the data in tables and lists tend to include repetition of type, using dummy data can confuse stakeholders if they take this to mean that the real content (not just the type) is repeated. Using actual data in a table may help, but comes with all the disadvantages of using actual content (finding it, ensuring it represents all variations, etc.) After some experimentation, I decided to use exclusively labeled data:

Annotations must accompany such a table to indicate the rules for populating it.

Dates
If a Web application depends on dates, the wireframes should use actual dates and employ them consistently. The project I mentioned at the beginning of this article was a scheduling application. As the wireframes evolved over several weeks, the date examples I used in the wireframes were not applied consistently. Some screens showed sample dates from May and others from August, which made narrating the scenarios very difficult.

To approach this issue on my final round of revisions, I first listed all possible scenarios (schedule new event, change existing event, etc.) and then identified key milestones (first login, first scheduled event, subsequent login, etc.). With these dates defined up front, the wireframes told a more coherent story.

Unique and Non-Unique Data
Using labeled sample data presents a challenge because a variable name can represent more than one piece of information. For example, in an address book application, [FirstName] could represent the name of the address book owner or the name of someone in the address book. There are two strategies for dealing with this situation:

1. For data that is unique, always use actual or dummy data. In the address book example, the first name of the owner would always be rendered as “Jane,” for example. Non-unique data could then use the labeled format (e.g., [FirstName-20]) without conflicting with unique data.
2. Using the labeled data format, visually distinguish unique and non-unique data. For example, when referring to a specific first name, the field could appear with braces instead of brackets: {FirstName-20}.

Conclusion
Sample data can make or break a wireframe, whose purpose is typically to illustrate architecture and interaction. Poorly selected sample data can end up clouding the wireframe or distracting stakeholders from its purpose. By codifying the types of sample content they employ in their deliverables, information architects can create a coherent narrative to illustrate a website’s functionality.

These days, rather than try to think of sample data, I use the labeled format almost exclusively. (Combined with Visio’s stencils, this makes keeping the wireframes up-to-date very easy.) If, later in the process, it becomes appropriate to include more concrete sample data, it’s easy enough for me to go in and change [FirstName-20] to Jane or John.