Response and Solution

The users are subconsciously making the affordance between text and reading. Even though the text is hard to read, they still try to read it because any text on any screen can be read. Branching off this, the user’s mental model of the way text messages work is that someone messages you and you read it and reply. This breaks the connection between reading it and replying. 

To approach solving this problem, I thought, "How do games differentiate cutscenes and loading screens from actual gameplay?" By possibly adding some feedback to the player that they are in a cutscene and cannot perform any actions it would prevent them from clicking. I ended up making this scene play out faster and included more unreadable text (non-English) in the first paragraph to communicate to the users that they shouldn't read it.  I also used black bars at the top and bottom that slide into view to simulate how a cutscene is being played.

Users are already familiar with cutscenes from games through the system image, the information the designer gives to the player. They have a mental model of how cutscenes work with previous experience with games, so trying to implement what makes cutscenes stand out from the interactive parts will help with user understandability.

My goal with this clear text example was to explain what was wrong with the text shown on the screen before and offer solutions that the user could understand. Addressing the problem in this practical way makes the users experience the struggles of unclear text and also understand ways of solving this for future projects. 

Response and Solution

This is valuable feedback to me, I feel victim to the concept I was trying to teach people to avoid this accessibility concern in the first place! The text in the first iteration isn't clear and is hard to read, so I ended up increasing the size of the text box, and also increased the size of the text as well to avoid running into the same issue. 

I also added a back button for users to go to the previous scenes if they missed or wanted to re-read information. This bottom screen stays persistent throughout the entire app for consistency.

In regards to Iteration 2, the wording of the text makes it seem like it's the user's fault for not replying when it says "I think they were trying to ask you a question... I don't blame you for not replying". I changed this text in the final product so now it reinforces their inability to not read the text instead of go against it and guilt-tripping the user.

My goal with this total recall section is to create sub-menus where players can access all the information presented in this application in case they might have missed something or want a summary. This is, once again, a practical way of explaining the Total Recall pattern by actually doing it and making the player go through the steps.

Response and Solution

Users made an excellent point that there was simply too much text for this section that is supposed to display easily digestible information. I ended up, over many iterations, reducing the text to the core of what users will need to understand the accessibility pattern. I removed the design problem in red text from every pattern and only kept the solution because it covered the design problem.

To make users understand that the action of scrolling can be performed, you can notice in the final that the bottom pattern is cut off a bit. This is a natural indicator for humans that there might be more down there and will scroll to reveal new information. In the first iteration there was too much text that it seemed like it was only supposed to display one pattern.