Using Expression Blend to Explore, Demonstrate, and Document Design Solutions

Demonstration and Documentation

Earlier, I mentioned that prototypes are refined demonstrations of your design intent. I did not mean to imply that demonstration is an outcome of exploration. In fact, demonstration occurs throughout the process of elaboration and reduction. However, while a simple sketch might be a great communication tool for demonstrating your design intent, it is not effective documentation. As I said before, a sketch is meant to be disposable, while documentation should be durable. A sketch does not have to tell the complete design story. It just has to tell enough to capture an idea or facilitate discussion. The same is true of a prototype. But design documentation should tell a complete story, without any outside explanation.

To create an effective demonstration of your design intent, you must consider your audience. I have no problem showing a hand-drawn, static sketch to a design-savvy crowd, who can easily see and understand the invisible behavior with little explanation. However, I am more inclined to show a digital, dynamic sketch or prototype to a mixed room. It is much easier to show rather than explain behavior, so your audience can actually see it—especially when testing your design with users. Liz Bacon, Chief Design Officer at Devise, told me, “Interactive prototypes deliver much more helpful feedback for concept testing and usability testing activities with users who aren’t trained in understanding user interface functionality.” This is also true for stakeholders who lack this training. Liz continued, “Perhaps, if a picture speaks a thousand words, we could say that an interactive picture speaks a thousand sentences!”

I do not create an abundance of documentation any more. Prototypes have become my final deliverable. The primary reason I can do this is that I work closely with the development team, so I am present and available for collaboration and support throughout their development iterations. If I weren’t as connected to the development team or was in a consulting role, I would have to consider creating additional documentation to supplement the prototype. The developers I work with have been pleased to have a prototype as their guide to building a product.

Liz Bacon told me about her experience delivering a prototype to one of her clients, “When I delivered an interactive prototype to St. Jude Medical, it became the go-to point of reference for the development team, so much so that when the final, verified requirements diverged from the prototype over the course of about a year of development, we were still seeing interim product releases that represented the feature as it appeared in the prototype!”

Dave Malouf, Professor of Interaction Design at the Savannah College of Art and Design, questions the viability of delivering a prototype as the final design deliverable. “We have to document. Even if [documentation] is an after-the-fact part of the design process…” Dave points out that various departments within your organization—like quality assurance, legal, or compliance—might need to be able to review the deliverables you create to understand parts of a product.

Dan Brown reminds us that we also have to consider other documentation needs like guidelines, standards, and pattern libraries when creating our final deliverables. The documentation facility within Blend seems limited. Pulling out the appropriate pieces for a pattern library would take some wrangling. Dave thinks tools like Blend and Catalyst need to push more into the area of documentation to be complete tools.

Though Liz and I have had success delivering prototypes to development, a prototype might not always be the appropriate choice. A prototype does not necessarily tell the complete story. I need to spend plenty of time discussing the functionality of my prototypes with my counterparts in development. There tend to be deeper behaviors that are not apparent in a prototype. While this is okay in my situation, it might not be in yours. You have to consider the context of your design effort. Dan summed this up by saying, “Team composition, approval processes, legacy technology, development culture, management structure, and tons of other constraints, both internal and external, help us zero in on the appropriate tool for doing design.”

Conclusion

Blend and other similar tools will become progressively more powerful and easier to use. As you start integrating new tools into your design process, use them to enhance your process of exploration, demonstration, and documentation. Integrating Blend into my design process has been a revelation. Now, I can finally create dynamic sketches and prototypes quickly, easily, and immediately. Here are a few things to remember when using Blend:

1. Don’t get hung up trying to create reusable, production code while designing. Doing this is detrimental to your exploring different possibilities. Instead, simulate behaviors through animation to get your intent across.
2. Don’t give up pen and paper. I still do a lot of sketching—either with pen and paper or on a whiteboard—before going to Sketchflow. Even when using Blend, I always keep my sketchbook within reach. Sketching helps me work through design issues.
3. Don’t get bogged down in details—especially visual design—when you are exploring different design options and possibilities through sketching. Dive down into the details and the visual design, once you are ready to prototype.

Remember, your tools should not drive your design process. First, focus on the design problem at hand, then decide which tools you should use to solve it. 

I would like to thank Liz Bacon, Dan Brown, and David Malouf for taking the time to respond to my questions as I pondered whether static wireframes are dead and considered the usefulness of tools like Blend and Catalyst. I am especially indebted to Dan Brown who challenged my initial premise, subsequently making me rethink the focus this article. I also want to thank Sarah Summers and Jared Bienz of Microsoft. Early on in my experience with Blend, I had a conversation with them about how to integrate using Blend into the design and development process.