I’ve been on a journey over the past few months, testing some theories about prototypes. I think I mentioned it before. The big question I’m grappling with is if I must build a prototype, what’s the best way to do it in the long run? These are my findings. This is why I’m leaving Sketch and InVision for HTML, CSS and jQuery.

(My) Options

  1. Sketch (app) + InVision (sync)
    This is what I’m doing now. As a recent convert to Sketch, I instantly saw how much faster it is as building interfaces than anything I’ve used before (Axure, Omni[x], Illustrator, Photoshop, InDesign etc). All of my up-to-date interface designs use Sketch files. I switched to InVision after running an internal test of competing solutions, and their Sync app ticked a lot of workflow boxes for me.
  2. HTML5 + CSS3 + jQuery
    There’s just something beautiful about a lightweight, scalable RoR/HAML/SASS setup running locally that really turns me on. It’s just. So. Manageable. I miss using this setup. The beautiful thing about CSS (Cascading Style Sheets) is that they cascade down through the DOM and can be inherited. This allows style to be incredible optimized and manageable.

The Variables

Sure—every project that needs a prototype has different requirements; what fidelity should it be? Are there pre-existing software or format requirements? Is the toolset limited? How ‘functional’ does it need to be? Who’s the audience?

All of these are valid, but for the sake of clarity, I’m going to be focusing on my own predominant use-case, in which 1) Prototypes are shared beyond just designers and developers, 2) Internal testing relies upon the prototype existing, 3) Eventually, something usable must be delivered to developers, and 4) I happen to be the UX guy, UI designer, IX designer, graphic designer and front-end developer on my team.

  1. Time Up-front

    Sketch+InVision wins here—since Sketch is a UI design tool, there’s an instant gratification when it comes to new interfaces, and sometimes, interactions. When those interactions are simple, InVision handles them with ease.

    HTML+CSS+jQuery typically requires a bit more up-front setup because when I’m in code, I’m thinking about so many more things; How are my semantics? Is it accessible? Is it scalable?… but once the basics are dialed-in, that’s when things get nice. But you’ve still got to take more up-front time to dial-in those basics.

  2. Deliverability

    Sketch+InVision is #giantFAIL in this department. I can’t send a Sketch file over to a developer and tell them okay, now build it. Unless they’re already comfortable using Sketch (and have a license), that’s a #fail right out of the box. I’ve tried plug-ins like Zeplin, but they just don’t do what I need them to do. InVision fares marginally better here – it can quickly mock an animated interaction (as long as I’m happy with their limited preset options).

    HTML+CSS+jQuery really shines in this department – particularly if the end-product is going to be using HTML+CSS (I only use jQuery to mock interactions). To state the obvious: if I’m building the initial prototype using HTML+CSS, it’s essentially starting the actual, deliverable, deployable build process. I cannot overstate this enough: My biggest pain point right now with Sketch+InVision is that I put in tons of man hours to design something that cannot be deployed, at the end of the day. It inevitably gets trashed.

  3. Inherent Specification

    This is an interesting concept. Even when prototyping a native app – such as iOS or Android – a spec will eventually be needed. Wouldn’t it be nice if the initial blue-sky, daydreaming-level format inherently had ‘spec’? I’m talking about basic stuff: margins, padding, font sets and sizes and colors. These are all things that developers need eventually, and if you send them a Sketch file – unless you expect them to painstakingly launch Sketch and measure and sample it themselves – they have no spec to use.

    Obviously, the nature of HTML+CSS is ‘spec’. You’re not just defining actual numbers, colors and sizes, but you’re also basically defining the design spec at the point where it, arguably, should be defined: at a design and interaction phase (and by a designer).

    Neither Sketch nor InVision, on the other hand, have any usable spec—in terms of a team’s workflow. Bummer really.

  4. Potential Fidelity

    Over time, this has started to become one of my big priorities. It seems that no matter which prototyping tool I use, I always hit a brick wall at some point when trying to mock a particular interaction. It shouldn’t be a surprise really—every application has such unique needs that no one can really be expected to cater to them all. Oh wait! What was that? jQuery, you say? Exactly!

    When I create prototypes using InVision, and inevitably hit a wall, I’m simply stuck. I have no control over what features InVision implements, and I certainly don’t have time to wait for them to do it. It’s literally a no-go, right off the bat. A standstill.

    jQuery, however, is the opposite. It is an abstract library that has yet to leave me lost in the woods. There’s always a way to mock up any interaction I can dream up. Sure—sometimes it takes time to learn or debug something, but I nearly always get what I want at the end of the day. jQuery, by a mile, has the highest potential fidelity of any prototyping tool I’ve ever used.

  5. The Longtail

    HTML+CSS, for me, take marginal extra time up-front to get set up compared to Sketch + InVision, but the longtail is where it’s at. With HTML+CSS, not only can you define a global, base-level of style and functionality, but you end up with ‘spec’ that is delivered to developers (and in my experience, they’ll love you for it).

    The longtail win goes to HTML+CSS here.

Winner: HTML+CSS+jQuery

It’s not much of a surprise, really. HTML, CSS and jQuery have been around for so much longer than any prototyping tool. The biggest variable here, for you readers, will be your level of knowledge with these tools. I have the good fortune of being quite familiar with them all, and so for me, it’s a question.


But here’s a challenge: if you build prototypes but don’t know HTML, CSS and jQuery, take a hard look at the time you’re spending building prototypes—especially fully-rendered prototypes like mine. Then, take a look at the process of design & development that happens after your prototypes are ‘done’. How is design & interaction spec defined? How are developers responding to that spec? How many steps does it take to get your design deployed? And how long does each of those steps take? Do you feel like they’re all warranted?

It’s a lot of analysis, to be sure. But when you’re under the gun, consider your skill set. Can it be more widely utilized in order to minimize hand-offs and maximize efficiency? If you invested a little time up-front into learning jQuery – for example – how much time would it save you and your organization over the next 6 months? Ask the hard questions, and be willing to push for the right answer.

Happy prototyping!