7 Reasons to Prototype with Microsoft Sketchflow



I’ve been trying to use more of the Microsoft Expression design tools (for a number of reasons). I’ve decided one of its biggest advantages over other options is its prototyping tool, Sketchflow (included with Expression Blend 3).

Why should you be using Sketchflow to prototype?

  1. It’s the closest digital option to paper prototyping
  2. Sketchy styles – helps people remember that it’s still under construction. More on this from this boxesandarrows article.
  3. Pen tablet integration – allows you to hand draw stuff, which is faster than anything else. Want one? Check out the ones from Wacom.
  4. Progressive Fidelity – move from hand-drawn objects to sketchy objects to wireframe objects to highly-polished designs
  5. Portable – can be packaged up quick and sent out to your team and your clients
  6. Feedback Management – your team and clients can annotate mockups directly and share back with designers
  7. Snappy transition to developers – it produces xaml and code behind files that front-end developers can use as the basis for their code (instead of just looking at a set of graphic mockups and having to translate those into development assets)

I recently watched a good video on Microsoft Sketchflow. If you just want to see a demo, jump to the 31 minute mark.



And if you didn’t know already, you should be prototyping your solutions, because it leads to better requirements and faster development. If you don’t have access to Sketchflow (or time to learn it), at least get out a pen and paper or jump on the whiteboard with your team. That would be better than nothing. Happy prototyping!

8 comments:

Kristopher Kinlen at: 1:55 PM said...

Converting a sketchflow app into a real wpf app has been a blocker for us adopting Sketchflow. There doesn't seem to be a clear path to do this. If there was a button to push that converted it for me, I would be all over it.

Dan Vanderboom at: 2:10 PM said...

I agree with Kristopher that the separate Sketchflow project type, which doesn't allow easy transition to a production project type, is a major obstacle. However, I still use it because it's better than paper prototyping, and I can copy the XML.

Bob Pappas - Microsoft at: 2:52 PM said...

Hi,
We've provided instructions on getting rid of SketchFlow cruft here: http://msdn.microsoft.com/en-us/library/ee371158(Expression.30).aspx

Sorry that we've not provided an automated way to do this. However, in some circles, converting a prototype to production is not a best practice.

Bob Pappas, SketchFlow Engineering Manager

Virginia at: 3:14 PM said...

Thanks Bob! But who decided it's not best practice? You might want to interview some real teams that are using Sketchflow today and see where we could improve on this experience.

I know as a designer, I would like to iterate through my designs with users and then click the "magic" button to send to the dev team.

Kristopher Kinlen at: 3:25 PM said...

Thanks for the response Bob!
If this is a tool for designers, having to open and edit multiple C# files and mess around with the code in there doesn't fly. We have walked through those instructions with limited success.

My understanding of the tool is we could prototype with it and then hand it off to the designers to build out the XAML. In practice this hits a wall when you try to hand it off. There are better tools out there for doing interactive prototypes, the benefit here is we are prototyping in the technology that we will deliver in. If there is no way to do that hand off then that benefit is not realized.

Anonymous at: 3:32 PM said...

From the MS sketchflow product page:
"Traditional prototypes are generally redundant after the concept phase and discarded. SketchFlow enables you to leverage all the previous conceptual work, every asset and component created is reusable in your production project – nothing goes to waste."

While this may be true, having to edit the csproj and App.xaml.cs file in a text editor, deal with removing references, etc sure isnt easily accomplished by designers.

Bob Pappas - Microsoft at: 3:50 PM said...

Hi,
Thank you for articulating your pain. Perhaps there is another workflow here that I am missing.

We are assuming there are developers eventually. Wouldn't editing a csproj file and .cs files be the job of a developer and not a designer? Do designers need to develop production assets in a non SketchFlow project before handing them over?

Anonymous at: 5:12 AM said...

I agree with the sentiments expressed here MS is missing a major market by not implementing a simple path to development code.

Most will not care if it is not best practice and if you provide the click to convert to c# project.

The effect of this provision will create momentum (sales) that will allow MS to put more resources into improving the suitably of the underlining code for developers. It is the old chicken and egg thing.

Please keep in mind not all IT departments have the resource of designer and developer most just have a developer who has to do it all and he will be reluctant to learn and use a system the results of which he has to throw away.

Post a Comment

Aaron Hursman
Aaron Hursman is a passionate user-advocate who is lucky enough to do what he loves for a living. As a user experience architect, he applies user-centered design principles and techniques including user research, persona development, information architecture, storyboards, wireframes, prototyping, visual design, graphic design, interaction design, and usability. Aaron has a background in web development, enterprise applications, and the social web. At nGame, he is applying his craft to design and build the next generation of enterprise software. Aaron is available as a speaker and author upon request.
Disclaimer: The information in this website is provided "as is" with no warranties, and confers no rights. This website does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. Inappropriate comments will be deleted at the authors discretion. All instructions and code samples (if any, ever) are provided "as is" without warranty of any kind, either express or implied.