-
Notifications
You must be signed in to change notification settings - Fork 1
Phase II
Phase II focused on refining AllergyDetect’s interaction design and turning conclusions from Phase I research into updated, user focused design artifacts. In this phase, we used cognitive walkthroughs and informal feedback to evaluate how easily first time users could navigate our wireframes to accomplish the primary goal of quickly confirming whether a product is safe to consume based on a user’s allergy profile. The results of these methods gave us ideas to add to our wireframes, especially around improving clarity of the basic workflow, strengthening system feedback, and refining how results communicate risk.
To evaluate the usability of AllergyDetect and identify areas for improvement, our team conducted a cognitive walkthrough and gathered informal user feedback. These methods allowed us to better understand how new users learn and interact with the system, especially under time pressure.
We used a cognitive walkthrough as our primary method, with four external UX evaluators completing the evaluation. We provided each evaluator with the same persona and scenario, focusing on a Jordan Michael whose goal is to quickly determine whether a food item is safe by scanning it, all while minimizing time and uncertainty. Evaluators worked through a structured set of wireframes, including logging in or signing up, navigating the home screen, scanning a product, and interpreting the results.
At each step, evaluators answered standard cognitive walkthrough questions to assess usability. They considered whether the user would know what action to take, whether the correct action was visible, whether the user could perform the action, and whether the system provided clear feedback. Evaluators recorded their responses and documented any confusion, errors, or breakdowns in the interaction.
The cognitive walkthrough revealed both strengths and weaknesses in the interface. Some evaluators found the login process and scanning results clear and easy to understand, but others also identified issues with setting allergies, unclear navigation, and confusion around scanning functionality. In particular they identified confusion whether to use barcode or image scanning.
In addition to the cognitive walkthrough, we gathered informal feedback during a live demo presented to a classroom of undergraduate software engineering students.
Through structured evaluations from external UX evaluators and informal classroom feedback, we gained a broader understanding of usability issues and user expectations. We used these insights to implement design revisions within our wireframes to improve how users complete tasks quickly and confidently.
The cognitive walkthrough showed that AllergyDetect’s basic flow is understandable, but usability depends on how clearly each screen communicates progress toward the goal. It was generally agreed upon that the login and allergy profile page was straight forward, and the large SCAN button makes the first step easy to identify. However, multiple walkthroughs of the app showed that the scanning step needs a better way to show feedback from the app; like "scanning", "loading", or "product found", so users know the app is working.
They also noted that the results screen is the arguably the most important moment in the flow of the app. “SAFE” and “NOT SAFE” are easy to understand when they are shown big and bold on the screen, but “UNCLEAR” created some hesitation, unless the screen explains what caused uncertainty and provides a recommended next step. I'm sure we already include this, but users agree there should always be an obvious “Scan Again” option, and if scanning fails, a manual search path should be available.
Informal feedback showed that users want AllergyDetect to be fast, direct, and easy to interpret at a quick glance. A common theme was that the app should prioritize the final verdict; SAFE, NOT SAFE, UNCLEAR, and avoid overwhelming users with nutrition label information. Participants also emphasized transparency. They wanted to quickly see why a product was flagged, specifically which ingredient or warning statement triggered the decision. It also pointed out that uncertainty needs better explanation, like "here's what to do next".
When faced with a question about intolerances, like lactose or gluten, feedback suggested that AllergyDetect should avoid labeling items as simply “SAFE” when the user has an intolerance. Instead, we got recommended to use a color coded scale for how risky it is. For example; green, yellow, or red so the result communicates a level of caution rather than a yes or no answer. The feedback also showed that mixing multiple result types, like showing “SAFE” while also warning about intolerances, could confuse users, so the system should present one clear status that fits the situation.
After running a cognitive walkthrough and gathering some informal feedback, a few clear patterns emerged in how people actually use and understand AllergyDetect. For the most part, the core workflow makes sense to most users, but how well the app works really comes down to how fast and clearly it gets information across at each step.
One of the biggest things we noticed is that users need immediate feedback to feel like the app is actually doing something. If there's no visual cue while something like a scan is happening, people start second-guessing whether it's even working. That finding pushed us to make real-time system feedback a priority in the design, so users always have a sense of what's going on under the hood. We also found that when someone's trying to make a quick call about whether a food is safe for them, the last thing they want is to decode a bunch of information. People want one clear answer, backed up by just enough detail to make sense of it. That's why the results screen is designed around a dominant verdict first, with the reasoning there if you want it.
Something else that came up was how the app handles uncertainty. Unclear results aren't automatically a dealbreaker for users, but what actually bothers people is when the app is vague about why something's unclear and doesn't tell them what to do next. So instead of leaving users hanging with ambiguous messaging, we redesigned that part to give real, actionable next steps.
Additionally, user responses around food intolerances suggest that a simple yes or no system is not always enough to represent risk. In many cases, safety is not absolute, and users could benefit from understanding different levels of caution. This led to the decision to incorporate a more flexible risk communication approach, such as a color-coded system, allowing the interface to reflect real-world uncertainty better.
Overall, these conclusions highlight that the effectiveness of AllergyDetect depends on how well it communicates information rather than how much information it provides. By simplifying the interface, improving clarity, and supporting quick decision-making, the updated wireframes make the app easier to use and understand. These insights will continue to inform future iterations of the design as the project moves forward.
A major limitation of this phase is that the cognitive walkthrough was conducted with a small number of external UX evaluators, which may not fully represent the behavior of all target users. While the evaluators followed a structured process, they are still making assumptions about how a first-time user would act, rather than observing real user behavior in a live setting.
Additionally, the walkthrough focused on static wireframes rather than a fully functional app. This limited our ability to evaluate real interactions such as system response time, scanning accuracy, or how users react to errors in real use. Because of this, some usability issues, related to real world performance may have been missed.
The informal feedback gathered during the classroom demo was helpful, but it was limited to a specific group of undergraduate software engineering students. This group may not reflect the full range of users, particularly those with severe allergies or different levels of experience with mobile apps.
Because of these caveats, future phases should include testing with a broader and more representative set of users, and include interaction with a fully functional prototype.