The designer’s perspective on prototyping
Why it’s important for designers to make ideas tangible and testable.
Perspective. (source: Pexels)
The Explosion of Prototyping Tools
The gap in design tooling seems obvious in retrospect. As the world goes digital—as software consumes it, to paraphrase Marc Andreessen—it only makes sense that software designers need digital toolsets to facilitate their work and craft. When we first began this journey to digitize the world, designers naturally found inspiration in and imported best practices from other disciplines: architecture, industrial and print design, ethnography, and computer science, among many others.
It would be wrong to say the early years of the web and mobile that design tooling did not exist: we had applications that helped us do the work, but they weren’t always exactly the right fit. Unsurprisingly, the first websites and web apps were prototyped using tools repurposed for the new digital medium.
Learn faster. Dig deeper. See farther.
However, as much as Powerpoint can serve to create rough interactive screen flows, it was built for presenting slides, not sorting through user paths. And Flash, as powerful and diverse as the technology would eventually become, began its life as a timeline-based animation tool. Similarly, After Effects is capable of animating a user interface beautifully, but it was originally intended for video post-production. Even Photoshop—one of the most important weapons in the designer’s arsenal—started as an application for photographers. These are all great software applications for creative endeavors, but none are built for or focused on user experience design. So, we pushed our way through, optimizing our process based on the software with which we had to work.
Adobe, the titan of design tooling, may have inadvertently set the stage for the current boom in prototyping software by discontinuing Fireworks in 2013 and then Flash in 2015—both applications for digital designers that could be used for prototyping. Ironically, Flash and Fireworks were originally acquired by Adobe in 2005 when it bought Macromedia, a firm focused on the world of digital design tools.
It can’t be a coincidence that this current wave of prototyping tools is being driven, at least in part, by product designers who’ve created tools for themselves to bridge the gap between ideation/creation and iteration/validation. Whether it’s Koen Bok at Framer, Clark Valberg at InVision, or Mike Matas, formerly at Facebook, they are identifying what they need most from the prototyping process and creating digital tools to optimize it.
Major advances in web technologies and frameworks over the past three to five years have also played a role. Now complex applications are fully possible in the browser. InVision, Proto.io, Marvel, UXPin, and Atomic—all browser-based—owe some of their rapid advancement to this fact.
There are larger forces at play here as well: economic conditions that favor digital automation of processes in every sector imaginable; a proliferation of connected devices, including those you bring with you to work; and societal trends that support digital entertainment and social interaction. Such trends put pressure on software companies to bring products quickly to market for first-mover advantage and fear of being outflanked by a more nimble competitor, or worse yet, being at the receiving end of a disrupted industry or business. Lastly, the outsized successes in the marketplace of design-focused companies means that more competitive businesses value design, and more people are becoming involved in the design process. Speed of collaboration is essential. And the need for usable, beautiful software is only increasing.
Should Designers Code?
So, now that these toolsets are available to designers, what are the pros and cons of using such software for prototyping? Making prototypes on your own and controlling your output can be a meaningful advantage, as you can create as you see fit. But the advantages that come with the flexibility of prototyping in HTML/CSS can be offset by the time it takes to create that prototype.
Code is where design lives. And designers need to know their materials. Much like industrial designers need to know plastic and metal, or architects need to know concrete and steel, digital designers need to know the rudiments of HTML/CSS and JavaScript or whatever code houses the user experience. Should designers be able to code their own prototypes? It pays to be familiar with code. Whether we should be conversant in it is a variable best determined by the individual designer.
While new prototyping software tools can speed the process and enable collaboration with stakeholders, there’s always a danger in having a software tool dictate your creative path. This can lead to scenarios where designers choose interactions just because they’re available or convenient to render. “That’s always a limitation of any tool,” says Uday Gajendar, a principal UX consultant whose past work includes product design for Cisco, Citrix, Microsoft, Oracle, and numerous tech start-ups. “Even back in the day of using Photoshop. I think I started using Photoshop 4 or Photoshop 5. And I remember the professors dissuading us from going digital, ‘Don’t use Photoshop because it’s going to lead you down a certain path.’ Stick with pen and paper and those kinds of things, nondigital analogs, to allow greater spectrums of exploration, a wider net of investigation.”
The idea that code is the material of software, and therefore vital for designers to understand is a position held by many. “I think that designers need to understand code, because it is the medium that they are working in,” says Kathryn McElroy, Advisory Designer for IBM Mobile Innovation Lab and author of Prototyping for Designers (O’Reilly). “If you’re working in print, you need to understand how [the design] looks on the page and how it reads, and line widths and everything. When you’re designing for the web or for software, you need to understand the limitations of [that medium]. With our prototyping tools, you can very easily design things that are not [able to be developed], because you are going straight from Sketch or Illustrator into just a click-through with hot spots. And yes, that looks really simple, but you don’t know the development time.”
“If you have developers that you are working closely with,” McElroy continues. “I think you can get away with using … prototyping tools because you have that check point … [Developers] can [say], ‘Yeah, that animation looks nice. That’s going to add four weeks to our sprint cycle to deliver that. Do you want to do that?’ It’s a give and take. If you don’t have a developer, you really need to understand code more for creating something that can be made.”
An understanding of code can provide designers with the tools to communicate effectively with developers. “I believe that designers need to be code-literate, but not code-fluent. I definitely encourage people to take a coding class,” says Fred Beecher, Director of UX Design at digital strategy consultancy, The Nerdery. “When I was in high school, I took Turbo Pascal. I took C and C++ in college. … That allows me to communicate effectively with people who really know what they’re doing when it comes to code. That is what I need to do as a designer. … I should be literate but not fluent, able to communicate with experts basically. … [Designers] need to maintain some skill that allows us to convey our interactive ideas. I don’t think that it’s a good idea to be a designer who can only design flat stuff, even if you can communicate effectively to developers.”
As digital design evolves, the elements that designers need to know will continue to change. The debate over whether designers should code will also continue. But it’s safe to say that for most, familiarity with what’s possible for engineering can only be helpful.