Interaction Analysis: The "Who Paid" Problem

Comparing Norman’s 7 Stages vs. GOMS using an expense-splitting application scenario.

Norman vs. GOMS Comparison Table

Scenario: A user needs to log a $50 dinner expense paid for a friend named "Sam" using a mobile app.

Comparison of Norman’s stages and GOMS concepts for logging a shared expense
Norman’s Stage Real-World Example (Expense App) GOMS Interpretation & Rationale Alignment Analysis
Goal ↔ GOAL “I need to record that I paid $50 for Sam so I get reimbursed.” GOAL: ADD-EXPENSE.
The high-level objective driving the task.		 ✅ Perfect Match
Both models identify the intention.
Plan ↔ METHOD User decides: “I will use the 'Quick Add' button on the dashboard.” METHOD: USE-QUICK-ADD.
Selection Rule: If hand is already on phone, use Quick Add.		 ✅ Conceptual Match
GOMS formalizes the choice as a Rule.
Specify User looks for Sam's name and decides where to type "50". Not Explicitly Modeled.
GOMS assumes the expert user knows the input locations.		 Divergence: Norman explains the mental search; GOMS ignores it.
Execute ↔ OPERATOR User taps "Add," types "50," selects "Sam," and taps "Save." OPERATORS: [K] for typing, [P] for tapping Sam's name, [B] for Save button. ✅ Direct Match
The physical actions map to GOMS Operators.
Perceive / Interpret / Evaluate 
Perceive: User sees “Expense Saved” and balance +$50.
Interpret: User understands the expense updated Sam’s account.
Evaluate: User confirms the system responded correctly and feels confident.
 Not Explicitly Modeled.
GOMS assumes success once the final Operator is executed.		 Divergence: Norman focuses on feedback (closing the Gulf of Evaluation).

Analysis Insight

In the "Who Paid" Problem, Norman's model is superior for identifying if the app makes it difficult to find a specific friend (the Specify stage). Conversely, GOMS/KLM is better for predicting how many seconds it takes an expert user to log multiple expenses in a row.