Contents
Intent
Insert here
The DRI for this discovery activity is [Person]
Discovery Plan
0️⃣ Kick off
Milestone | Output | Owner | Approver(s) | Reviewer(s) | Status |
---|---|---|---|---|---|
Problem defined |
| NOT STARTED IN PROGRESS DONE | |||
Stakeholders informed |
|
1️⃣ Discover
Opportunity/problem ticket
Milestone | Output | Owner | Approver(s) | Reviewer(s) | Status |
---|---|---|---|---|---|
Stakeholders interviewed |
| ||||
Franchisees interviewed |
| ||||
Existing metrics understood |
| ||||
Success metrics defined |
| ||||
Run usability testing on existing solution |
|
| |||
User interviews | |||||
Online surveys | |||||
Desk research | |||||
Competitor landscape | |||||
Persona mapping | |||||
User journey (use cases) mapping |
|
|
|
2️⃣ Define
Opportunity/problem consolidation documentation
[Insert here Confluence page on opportunity findings consolidation]
Milestone | Output | Owner | Approver(s) | Reviewer(s) | Status |
---|---|---|---|---|---|
Problem consolidation |
| ||||
Approach review and stakeholder validation |
3️⃣ Develop
Note: the term “Develop” refers specifically to the production of solution design artefacts. There will be no software development in this phase.
List of solutions & designs
Potential Solutions
Giving the results of the Competitor landscape and benchmark (here), we worked on 2 different approaches:
Exploration 1: showing only the accepted cards thumbnails once the user has selected that they want to add a new card:
Exploration 2: showing the accepted payment methods thumbnails before the payment method selection. This way the user can see all the payment methods in a glimpse before deciding:
However, the Exploration 2 has been discarded because it brings more cons than pros. Here it is the rationale behind each potential solution and why we discarded the second option:
Exploration 1:
Pros: There is not as much cognitive load because we only inform about the cards that are accepted.
Cons: No cons found (as yet).
Exploration 2:
Pros: The user can visually know the accepted payment methods before opening the drop-down.
Cons:
When we have lots of different types of payments methods, the UI may have a huge cognitive load that risks usability.
If the restaurant had activated the “Pay with Card on Delivery” option, we might be showing cards that its terminals could not accept.
Milestone | Output | Owner | Approver(s) | Reviewer(s) | Status |
---|---|---|---|---|---|
Ideation & wireframing |
| ||||
Design & prototype |
| ||||
User testing |
| ||||
Design review with stakeholders and franchisees |
|
4️⃣ Deliver
Note: the term “Deliver” refers specifically to the delivery of solution design artefacts. There will be no software development in this phase.
Solution Description
The proposed solution is to add all accepted card thumbnails once the user has selected “Add New Card”:
Important: there are 2 different Payment Pages designs for each type of order: Delivery and Pick-up orders. By now, this should not affect the Dev Team but the Core FE.
DoD
Show new title “Card Details”, followed by the card Thumbnails:
Create a solution that works when there are many payments methods or the title is large:
Important for the DoD: we are not going to work this feature for the “Pay with Card on Delivery” option, because we don’t know if all terminals have the same accepted cards or not. And making the card images configurable by restaurant could imply a complex development that can’t be affordable on time and effort.
Milestone | Output | Owner | Approver(s) | Reviewer(s) | Status |
---|---|---|---|---|---|
Feature (MVP) agreement | NOT STARTED | ||||
Tech solutioning review | NOT STARTED | ||||
Development Handoff | NOT STARTED | ||||
Analytics tagging | NOT STARTED | ||||
User story breakdown | NOT STARTED |
Documents
Ideally (not mandatory) we should use the same Opportunity and Solution templates that we use for Delivery.
Add Comment