Bring every idea to life.Learn more
Learn how to prototype for the best case scenario—and the worst.
The following is a guest post by Shan Shen, Product Designer at Wish. Shan loves crafting both consumer and enterprise products and writing about process.
Recently, after spending hours creating a prototype that my design team loved, I walked over to the engineers to share my work. At this point, I was expecting an exciting discussion and an action plan around the prototype.
"Sorry, it’s out of scope." Just like that, my engineering counterparts declined my proposal.
"We need time to dig into the prototype and figure out a way to make it work. Given the time and effort needed, we won’t be able to take on animations in this release."
I was dejected, but there were bigger implications. Now users were going to miss out on an interaction that the design team thought would be helpful for their experience. And from a company perspective, we’d be behind on testing and validating design and business ideas and collecting feedback.
Pointing out this all-too-common experience isn’t meant to discount the impact of prototypes. In fact, most of us know that they are invaluable in the product workflow. But it’s just as important to consider when and how to prototype effectively. Secondary to that is the delicate balance between the need for thorough animations and a design that is lightweight enough to work for development.
Let’s start with bad user experiences. I think we can all agree that a product should consistently present meaningful information and remain transparent about its abilities. Because when a page fails to load or returns errors, users get frustrated.
Now you may have heard of the term "graceful degradation", a scenario wherein designers need to account for apps or systems that are inoperative. Most of the time, the solution can be 404 pages or explanation messages. And while this doesn’t fully reconcile our users’ frustration, it does allow us to turn a horrible (potentially churn-inducing) experience into an opportunity to surprise and delight. Instead of throwing users off the bus, some simple motion effects can keep momentum going and channel their frustration into positive reactions.
Take a look at the Chrome dinosaur game. When Chrome is offline, users can play the runner game in the browser until they reconnect to Wi-Fi. This game allows users to stay engaged for as long as they want and access limited functions within Chrome. This is a great example of how prototyping for the worst case scenario can lead us to rethink the continuity of interactions beyond a single static screen.
Bring every idea to life.Learn more
Next, let’s look at an integral part of the user experience—conversion. When a user makes a purchase or submits a form, they expect to receive a confirmation message upon the completion of said action. These messages give users’ peace of mind and ensure their requests are being processed. But how much time do users require to read and understand a confirmation message?
Initially, I assumed the actual content of the confirmation messages to be redundant, since users should be fully aware of their actions at this stage. As long as a confirmation message appears, I thought, then the content of the message was less relevant.
Hence, I used this formula to set the duration of a confirmation message: Duration = # of words in the message x 100 millisecond
Translated, that meant that every 3-4 words would take about one second to read. For a short sentence, that duration amounts to 3-4 seconds. Then, during testing sessions, I received feedback from many users that messages faded out too fast, and they weren’t able to follow along. From running eye-tracking tests on some prototypes, I also learned that because a user’s attention is often divided, a longer timeout was needed to ensure the user noted the confirmation message. Now that’s something I wouldn’t have caught with a static design.
Another factor to consider is that often, users can be temporarily disabled when they are using apps. Such scenarios exist when users receive chat messages while driving, browsing an app in direct sunlight, or following recipe instructions while cooking.
It’s important to consider that we don’t always have our users’ full attention, and we should be aware that the user’s interactions commonly fragmentize while multi- or triple-tasking. If we simulate distractions through prototyping, we can more accurately put ourselves in users’ shoes first, which gives us a better all-round picture of how to design for them. For example, a ringing screen in video chat-enabled apps is essential because it communicates urgency, but also engages users through an indirect nudge rather than pressuring them.
Prototypes are compelling because they help us put our app in various states: from the best-case scenario to the worst. When done right, prototypes can show us that deprecating an animation in favor of our app’s performance is the right thing to do. Other times, prototypes can lead us to contextualize edge cases and provide inclusive solutions. It all starts with a purpose, ultimately helping us land on usability.
Want to learn more about prototyping? Check out the following resources:
Join our newsletter and get resources, curated content, and design inspiration delivered straight to your inbox.