Making your user squeeze through a narrow tunnel
When playing video games, you’ve probably noticed those sections where your character is forced to walk slowly through a long corridor while having chat with someone or where they squeeze through a narrow tunnel. One reason for this is to allow the next section of the game to load. It’s a handy way to create a continuous experience for the player.
I’ve rarely found game design techniques to be applicable to web design, but I couldn’t help but think about those hidden loading sequences from games when we were building a feature for a client. The crux of the feature was to allow users to create questionnaires out of video transcripts using AI. The problem? The videos can be anything from a couple of minutes to a couple of hours long. Therefore, as the prompt for the AI included the entire transcript, it could take some time to process the request to generate the questionnaire. Due to that variance, we could perhaps make the users feel like there’s no waiting at all for most of the videos.
So what do we do? I like to think of UX design as playing magic tricks on the users. Since we were working with a Ruby on Rails app that has been around for over 10+ years (and to be efficient), we wanted to do something simple. What we needed to do was play some time until the AI had managed to generate the questions, like a video game would by forcing the player to walk through a corridor. Instead of removing friction from the flow, we add some. After the user clicks the button, we start a background job and then greet them with a static view. Here are the considerations that we had:
- We want to indicate that the request is being processed, so we show a spinner.
- We don’t want the user to click “back” on their browser so that we don’t queue up the same job multiple times, so we redirect them by force after a while.
- Due to the variance in how long the AI takes to process the request, we didn’t want to build auto-redirect to the processed questions so that the user wouldn’t stay on the page waiting for the questions to be generated. We’d rather have them work on something else if the process takes long.
In most cases, the user will be greeted with a notification alerting them that the questions are ready right after the redirect – especially if they let the timer run out. This is really what we want, but we also want to make sure they can continue creating content and queue up another questionnaire if the process takes longer than expected. While we could’ve just given the users a flash notification and let them continue working on other things, we wanted to make the user feel like the questions get generated instantly (at least most of the time) and that they could also keep focusing on one thing at a time. By mitigating the opportunities for the user to get side-tracked, we make sure the questionnaires get reviewed and published as the task is fresh on the user’s mind. Sometimes even a simple solution like this can be effective.
Comments
You can leave a comment on Bluesky