/*
var quicktagsL10n = {
quickLinks: “(Quick Links)”,
wordLookup: “Enter a word to look up:”,
dictionaryLookup: “Dictionary lookup”,
lookup: “lookup”,
closeAllOpenTags: “Close all open tags”,
closeTags: “cl
ose tags”,
enterURL: “Enter the URL”,
enterImageURL: “Enter the URL of the image”,
enterImageDescription: “Enter a description of the image”,
fullscreen: “fullscreen”,
toggleFullscreen: “Toggle fullscreen mode”
};
try{convertEntities(quicktagsL10n);}catch(e){};
/* ]]> */
edToolbar()
At Evantage, interactive prototyping and iterative prototype testing are key components of our process. We typically work on complex, business critical systems that must serve a wide array of audiences. Iterative prototyping and testing are absolutely crucial to designing a pleasant, usable experience for systems like these. There are many factors that contribute to the effectiveness of prototype testing, but one of the biggest is content. I recently cooked up a tool to help designers articulate their needs and get that content from those who have it.
A Little Background
What we discovered early on in our adventures with interactive prototyping was that simple interactive wireframes weren’t going to cut it. We tested with pages that were actually labeled “<Product Page>” and were full of lorem ipsum, just like our wireframes. People were getting to the right place, but not understanding that they were successful. We quickly learned that our prototypes had to have some content in them. It didn’t have to be real, but it did have to be plausible.
Another thing we discovered about just prototyping our wireframes was that it required a lot of rework to update them for testing. Once we had our interactive wireframes, then we started working on the test plan. This was the way we had always done things, but the rework issue made it clear that we couldn’t continue to do things this way.
A High-Level Prototyping Process
These two experiences are part of what led me to develop a high-level prototyping process that I’ve stuck to ever since:
- Think on paper, not in a tool (i.e., sketch. This is a different but important issue.)
- Collaborate with the
client to define the scenarios you should test the prototype with.
- Use your sketches and the scenarios to identify the content you’ll need to populate the prototype with, and then get it from whoever is responsible.
- Prototype in your tool of choice. As you do so, integrate the scenario interactivity and the plausible content you’ve gathered.
The Template
For my current project, I found myself in this very position again. But this time I have the luxury of having access to a whole team of people focused on and expert in the content. All I needed to do was to communicate with them effectively about what I needed and they’d get it for me, so I came up
with the document below.
The scenario text (1) at the top of the template gives the context for the content requirements below, as does the testing goal (2) right beneath the scenario text. The screen, page, or template names (3) are listed across the top of the table and the content types (4) are listed down the side. For my current project, there were only two types, main content and instructional/UI content, but it’s possible there could be additional types.
Within each table cell is where I articulate the specific content I need for that instance of the page type, e.g., “search results for machinist.” If I’ll be using multiple pages of the specified template, I indicate that I need e.g. “search results for machinist and carpenter.”
The content I’ve gotten back after delivering this document was accurate, so that led me to believe that it was worth templating. So here you go! Click on the link below to download a ZIP file containing a template PPTX file as well as a partially filled-out example. Enjoy!
Scenario Content Needs Downloadable Template
edCanvas = document.getElementById(‘content’);
Tags: content, Prototyping, scenarios, templates
Good article Fred. I’ve definitely run into some of the same issues you brought up.
A few questions about your prototyping process:
Are you saying you go straight from sketches on paper to prototyping?
Do you bypass creating generic wireframes and use the prototype as the documentation?
What do you do about those pages in the site that aren’t part of the test plan?
Do you still add these to the prototype so they are documentated or do you document them another way?
Minor note: I think the note icons 3 & 4 in the screenshot might have gotten flipped.
Nice showcase! Next time I will need content from my client — i will recollect your exprerience and use the template. Thank you, Fred!
Chris: If I’m prototyping a fully digital interface, then yes, I usually go straight from sketches into Axure. We don’t do standard wireframe decks at Evantage anymore because Axure makes it easy to do prototypes and documentation at once. Sometimes though, we’ll go from sketches to a few high-level concepts which we render as sketchy looking wireframes in Balsamiq. We’ll review those with the client and then start rendering the final concept in Axure. Regarding additional pages, in our testing we hit all the pages in the prototype. Those pages represent all the different types of pages within the system, so nothing gets left out. They get documented as well as tested.
Rinat: I’m glad you found it useful!