Prototyping is critical part of UX process. Obviously, prototyping tools play significant roles, and we have seen various software programs throughout the past decades. Among these tools, I would like to focus on Adobe Flash (now called Animate), and share what I learned from using it for years, and why I think a lesson from Flash holds a future of prototyping. Let me dive in.
History of modern-day prototyping
When we think about the future of prototyping, it’s worth looking back in a history. A chart below shows major prototyping and authoring tools from 1987 to 2020. On the bottom, I added key product/service launches that impacted the world, which provides an overall historical context. The list is not exhaustive, but you get the idea.
The rise and fall of prototyping tools have always been heavily influenced by the underlying technology trends, which can be divided roughly into 4 eras; 1) Multimedia Era, 2) Flash Era, 3) Web 2.0 Era, and 4) Mobile Era.
Strictly speaking, Microsoft Powerpoint, Adobe Photoshop, Illustrator, After Effects, PDF are not prototyping tools. But in early days (and even today), designers used/use these tools to create simple prototypes. Prototyping can be done using any tools, including hand-drawn sketches on paper, after all.
Processing never took part of the mainstream UX prototyping, but it created a distinctive, interactive/generative art community, which gave birth to Arduino, a popular hardware prototyping platform.
Among these, Flash launched in 1996 by Macromedia, which later acquired by Adobe in 2005.
Flash in a historical context
In early 90s, When the internet went mainstream with the birth and wide adoption of web browsers, the basic HTML was extremely limited. It was Flash that came to rescue this limited environment of early web by enabling various rich interactions within its embedded SWF file in an HTML page. Since its launch in 1996, Flash quickly became the center of rich internet web development platform. During mid 90s to early 2000s, Flash was dominant as a prototyping tool as well as a web development platform. Many Flash-based games flourished. Even the initial YouTube on PC web was Flash-based, until Google switched to HTML5 video in 2015.
During early 2000s all the way up to 2019, I lived with Flash. I literally created hundreds of Flash prototypes. During these days, I worked on various advanced concepts too, and Flash was perfect for that.
It was true that Flash had many technical, implementation problems such as sluggish performance, poor memory management, being buggy, unable to bookmark specific “page” inside Flash, a browser plugin always had to be updated, and so on.
However, from a designer’s perspective, Flash offered an almost ideal environment for several reasons.
Flash took almost any media effortlessly
So what was so special about Flash? Flash was extremely flexible and forgiving in terms of how you create and what you could create. It took almost any media effortlessly including text, images, vector graphics, videos and audio files. This was huge at the time when software programs were siloed based on different media types. Whatever media types that you brought in to a stage in Flash, you could handle pretty much the same way to scale, group, animate, and add interactivity. Flash even had a camera object, that you could manipulate almost the same way as other objects.
In a nutshell, Flash gave designers a freedom to push their creativity to a whole new level which was not possible in such an easy way before. During this time, many creative and inspirational works came out from various designers’ experiments such as Mono*crafts above.
Nested timelines
One of the most powerful features that Flash had was its nested timelines. This was essentially object-oriented programming done visually. Micro-interaction animations could all be embedded within each object on a page. Although it could get complicated, this was very simple and straightforward model for designers to mentally understand and work with.
Controlling multiple timelines via basic commands
These multiple timelines typically needed just the basic controls such as play, stop, loop/etc. Even if you were a designer with no coding experience, these were easy enough to handle. For example, “stop();” to stop an animation, “gotoAndStop(1);” to rewind the “playhead” to the beginning of the animation and stop, or “gotoAndPlay(1);” to keep looping the animation. As seen in the screenshot above, all you had to do was to add a desired line of command on the last frame of the animation timeline.
Above shows another example of adding an interactivity to a Movie Clip in ActionScript 3.0. Now ActionScript 3.0 became more complex compared to the original ActionScript 1.0. With ActionScript 1.0 or 2.0, you could add these scripts directly onto a Movie Clip without having to write a custom function. These interactivity allowed designers to intuitively play and stop animations, and jump between different screens with ease. Most of the time, this was more than enough to build quite sophisticated prototypes.
Animation was baked in by default
Because Flash initially started as a vector graphic animation software, animation capability was always baked in throughout the program by default. Designers were able to animate pretty much everything in Flash, and this was huge in the time of early web with static pages.
Flash gave designers a fresh, blank canvas to play around with virtually any media, with an ability to animate objects and add interactivity with ease. Who doesn’t want that?
Blending graphical vs. coding approach
Another unique aspect of Flash was its ability to blend graphical approach and coding approach. As mentioned earlier, if you were a designer and wanted to work only through graphical user interfaces, you could absolutely do so by drawing an object and create a tween animation on a timeline. You needed to add basic ActionScript to enable interactivity mentioned above, but that could be minimum.
If you were an experienced designer with some coding knowledge, you could write your own ActionScript functions to enable advanced interactions on top of what you designed visually and animated along the timeline. You could combine tween animation with code-based animation. You could combine static objects in a library with a dynamically created ActionScript objects. The choice was yours, whether the ratio of graphic approach vs. coding was 80/ 20, 50/50, or 20/80, whichever was right for you.
If you wanted to go 100% with code without drawing anything graphically, you could do that too. Code-savvy designers or engineers were able to define everything in ActionScript without creating any Movie Clips manually on stage, using either Flash or Flash Builder.
This was fantastic for designers because there was always a way around if you bump into coding problems or tween animation problems for example. Designers didn’t want to spend too much time debugging their half-ass codes, because perfecting a code in a prototype was never their goals. They could easily switch to tween animation to get around. Or if tween animations fell short for what you envisioned, adding a bit of ActionScript could solve that problem.
Single prototyping+development platform where designers and engineers can work together seamlessly
Flash provided a unique platform that allowed both designers and engineers to work on exactly the same platform. This was great because designers could create visuals, animations and interactions in Flash, and delivered Flash files to engineers. Engineers who received Flash files did not have to reproduce the front-end, which is the typical workflow in today’s web and app development. All they had to do was to add ActionScript to complete the product. In this workflow, the handoff from a designer to an engineer was perfectly executed in form of a Flash file (FLA), without the designer having to produce additional deliverables such as bitmap assets and design specifications separately.
When the world transitioned to HTML5 and mobile, we lost this flexibility that designers and engineers used to have on Flash platform.
Web 2.0 and Axure prototyping
In mid 2000s, Web 2.0 dramatically changed how we experience the internet from static to dynamic without having to rely on plugins like Flash. Facebook, Gmail, Twitter, Skype, Google Map, YouTube were all born around this time and became widely adopted by the mainstream internet users. WordPress also launched, and automated content management of many websites which used to be manually maintained before.
Axure launched in 2003 to address emerging needs of designing Web 2.0 applications. In a way, Axure attempted to have a Flash-like capability via Interaction Editor without having to code. While Axure’s Interaction Editor is well designed and powerful, it somehow feels a bit too cumbersome to build complex interactions just by clicking and selecting every single event and action, compared to defining those in Flash ActionScript.
Axure was lot lighter than Flash, and published a prototype in native HTML5 without a need for any plugins. Axure shipped with it’s cloud service for free, so designers didn’t have to worry about setting up their own web server to host their prototypes. It was all included. Today, cloud share feature is a must for all the prototyping tools.
World became mobile-centric
When iPhone launched in 2007, Apple did not support Flash because Flash was too heavy on mobile. More details on why Apple dropped Flash was described in “Thoughts on Flash” written by Steve Jobs in 2010 on Apple’s website. In 2008, Apple App Store and Google Play launched, and the center of the internet shifted from desktop to mobile. Today, the internet usage on mobile accounts for 53.3% of the total internet traffic, surpassing desktop according to BroadbandSearch.
Because Axure started as a tool to primarily design desktop web applications, it fell short in designing mobile apps. As mobile started to take over the world, many new tools emerged with mobile-first approach. Wide adoption of mobile phones also raised a bar for customers’ expectations on user experiences on mobile devices and even desktop web applications.
Today’s prototyping tools
Today, UX designers are tasked to design, test and iterate UX concepts with much shorter timeframe than before. Modern tools are offering easy + smart features to keep up with demands for these fast iterative processes. This is where we are, with Sketch, Craft, Balsamiq, InVision Studio, Principle, Adobe XD, Figma and Framer X, and more.
Recent trends in prototyping tools are ”stitch screens with wires” interaction model, accompanied by auto-animate transitions that smartly animate transitions between two screens connected.
Various smart features are also developed such as Smart Layout in Sketch, Duplicate and Data features in Craft, Repeat Grid in Adobe XD, Stack feature in Framer X, all of which automate otherwise mundane repetitive tasks beautifully. All these make prototyping super-fast and intuitive for non-code-savvy UX designers.
While these are great accomplishments, many of these are geared towards increased productivity for most typical design works. Somehow I feel these are optimized too much towards today’s mobile standards and expectations, leaving very little space for designers to explore beyond those standards.
This is probably due to what the market demands. Every company and startup is aware of the importance of user experience today. Everyone wants to create its own website and app, as fast as possible. This fast-paced market demand pushes UX designers to work faster. And with today’s expectation on user-centered design practice, everything is moving towards similar directions, similar designs, and similar patterns, because that’s what users are used to and familiar with.
There’s nothing wrong with this from a pure user-centered design perspective. But at the same time, this concerns me. What happened to out of the box thinking, pushing the envelope, experimenting with new ideas, sailing to the unknown?
As much as UX designer’s job is to solve users problems and create delightful user experiences for its users, it should not be JUST listening to what users have to say and simply implement what was heard in form of conventional patterns and standard designs.
Based on users’ voices and observations, UX designer’s job is to imagine and create a better future. This is where more of a free-flowing imagination and creativity need to come in. And prototyping tools should accommodate this as friction-free as possible. Many of today’s prototyping tools don’t seem to put weight on this aspect.
New experiments towards the future of prototyping
But I do see a few interesting experiments happening towards pushing an envelope. For example, Framer X has an online store feature where users can upload and download custom components. Framer X also has pretty powerful code-based extensibility such as Frame Motion. It also has an ambitious vision to take care of handoff from a designer to an engineer.
Adobe XD’s voice interaction capability is quite impressive too, which you don’t see anywhere else. Voice interaction has already become part of our daily lives, and its presence will only grow further.
I really hope that the next evolution of prototyping tools explore more free-form flexibility so that designers can experiment wild ideas and push their creative limits all the way to come up with unexpected, innovative and groundbreaking concepts.
From this perspective, lessons from Flash still holds super valuable. What Flash did in the early days of the internet truly inspired many designers and helped them push their creativity.
I look forward to a world where experimenting with wild new concepts becomes a breeze for designers AND engineers!
I also look forward to a world where a prototype created by a designer IS the front-end of the final product, where engineers plug in their code to turn it into a real product. Engineers should not have to reproduce the front-end already created by designers, and designers should not have to create additional deliverables such as design specifications and bitmap assets for engineers to reproduce their designs.
This article was originally published on Medium in UX Collective on March 25, 2020.
Also, check out my article “Prototype is worth a thousand pictures“.