It’s not uncommon for a designer to join a project in which “the use cases are already written.” This documentation attempts to describe in words how a user will complete a particular task within the system.

Scenarios take this further and include the context around the action to form a complete story of a person in the real world using the product to create a positive outcome. In the example shown here (Square’s credit card reader), I’ve intentionally de-emphasized the steps around charging the card to highlight the surrounding context. Reviewing the full story helps the team identify additional functionality the product needs to serve this customer:

• The charge needs to be authorized in less than 5 seconds. (Count it out and imagine being the buyer, waiting and drumming your fingers.)

• The seller needs an easy way to cancel or refund the charge. (Someone will hit the wrong button in the chaos of the trade show floor.)

• A simple way to keep/decrement inventory would be a value-add for the seller.

Imagine if this team stopped at simply “meeting the requirement” that the seller swipe the card and the buyer signs with their finger. That notion is abstract beyond the point of helping the team know if they can serve this customer. Instead ask how your product will help a specific person get through a specific situation.