This section shows a generic example of a user journey. After reading this section the reader should know who are the stakeholder within the system, how the user interacts with the system and what are the results of an interaction.
The Below diagram illustrates a purchase order within the system. User journey starts at the moment of browsing a meal from the catalog and ends when a meal is picked up by the user. Dotted lines represent optional interactions in the system.
- Subscriber - Interested in choosing a meal, picking it up and eventually rating it and writing a review.
- Cashier - Is a Point of Sale operator, facilitates meal purchase for unsubscribed users.
Access code generation can be cumbersome to implement. We might introduce PIN instead. We need to put in place mechanisms that handle submissions of two valid coupons. Handling of cash payment. This should be discussed further.
This journey illustrates a purchase of a meal by an occasional user - a user who is not registered in the system. The idea of occasional user is to convert him into a subscriber
- Occasional User - Interest of purchasing a meal without being registered in the system.
- Cashier - Is a Point of Sale operator, facilitates meal purchase for unsubscribed users.
We need to put in place mechanisms that handles submissions of two valid coupons. Providing access code to the smart fridge for meal pick up.
Bellow user story, show a use case where some unexpected error (perhaps mechanical) prevents the user from picking up the meal. Outcome of the events is creation of complaint by a user receiving a new meal (or compensation) later on.
- Subscriber - Interested in choosing a meal, picking it up and eventually rating it and writing a review.
- Admin - Backend user who moderates content and resolves subscribes complains.
There might be a risk that a subscriber will be cached in a loop on submitting a valid code in a system that cannot validate the access code. However, this case should be mitigated by storing access codes locally.