First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

After almost one year of using Balsamiq I decided to give Blend SketchFlow a try. After using it in one project, I realized it’s not a sketching/mockup tool. And here I’m telling you why.

My definition of a sketching/mockup tool

I think a sketching/mockup tool should be a replacement for sketching on paper. It should allow you to “draw” lines, add a textbox and some text, without thinking too much about alignments and about how you will “implement” UI element in the real application. And must have a quick way to include common UI elements like windows, dropdown, tabs, grids and so on.

Test-driving SketchFlow

SketchFlow could be improved in many ways, but there is one main point that would probably need a more high-level rethinking: it’s not intuitive and forces you to think too much about how the design will be implemented. But let’s look at it in detail:

New Project window: SL or WPF?

First thing I didn’t like is the “New Project” window: why do I’ve to choose between a Silverlight and WPF application? What if I want to prototype a web application?

You have WPF/SL Controls

There is only a very small selection of sketch components and for most of the complex UI elements you either have to design them with lines and rectangles, or have to use the standard SL/WPF controls. For example you have to use a DataGrid if you want to display a table with data. Or the calendar, the canvas layout, the stack panel, the grid layout and so on. This is a problem because it forces you to think in terms of controls rather then in terms of sketches.

You need to understand data binding

If you want to add text to a list, a combo or the aforementioned data grid, you have to understand data binding: add a sample data source, bind it to the UI element and configure the visualization options.

Default style is not a sketching style

One last point is that I would have expected to have the sketch style (the wiggling stroke) by default. But the default style is the standard WPF/SL one. To get the correct style you have to click on the tiny little arrow button and choose from the big list of controls.

Advanced animation

With SketchFlow you can do fancy animations or state transitions, but I don’t think this increased power will be used by interaction designers and by UI experts. And since these advanced features must be developed with code (or by dragging behaviors) I think they are just adding complexity if you all you want is a sketch of your application.

Wrapping up

Probably I was using SketchFlow for the wrong purpose, but it seems to me like a tool for prototyping the UI of a WPF/SL application rather then a general purpose sketching application.

After using SketchFlow in this project I think I’ll never use it for sketching web applications again. Probably I’ll use it when I’ll need to design a WPF/SL app, but not for web apps. I’ll stick to Balsamiq for now.

What can Balsamiq learn from SketchFlow

But not everything that SketchFlow has is bad. It also has some interesting features that I’d love to see also in Balsamiq:

  • the navigation tree that makes very easy to create the “flow” of the application (Peldi says they are working on it)
  • the possibility to “componentize” some parts of the sketch, like a navigation bar that is the same in every screen (There is a lot of talking on this in Balsamiq forums)

Exporting a Balsamiq sketch to a player

Another feature of SketchFlow that I now I want so badly with Balsamiq is the possibility to export a “playable” version of the sketches for sharing with stakeholders. And you can do it now using Napkee, a very nice AIR application that can export Balsamiq projects to both Flex or HTML/CSS/JS.  There are also other opensource tools to export to various other formats.

posted on Thursday, November 26, 2009 8:06 PM

Comments on this entry:

# re: Why SketchFlow is not a mockup software

Left by Peldi at 11/26/2009 9:42 PM

Hi Simone, thanks for the review! One feature you might like is the new "export to PDF package", described here:

# re: Why SketchFlow is not a mockup software

Left by Steven Quick at 11/26/2009 10:42 PM

Have you tried MockingBird, looks very promosing..

# re: Why SketchFlow is not a mockup software

Left by Simone at 11/26/2009 10:55 PM

@Peldi: SketchFlow has an export to Word document as well, but I didn't even mention it because I ended up exporting to Word just to copy&paste the screenshots to another document with the company's template and all the other paragraphs and diagrams. I'd love to see a "batch export to jpg" feature instead. (even tho I think I've seen some scripts somewhere)

@Steven: I'll give a try, but from a first look, it seems a bit under-featured compared to SketchFlow and Balsamiq. Nice thing is that it's all JS without any external plugin :)

# re: Why SketchFlow is not a mockup software

Left by Steven QUick at 11/26/2009 11:12 PM

MockingBird beta only started in November so theoretically it can only get better.

If it gains any ground the competition between it, Balsamiq and any others should be interesting.

# ...because SketchFlow is a prototyping software!

Left by Cristiano Rastelli at 11/26/2009 11:26 PM

Hi Simone.
I agree with you about the lack of native controls with a sketchy look&feel, but I think you could build your own with little effort; same thing about data binding: it's not that hard, it's quite intuitive (also for a simple designer, as I am). I also agree that the sketching style should be the default, this is very tedius thing that should be fixed.

I also agree with your conclusion: SF is NOT a "mockup" software, but a "prototyping" software. But that's its value, not its defect!
It's not for designing interfaces or creating quick visual mockups (use instead napkins, paper, Fireworks, Balsamiq): it's for building "fake" real and interactive applications. You use it to test the application logical flow between pages/screens and check functionalities from a "interaction design" point of view.
That's the reason for which you have to choose between WPF or Silverlight, because they have different controls and behaviours (even if the output is the same, a "player" of a sketchflow prototipe, that can accept comments and reviews from your customers/users).

Being a "prototyping" software means that you can give a full functional and interactive application to your customers/users, and have feedback and rewiews from them _before_ the real coding of the application, but reusing large parts of the code developed in the SF prototype development (tipically the behaviours).

And last, don't forget about the "export to word" feature, that can save you a lot of time if you need to write some specs or ducumentation.

(Other discussions, but in italian, here: )

# re: Why SketchFlow is not a mockup software

Left by daniela at 11/26/2009 11:28 PM

I found very useful the SketchFlow possibilitiy to have a real demo, but it has to many tools to manage and it lost the semplicity and the speed thinking of the first stage of prototyping

# re: Why SketchFlow is not a mockup software

Left by Cristiano Rastelli at 11/26/2009 11:39 PM

@daniela: think to SF as the stage _after_ the rapid prototyping phase, when you have to convert your ideas and visual sketches to a interative prototype.

# re: Why SketchFlow is not a mockup software

Left by Simone at 11/27/2009 12:12 AM

@cristiano: I kind of agree with what you say but:
1 - why would I want to develop a working demo in SL or WPF if then I want to build a web app? If I have to develop a SL/WPF it might be worth the effort since then I could reuse the behaviors, but when developing a web app, seems just a waste of time.

2 - I rarely work on projects where a working demo is needed, but when it is, the client also wants to see the graphic design, not just an interactive sketch.

3 - When building RIA (sorry for the word, I don't like it, but couldn't come with anything better at midnight) apps, we hardly do the sketching phase: here you are saying it's a 6 phase design process?
- Sketches
- interactive "sketchy" prototype
- graphic design
- interactive graphic prototype
- final implementation with WPF/SL?

Seems overkill for 99% of the applications.

"Export to Word": As I said answering to Peldi, I ended up copying the exported images to the real documentation: the exported doc is just too simple, and at the end you either have to copy images in to the main doc, or copying text into the exported one. So an export to folder of images would have been enough.

# re: Why SketchFlow is not a mockup software

Left by PM-SilverCrux at 11/27/2009 8:46 AM

Balasmiq is nice, I am just starting to use it, however one thing it clearly misses is the "Solution view". In order to create a mockup for a solution, I have to create seperate files and then there is no feature of linking them so I can offer for client review. I have to often write, open this file for this and that file for that etc. I don't want to confuse them! Peldi, is there something that can help guys like us who prototype whole application, not just single pages?

# re: Why SketchFlow is not a mockup software

Left by Diego Guidi at 11/27/2009 8:53 AM

what about mockflow?
anyone tried this?

# re: Why SketchFlow is not a mockup software

Left by Peldi at 11/27/2009 2:34 PM

Hi PM-SliverCrux, you can link mockups together and export all of them as a single, interlinked PDF.

# re: Why SketchFlow is not a mockup software

Left by Giorgio Bozio at 11/27/2009 3:04 PM

Thanks Simone, now I know I'll better not use SketchFlow...

Did you give a look at Pencil? (it's a Firefox plugin) it let's you
easily sketch software controls. I then used Powerpoint to add links
between pages and animations. it's really easy, almost no learning
curve and you can distribute the "prototype" as a ppt file.

I've written about it in my blog:

# re: Why SketchFlow is not a mockup software

Left by Cristiano Rastelli at 11/27/2009 8:58 PM

1: if you don't need the"plus" that SF gives you, why not prototype web-apps directly in HTML using a visual editor like Dreamweaver or Expression Web? I mean: I use SF if I need _more_ than a simple HTML prototype (comments and annotations, export to Word, visual "sketchy" style, ecc.) otherwise use plain old HTML, and some quick prototyping frameworks (*)

2: I think that submitting to a customer a prototype (in the early stage, I mean) with both functionalities and appearence/look&feel is not a good idea! you end to discuss about the background color of a button, not about if what that button does is what he expect and he needs; better separate in two different stages the two aspect of a good design (form+function, where form ALWAYS follow function)

3: "when building RIA apps, we hardly do the sketching phase" - bad thing! ;-) anyway, my ideal process is: quick sketches (tipically, paper prototypes or wireframes) -> interactive "sketchy" prototype -> graphic design (on paper as bitmap) -> final implementation; depending on the project complexity, you can "jump" a step and go to the next one; in any case you have to collect feedback from you customer on both aspect of a design: appearence and functionality; any of the forementioned step is just to collect more feedback as possible before the development; and yes, it's overkill for large part of the applications, if the project don't need to go that deeper in your analysis...

4: agree with a "export images" function, but as an extra option, not replacing "export to word"

(*) - -

# re: Why SketchFlow is not a mockup software

Left by Janko at 11/27/2009 9:06 PM

I haven't tried SketchFlow, but it sounds as if it is really a tool only for prototyping.

Most of the time I use only paper and pencil. It helps me to create quick sketches anytime, anywhere. Tools limits and slows down my thinking process.

# re: Why SketchFlow is not a mockup software

Left by Christian Schormann at 11/27/2009 9:35 PM

Thanks for looking at SketchFlow!

A few comments on the thinking behind it:

Modern user experiences routinely move beyond sequences of static "pages". Resizable apps require explorations of dynamic layout, there are complex interleaved states, animations and transitions, and many new interaction patterns.

I believe that in many cases, these dynamic aspects of user experiences cannot be expressed adequately with just static images. The inability to quickly and cost-effectively create, communicate and review compelling prototypes is often cited as a crucial pain point in the design process, and I certainly experienced it in my own work.

I really don't think there is an "either-or" between quick, low-friction sketches and dynamic prototypes: There is a continuum between the very transient nature of a cocktail napkin or whiteboard sketch, a statick mockup and a dynamic prototype. Some projects need all of the above, others just some.

On this continuum, SketchFlow certainly is biased towards dynamic prototyping - this is what it was designed for.

With a slightly different perspective on the meaning of "mockup", many users literally take the SketchFlow map as a mind map to explore the flow and structure of an application without any concrete UI at all - they just throw sketches and sticky notes on the screens. With the SketchFlow player reviewers can explore and navigate such flows from the very first moment on, even before any actual UI has been created. This is a very different form of mockup (focussing on mocking up the flow, rather than any screen), but a capability that is very much appreciated by many designers we talk to - getting the flow of an app right is often what matters most.
Just like in architecture, this is an aspect of design that is crucial to the functioning of the artifacts we create - UX, just like a building, is after all there to be used. An airport not designed with the flow of people people in mind will likely fail.

Basically, the idea behind SketchFlow is to let you begin with simple flows, and to evolve them, to make them as real as they need to be for the design aspect you are trying to explore.
Because SketchFlow prototypes are always real WPF or Silverlight applications, there is a lot of scope for this process of iteration - there is pretty much no glass ceiling. But that SketchFlow prototypes are WPF or SL applications doies not mean that you can only prototype for WPF or SL - in fact we have seen for example prototypes for Win32, Flash/Flex or HTML apps.

Without a doubt, the added depth and scope comes at the price of higher complexity, and requires more getting used to and more training time than a pure static mockup tool.
If this trade-off is worth it, of course depends on the needs of the individual project and designer.

I just realize that this comment has gotten a little longer than I expected. Wouldn't quite fit in a Twitter message. My apologies.

Just one more comment: The original post states that animations in SketchFlow need to be developed with code or behaviors. I'd like to clarify that Blend/SketchFlow has a built-in animation system that does not require either code or behaviors at all.

# re: Why SketchFlow is not a mockup software

Left by Cristian at 12/12/2009 11:25 PM


I think you got it right. SketchFlow, as well as Flash Catalyst, are two prototyping tools that are built with a specific platform in mind. I think that's totally OK. Having better tools for each platform is definitely a good thing.

On the other side, there are plenty of platforms out there, with plenty of capabilities. So general purpose wireframing/prototyping tools are also needed. Take for instance FlairBuilder: Although is built in Adobe Flex, I've tried to make it as platform agnostic as possible. And as with Mockups, it comes with a generic and pretty extensive set of widgets that you'd use in any environment, desktop or web.

Overall, I feel that it's a great thing that prototyping is taken more and more seriously and tools are evolving.


# re: Why SketchFlow is not a mockup software

Left by Michal at 1/20/2010 9:35 PM

This is a really great post with great insight; thank you!

This is exactly why I personally like to draft the UI on a whiteboard before I start with

After I've figured out my designs on the board, I then move on to using Balsamiq to make it work more perfectly.

Might take longer at the start of the design process, but saves a ton of time in the end.

# re: Why SketchFlow is not a mockup software

Left by Ryan at 2/5/2010 3:44 AM

Ok, right. You're comparing balsamiq to sketchflow. That's like comparing a candle to the sun. Sketchflow is the best thing that has happened to this industry in quite awhile. Before sketchflow there was _NO_ prototyping software. And by prototyping I mean a way to actually prototype interaction with the program. All I have to say is that Microsoft outdid themselves on this one. Do us all a favor and just delete this article. I'm a sketchflow fanboy all the way. Way to go Microsoft!!!

# re: Why SketchFlow is not a mockup software

Left by Mark Rendle at 2/5/2010 11:53 AM

The release of SketchFlow happened to coincide with my starting on a small, inductive UI application in WPF, so I used it as an exercise. Although getting the prototype completed was a little complicated and took some time, I found the time required to mock each screen provided a very useful guideline when I was assigning points during the sprint planning. I also referred back to the prototype repeatedly during the development process, and having the flow information as part of the data was really helpful.

That said, I wouldn't use SF for all of every project, but I have used it since on at least part of most prototyping exercises.

Comments have been closed on this topic.