When we think of the ancient wonders of the world, the Great Pyramids of Egypt are among the first we recall. As great as those structures are, other, lesser-known structures predate those pyramids.

One of those structures is the step pyramid known as Djoser. Built roughly 100 years before the better known Great Pyramids, Djoser was the first in a string of prototypes built by the Egyptians as they attempted to make bigger and grander tombs for their deceased leaders.

While the Djoser pyramid still stands, it doesn't look much like its more famous structural cousins. The later structures capture our attention now, but without Djoser, it's unlikely the Egyptians build the Great Pyramids. And yes, even Djoser was likely preceded by a smaller prototype.

Such is the role of any prototype. Prove the idea is feasible and figure out how to make it better.

As the pyramid example displays, humans have long built prototypes.

Nearly every industry constructs prototypes before embarking on the production of the product itself. Buildings and cars prototyped for structural safety. Furniture tested for flammability. Broadcasting companies use TV pilot episodes to verify the premise of a show before authorizing an entire season.

Quick side note, many TV pilots are hilariously bad.

Prototypes allow us to take a step forward in the creation process while minimizing our risk until we collect more data. Because this creative practice has worked so well with physical products over the past several centuries, it's logical for us to extend the pattern to digital products as well.

Poorly designed physical products pose an immediate danger, but generally to smaller groups of people. Conversely, poorly designed digital products could fail to reach an audience of any kind — or they could garner a massive audience overnight. For this specific reason, you should prototype and rigorously test every product before release - without exception.

Luckily, building prototypes of our digital products is significantly easier than creating a new concept car, building, food product, or television show. The guidance that follows will help you bring your design concepts to life for testing with real users — don't get too attached. You're going to end up sacrificing most of your prototypes to the feedback gods.

A prototype for all occasions

Prototypes are a useful tool for determining if our work is easy to understand and use. Regardless of the project size, a prototype can generate feedback that other forms of research are unable to produce. The amount of effort poured into any prototype is mostly dictated by what you are trying to learn.

Prototypes are a beneficial tool to utilize across the entire life cycle of a product. While it is common to see prototypes used initially to test the feasibility of a concept, you can continue to leverage prototypes for smaller sections of an existing product as features are introduced or reimagined over time.

While it's not uncommon to see prototypes evolve from simple sketches into replicas of the final product, this transformation isn't required. Many prototypes have a relatively short existence confined to simple tests and aren't any more sophisticated than wireframes or rough sketches.

The freedom that prototypes afford can often lead to confusion when determining the type of prototype needed for a task. Because the purpose of the prototype often determines the fidelity, let's investigate the contextual moments that lead to prototype creation.

...for discovery

Often the prototypes we build are actually for ourselves. It's challenging to comprehend exactly how a proposed product will work without connecting the parts. Ideas that once seemed great will be exposed — and this is what we want to happen. The quicker you can find the problem, the cheaper that problem will be to solve.

When you are just trying to find the obvious holes in your work, it makes sense to limit the amount of effort you put into this work. Any additional fidelity added to the work will only drive up the cost associated with the work.

...for understanding

Designers are loyal to the task at hand, but we all have a blind spot in determining if our products are useful. Throughout a project, familiarity with the goal will inhibit your ability to acknowledge the perspective of the average user. The longer we hold onto our prototype without testing it, the higher the likelihood that our product will be challenging to use.

Putting your work in front of a user to see if they understand the product is the ultimate test. Can you put your designer ego aside for a moment and observe the user attempt to use your product? If you can, you'll open yourself up for the most significant moment of growth as a designer.

...for function

While a user might understand the interface, whether it's an excellent interface is another matter. Regardless of the fidelity, a prototype can generate both visible and subtle clues in response to the work. These responses directly determine the next steps you and your team will take as they highlight potential issues that could be costly if left to rot.

Ultimately, prototypes are created to reduce risk. Broken designs and poor designs introduce risk to the equation, but both are equally exposed in a prototype. The faster you can test a prototype, the quicker you uncover problems that users are uniquely suited to find.

Scope of the build

As previously stated, prototypes do not need to reflect the totality of the product you are building, but a successful prototype will excel in the following ways.

Focus

Prototypes only need to encompass the parts of the product that would need to be present for a user to complete a set of tasks.

For instance, if you were testing the ability for a user to compare products, you likely wouldn't need to build out the account settings portion of the prototype.

Your ability to restrain yourself from overbuilding a prototype will save you time that multiplies with each revision you make.

Empty States

You must remember to include the intermediate steps that are presented to the user when they begin using a product. I'm specifically talking about empty states. These include, but are not limited to:

• Empty dashboards
• Empty forms
• Empty order pages
• Empty lists

Empty states offer the opportunity to inject helpful direction and personality into your work that might be otherwise absent.

Feedback

For a static design to become an experience, it must provide feedback to the user. Feedback obviously can be delivered in many forms, but even in simple wireframes, it is possible to provide helpful guidance to a user.

The purest forms of feedback acknowledge the user's interaction. When someone clicks on an icon and the background changes, the application is recognizing the user. This is helpful feedback.

Guidance plays a key role in providing feedback, which is why the microcopy that you include with password creation or file uploading matters so much. You are helping the user understand how to move forward successfully.

We overlook these small details in prototypes often. These oversights occur because we value the polished design too highly, missing the impact that feedback has on the overall experience our products provide.

Exercise

Length: Four-to-six hours to complete.

Use the video above as a guide to better understand how to connect your wireframes in Figma. As the video displays, building a prototype in Figma is relatively straightforward. Still, your discoveries along the way will often lead to additional wireframe work in addition to what you produced in the previous exercise.

Your work has been guided for several chapters by the four, or five-user flows you hope to test with users. All should be present in your prototype.

In your Journal, document the five tests and the path that should be followed to complete the journey through your prototype successfully.

You are encouraged to post updates to your Journal in the #Feedback-Loop channel for review as you progress through the work.

///

Up next UX Case Study