Why do we, digital designers, prototype?

Some of you might say that we create prototypes to improve the user experience. Others would argue that prototyping allows us to iterate faster in our creative flow, and still others would mention that prototyping saves developers’ time.

Eventually, it all comes down to validating ideas and solving problems. That’s what the prototyping is truly all about.

Prototyping Digital Products ≠ Hollywood movies.

Our digital products are not linear, moving from one fixed state to another. All of them, besides maybe one-page websites, are dynamic and have many possible flows that users can follow.

These flows are painfully-hard to replicate with the existing “duplicate-screens model” tools. Instead of solving problems, we end up spending hours cloning screens for every new element state. We later insert pre-made transitions in between, just to create very basic interactions.

In the end, we still have to explain to our prototype’s users (or developers) that “this thing here works, click here. But wait, this doesn’t work, ignore it”.

Duplicate-Screens Prototyping Model

In order to prototype apps and websites that really work, we need conditional logic. Simple (and visual) if/else statements, combined with other interaction building blocks: element states, dynamic selectors (select all elements with border of $x px and only children elements of $y), events (i.a. click, hover, pointer-up) and operations (page transitions, state or data changes).

If you want to learn more about how these work in Phase, check out our recent piece.

How Conditional Logic Works

Today, let’s take this one step further. Imagine we have created our dream prototype, where every button and every element works.

What happens now? How do we really use it to validate our ideas?

The Turning Point ⎋

Most of you probably might now be thinking — we can already do user testing on our prototypes.

User testing is the moment of truth. It’s where we get final, real-world validation of our ideas.

We’ve got our working prototype. Now we are giving it to the real users for a trial. We carefully collect their feedback. Analyze both quantitative and qualitative data. Maybe even follow up with them and ask a few questions. And voilà — we have our answers. Great job.

Sounds like a piece of cake, eh?

But is that really what happens? Is that how we currently do user testing?

Well, that’s what all of us would definitely want to happen. But in reality, it’s not that simple.

Real prototypes have to be coded nowadays. By real prototypes, we mean prototypes where every button and every element works, even when we have a few dozen screens. No duplicate-screens tool can handle that level of complexity.

The trouble with testing something that doesn’t fully work (i.e. has been coed), which we test with instructions like “click that,” and “…oh, no don’t click that! It doesn’t work,” is pretty clear.

What the user is testing in the prototype and what may eventually exist in the real world, is only vaguely the same thing.

Getting engineers to code these prototypes for us also takes weeks, even months of time in some teams — depending on your engineering department’s size and availability.

While waiting (no one can really afford to just sit and wait), we designers start prototyping new things — adding even more tasks to the development pipeline.