With the recent release of Silverlight 3 we also got a new version of Expression Blend. This new version, Expression Blend 3, includes an exciting new feature called “SketchFlow.”
Introduction
There are three main aspects involved in SketchFlow: Sketch Styles, SketchFlow Map, and the SketchFlow Project. In this blog entry I’ll look at each of these aspects and how they can help us build a prototype of an application. First, however, let’s look at a brief overview of when this is useful.
When starting a new project one of the first processes is to figure out what data the project will present to the user, and how this information should be laid out. This is usually the work of an Information Architect or a User Experience expert. When the IA or UX finishes their discovery process usually what comes out is a PDF document with annotated wireframes. These go to the designers and the designers put a pretty face on it and produces Photoshop files (PSD’s) that the Interactive Designers/Interactive Developers need to translate into a fully functional web site/web application/Rich Client Application/Rich Interactive Application. Sometimes you will be lucky enough to work with an IA/UX professional that will write up very detailed functional specifications, but in most cases an annotated comp is all you get. In extreme cases you’ll only get wireframes, site map, and the designer’s PSDs, but that’s a whole another headache waiting to happen.
I digress, this black hole of information that isn’t gathered in most cases and only written in plain English in the best of cases really needs to be improved. This is the “need” that SketchFlow solves.
Imagine if the IA/UX person could easily prototype the application in such a way that not only would the stakeholders be able to “play” with it, but the stakeholders could also make comments on it from the comfort of their own browser and send those comments back. Oh, and then add in the ability to export it all into a basic set of functional specs complete with screen shots. That is what SketchFlow provides.
I know what you are thinking because I’ve been there before. If the stakeholder sees something that is too functional they’ll think it’s finished. A statement like, “Great, so when can we go live” comes to mind. Well, SketchFlow comes with a resource files that contains styles called Sketch Styles.
Sketch Styles
Sketch Styles attempts to solve the “blue button” problem that can stop progress in a demo meeting with stakeholders. The “Blue Button” problem is the one where the wireframes look too polished and a stakeholder asks if you could make the button blue, or ask why the site doesn’t use the corporate color standards. Instead you can show the client something that looks like the image above.
This is an image of a hypothetical prototype application. It’s hypothetical for this blog, but I’ve done this for other apps and it works pretty well. However, the really cool thing here is that although this looks like a crude drawing (except for that stick figure next to a graph as that truly is a crude drawing) it is 100% functional. On the left there is a real list box, and contained within that real list box are real buttons. Those real buttons are hooked up to logic that actually changes the page when viewing this prototype in a web browser. It is only the style that makes the list box and the buttons look like a crude drawing. This crude drawing style is there in an attempt to get the stakeholders to look beyond the surface and think about what the application actually does.
SketchFlow Map
As I said earlier the buttons on this prototype actually navigate to the “Home,” “About,” and “Tickets” pages. I managed to quickly setup these pages using the “SketchFlow Map” feature in SketchFlow. This is seen in the image to the left here.
The map always begins with the first page. From there you can create as many connected screens as you’d like. This map is a great replacement for a “Site Map” because this map actually represents actual pages in the prototype. You can color code the pages, create connected components, and arrange the pages in the map any way you’d like. This information is also presented in the SketchFlow Project that we’ll look at in a minute. One more place that this information appears is in the export to Word doc. Again, this makes it a handy starting point for the functional specifications.
SketchFlow Project
Once you’ve mocked out the entire application you can export the prototype to a SketchFlow Project. Then just host the project on a web site that the stakeholders can see and you have a platform for very rich interaction between clients and developers. I won’t discuss all the features of the SketchFlow Project, but it is a very handy tool to let the stakeholders see the progress of their application as it is still in the ideation stage.
The stakeholders can make comments, highlight sections of the prototype, and draw all over it. However, to get that feedback back to the IA/UX teams is a rather cumbersome process that itself is more of a proof of concept than a fully baked product. After the stakeholder marks up the prototype, they can save those comments out to a XAML file and then E-mail that XAML file back to the IA/UX team. Then the IA/UX teams have to import that information into their SketchFlow prototype. To make this just slightly more complicated, that import action is hidden be default. You have to enable a “Feedback” pane by an option in the “Window” menu. Then you can load in the feedback. Granted that feedback pane can contain a whole history of feedbacks, but it just seems lightly less thought out than the rest of the product. This is only a Version 1 product (the SketchFlow part, Blend is actually a great solid Version 3 product) and as such I’m sure this process will be better thought out in the next version of the product.
So Where Does that Leave Us?
This has been just a real quick overview of the main features of SketchFlow. I haven’t even mentioned how you can create a temporary dataset for use in the prototype among lots of other little features. There are two (2) main issues that I have with this whole prototyping idea.
The first issue I have with this whole workflow is that regardless of how many times you tell someone that what they are looking at is a prototype and they shouldn’t look at it for style or color, but for functionality they will immediately ask you to change the font. I can hear it now, “That title has to be in Segoe, and where is our logo and the consistent user experience?” On the other end of that spectrum are the customers that like the look of the sketch style and approve it to be in their application. Give it about a year and I’m sure I’ll be running across live applications that are using that sketch style.
The second issue I have with this workflow is that far too few companies are willing to expend any amount of energy on a prototype that is throwaway code. What this means is that after the prototype is finished the powers that be will demand that the prototype code is used for the basis of the real application. I mean, it’s just a sketch style, can’t you just change the style to Contoso Corporation Style and it’s finished? If all you are looking at is the look and feel of the application you’d be 100% correct. However, there’s a reason that the instructions to “Convert into a production project” are 6 or 7 printed pages. It’s really not recommended!
The prototype was built for speed of delivery, not for security, upgradability, or maintainability. The code behind the prototype that is delivered isn’t using any best practice of software architecture or a development pattern of any discernable type. The code in this prototype is throw away. Just think of it this way, would you have your software developers write the site copy? No. In that same way you shouldn’t let your IA/UX people write any final production code. They used SketchFlow to get an idea born and to play with it. The useful parts of the prototype are the ideas that come out of it. The functional specifications are still the final delivery of IA/UX, it’s just that in this case instead of flat 2D wireframes, the developers and designers actually have a prototype to play with as they are doing their job.
Far too many people trivialize the role of the developer. It is important that people understand that a developer is not just a glorified typist. Clearly you hired experts in usability and information architecture to do the IA/UX work, and you hired experts in design to do the design work. Let the experts you hired to write code, write code. Don’t trivialize their abilities by forcing them to try to repurpose prototype code for a final product.