Why do we prototype? Most of you, dear readers, would agree that the design process for any medium, whether physical or digital, cannot exist without prototyping. Prototyping is such an essential part of any design work that we can’t even imagine not having it as part of our workflow.
In fact, it’s so essential, so obvious… that it stopped being discussed as something we're supposed to care for and optimize. After all, everyone knows how to prototype, right?
Unfortunately… wrong.
Throughout the last decade, I’ve seen absolutely terrific approaches to prototyping that pushed projects forward in great, initially unforeseen, directions and some truly terrible attempts to prototype, that led projects astray.
To really understand what differentiates bad prototyping from excellent prototyping, we have to explore the reasons why we prototype in the first place.
In my opinion, there are 3 reasons:
- Exploration. To explore a variety of design concepts without investing resources into producing the final product
- Testing. To test many design concepts with users before any production work starts.
- Specification. To show how the product is supposed to work without investing into documentation that describes details of every single feature
Prototyping cuts costs and increases our understanding of experiences that we’re supposed to build.
So what could go wrong? Apparently plenty.
Changes in the process over the last 10 years
In the past decade, we’ve observed a massive growth in the UX design industry. Teams became bigger, the number of available positions went through the roof (in 2017, CBS listed UX as the 9th most attractive job in America ) and design became more valued by executives than ever. Forbes called it the UX Gold Rush. According to one of the fathers of modern UX – Jakob Nielsen, we can expect even more growth in the next 25 years.
With all the growth, we also observed changes in the design process. Ten years ago, the processes of designing the experience and designing the final graphic design were, more often than not, separated. We used different tools for every part of the process (typically Axure + Photoshop) and quite often – different people. Designers, focused on the prototyping process, would typically work on the interaction between the human and the interface, and test and iterate over a low to mid fidelity prototype. The aesthetic part of the work would be a graphic designer’s job.
Over the years, there’s gradually been a growing desire to merge these two parts of the process and roles.
One could argue that it makes a lot of sense. As humans we don’t dissect our experiences to separate aesthetics from function, and hence great design needs to embrace both. If a designer is able to efficiently work within the two worlds – why would that unification of positions and processes be bad? Sounds like a great design process.
Unfortunately, more often than not, it’s a recipe for disaster.
First of all, it’s really hard to find designers who can efficiently work with both the experience and the aesthetic part of the design process. And while, in my opinion, we should all aspire to build this unification of skills and knowledge in us, it is a process that, industry wide, will take years, if not decades. Patience is a virtue of career growth in a crafty industry like design, but the job market remains as impatient as ever. While universal designers are slowly growing their skills, the demand for them is at its highest. And with that… the design process broke.
Following the demand on the market, designers, who are supposed to work on crafting interactions between human and machine, started to use high–fidelity, vector design tools. Spending more time on crafting all the visual details early on, leaves little to no time for prototyping. So instead of working on the realistic reflection of the experience of users for exploration, testing and specifications, designers started to ship static art boards connected with “hotspots” and links, in a way slideshows, as prototypes. With that:
- Testing with users became limited
- Exploration became rare (sunken cost of graphic design!)
- Specifications for the development – inaccurate
Hotspot-based slideshows of graphic design mockups are not a fit for any of the reasons to prototype. Yet, they became the dominant process over the past few years.
Prototyping and design got sacrificed on the altar of the industry growth.
When hotspot–based prototyping is OK
Alright, let’s catch a breath. The situation is not great, but it’s not all bad either.
Hotspot-based design slideshows can simulate very basic use cases. Over the years, tools started to animate changes between static artboards which can generate a visually attractive animated prototype for a few simple use cases.
Examples of use cases where a hot–spot approach can work well:
- Simple landing pages
- Small changes to simple design patterns
- Quick demos intended only to demonstrate design skills to other designers (Dribbble demos!)
More complicated situations need a more advanced approach to prototyping and more advanced tools. Attempts to fit complex design work into a static, vector design tool with a highly limited prototyping capability, ends up as a set of suboptimal user experiences, broken design processes (especially on the edge of design and development!) and, at times, completely broken design patterns.
When hotspot–based prototypes break the design process… and the web
How can a simplistic design process, static design tools and hot–spot based prototypes break the web? One could write a book about it.
When a designer focuses on designing the interface with a static, vector design tool (such as Sketch, Figma, XD, Studio…) certain aspects of user experience become simply unavailable. So it happens that many of them are absolutely crucial for prototyping and testing digital experiences. The limitations of those tools take designers hostage.
Examples? In all these vector design tools:
- Users cannot enter any content into a prototype (there are no text fields, checkboxes, radio buttons…)
- Content provided by users cannot affect design
- Components cannot have interactions that are triggered by user actions or changes in other interactive components
- … and many more!
The list goes on. Vector design tools limit the ability of designers to emulate the entire, planned user experience. Forget about testing forms and validations or advanced forms of navigation. Vectors tools bring everything to the form of a static image that you can only partially bring to life with hotspots.
And what’s the result? Wrong design decisions, untested prototypes, tension between design and engineering… everything that proper prototyping can solve completely disappeared from the design process. Why? Because of vector design tools and hotspot prototyping.
Here’s a concrete example that you’ve definitely experienced personally.
You sign up for a web app. You’ve just entered your email address, and now it’s time for a password. You entered your choice of a password into an input and are ready to submit the information. Just when you expect to move forward, you get an error message: “Password needs more than seven characters, one number and one special character”.
Frustrating, isn’t it?
The security reasons are unquestionable, but why wouldn’t they dynamically check the content of the input and show the validation method before you submitted the information. It’s not technologically challenging, so… why?
Most likely, the form was designed that way. Because vector design tools don’t allow for state of elements and inputs. So a designer probably put together two static art boards, one with the default state, one with the error state and linked them together with a hotspot. The engineer looked at it and built exactly what she was asked.
And there you have it—the wrong design tool, likely led to a horrible user experience. Could that be avoided with written documentation? A conversation? Yes. Most definitely. But when you build a process around a faulty set of tools, you increase the risk of errors.
Processes run by humans break faster than good tools run on… machines.
The future of prototyping is here. And it’s code–based
Let’s get back to the beginning of the post. We want prototyping to empower:
- Exploration
- Testing
- Specification
We know that a combination of a vector design tool and hotspot prototyping is not the answer; it leads to completely broken experiences. Do we have to come back to the tools we used 10 years ago? No.
Let me show you two prototypes created entirely in UXPin without any coding:
Password with dynamic validation
Credit Card form with credit card type recognition, validation and dynamic confirmation page.
You’re probably wondering, “What is this sorcery?”.
Unlike vector design tools that are primarily optimized to work with illustrations and icons (the only real use cases for vectors outputted by all these tools), UXPin, has been built from scratch as an interface design tool. To achieve this goal, UXPin is built in the paradigm of code–based design tooling, which gives designers access to the powers of HTML, CSS and JavaScript, without asking them to actually code anything. You can design forms, plan validation (all elements can have states and you can validate users’ input with simple expressions!) and create chains of conditional interactions. All of that in a highly visual design environment that is ready to cover the entire flow.
Welcome back, real prototyping. Sleep well, hotspot limitations! It’s time to improve the web.