Saving Your Web Workflows with Prototyping

Prototyping.news: For a monthly update on the latest articles, tools, and other resources about prototyping for the Web, sign up for my new newsletter prototyping.news.

The Illusion of Control

We have a problem. And I fear that many of us still don't see it. And those who do see it are still not completely sure what to do about it. The problem is this: The traditional tools and workflows we used for years to build things for the Web don't work anymore for today's Web.

Most of our tools and processes originated in a time when designing for the Web basically meant designing with only a few colors and pixelated type for screens that had relatively clear and small dimensions. The obvious constraints of “new media” – with the pixel as the omnipresent smallest visual building block – were defining its character and made it stand out against print media. Over time, in search of control and with growing professionalization, agencies and design studios established processes that allowed them to build and sell websites professionally. And because every new medium first borrows from its predecessors, the answer to the question of how to approach the web design process seemed obvious. Let’s do it like we do printed products, like we design all products in classical industrialized workflows: Plan. Design. Produce.

And it worked.

Planning websites grew to a domain of great expertise. Specialized disciplines like Information Architecture, Content Strategy, or User Experience Design evolved. Sitemaps and wireframes got created so that the structure and hierarchy of a website would be clear before starting with the design phase. The designers then built beautiful layouts out of those wireframes so that clients could approve how the website would look like. And finally, the developers took those Photoshop layouts and magically transformed static designs into interactive pages. Everything was plannable. Everything was predictable. Everything was under control.

Until everything changed.

It was the Web itself that changed. Because change is in its nature. Maybe the most striking example of this change is that instead of a clearly defined canvas (of 640 x 480 800 x 600 1024 x 768 pixels) we now have to design for this:

What you see here is a – by no means complete – visualization of currently available screen sizes, ranging from tiny smartwatches up to huge 4K screens. Apparently, the differences between the individual screen sizes become more and more blurred. Where do we draw the line between “mobile” and “tablet”? Where does “large desktop” start? The idea of a fixed canvas and the control we thought we had over it is definitely a thing of the past. And this doesn’t only apply to screen sizes, it also applies to the Web as a whole.

The Web has evolved at an unimaginable speed and we are now witnessing an unprecedented diversity of not only screen sizes, pixel densities, and color spaces, but also devices with most different capabilities, sensors, input types, browsers, APIs, accessibility features, security issues, connection speeds – the list is endless and it won’t ever be complete.

All those technologies and contexts are things that we can and often even must take into account when we build something for the web because all those things can inform our products and shape the experiences of the people who use those products. A website is not a static artifact. It’s a flexible, living thing that can assume the most different forms and can even evolve over time. And if you consider all the things that are yet to come, for example in the fields of the physical interfaces, AI and machine learning, or also with additions to existing technologies like JavaScript Web APIs or CSS Houdini which will let you create your own custom properties, custom functions, and custom @-rules – how can one possibly think of the Web as something homogeneous in this age of extreme computing?

The Web isn’t uniform. It never was. If we thought we were in control, it was only because we hadn’t yet imagined what the web would look like when unfolded to its true nature. The Web of today is complex, flexible, blurry, chaotic, unpredictable, extendable, immediate, omnipresent. And this complexity of the Web leads to the major problem regarding our processes: When every project is different, when conditions, tools, and technologies change with every project, static and linear processes are less and less repeatable and planning for success beforehand becomes basically impossible. There are simply too many factors with too many unknowns to consider. So if we want to build lasting, appropriate, performant, accessible, consistent, secure, and unique experiences for everyone on the Web, we need to find ways to cope with this multiplicity.

To some extent, we already started. In the year 2000, John Allsopp wrote his renowned article A Dao of Web Design in which he suggested that “we should embrace the fact that the web doesn’t have the same constraints [as print], and design for this flexibility.” But his call remained unheard for years and it wasn’t until the mobile revolution that we actually started to change the ways we design for this flexibility.

First, we indeed ditched the notion of a fixed-sized canvas and got our heads around the idea of responsive web design. Ethan Marcotte, who coined the term responsive web design back in 2010, recently pointed out that we also “have started to break our interfaces down into tiny, reusable modules, and began using those patterns to build products, features, and interfaces more quickly than ever before.” We also questioned Photoshop, the “damn liar”, and started to fall in love with tools like Sketch or Figma, that promised to be more suitable for designing user interfaces. Instead of designing static pages we are now building modular systems of components. At least that’s what we do in theory.

In reality, many of us are still struggling with the permanent shifts and rapid change of the medium. In reality, the new agile and lean processes we love to talk about in front of our clients are seldom more than high-frequency waterfall. In reality, I still hear project managers, designers, and developers regularly talk about screen widths in device-specific categories like mobile, tablet, and desktop. In reality, I still get to see my fair share of static Photoshop layouts and, to be honest, breaking up our static designs into components and modules in Sketch may be a step in the right direction but it doesn’t necessarily make our designs less static. To some degree, we only switched one static design tool for another. To some degree, Sketch is a liar, too.

We are still drawing pictures of websites – although, as Paul Robert Lloyd noted, the true web aesthetic is hardly visual at all. We are still tackling a flexible medium with the static tools and linear waterfall processes of the past, that can’t represent the inherent nature of the Webs ingredients because we are always creating static abstractions of the final medium. This leads to tedious, inefficient, and highly ineffective tasks, wrong features being built, and most importantly: because we spend most of our time doing the wrong things, the quality of the experiences we offer our users suffers. So it is about time for us to change that.

A Material to Build With

At Webstock 2015, Frank Chimero gave an outstanding talk in which he discussed the true nature of the web – he called it The Web’s Grain – and suggested that if we want to come up with appropriate design solutions for today's Web, we need to recognize the things that are implicit to the medium and work with them accordingly. And he asked:

If we look at the Web as a material or even as a multitude of different materials to build with, using tools like Photoshop that ignore fundamental attributes of those materials – like interactivity or movement – suddenly appears even more inappropriate. At the same time, finding ways to appropriately build things out of those materials becomes an imperative. But how can we approach this? How can we find tools and processes that let us work with the Web as a material? To answer this question it is worth looking at the history of some disciplines that have always been working with materials.

In architecture and industrial design, but also in engineering, materiality has always been a crucial element. Building for the Web combines properties from all of those disciplines, but maybe we missed to realize and consider the materiality of the Web because of its virtual nature, because it lacks physicality. At least, you can’t feel the weight of a website or smell it (yet).

In architecture and industrial design, there exist the concept of material honesty. Material honesty means that a material should be used in accordance with its true nature and its properties and that those properties should influence the form the material is used for. The origins of this idea can be traced back to the Bauhaus, the German art and design school that laid the foundation of modernist industrial design and architecture. The Bauhaus was founded with the objective of finding a new aesthetic that was appropriate to the standardized production methods of the industrial age. In contrast to the Art Deco movement, the Bauhaus wanted to forgo the romanticizing, ornamental decoration of industrially produced objects. In his ‘Principles of Bauhaus Production’, architect and Bauhaus founder Walter Gropius wrote:

Consequently, material studies were a central element of the Bauhaus teachings. Timeless and for their time revolutionary designs like Marcel Breuer’s “Wassily Chair” or the Bauhaus Buildings itself, by Walter Gropius, combined materials in a new, materially honest way: Instead of hiding materials like steel and concrete those materials defined character, form, and function of the designed objects.

The guiding principle of finding a materially honest form and function is one of the major legacies of the Bauhaus. Many designers and architects were deeply influenced by the ideas of the Bauhaus, for example, Charles and Ray Eames. For them too, selecting and working with the right materials and taking their qualities into account was pivotal to designing objects like the Eames Plastic Armchair that masterfully combined molded wood, aluminum, steel, and high-performance plastics, using each material to its full potential. In the Eames workshop, the couple experimented with different materials like molded wood, for which they used a machine they had crafted to pressure-treat wood. The resulting prototypes were honest and pure expressions of the molding process, not upholstered and straightforward. But Charles and Ray Eames also considered another aspect of product design, that is, that eventually all products are used by humans and the usefulness of a product also highly depends on the human factor. This is why they built prototypes like an adjustable chair design tool to understand how people sit. Charles Eames: “We’ve always been aware of not even attempting to solve the problem of how people should sit, but of rather arbitrarily accepting the way people do sit and of operating within that framework.”

So to design resilient and adaptable systems in accordance with the true nature of the Web, we should do the same: We should explore the materials of the Web to work out their characteristics which then shape the design patterns of our system, while always considering the usability of our solutions. For physical products, certain technical and aesthetic qualities like structure, surface, flexibility, or durability characterize the nature of a material. For digital products, similar qualities can be explored: How flexible is a solution? How robust is it? How well does a solution work in different contexts? How much interactivity does it have? Does it allow growth? How performant is a certain framework, how flexible a CSS methodology and so on. To assess all those qualities we need a tool that is just as approachable, just as flexible, and just as extendable as the Web itself.

This tool is prototyping.

A Prototyping Mindset

All design is the result of a series of decisions. Along the way, all of those decisions influence how the result will look like. And so, depending on which paths we decide to take, there are endless possible futures. Many of those decisions can only be made thoroughly when you have arrived at the point where the decision has to be made. If you try to plan beforehand, you run the risk of following the wrong strategy and ultimately building the wrong product. Neither a linear waterfall process nor static visual designs are suited to reveal the true cost and effort it takes to build something for real, whether a certain feature is really what your users need, or if an implementation will work in production. So you need to work iteratively, being flexible enough to change course if a road proves to be the wrong one and being there when a feature evolves that needs more attention.

Prototyping supports you in making informed decisions in iterative workflows. It allows you to explore the characteristics of materials, quickly combine them into new constellations, and come up with something original. In this way, prototyping actively supports the generative and constructive nature of design. It lets you validate your assumptions and test ideas and new solution approaches early and in different contexts so that you know what will work and what you are building. Prototyping is a tool and a process, a way of working. But most importantly, prototyping is a way of thinking, a mindset.

A prototyping mindset means that you include prototypes in every phase of your process. This also implies that you understand prototyping as the flexible tool it really is. When someone mentions prototyping, many people either think of interactive wireframes or rapid prototyping techniques. But this definition is far too narrow. Prototyping is much more. A prototype can be anything: A quick sketch, a short animation, a markdown file outlining a structure, or an interactive HTML application. Anytime you start to explore a problem, begin to try something out, and start to render an intent you are basically building a prototype. It is not the form of the prototype that counts, or how fast you build it, or if it is a deliverable – it is what you want to achieve with it and what you learn from it.

A prototyping mindset also means embracing the complexity of the Web and getting comfortable with uncertainty. It means starting with the most basic solution to a problem and then exploring and iterating from there, using real materials like code and real devices as early as possible.

A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.

Moving away from static processes doesn’t come for free and requires a lot of patience and effort. Convincing colleagues and clients to use a prototyping-driven workflow can be tedious. It implies that people let go of old habits and get comfortable with a process that seemingly offers less control. But in the end, introducing iterative, flexible workflows makes the difference between average and great digital solutions.

Prototyping is an essential, powerful element of those iterative workflows and especially prototyping with code will enable you to develop solutions that matter, solutions that are appropriate, robust, performant, accessible, and secure. Honest to the nature of the Web and thus honest to your users. But most importantly: It will feel like you are building the right thing. Finally. So if you haven’t started prototyping yet, do it today.

–

Header artwork based on a photo of a rare, clear case prototype of the Macintosh SE by Jim Abeles

Prototyping.news: For a monthly update on the latest articles, tools, and other resources about prototyping for the Web, sign up for my new newsletter prototyping.news.

~