Writing User Stories for Transfer Review Screen
In this session we wrote the user stories for the review screen for making a transfer. We covered all the scenarios so that the user can see all their selections.
Member Track Questions
Track 1 – Foundations
Goal: Learning to understand intent and flow
-
Why is the review screen read-only instead of allowing edits directly on that screen?
-
What is the user’s primary goal when they reach the review screen — reassurance, correction, or commitment?
-
Why do we need a confirmation step when the user chooses Cancel instead of just canceling immediately?
-
What could go wrong if we did not repopulate the data when the user selects Edit?
Track 2 – Interview Ready
Goal: Learning to articulate decision thinking
-
If asked why we built a review screen before confirmation, how would I explain its business value beyond “it’s standard practice”?
-
How would I explain the risk we are preventing by showing a cancellation confirmation dialog?
-
If an interviewer asked how I handle navigation logic in requirements, could I clearly describe managing the edit flow vs the creation flow?
-
How would I use this review screen example to demonstrate that I think about user confidence, not just functionality?
Track 3 – Early BA
Goal: Execution depth and requirement precision
-
Did I clearly define what fields are displayed on the review screen and confirm that they exactly match what was entered?
-
Did I specify what happens if the data changes between the initial entry and confirmation (e.g., account becomes inactive)?
-
Did I clarify whether Confirm triggers immediate processing or queued processing — and whether we show a success page?
-
Did I define how the system handles browser refresh or back-button behavior from the review screen?
Track 4 – Practicing BA
Goal: Risk, systems thinking, and strategic UX evaluation
-
Is the review screen mitigating financial risk, regulatory risk, or just UX confusion — and have I articulated which one?
-
Should cancellation confirmation be required for all transactions, or only high-value ones?
-
Have I considered audit logging requirements for Confirm, Edit, and Cancel actions?
-
Is the edit flow preserving state securely and accurately across sessions, devices, or timeouts?