SketchFlow: Prototyping for Expression Blend
Author: Christian Schormann, Program Manager, Microsoft Expression
subscribe now to get yours.
The Expression team at Microsoft has one simple mission: Make tools that enable designers to create outstanding user experiences. Expression Blend is our authoring environment for rich interactive applications and content, targeting WPF and Silverlight.
Expression Blend has historically been focused on production tasks: creating designs, layouts, animations, skins, or controls for the final software products we create.
However, we very much realize that in order to enable great user experiences, it is not enough to only support production. A lot of what makes or breaks a great product usually happens earlier, when the product is designed.
One of the techniques of a good design process is prototyping. There are, of course, two factors behind it. One factor is that many complex systems, including software, are hard to judge on paper. Instead, we have to touch them, interact with them, see them and hear them. The other factor is that, as the saying goes, there is no better way to have a great idea than to have many ideas—and by extension, to have a process that can quickly and cost-effectively evaluate and reject or approve ideas. In the end it comes down to this: Find out which ideas really rock early—cost-effectively and safely.
And this is where SketchFlow comes in: SketchFlow is a fun, informal, flexible, quick and powerful way to sketch and prototype rich, dynamic interactivity with Expression Blend.
Prototyping with SketchFlow
SketchFlow addresses three pain points in software sketching and prototyping:
- It makes it easier to experiment with ideas for dynamic user interaction.
- It facilitates communication of design ideas and intent between designers and other stakeholders.
- It makes it easier to gather stakeholder feedback, to evaluate and use to refine design ideas.
SketchFlow helps to fulfill two goals: create better software products and reduce the cost of design and design communication. This is not just important in design teams that need to define their products, but it also helps, for example, design agencies that need to respond to RFPs in a cost-effective and compelling manner.
In the remainder of this article, we will explore the motivation and concepts behind SketchFlow in greater depth.
As designers of software products, what we build every day has become much more complex, richer and more dynamic over the years. Creating, describing and communicating design ideas and specifications for modern user experiences have accordingly become more involved.
In many ways, one of the earliest roots of SketchFlow grew out of frustration with the process of mocking up and evolving design ideas for dynamic interfaces. We also talked to other designers involved in various parts of the software sausage factory, and the pain points we heard were similar to our own:
- It is too hard and time-consuming to create compelling prototypes
- Communicating a design idea accurately and convincingly is hard
Part of the problem, we realized, was that almost all the tools for design work available were built with the needs of production tasks in mind: It was all about quality, polish, driving decisions, and creating shiny finished assets. Our mindset during early-stage design is usually quite different: We want to explore, expand the design space, be vague, tentative. Yet we still would like tools that “read our mind”—tools that understand our design intent and help us do a better job.
Early-stage design of course is a wide field. With SketchFlow, we wanted to create a tool that would make it quick and easy to outline an experience, and to rapidly evolve it to represent as much of the dynamic aspects of interaction as cost-effectively as possible, so that we could try out more ideas before committing to a particular design.
We also wanted to help communicate: a tool that would enable more stakeholders of the design process to explore and evaluate the prototypes, and to provide feedback to the process.
We wanted to let you create living and breathing specs that bring your vision to life for all to see, helping us all to make more informed product decisions and end up with better products.
SketchFlow is the first product of this journey.
The SketchFlow Map
In SketchFlow, the SketchFlow Map lets you model the flow, navigation and composition of your app.
What does that mean?
A SketchFlow prototype is made up from a collection of screens . You can think of a screen as Window, or a Dialog, but especially in an early-stage prototype, I just like to think of a screen as a whiteboard on which I can sketch anything I like. Maybe I just start with a pencil drawing, a sticky note or a picture. As the prototype evolves, and I develop a clearer idea how the actual UI might look like, I replace the sketches with real UI. In the SketchFlow Map, a screen is represented by a colored rectangle.
Screens can be connected in the map to indicate that you can navigate from one screen to the next when the prototype runs. This is kind of like making a slide show in PowerPoint, except that the Map is not a flat list, but lets you connect your slides into any graph you like—one screen can navigate to multiple others and back. Navigation is represented by solid colored arrows that go from one screen to another.
One screen on the SketchFlow Map is always designated to be the Start Screen . This is the screen that your prototype begins with once you run it. You can make any screen on the Map the start screen.
Many times, when you think about UI, you automatically think about components , implicitly or explicitly . For example, as you think about a shopping page, you know your page has a catalog area, a menu and a shopping cart. It is often useful to show the existence of these logical components of your app in the “mind map” of your prototype.
This is what SketchFlow component screens are for. Component screens are just like other screens as far as their content is concerned, but they are never navigated to. Instead, they are inserted into normal screens, just in the same way as you would insert a menu on a page, or just as you would insert a table symbol in the floor plan of a dining room in an architectural home planning program. You can of course use the same component on multiple screens. Component screens are displayed as “oil tank” shapes on the SketchFlow Map.
Component insertion is represented in the map with a dashed arrow that goes from the component to the screen it is used on.
Did I mention, by the way, that you can import PowerPoint presentations to create a series of screens? Currently, this imports each slide as a picture only, but it makes it really easy to import existing click-through prototypes as templates for further work in SketchFlow.
Using drawing tools, sticky notes and pictures to begin a prototype is all good and well, but after all we are building UI prototypes—so at some point you probably want to begin putting some UI controls on your screens.
Because SketchFlow lives in Blend, you can of course use any built-in WPF or Silverlight UI control or layout panel, and there are tons of external controls from third parties that you can use as well. You can also use WPF or Silverlight control libraries that you might already have.
The standard UI controls have a nice, polished look. This is good for a real application, but not always ideal for a prototype: If you show polished content too early, people evaluating the prototype easily focus on the wrong things, the details of the look in particular, even if the explicit purpose of the prototype is to look at the structure and concepts. It is just a human thing to do. Additionally, especially with customers, we often want to avoid giving the impression that we are further along than we really are—polished looks easily tempt customers into thinking they are seeing more than there is.
Because of this, SketchFlow comes with a set of Sketch Styles that give the built-in controls a look consistent with a prototype: wiggly lines and sketch fonts are used to create a sketchy look. But even with the sketch look, the controls are real functioning platform controls—the power of control templates lets us just replace the skin. You can of course at any point reset the control template to the original to get the platform look back.
Once you have any SketchFlow map, even the most simplistic one with just a couple of screens and a little drawing on each (well, even when you have one that is entirely empty, although that is not particularly useful), you can run your prototype.
You might ask yourself how you can interact with a prototype that you haven’t given any UI yet? This is what the SketchFlow player is for. Every prototype you build is running inside the SketchFlow player. If your prototype is WPF, the player is an app. If your prototype is Silverlight, the player is running in the browser.
Either way, the player is part of your prototype and you can distribute both together.
The SketchFlow player has two important functions:
Basically, the player adds “training wheels” to your prototype so that you can navigate and explore even if there is not a tiny bit of actual UI on the screens you have created yet. That allows you and other stakeholders to look at concepts, logical distribution, scope of screens and all the other important high-level decisions.
The player also allows anybody who explores the prototype to add feedback. You can type in text comments or use digital ink to draw right on the prototype. You can then export the feedback and send it back to the designer, who is then able to see it as an overlay on the Blend art board, making the feedback loop between designer and other stakeholders a bit tighter.
In the picture, the red and green markup was added in the player as feedback. There are also text comments to the left. The following screenshot shows that same feedback after importing it into Blend, right on the design surface:
Almost any design project needs design documentation. SketchFlow can export your prototype to a Microsoft Word document. What you get is a document that contains screenshots of the Map, as well as every screen and component screen you have in your project. You also get a table of contents and a table of figures. That can save a lot of work when preparing the paper trail that is often a project requirement.
SketchFlow by default uses the standard Microsoft Word template you have on your machine, but you can also specify a custom template.
In an early stage prototype, we often want to communicate a design idea really quickly and easily. Animation is a great technique to do so. SketchFlow of course offers a complete set of keyframe-based animation tools that let you create as many animations for a screen as you need. You can set up your animations in such a way that they show up in the SketchFlow player helper UI for navigation, so that it is really easy to run and show animations as part of a prototype presentation.
For all its power, however, keyframe animation is not always the most effective way to create walk-through-style animations. You simply have to create and manage too many keyframes, slowing you down unnecessarily. Because of this, SketchFlow offers a special animation method called “ SketchFlow Animation ” just for these “ show-what-this-UI-does-step-by-step ” animations. It pretty much works like clay animation: Add a story board frame, and arrange your screen to look the way you like. Repeat as often as desired.
For each storyboard frame, you can set a hold time (how long do you want to show this frame) and a transition time (how long does it take to transition from the previous screen to this one).
For those of you who have been using Blend before, you of course know that States are really not a new concept of SketchFlow, as they were introduced with Blend 2 SP1. However, states are so incredibly useful for prototyping that I want to mention them specifically in the context of SketchFlow.
States are very prevalent across almost all UI. We find them at various levels of hierarchy. For example, buttons have different visual states depending on if they are pressed, hovered or disabled. A web page might show itself slightly differently depending on whether a user is logged in or out. Components on a screen might be collapsed or expanded.
In principle, we can model state in a prototype by using separate screens. For example, we have a screen that shows the web site in normal state, and one that shows the same web site when a user is logged in. This is quite possible, but not always the most convenient or efficient.
Visual States are often a better technique to use. Basically, think of a visual state as a snapshot of your screen. When you switch between states, you switch from one snapshot to another. States are really easy to create—just add one and then arrange the screen’s content as you please.
States are grouped into State Groups . This allows you to overlap multiple partial states on a screen, which is incredibly powerful. As an example, you might have one state group that modifies UI elements that need to look different depending on whether a user is logged in or out, and another that represents whether the shopping cart is minimized or not.
States can also contain animations , which is a very nice bonus.
And to round the story out, we support smooth transitions between states that can be controlled in a flexible manner.
The following screenshot shows some predefined easing functions for transitions:
Wiring up Navigation and States
Using the SketchFlow player to explore a prototype is really helpful. But at some point, you’ll want to wire up actual UI controls on the screens to cause navigation and state changes. In SketchFlow, you can interactively wire up navigation, state changes and many other behaviors without any code. Because navigation and state changes are so common in prototyping, SketchFlow introduces special short-cut UI just for this purpose.
Blend 3 Concepts that REALLY help with Prototyping
Blend 3 introduces a whole set of features that give prototyping an extra dose of power and enable you to make it as real as it needs to be. There is no space here to explain these in depth, but there are already posts on my blog and the Expression blogs on most of these:
- Adobe Photoshop and Illustrator import. This does just what you would expect: Faithful import of Photoshop files, preserving layers, vector data, and text information. This makes it really easy to integrate Photoshop comps into a prototype. Also note that Blend 3 introduces a feature that lets you convert any graphics, including those coming from a PSD file, into a control skin.
- Data Binding and Sample Data. Many applications today are data-driven, and mocking up data-driven applications is traditionally a pain. Not so with Blend 3: Sample data lets you create meaningful sample data on the fly, and you can build working data-bound lists and master-details views just with drag-and-drop. You can even use a Photoshop comp as the visual template for your data-binding. Watch the
MIX keynote or the
launch keynote for a sample of that.
- Behaviors. Behaviors are a mechanism that lets you add production-quality interactivity to your prototype with drag-and-drop. Behaviors are packaged, re-usable patterns of interactivity. We ship Blend 3 with some basic ones, but the mechanism is extremely extensible, and there are already several new libraries on our web site, including a set of physics behaviors. Behaviors and sample data together allow you to create deep interactivity in prototypes that would have required serious coding before. More on behaviors in
my March 29 blog post.
- Workspaces. You can now create your own panel configurations in Blend and save them as custom workspaces. This enables you to adapt Blend to your tasks and needs. Especially when building early prototypes, for example, you don’t need most of Blend’s UI. You can easily hide it away by just making a custom workspace. Go to
my July 10 blog post for a post that explains how...
There are several demo videos ready to watch online:
There are also a couple of samples that are included with the Expression Blend download.