Resolve the address in context
Show a suggested correction when confidence is high. When it is not, let the sender edit, request confirmation or consciously send anyway.
I designed the system that stopped bad addresses before gifts were shipped.
Sendoso launched Address Confirmation in 2020. In 2021, I expanded that recipient journey and designed the original Address Validation experience. I connected sender configuration, address quality, recipient trust and failure recovery into one address-confidence system.
Sender inputEnter one address or upload hundreds
The system had to support both deliberate 1:1 sends and operational bulk campaigns.
Recipient resolutionConfirm, correct and continue
When data failed, the recipient could safely repair it before fulfilment began.
- Role
- Senior Product Designer, individual contributor
- Project period
- Dedicated end-to-end design and research sprint, mid-May to early June 2021
- Team
- I owned the complete design. Kelly Hoover was the Product Manager for the original Address Validation work. Yume Sato supported design, Grace Tran was Senior UX Researcher, Matt Samson led UX Research, and Marijan Baranjec partnered on the confirmation work.
- Status
- Core concepts reached production. Public documentation now shows the confirmation controls, 1:1 validation choices, bulk fallback and recipient self-correction patterns.
Scope boundary: I did not design the original 2020 Address Confirmation launch. I owned its 2021 personalization expansion and the complete original Address Validation design, including the Design, Research and Figma Session work. Later releases provide production evidence, but I separate my design authorship from product changes made after I left Sendoso in July 2022.
The problem was not only asking for the right address. It was deciding what happened when an address was wrong.
Address Confirmation was fast-tracked when offices emptied during COVID-19. It let recipients replace obsolete office addresses before fulfilment. The next problem was broader: validate data before a send, explain errors without blocking legitimate addresses and recover safely when the system could not determine a reliable answer.
March 2020
The core Address Confirmation workflow launched early for customers working remotely.
May to June 2021
I led the end-to-end confirmation expansion and designed the complete original Address Validation experience.
2022 to 2024
Production documentation showed personalization, variant selection, individual validation and automatic invalid-address fallback.
2026
Sendoso added global defaults and SmartDelivery fallback. These later releases extend the system, but are not work I claim to have designed.
1. The sender provides data
Enter a single address
Upload a bulk CSV
Enable recipient gift choices
2. The platform evaluates
Accept a valid address
Suggest a correction
Flag an unresolved record
3. The journey recovers
Edit or deliberately send anyway
Trigger Address Confirmation
Let the recipient self-correct
Continue to fulfilment
I designed Address Validation as a routing system, not a red error message.
I own the complete Address Validation file. Across its Design, Research and Figma Session pages, I mapped the full decision space for individual sends, bulk campaigns, recipient-entered addresses, uncertain API responses and deliberate overrides. Kelly Hoover partnered with me as Product Manager.
Do not let one bad row stop the campaign
Separate valid and invalid recipients, support CSV correction and route unresolved records into Address Confirmation.
Validate the correction too
Recheck recipient-entered data, explain unresolved errors and prevent unsupported destinations such as P.O. Boxes.
InputAddress entered or CSV uploaded
ValidateValid, suggested or unresolved?
Valid Continue to fulfilment
Suggested Review correction
Unresolved Edit, confirm or send anyway
A reliable suggestion exists
Compare the entered and standardized addresses so the sender can accept the correction without losing context.
No reliable suggestion exists
Explain the limitation and preserve agency through edit, Address Confirmation and a guarded Send anyway path.
Address Confirmation is already enabled
Avoid redundant blocking because the recipient is already scheduled to verify the destination before fulfilment.
Validation fails during a normal send
Convert failure into a recoverable recipient request instead of forcing support or manual outreach.
A bulk file contains mixed quality
Process valid recipients while isolating records that need correction, re-upload or confirmation.
Core design constraint
Validation confidence and response time changed the interaction.
The research compared validation on upload, on Send and asynchronously in the background. A fast response supported inline correction. A slower service required pending states, resumable work and clear separation between valid and unresolved recipients. The interface could not imply certainty the underlying service did not have.
Each decision made one part clearer by making another part more expensive.
The important work was not choosing controls. It was deciding where the unavoidable complexity should live, who should see it, and which trade-off the recipient could safely inherit.
I combined the tickets even though it expanded the scope.
Ticket 341 covered the sender's configuration experience. Ticket 402 covered what the recipient saw. Product initially treated them as separate engineering surfaces. I used journey mapping, hypotheses and the usability study to show that sender choices around messages, product visibility and variants directly changed recipient trust, address confirmation and fallback behaviour.
What it cost: The system view created more design and coordination work. It also prevented us from shipping two individually reasonable controls that produced a fragmented end-to-end experience.
I surfaced the complexity instead of hiding where it moved.
Letting a recipient choose gift options automatically required address confirmation. The system could hide that rule and surprise the recipient later, or explain it to the sender at the moment of choice. I chose the second path. This is the conservation of complexity in practice: automation moved the work, it did not remove it.
What it cost: The sender had to read one more explanation. In return, the recipient journey became predictable before the send was configured.
12- 1Recipient choice creates a new dependency.
- 2The system confirms exactly where that complexity moved.
Research reduced three disclosure concepts to one production rule.
The prototype explored a visible product, no gift block and a generic surprise illustration. Testing showed that removing useful visual context weakened recipient motivation, while too many content controls made the sender experience harder to understand. Production kept the high-value choice: show the product name and photo, or hide both.
What it cost: The generic surprise treatment and separate landing-page message were cut. The shipped model offered less creative flexibility, but it was easier to configure and maintain.
123- 1Product and name revealed.
- 2Gift block removed.
- 3Generic surprise and different action copy.
Preview survived, but the confirmation pattern did not.
The prototype used a Review and send popup to bring theme, recipient email and gift choices together. Engineering constraints removed that confirmation modal. Production retained a live preview entry point, custom email messages, theme selection and product visibility controls.
What it cost: The final implementation was technically simpler, but preview remained a low-emphasis action rather than a persistent representation of the recipient outcome.
I had to persuade the team that technical boundaries were not user boundaries.
Product stakeholders initially resisted combining the tickets because the web-app sender view and external recipient page belonged to separate engineering components. I used the journey map and usability evidence to demonstrate that variant selection, product disclosure and fallback behaviour crossed that boundary. Marijan and I aligned on the confirmation direction: I represented the user experience and system logic, while he owned the product decision. For the original Address Validation work, I owned the end-to-end design and Kelly Hoover partnered on product direction.
We ran Sendoso's first feature usability test, then used it to cut scope.
During the 2021 sprint, Grace Tran led the usability study. I co-wrote the hypotheses, built the clickable sender-to-recipient journey in UserBrain and shaped the research plan with Grace and Yume. We ranked risky assumptions and tested the two profiles separately. In parallel, the Validation file used solution comparisons and working sessions to test the feasibility of low, medium and high-effort recovery models.
What the study established
- Company branding was essential for trust when recipients were asked to share an address.
- Removing every product visual weakened anticipation and motivation.
- Three separate message destinations created too much configuration complexity.
- Sender choices had to be evaluated through their recipient consequences.
What remains uncertain
- The final participant count is not preserved in the surviving planning files.
- The three variants changed multiple factors at once.
- A note labelled variants negative, positive and neutral, which could bias facilitation and synthesis.
- The documents do not show counterbalancing, so order effects remain plausible.
The study changed the release, but I would make the comparison cleaner now.
The team removed the separate landing-page message and generic surprise illustration, reducing both sender workload and implementation scope. Production focused on company branding, a custom email message and the show-or-hide product rule.
Today, I would hold the layout and action copy constant, vary one disclosure factor at a time, counterbalance order and measure comprehension before preference. Taste is not evidence that a recipient understands what will happen.
The system logic held up better than parts of the prototype craft.
What held up
- The sender and recipient journeys were modelled together.
- Validation failures were designed as routes, not dead ends.
- 1:1 and bulk sending shared principles without forcing identical interfaces.
- The automatic address dependency was visible at the moment it was created.
- The prototype explored more disclosure options than production needed.
- The study produced concrete scope cuts, not only preference feedback.
What did not
- The long sender page weakened scannability.
- The preview route had too little emphasis for its decision value.
- The comparison confounded disclosure, layout and action design.
- The prototype carried inconsistent placeholder data and an unnecessary National ID field.
- The surviving validation work does not preserve measured API latency or false-positive rates.
- I would now place a direct privacy explanation beside the address request.
Design ownership
The Address Validation file is not adjacent evidence. It is work I designed end to end.
I own the complete file. The Design page contains the production-oriented 1:1 and bulk states. The Research and Figma Session pages preserve the problem framing, solution levels, technical questions and working decisions. Playground, References and Trash are empty, but remain part of the source file.
- Validate a bulk CSV on upload, on Send, or asynchronously in the background.
- Let managers correct invalid records inline, re-upload a CSV or send confirmation requests.
- Process valid recipients while holding invalid ones instead of blocking the whole campaign.
- For 1:1 sends, offer edit, Address Confirmation or a deliberate Send anyway path.
The same core interaction patterns later appeared in Sendoso’s production documentation. That is evidence of continuity, but not proof that every later implementation detail came from the 2021 prototype, so I keep later SmartDelivery and global-admin work outside my authorship claim.
1- 1A required national identifier is unnecessary for shipping this gift to a US address.
The original design patterns became part of Sendoso's production address framework.
Production documentation now shows both sides of the system. The confirmation experience includes custom messages, themes, product visibility, recipient variants and preview. Address Validation includes suggested corrections, edit and Send anyway choices, recipient self-correction and automatic fallback for unresolved individual and bulk addresses.
Original design concept1:1 validation choices
Suggested correction, edit, Address Confirmation or guarded Send anyway.
Production evidenceIndividual invalid-address prompt
Current documentation shows edit, request confirmation and Send anyway.
Original design conceptMixed-quality bulk handling
Separate valid records and recover unresolved CSV recipients.
Production evidenceBulk confirmation fallback
Invalid or unverified CSV recipients receive Address Confirmation forms.
What the live framework supports today
Validation routing Individual, bulk and recipient-entered addresses are checked and unresolved records receive a recovery path.
Automatic fallback Invalid single, bulk and triggered sends can move into Address Confirmation.
Enforced confirmation Recipient product-variant selection automatically requires Address Confirmation.
Campaign governance Administrators can define default confirmation behaviour for newly created campaigns.
Expiration and reminders Senders can choose a 2 to 30-day confirmation window, with a reminder 24 hours before expiration when Sendoso sends the email.
Destination safeguards Recipient corrections cannot change a physical shipment to a P.O. Box.
84%Snapdocs response rate using the broader Address Confirmation featurePlatform evidence. Not attributed to my 2021 design work.
385/400Cradlepoint contacts whose addresses were confirmedPlatform evidence. Not attributed to my 2021 design work.
FirstFeature usability test established at SendosoDirect contribution from the 2021 project.
“Umair not only helped me brainstorm for, but also mount and launch the company’s first usability test for its features.”
Grace Tran, Senior UX Researcher at Sendoso
What I can claim, and what I cannot.
I can claim ownership of the 2021 reframe, the sender and recipient journey, the complete original Address Validation file, prototyping, research planning, testing, stakeholder alignment and handoff. Production documentation verifies that the central interaction patterns reached the platform. I cannot claim the original 2020 Address Confirmation launch, customer metrics as causal outcomes, or authorship of later SmartDelivery and global-admin implementations.