Recently, I’ve had to create several in-depth interactive prototypes, and keeping all the various designs and interactions straight was a bit of a daunting task. Especially when the level of interactive fidelity was high. To ensure that I hooked up every piece of interaction and wrote every logic case needed, I took the development of the prototypes step by step, or layer by interactive layer. This post is  a brief description of the process I followed. I’d be interested to know how this relates to your own process and any other comments you might have.

My first goal was to make sure the prototype was a complete click-thru of  all the designed pages. Now, this doesn’t mean I made just the main navigation click-able, but I also linked up any cross link opportunities too. Once I verified that all of the pages were linked together and could be traversed, it was time to move on to the next layer of interactivity.

Developing the various states for each page was next. Since I was using Axure, this meant I broke out the Dynamic Panel and used it anywhere particular components of a page changed given the right conditions. This was the part that took the longest, as I had to work out all the various iterations of the same controls.  I didn’t worry too much about the specific conditions needed for the various states, as keeping track of all the logic in my head was distracting. At this stage in the game, it was  important that I got all the finer details of the interactions designed out.

Now that all of the pages were linked up, and the states created, I got started with the really intensive stuff. Getting the detailed interactive logic done was the final layer to my process. The first bits of logic I tackled were those that effected the whole prototype. A prime example of this was the logged in/logged out states, which requires multiple layers of logic to ensure that it properly affected the whole prototype. Once these general logic cases were covered, I tackled the individual cases present in each page and state. These prototypes were of decent size, so I kept a checklist handy to ensure I didn’t miss anything.

The key to any advanced prototypes using Blend 3 w/ Skecthflow is using the SketchFlow Animation Panel, the more advanced States panel, or by adding common interactive behavior to controls. Now, if you happen to have any Flash background, setting up animations will feel very comfortable for you. Below are my thoughts on how to set up some of the behavior that is exhibited by another Silverlight Prototype I put together. (Please explore the prototype to see how feedback and annotations work.)

Creating an Accordion Navigation

The image shown above was the base state of the accordion navigation I built. All of the screen elements presented are drawn rectangles rather than any control that comes along with inherited behavior. The base state is the foundation for any animation a designer wishes to built to mimic interactive behavior. From this starting state, a designer can create iterations of the screen and tie the various states together. What happens when switching between the various states is completely taken care of by Blend, very much like the tween functionality in Flash. Below are screen shots of the two other states I created, and the States panel. Notice one of the defined states returns the accordion to the base state, I am unsure if this is necessary but it worked for me.

The SketchFlow Animation Panel works exactly that same way as states, but only allows for a single animation flow. If it’s desired that the interactive aspects of the prototype be conditional, it’s required to use the States aspect of Blend.

Rollover Effects

Providing a rollover effect is a common need for prototypes. The SketchFlow Animation Panel is perfect for exhibiting this type of behavior. On the ‘Countries’ page, the sketched picture circles can be navigated by rolling over the right arrow. Here is a look at the SketchFlow Animation Panel that allows for this type of behavior.

Drag and Drop

Adding the Drag and Drop behavior is as simple as adding a property to a control. With this property added, it’s possible to place the control anywhere on the screen. Blend adds the proper code necessary, behind the scenes, so a designer can concern themselves with exploring the behavior rather than programming it. As you can see from the screenshot, there are many behaviors available that can be added to any control.

Blend is a powerful prototyping tool given that you find yourself in a WPF/Silverlight development environment. It provides the same benefits that many other prototyping tools have for other development environments. So which tool should a designer use? It depends. It all depends on the type of environment you find yourself in and personal preference. Hope you have enjoyed my exploration of Blend and if you find yourself using it one day please share your experiences.

My first introduction to Blend wasn’t a pleasant one, so bad that when Blend2 came out I promptly ignored it. However, while attending the Day of .Net Conference I sat in on a demo of Blend 3 with Sketchflow. It was impressive to see the improvement that has been made in the Blend, and with the addition of Sketchflow.  To dive deep into the capabilities of Blend, I downloaded the trial version and set out to create a prototype for a future design of this blog (and do some R&D for how to use this on my project team). Below are some thoughts I had while cranking out this concept.

Pros:

Powerful Mapping Module - Flow maps and site maps are key to any design process. Using the SketchFlow Map module, a designer can make either of these very quickly. Blend 3 takes these models a step further by breaking them up into two types. A Screen represents a unique page in the design, allowing for a detailed set up of the overall structure of the site or application. Components are aspects of a page that can be used on many screens throughout the design. The SketchFlow Map module allows for connections to be made between the various screens and components in order to properly showcase the relationships that are involved. The various Screen and Components nodes can be customized via coloring coding in order to convey some deep meaning. In my example, blue nodes are main pages, green nodes sub-pages, red nodes navigation components, yellow nodes UI components, and orange nodes form components.

Components - Creating components that represent shared aspects of the overall user interface is a huge boon. Only having to create a form that is used on half a dozen pages only once not only saves design time, but also removes a lot of repetition in our work. Other applications have a similar concept by the use of master pages, or template, but the downside of these overall frameworks is when only certain aspects of the framework need to be used.

Low-Fi Look and Feel - The name SketchFlow really holds true with the overall style that is applied to produced prototypes. Though it is obvious that they were created with the aid of some program, the prototypes look down and dirty enough to really get the message across that this is just a concept. Though I haven’t tried it yet, during the demo of Blend3 it was stated that user defined controls can be created and the sketch style applied to them in order to maintain the low-fi look.

Behavior Set Up - A prototype isn’t really a prototype unless it has some level of interactivity. Setting up a simple click thru is as simple as can be. Through the use of the animation module, some pretty slick behavior is possible to set up without needing to get into the code. But, if you happen to have some basic skills in C# or VB.net, it’s possible to add some pretty complex behavior as well.

UI Control Library - The library of controls that comes included in the SketchFlow style covers just about any standard control you can think of. Included with all the standard controls are simple shapes that may need to be used for a variety of reasons. When prototyping is complete, and approved, a developer can simply remove the Sketch styling and all controls revert to standard Windows styling and are ready to be hooked up. (In theory)

Adobe Import - Blend has the ability to import any layered file from either Illustrator or Photoshop.  Each layer gets inserted into the Blend project as a user control, which upon import is just an image. Once imported though, you can tell Blend that this image of a text box is an actual text box, and poof it’s a text box and all the styling from the image is retained. The has great benefits for the interaction designers, visual designers, and user interface developers that work closely together.

Animation - Todd Zaki Warfel has a great quote regarding prototyping, ‘If you can’t make it, fake it.’ The animation capabilities in Blend3 allow you to fake just about anything, depending on your animation skills and maybe some C# or VB.net knowledge.

Right Click - Inside the Blend3 environment, right clicking is really your best friend. The majority of the settings and commonly used functions are available via this little context menu. This is also the main method for which to set up any type of click-thru behavior you want presented in the prototype. Denny Payton, who gave the Blend3 Demo, made that comment ‘If you are not sure how to do something in Blend3, just right click.’

Annotation Feedback - Any prototype created in Blend3 can be packaged as either a Silverlight application, or a WPF application, and shared among the project team, stakeholders, or used for some user testing. The method of annotation is great, as people can grab a virtual pen or highlighter and mark directly on the prototype, these annotations are stored with the actual project for review later. A message box is also available for more detailed feedback and all is captured in the project files for reviewing later.

Test Data - Lorem Ipsum only gets you so far when adding content to a prototype. Plugging in real world sample data can be done in a variety of ways. If you happen to have a functional test database, tables from the database can be bound to any control. Something that was removed in Blend2, but added back in Blend3, is the ability to bind to an external XML file. The real gem of Blend3′s test data capabilities is creating some on the fly, and storing it locally to the project. This way drop downs and list controls don’t have to be empty and the data inside them isn’t hard coded.

Cons:

Buggy - During the course of creating my prototype the application bombed out twice. Now, some might say crashing only twice doesn’t sound that bad, but any crash is bad in my eyes. At first, when creating the sitemap, somehow two of the nodes had become linked together. Moving the most recent one would also move the last selected, the solution came during one of the crashes when the behavior went away when I reloaded Blend. Though the layout of the framework is pixel perfect between the various screens, some UI controls still jump around in the produced prototype. For someone who is a perfectionist in this regard, it drove me batty!

Interaction Design of Blend3 - For some reason, someone thought that the most common use of the scroll wheel is to zoom in and out of the both the Design module and the SketchFlow Map module. Eventually, I found the setting that allows you to rebind what the standard behavior is for the scroll wheel and my frustration eased. The only way to remove a node or connection in the map module is by right clicking and choosing remove from the menu. The delete key is completely ignored from this aspect of the UI. This caused many mental ‘WTF?’ moments.

Structuring Site Map - While the SketchFlow Map module provides great value for visualizing the structure and flow of a site, it’s easy to create a very complex and confusing map for something more than a simple site map. It becomes difficult to follow the connection lines with the crisscrossing of each other, or placing component nodes in a meaningful location when they are shared by many screens. Hopefully, in future versions this module gets a bit more flushed out.

Component Placement - Creating common aspects of the user interfaces once, but using them in many places, is a great advantage for any designer. But, the component has to be placed individually on each screen it’s linked to. This can make the prototype look clunky since the same component might jump around as the prototype is traversed if not placed exactly right. This could be easily fixed if the background size of each component was the same as the overall size of the interface. When linked to a screen, the component gets  automatically placed in the proper place.

Screen vs Artboard Size - There is a huge disconnect between the size of the screen and the artboard that contains the UI controls. Now, I understand this disconnect is in place for detailed animations, but it would relieve some confusion when creating just a simple interface with no animation if the sizes were tied together. For the prototype that I created, it wasn’t until I ran the project that it became apparent that the screen size did not match the interface I had created.

Grid System - Though Blend3 has an underlying grid system you can use to place controls, it isn’t possible to create grid lines on the fly that are shared across different screens. This was the other reason why when the prototype was ran, the screen components would jump around on me. It’s possible to customize the underlying grid system, but it is application wide rather than limited to just the project.

Adobe Import Limitations - The way Blend3 imports the files from Illustrator or Photoshop put a huge burden on the designer working in those applications. The layers need to be set up so each UI control has it’s own layer and the layers are organized in a detailed manner. Now, having organized layers in either Photoshop or Illustrator is the ‘right’ thing to do, but sometimes time just doesn’t allow for it. It’s a good step in the right direction, but still needs a bit of work.

Word Export - Axure is hands down the best when it comes to turning a prototype into spec, Blend3 is taking it’s best stab at it too. The downside being that the produced document is very flat and only creates the images of the user interface. It can be argued that any spec is better than none, but there’s some good information you can attach to controls when they are being placed that don’t get exported into the document. Again, good first step and it will be interesting to see how this feature gets flushed out in the future.

Annotations Limitations - While being able to annotate directly on the prototype is great for gathering feedback, but in Blend3 it’s limited. Annotations are not store per instance of the prototype, but shared across different uses. This pretty much limits prototype review to internal teams and maybe key stakeholders. Allowing the annotations to be shared while performing user testing raising the risk for bias and invalid results. This seems like a simple enhancement to this features, and hopefully become available one day.

Media Sketch Controls - Though the control library available in the SketchFlow part of Blend3 provides almost any ui control you would need, it is missing a few. Generic placement boxes for media, like pictures or videos, are missing. Requiring the designer to use the generic shapes and text to put in placeholders. Granted, you could create a user control to fulfill this need, but it would be nice for generic media controls to be available out of the box.

Repackging Prototype – One of the promoted benefits of using Blend is to create a prototype or interface that could be used in either a WPF or Silverlight application. Sadly, it isn’t possible to just repackage a project into one of these formats when using SketchFlow. So, if you create a kickass prototype in WPF and want to host it as a Silverlight app in order to get some feedback, sorry that’s just not possible. (Like I wanted to do!)

Overall Thoughts

Seriously, kudos to the designers and developers at Microsoft for getting Blend to such a state that you can do create some kick ass prototypes. Though it has some flaws, like any piece of software will, it provides some great benefits for designers. The value could really be seen for any designer working in a Microsoft development environment, creating Silverlight apps or Desktop apps using WPF. The need for other prototyping tools like Fireworks or Axure that don’t necessary provide good output for developers in this type of environment could be replaced by using Blend3 with Sketchflow. I’m not saying one tool is better than another, but when you take into account the environment the project is being developed in, one tool may be more beneficial than another.

Images from the prototype I created

Seeing Things Differently – It is always best to keep in mind the people that always need a little help.

Designing A Unified Experience – Kim Goodwin gives an outstanding overview of design. Great video to check out.

Todd Zaki Warfel – redUX DC ’09 – Todd gives us a great run down of the workshop he gave on prototyping at the IA Summit back in March.

So You Wanna Be A UX Designer Part 1 – Beginning of the roadmap to success for any UX Designer. If you care about UX and haven’t seen this yet, check it out!

Being An Experience-Led Organization – Johnny Holland delivers up yet another gem.

Understanding Critical to Being Understood –  Rather than playing the give and take game, converse with each other and great something great.

247 Web Usability Guidelines -  Monster list of heuristics to consider when reviewing a design.

You Can’t NOT Afford Good User Experience -  Great resource for anyone looking for ammo to sell UX internally. Stated so simply it is amazing that some people still don’t get it.

Prototyping Makes You Tell The Right Story – I am not ashamed to say the kid in this video is better at explaining a design than I am.

10 Best User Experience Design Blogs – If you are looking to fill up your RSS feed some more, here is a great list for you.

If there was a best of show award given at the IA Summit, Fred Beecher’s (twitter) track on prototyping would be one of the nominees. Jonathan Knoll (twitter) summed it up best by stating ‘@fred_beecher‘s prototyping session is turning into the most directly educational & practical I’ve seen in a long time.’ Below are my tweets from the presentation:

Prototyping is just a tool to communicate ideas and explore ideas.

The level of prototyping depends on the level of fidelity you need.

Fidelity has two types of dimensions: Visual Fidelity, lowest form is sketches. A sketch prototype is more than one page.

Highest Visual Prototype is colored JPG pages.

The second dimension of fidelity is functionality, how interactive the prototype needs to be.

Proof of concept allows you to test an idea in an interactive way to see if you are on the right path or not.

To get a good idea of if some of the design ideas work, it is important to test them in an interactive method.

“Slap & Map” image mapped jpgs offer a great middle ground between high visual fidelity and mid-level functionality.

Problems with production level prototyping is that it can constrain the design. As a designer we need to be free to explore.

People in development are creative, and they can offer insights into many design issues.

Content is another dimension of the fidelity of a prototype. Your prototype isn’t just about interaction, but also the content.

The screen just randomly rolled up into the ceiling for @fred_beecher, doing a great job just rolling with it though.

Content doesn’t need to be perfect, you just need plausible content the makes sense to the user when testing it.

“There is no such thing as high or low fidelity, only appropriate fidelity.” Bill Buxton

You can also test out the various concepts to see which work and which don’t.

Prototyping also allows you to have the conversation about ‘Is this what you meant?’

LVF/HFF prototypes are good for using testing as a design tools. It tells the designer if their ideas work or suck.

Proof of concept testing of isolated interactions, the design may work but it tests if the necessary interactions work as well.

Interactive prototypes supplement documentation for the development teams. Visually express the desired interactions.

HVR/LFF prototypes are good for discovering usability problems introduced by visual design.

You are able to find problems with the workflow when testing with non-savvy user groups.

HVF/HFF enable user testing as a design tool when testing new functionality into an established system.

This type of prototype gives you supplemental documentation for OFFSHORE dev teams.

“People are dumb and we like shiny and movable things” @fred_beecher

Know what questions you want your prototypes to answer, early in design the questions are structural, later questions about usability

In corporate agile mature ux organization use prototypes to show small complex proof of concepts.

Corporate-Waterfall-new to UX start off by developing detailed scenarios you want to test.

Walk through the interactive prototype using the printed documentation with developers and stakeholders.

Consulting/Agency Develop the detailed scenarios you want to test, sketch 2 oe 3 of your UX design concepts into small prototypes.

It is important to keep clients involved in the process, walk them through each prototype and gather their feedback.

Last context is when doing Hardware Devices. First step, once again, develop detailed scenarios you want to test.

Do as many iterations of a low functional fidelity prototype as you can.

Creating wireframes and prototypes are an important aspect of what an interaction designer does, and one of my personal passions. The key takeaway from this track was the methodology for the various forms of fidelity a prototype can have and the situations they are best utilized in. It is a fine line between having a detailed design and a conceptual design. Using Fred’s process for developing prototypes, a designer can better gauge when they need to do something more conceptual, or get down and dirty with the details.

Integrating Effective Prototyping Into Your Design Process

View more presentations from Fred Beecher.