At Stride, users are at the center of the entire design process. Our goal is to design a product with purpose, which is why the last stage – high-fidelity wireframes – is not the final one. 

In the last phase of design, we build a product prototype that we can use to demonstrate the behavior of an application, validate stakeholder expectations, and gather user feedback.

It is important to note that I am talking about prototypes from the design point of view only. In this context, a prototype is a clickable representation of the final product (i.e., not a static view like a wireframe).

Product prototypes help meet user expectations

While I love using an actual built product to get feedback, that is not always possible. However, a design prototype provides a realistic view of how the product will work by simulating the user experience, which is sufficient to get the feedback we need.

Prototypes bring the wireframes to life by allowing users to click on the screens and get a response. This gives our stakeholders and end users a much better idea of what will be built and validate application behavior (i.e., how a user will move through the different screens and how those screens will work once built).

With a prototype, we can demonstrate how the different states of the application behave as the user moves through them. For example, does hidden information become visible as expected, based on a specific user action?

Should product prototypes use clickable or no-code/low-code?

At Stride, we use prototypes to validate the usability and overall value of the solution. There are two types of prototypes we usually employ: clickable and no-code/low-code. Both types are fairly quick and easy to put together.

Clickable prototypes 

Clickable prototypes are either lo-fi or hi-fi wireframes with hot spots added to the designs. The hot spots create clickable areas on the wireframes. 

I use this type of prototype when demonstrating to the stakeholders how the wireframes will flow because I can show both how the user will move from one wireframe to another and how user interactions behave, such as drawer slide-outs or modal windows. This begins to bring the static wireframes into the world of an actual product and is great for initial feedback from the stakeholders.

No-code or low-code prototypes 

No-code or low-code prototypes are better for eliciting feedback from end users because they will more closely mimic the final product. 

All the branding, final page copy, and elements are present on the page and will behave like users are expecting them to (e.g., input fields accept typed text, dropdowns slide down, etc.). We want users to be comfortable enough with the product to give useful feedback, so it helps to have the prototype mimic the actual end product as closely as possible. 

To that end, I have found that users provide more relevant feedback when using the prototype rather than viewing the wireframes.

Prototypes lead to design updates or backlog stories

So, what do we do with the learnings from our prototypes? If the areas affected have yet to be developed, the designs are iterated on and approved by the stakeholders. If updates are needed for features that are already in development, a story is written and added to the backlog. Although development may have already begun, the designers are continuing to iterate and refine as new information is received and prioritized.