Functional Prototyping
A Missed Opportunity in Web Design
Why prototyping
All buildings are predictions.
All predictions are wrong— Stewart Brand How Buildings Learn
We designers make predictions about the user, the device, and the environment all the time. Even the most battle-scarred designers make poor predictions that result in painful user experiences.
Prototyping could have revealed some of the wrong predictions about this towel dispenser and its users — 1) do people always pull the towel downward? 2) does pulling one piece of towel always reveal the next? 3) do people know where the knob is and what it does? 4) when people turn the knob, do they turn it clockwise or counterclockwise? Prototyping saves the day by catching errors in predictions like these before we’ve gone too far. With the help of prototyping, we can:
Fail fast, fail cheap
Prototypes are built with materials that are cheap and easy to modify or replace. Antoni Gaudí’s prototype of Sagrada Familia was simply made of strings weighted down with birdshot. The everyday material enabled Gaudí to instantly adjust the curvature of the vaulted ceiling in his model. He just needed to increase or reduce the birdshot weight. The beauty of the final product was marveled by millions of visitors every year.
Whenever a change in design is prohibitively expensive, prototyping helps in reducing the cost of development. Electronic engineers prototype on breadboards or micro controllers like Raspberry Pi that cost a fraction of the real thing. Each design flaw discovered during the prototyping translates to millions of dollars saved in marketing failures, recalls, and lawsuits.
Select the best from the pool
Thanks to their low cost, multiple prototypes can be built and tested at the same time, so the designers can select the best from the pool. This is effectively artificial selection.
Think of genetic engineers as designers of species. Instead of trying one crossbreed or one genetic mutation on one individual at a time, they always test on a population, maximizing the likelihood of finding desirable traits. It is the low cost of reproducing each additional individual that makes the selection possible on a large scale.
We see a similar strategy in quantitative trading where the investors use a computer algorithm to determine when to buy or sell stocks. Before they trust a new algorithm with millions of dollars, the investors “prototype” the algorithm by auditing its performance for a few months with a hypothetical investment. Since the cost of adding one algorithm to the performance audit is almost zero, the investors can hold worldwide competitions like this to maximize the likelihood of finding the best algorithm.
Bring in the reality
No matter how good a piece of design looks on paper, it may not work as expected in the real world due to added complexity and unexpected conditions. Testing a roughly-made prototype in the real environment can be more productive than pursuing the perfect design on paper.
The space industry probably requires the most rigorous design on paper. Engineers spend sleepless nights solving equations and running simulations. Risks are avoided by all means because failures cost billions. When CubeSat, the 10×10×10 cm cubic satellite, entered the industry, it brought down the cost of each unit so much that risk-taking suddenly became affordable. Engineers would collect real-world data from the launch of a prototype, improve the design using the data, and launch the next iteration within months.
The prototypes exposed the design to real-world conditions such as wind, temperature, and cosmic rays, which are almost impossible to simulate with computer aided design software. Powered by the learning from these real-world lessons, people turned what was a once a prohibitive rocket science into fun and educational crowd funding projects like this. Sky is no longer the limit.
A similar prototyping practice had been widely adopted in the automobile industry where they call prototypes “pre-production” cars. Those camouflaged prototypes allowed car makers to evaluate the handling, comfort, and performance of a design with real drivers and passengers on real roads under real weather conditions, but without the overhead in building complete production lines or the need to meet all industry regulations. Using the data collected from the prototypes, car makers can address issues that are difficult to identify through software simulations.
Existing prototyping in web design
Just like designers in any other industry, web designers have already been using prototypes to inform their design thinking, conduct user research, or convince stakeholders. But the techniques and tools we use have prevented us from harnessing the full potential of prototyping:
Low fidelity prototypes — wireframes in Balsamiq
The most basic pen-on-paper prototypes or the Balsamiq wireframes are very easy to create, allowing us to fail fast, fail cheap. It also allows us to quickly make several variations of one design so that we can select the best from the pool. But representing the content with fixed sized lines and blocks is fundamentally at odds with the reality.
Real content, rendered in browser, have variable lengths that could overflow the blocks prescribed by the wireframe. Real screens are never the same size as the artboards the prototype is framed in. Real buttons can be clicked, touched, hovered, disabled, and various actions can be triggered, but the prototype, made with static blocks, only represents a snapshot in time and a flat surface in space. The liveliness of interactions and responsiveness, and the depth of the underlying content structure are lost.
Once a prototype is selected to be carried forward, it cannot be reused or polished with added details. The paper prototype only lives on that piece of paper. The Balsamiq project cannot be exported in code that a real browser understands. If we need higher fidelity, we must re-create the same content with a different tool.
High fidelity prototypes — interactive screenshots in XD
At a glance, the prototypes created in high fidelity prototyping apps are indistinguishable from the real product, certainly serving to bring in the reality as we validate the details in our design. But the added fidelity resides primarily on the visual level. The user interactions, on the other hand, are still limited to “switch to screen X when user presses button Y”. Built with static assets, the visually polished screenshots in these prototypes cannot adapt to variable content, respond to screen size changes, and do not support some of the most basic user interactions such as typing and scrolling, let alone complex interactions like screen rotation, drag-and-drop, pull-to-refresh, or sticky headers. As of now, users are still begging Adobe to support right click, double click, scroll, tap, hover, swipe, and pinch-zoom. The list will keep growing.
Unlike low fidelity prototypes that can be created in minutes, the high fidelity prototypes take much longer to draw and assemble, and once built, is not as easy to change because changing the content on one screen might cause all other screens to be updated. The extra overhead in building and changing a high fidelity prototype doomed it to become the new PowerPoint for executive reviews rather than an evolving design in progress.
Reality prototypes — shitty code in production environment
Some teams prototype features in the production environment using new code branches or “dogfood” environments. The practice helps engineers but excludes designers because the prototype is highly coupled with the technology stack of the product. Without advanced coding skills and in-depth understanding about the engineering system, few designers can pull this off. Worse still, once a prototype scores a successful demo, the manager would expect it to be shipped after just a bit of clean-up and testing. We must remember that a rough prototype and a polished product occupy two contradicting ends on the quality-speed trade-off spectrum.
Hence switching from the prototype to production often requires a complete re-write. In the end, this kind of “prototyping” has become an excuse for engineers to check in poorly written code littered with //TODO or //HACK comments.
Functional prototyping — a promising alternative
So, what can we do to improve our prototyping process? Let’s start with the same building blocks and environment as the real product uses: HTML+CSS+JavaScript in the browser.
Content first design
When prototyping with HTML, we are forced to put visual representation aside and think first and foremost in terms of content. The prototyping process informs us on the relationships between regions and components on the screen. “Does that image contribute meaning to that one specific paragraph or the entire article?”, “Should this input filed belong to a fieldset or should it stand alone?” — questions like these will be answered when we prototype with the HTML so developers don’t have to scratch their head playing the role of information architect.
Fast and cheap
A functional prototype, as its name says, focuses on accomplishing a function rather than presenting visual assets. We should not be concerned with frameworks that are overloaded with features irrelevant to our goals. Framework features such as routing, unit testing, bundling, scaffolding, and asset optimizations all become potential points of failures in our prototyping process. A functional prototyper is blessed with the freedom to choose the simplest tool that gets the job done quickly. We can iterate even faster by leaving out CSS entirely because modern browsers apply default style to semantically correct HTML.
Progressive enhancement
When prototyping in the browser, we can start with very low fidelity by writing plain HTML, achieving what a pen-on-paper sketch or a Balsamiq wireframe does. Once we are ready to increase the fidelity, we simply take the HTML we wrote, style it with CSS and add interactions with JavaScript. Each added layer of fidelity enriches and enhances the layers we’ve built. In the end, we can simply hand off the code to the engineers as the design spec. By progressively enhancing the prototype from a design to a product, we save the time needed for recreating the same content in multiple tools, drawing the redlines for the handoff, and going back and forth with engineers about the interpretations of the mockup. You can read more about the pursuit of a lossless handoff workflow in this article I wrote.
Real constraints and capabilities
With functional prototypes, we will be able to test so many things that are impossible with traditional prototyping methods. In addition to testing responsive design on any screen size, we can test animations with the latest CSS features. We can validate accessibility on a visually impaired user’s highly customized screen reader. We can fiddle with complex interactions such as drag-and-drop, form validation and correction, auto-completion, search and filter. We can access the camera, perform voice recognition, even interact with a VR headset— anything that the device supports can be prototyped. Prototyping apps like InVision, Figma, and XD will have to constantly develop new features to keep up with the ever-changing browser and that’s why they will keep charging you subscription fees. Instead of paying for an incompletely emulated environment, why not simply use the real thing?
Summary
In this article, we observed how prototyping allows engineers in various industries to “fail fast, fail cheap”, “select the best from the pool”, and “bring in the reality”. We identified the drawbacks of low fidelity, high fidelity, and reality prototypes. In response to the problems, we proposed “functional prototyping” as a promising alternative that could bring our web design process to the next level.
In the next article, let’s explore the technical aspects of functional prototyping. Stay tuned!
