The document summarizes interviews conducted with restaurant managers and owners to validate a proposed delivery bot management system. Key points from each interview are provided along with observations and improvements made between interviews. Common feedback included the map having too many colors and callouts, a need for search and list views, and clarifying what happens if a bot encounters issues. Based on the interviews, improvements will be made such as adding clickability between bots and orders, distinguishing initial ETAs from delivery times, and redesigning the issue fixing flow. The document concludes by posing feasibility questions around system capabilities needed to implement the suggested changes.
4. Isaac - Interview #1DEFINEVALIDATE
Worked well
● Was happy to hear about this option
● Liked the general view of the map
● Provided some great feedback about business structure
Participant got stuck
● Too many callouts on the map and too many colors for the bots
● Had no idea what the error means or why it matters
● Was inclined to call support when noticed the issue
Observations and improvement
I didn’t set the scene properly with clear enough instructions,
so the participant was very confused. I’ll do better next time!
I also realized the map is very confusing when using Manhattan,
so changed the map background for the next interview.
5. Sanjay - Interview #2DEFINEVALIDATE
Worked well
● Liked the general view and layers of the map and bot info
● Liked the troubleshooting option and flow
● Provided some great feedback about user needs
Participant got stuck
● Too many colors for the bots
● Was looking for search options and a list view
● Was worried about what happens if the bot fails both attempts
Observations and improvement
I was a lot better at following the script, and asked more open
questions. That was great! Also, the clear map was a good call.
Sanjay mentioned a crucial need for a list view with search options for
best ops, so I’ve added that to my final prototype and last interview
6. Amit - Interview #3DEFINEVALIDATE
Worked well
● Liked the general view and layers of the map and bot info
● Loved the list view on the left
● Was able to navigate through the product on her own
Participant got stuck
● Wasn’t sure if/when she needs to handle the issue
● Got confused during the flow
● Needed a way to connect the bot with the respective
order on the list
Observations and improvement
This was my best interview so far. I was able to set the scene
and cover all questions.
Amit offered 2 great improvements that should be included in
the following iterations
7. ImprovementsDEFINEVALIDATE
Click from bot to list
As suggested by Amit and Sanjay, the
users would want to see the order
details on the dashboard if needed.
A click on the order div will open the
order details on the left
#534
8. ImprovementsDEFINEVALIDATE
Add “Initial ETA” vs “Delivery time”
As suggested by Amit, users would want
to see the differences, if any.
She also suggested adding customer
ratings right there, but we’ll have to
evaluate this idea further before adding
it to the list.
#534
9. ImprovementsDEFINEVALIDATE
Inform restaurant about delays
As suggested by all participants, users
would want to know if there’s a delay,
and would want the customer to be
informed as well.
When a delay occurs:
● Show a small pop-up on screen to
indicate the amount of minutes
added/removed from original ETA
● Send push notification to the customer
to let them know about the new ETA
10. ImprovementsDEFINEVALIDATE
Re-design the issue fixing flow
While trying to be clear and simple
it seems that the issue-fixing flow is not :)
All 3 participants were having a hard time
following the troubleshoot flow without my help.
Feedback so far:
● Inform the user of the issue severity
(create priority like critical, medium, minor)
● Keep the design clear with only one button per screen
● Keep the flow focused about fixing the issue
● Provide details about the issue and consequences
It became clear
that we need
another sprint,
focusing on the
issues theme
11. Feasibility a.k.a: Can we actually do that?DEFINEVALIDATE
● What is the expected latency for the current PRD?
● How are errors returning from the server,
and where are they stored?
● Can we track and collect new errors?
● What could cause bot data latency?
Can we have an error for that delay?
● Are there errors that we cannot fix remotely?
● How many "regular" issues require IT intervention?
●