Monday, August 10, 2009

Real content in design prototypes

I came across this article at Boxes and Arrows about the value of using real content during the design process: http://www.boxesandarrows.com/view/the-content

“As web designers and information architects, we often dismiss deep consideration of content when we design interactive experiences. By content I’m not only referring to the various forms of text (e.g., headers, body copy, error messages) but also imagery, graphics, and videos or audio that make up the full interactive experience.

Sure, we have a sense of what content is available, and we’ve likely considered it to some extent when creating flows, wireframes, and prototypes. But the design artifacts that we create represent only part of the overall user experience that we’re designing. The content that sits inside of our design framework is often the final arbiter of success, yet we sometimes diminish its importance and separate ourselves from it. The more we separate our design activities from content development, the greater the risk of design failure.”

Recently I was designing a new navigation system and was asked by my UX manager to not use real content, so people could focus on the actual navigation system and not on the content. Also, since this was a navigation system for a set of products, the prototype needed to be generic.

I can see the pros and cons to this request. During the first round of feedback sessions I had fake content in my prototypes. I was able to focus on the actual mechanics of the system quite easily, but I received a lot of questions around if I’d tried to integrate real content to make sure it works. There was a lot of effort for people to imagine how it would really work, and questions about if I considered x, y, z content use cases.

For the second round of feedback I used real content. Having the content helped me find problems early on (can these products’ models work in this structure, spacing issues, size limits, etc.). During feedback sessions, this did help people to understand how the system would actually work, but it also added another level of distraction. The focus would move away from the navigation system and discussions cropped up around the content.

Though more time consuming, I felt having both versions was helpful. Starting with a prototype without real content allowed me to focus on the system itself, and then adding content was like a first test, and gave different, but still useful feedback.

1 comment:

  1. I have found that real content can make a world of a difference when showing a demo or prototype of your software system. I have done several prototypes at work and we always use a client's real content. We also provide a UI or skin that shows the client specific logo, colors, theme, etc. Real content helps show the software system in the client's specific context or frame of reference. Because you are walking the client through the software system with their own real content, they can actually see how the system will work with their content instead of having to visualize it. When you don't have real content or the client's specific content you will often get questions about the content that have nothing to do with system or a particular feature.

    ReplyDelete

Note: Only a member of this blog may post a comment.