Repository navigation
phaseII
During Phase I, our team focused on understanding our users and analyzing our competitors through competitive analysis and heuristic evaluation. From our findings, we saw many usability issues like limited alert customizations, unclear navigation, and a lack of user control.
For Phase II, we focused on evaluating our wireframes and see what could be improved. We did cognitive walkthrough with three evaluators from outside our team to see how users would use our app and see if any problems may occur. We also gather informal feedback from fellow software engineering students during a demo of the app.
Using the feedback from both methods, we identified many areas that needed some improvements like the purchasing process, missing screens, navigation, and notification settings. These helped us in coming up with designs recommendation that could further improve QuickCop.
The purpose of a cognitive walkthrough is to find learnability problems by stepping through a task as a first-time user would. We chose it because QuickCop's wireframes are early and have not been tested with real users, and a walkthrough can expose confusing steps before anything is built. We used the streamlined two-question version described by Spencer (2000), which reduces the original procedure to the two questions that matter most at each step and makes it practical to complete in a short time.
Three evaluators from outside our team, but still in the Usability Engineering class, each completed a walkthrough individually, working independently of one another. Each received our Figma wireframes along with our personas and scenarios, and each chose one of the personas. Evaluator 1 used Chloe (Window Shopper) and her scenario of finding a 21st-birthday gift for her friend and setting a reminder for it to go on sale. Evaluator 2 used Clarence (Collector), whose goal is to buy trading card game products. Evaluator 3 used Collins (Penny Pincher) and his scenario of watching for a drill bit to go on sale. Evaluators completed their walkthroughs on October 15th, 2026.
Following instructions given in class, each evaluator first listed every step they expected the persona to take through the wireframes to reach the scenario's goal. For each step, the evaluator answered two questions: "Will the user know what to do at this step?" and "If the user does the right thing, will the user know that they did the right thing and is making progress toward the goal?" Evaluators recorded their answers in a notes document, including any step where the answer was no and why. Our team then read all three documents and grouped the problems by the screen on which they occurred.
To collect broader and less structured reactions, the Software Engineering team demonstrated the QuickCop prototype to a classroom of 27 undergraduate software engineering students. During the demonstration, we asked whether users would want to receive a notification repeatedly if they had not acted on it, how often those reminders should arrive (every 24, 12, 6, or 1 hour), and whether follow-up reminders should use a lower-priority channel than the first alert, for example a push notification followed by email only. Students also gave open comments after the general presentation, which we recorded as written notes. We chose this method because it was quick and reached people who resemble potential QuickCop users, while recognizing that it is less rigorous than a structured evaluation.
Evaluator 1 (Chloe). This evaluator described the path a user would take through the login and registration screens, the hamburger menu with its home, recently watched, recommended, popular, category, settings, and store entries, the category and store pages, the item page, and the profile change page. They noted that watched items can be adjusted for discount, stock, and store through a settings gear icon. For the second question, whether users would know they were making progress, the evaluator found the experience confusing, because nearly all navigation depends on the hamburger menu. Users familiar with hamburger menus would likely cope, but others might not know where to go next. The evaluator recommended adding a home page with easier navigation than the hamburger menu alone. Their walkthrough did not reach the point of setting a sale reminder for a specific gift.
Evaluator 2 (Clarence). This evaluator followed a short path from login and registration, where the user enters an email, a username, and a password twice, to the home page, then to Categories and Cards, then to a product and finally an external store. They found the login and registration screens self-explanatory because they resembled screens they had seen before, found the home page easy to understand, and called selecting a product trivial. The one problem came at the end. The item page lists external stores, and clicking one sends the user away from the app, which the evaluator called inconvenient but doable. This walkthrough covered buying a product and did not include setting an alert, and the evaluator did not explicitly say whether users would know they were making progress.
Evaluator 3 (Collins). This walkthrough found the most problems. Collins registered without difficulty and then scrolled through the Popular section, where the "prod" and "phone" buttons confused him. He avoided them because he did not want to mess anything up. He then used the search bar, typed "1/16 inch drill bit," and pressed Enter, but the wireframes have no search results page. Assuming he found the right bit, he opened the item page and looked for a cart or buy button. He was slightly confused about how to buy the item and tapped the first thumbnail in the Stores gallery, but there is no wireframe for the Store page. After backing out to the item page, he became confused, closed the app, and opened Amazon. This walkthrough also never reached setting a sale alert on the drill bit.
Students' comments fell into four themes. On notifications, the response to our question about repeated reminders was that reminders should arrive about once a week, which is far less often than the 24, 12, 6, and 1 hour intervals we proposed. We did not get a clear answer to our question about lowering the priority of follow-up reminders, so we can't draw a conclusion about it.
On purchasing, students suggested that QuickCop could order automatically from a site as long as an item meets a user-set threshold. They asked how the app would handle accounts for buying things and suggested a balance held on QuickCop for purchases. They also described three levels of purchasing: notifications only, giving the app a credit card, and buying immediately with the option to return the item later.
On trust and safety, students asked for detection to keep bots from using the app, for authenticity checks on items from marketplaces such as eBay, for the ability to blacklist sellers if QuickCop opens to more sellers, and for a minimum price to guard against scams.
Finally, students made other suggestions: that settings save automatically rather than through a save button, that more local stores be included, that the app support crypto, and that it connect to the dark web.
The walkthroughs show that the wireframes support the first half of each scenario, registering and browsing, but fail at the moment users should act. Two evaluators were confused or left the app at the item page, and none completed a scenario by setting an alert. This is the most important insight of the phase. Collins looked for a cart or buy button and found only a gallery of external stores, and Clarence completed a purchase but found being sent to another site inconvenient. Therefore we recommend that every item page present a clear alert button and a clear purchase path together, and that the purchase path hand the user to the retailer with the item and price carried over. This extends our Phase I recommendation for fast purchasing and for making alerts quick to set up.
The second finding is that missing frames cut evaluators off from their goals. Collins's search ended at a screen that did not exist, and so did the Store page. We recommend adding a search results page with filters, a Store page, an alert setup screen, and a "my alerts" screen where users can edit, delete, and undo alerts. These additions answer the Phase I needs for better search, faster alert setup, and easy ways to go back or undo. Collins's hesitation over the "prod" and "phone" buttons also tells us that older and less experimental users avoid controls they do not understand, so we recommend replacing them with plain-language labels.
Evaluator 1's difficulty with the hamburger menu leads us to recommend persistent navigation, such as a bottom bar with home, search, alerts, and profile, so that the most common destinations never depend on a hidden menu. The hamburger menu can remain for secondary items such as settings and stores.
The classroom feedback pushes the design toward trust and user control. Students asked for reminders about once a week, so we recommend making reminders optional and defaulting to a low frequency, with the user choosing the interval and channel. The three purchasing levels students described fit our personas well. Carson and Clarence value speed and might want automatic buying, while Collins and Corbin mainly need alerts. We therefore recommend a per-alert setting with three options: notify only, one-tap checkout with pre-filled details, and automatic purchase up to a price the user sets. Students' safety suggestions fit our Phase I recommendation to be honest with users, so we recommend a minimum-price option and a flag on unverified sellers. We also recommend that settings save automatically with a visible confirmation, which supports the Phase I finding that users need clear feedback and control.
We recommend not pursuing a dark web connection or crypto payments in this version. Neither answers a need expressed by any of our personas, and both add legal and safety risk that conflicts with our goal of trustworthy alerts. A stored balance on QuickCop would make us responsible for handling users' money, so for now we recommend handing users off to retailers' own checkouts. Bot detection, local stores, and seller blacklists are worth recording as future work.
Our walkthroughs used three evaluators, one per persona, so each persona and scenario was tested only once, and one evaluator's confusion may not generalize. Although all evaluators received the same two-question instructions, they documented their walkthroughs in different formats. Only one answered both questions explicitly for each step, and the other two wrote step lists or narratives from which we inferred their answers, so some findings reflect our interpretation. The evaluators were fellow students from other teams, rather than professional UX practitioners, so they may catch fewer problems than experts would. Because none reached the point of setting an alert, we have little evidence about the alert setup process, which is QuickCop's central feature. Evaluators also had to assume what would happen on screens that did not exist, so some findings reflect gaps in the wireframes rather than flaws in the design itself. The second walkthrough named its persona "Collin" and described a trading card goal, so we interpreted it as Clarence this was also because they told us that they were picking Clarence. Also there have been changes made to the wireframes since the cognitive walkthrough was complete.
The classroom feedback came from software engineering students, who may not represent users like Collins (62, retired) or Corbin, so their reminder preferences should be tested with more varied people. The questions were informal, we do not have counts for each response, and some suggestions, such as the dark web and crypto, may have been offered casually. We have not yet tested the design with real users on a working prototype, and we recommend usability testing in a later phase.