As a platform owner for delivery and quality, I’ve created guidelines and pattern documentations for the design team to follow. These documents help guide teams who need to build new features into the delivery side, understand how deliveries work, and what types of patterns are available to use, along with rules on why certain components / elements are where they are on the page.
Delivery Timeline Audit
Due to the delivery timeline being different across the different platforms we operate on (iOS, Android, Web), I put together an audit with the engineering team to pull out delivery status’s starting from the moment you place the order, to when the order is completed. The completed audit, was then used by designers and product managers who need to use the delivery status chart either as guidance for when to pop-up certain notifications, messaging, or even to add new status’s in a way that works with timeline as it stands.
Delivery Tracker Guide
As the the need to have more features added into the post delivery screen grew, I created the tracker card guide as a way for designers building onto the tracker card to better understand the in’s and out’s for how the card segmentation is broken down. Within the guide is general guidelines on where each segment of the tracker information sits, the rationale behind the ordering, and detailed views of the different states of each segment. Designers could then play around with the segments themselves, when exploring solutions, while knowing where the boundaries are. This prevents teams from breaking any fundamental patterns that could effect the usability of the tracker card.
Support Page Templates
Once all the updated support flows were updated with the latest resolution / content, I started putting together a template to help other designers looking into building on top of the support framework. This guide helps incoming product and design functions understand where order issue collection starts, how we ask for details for the defect, and finally what types of outcomes are possible based on the defects currently in place. The goal was to make it easier for other marketplace teams like merchant and dasher, to create support flows of their own, while still adhering to a set of consistent patterns.