Prototyping in the Post-Flash Era
A tool-agnostic framework for modern prototyping
With so many options available to UI designers these days, few will remember a time when prototypes were a luxury.
Before today’s abundance of tools, we had Flash. Not long after its 90s debut, Flash dominated interactive media on the web. It took time to master and wasn’t a prototyping tool per se. But for over a decade, it was the best way to show the motion and interaction lacking in our mockups and click-throughs. Surely, this was the bedrock of a boundless digital prototyping future!
In 2010, Steve Jobs famously killed Flash. HTML5 was waiting in the wings. But without a universal visual UI for handling the basics, HTML5 never took hold for day-to-day prototyping.
New tools would soon fill the void. Code-free and made for prototyping, they invited more designers to participate. But the increasing number of products made it hard to find “the one.” Tools got easier to use, but harder to choose.
Starting over wasn’t fun. I was anxious I’d never find the holy grail I needed to move forward. But my quest for a new Flash reminded me that communication isn’t defined by tools.
Graphic design isn’t Photoshop.
Presentation isn’t PowerPoint.
Prototyping isn’t Flash.
The loss of Flash was a chance to understand the concepts behind what I had built so far, and to create a framework that put goals before tools.
Seeing Past Flash
Looking back at several examples, my Flash portfolio showed a consistent pattern:
- Click-through prototypes focused on global navigation, giving a low-fidelity tour of the application’s key screens.
- Play-through animations showed detailed sequences of everything from task flows to rollover effects.
- Microinteraction prototypes delved deep into advanced UI behaviors, especially ones with continuous interactions like dragging or scrolling.
These might just have been an artifact of how Flash worked. A frame-based timeline could be hacked into making click-through prototypes. A timeline-centric UI afforded play-through animations. ActionScript enabled almost any microinteraction imaginable.
But the spirit of these categories got at something more universal. Click-throughs were really about understanding the breadth of a system. Animations described the system as a collection of stories. Microinteractions revealed the workings of specific system details.
Framing prototypes in terms of architecture, flow, and logic ushered me into a more purposeful, post-Flash era of prototyping. It got easier to scope prototypes because I could articulate their function. Easier to choose tools because I knew what features to look for. Easier to think about prototyping beyond just screen-based interfaces.
Prototyping for Architecture
Architecture prototypes answer “where is everything and how do users get there?” With just flattened mockups and hotspots, their low-fidelity interaction frees you up to consider how the whole system works. They’re ideal for framing early stages of information architecture and navigation.
Interactive breadth. Easy to make, but hard to maintain if continuously updated over the course of a project. Best if contained to the early stages of design — let developer builds do the rest.
Foundational overview for project stakeholders, taxonomy/navigation usability studies.
InVision, Flinto, XD, Marvel. For visual UI design, any page-based tool with linking or hot-spotting features. Most of these offer transitions between states, but flow tools allow more precise control over motion.
Prototyping for Flow
Flow prototypes answer “what happens from start to finish?” These time-based demos are equally adept in long form (product hero flows) and short form (signature animations). Finely-tuned motion makes them uniquely suited to persuasive storytelling. Video formats make them easy to share.
Linear breadth or depth. Low to medium effort, depending on flow length and fidelity of transitions. Hybrid architecture-flow tools make click-through motion easy, but use logic prototypes for more advanced interactions.
Product hero demos, task flows, signature animations, component state transitions.
After Effects, Flinto, Principle, Hype. Any time-based tool for expressing state transitions with precision. Flinto and Principle allow interactive transitions through scrolling and dragging.
Prototyping for Logic
Logic prototypes answer “how exactly should this work?” Code or visual programming gives you precise control over the device, more realistic interfaces, and the algorithms that make them work. Their technical complexity makes them best for interactive details, but inefficient for big-picture things like information architecture and task flows.
Interactive depth. These prototypes are the most technically challenging, so to get the highest value they need to stay tightly scoped. Rule of thumb: focus on a single behavior and don’t spend longer than 4 hours building it.
Microinteractions, data visualizations, custom gestures, business logic, electronics, devices for which no visual prototyping tool is available.
Building Tomorrow’s Toolbox
The architecture/flow/logic framework helped me develop a reliable but evolving mix of tools.
I’m excited to see what software companies make next. But despite some fond memories, I’m not holding my breath for another Flash.
This medium is every bit as nuanced as visual design. There isn’t just one kind of prototype, nor one kind of prototyping tool. A product that tries to do it all risks being too complex. And in a volatile market where products can quickly come and go, committing to a single method is a gamble. Having a system that puts goals ahead of tools will diversify your toolbox and guide you back to what really matters: getting the design right.
Emilio Passi is an interaction designer and technologist in San Francisco, California.