- When I joined the Delivery Experience communications team, there were no documented principles, no standards, and no shared definition of what good looked like. Design decisions were based on unspoken tribal knowledge and gut feel.
- I initiated and led the creation of a suite of living standards — design principles, email standards, component guidelines, and fraud standards — grounded in team surveys, customer research, and cross-functional alignment sessions.
- The work has given the team a defensible, research-backed foundation for every design decision, and changed how we negotiate with requesting teams. It now reaches director level for sign-off.
The rules existed — they just lived in people's heads
When I joined the Home Depot Delivery Experience communications team in spring 2025, I noticed something quickly: there was a lot of institutional knowledge, but none of it was written down. Decisions were made with "just make it look like the others do." There were unspoken rules about where components lived, what information went where, and what made a good communication. But none of it was codified, shared, or defensible.
This created two compounding problems. Internally, it made onboarding slower and design reviews inconsistent — the standard changed depending on who was in the room. Externally, it made it nearly impossible to push back on requesting teams who wanted to use our communications templates to host their content. Without a documented rationale, every conversation was a negotiation based on opinion rather than principle.
There was no shared answer to: what does it mean to do this work well? Without that, the team couldn't self-direct, couldn't defend its decisions, and couldn't improve intentionally.
We also had no customer-grounded understanding of what people actually needed from our communications — what information mattered, in what order, at what point in a delivery journey. We were designing from assumption.
I saw the gap and decided to close it
This work wasn't assigned to me. I recognized it as a prerequisite for everything else — if we didn't have a shared definition of good, we'd keep having the same circular conversations indefinitely.
I initiated the principles work, designed the research process, synthesized the findings, presented to leadership, and led the rollout to the broader team. As the work expanded into email standards, component guidelines, and fraud standards, I continued to lead — each time identifying the need, structuring how we'd answer it, and bringing the team along.
Throughout, I worked closely with our principal designer and senior manager, who championed the work upward. The ideas and execution were mine; the organizational pathway was a genuine collaboration.
From survey to living document — how it actually happened
Phase 1 — Design Principles
Rather than writing principles myself and socializing them, I sent a survey to the full Delivery Experience UX team (~12–15 people) asking two questions: what defines success for our communications, and what do customers want from them based on their experience? I got ~80% response rate — high engagement signals the team was ready for this conversation.
I synthesized the responses into themes and presented them to my senior manager and principal designer with a proposed framework. This wasn't a rubber stamp request — I explained the rationale for each principle and how the survey responses supported it. They took it to our director for approval.
The director approved the finalized list of 8 principles organized under 2 overarching themes. I shared these with the full Delivery Experience team — not as a top-down mandate, but with the context of how they were built and what they're for.
The two overarching themes
Phase 2 — Email Standards (customer-grounded)
After the principles were established, I ran research to ground our layout decisions in actual customer expectations — not assumptions.
The usability test asked customers to evaluate existing emails and tell us what information they needed to see. The follow-up survey asked where that information should live — above the fold, middle, or bottom. The team then used those findings together to define our email standards: what belongs where, and why.
These aren't opinions anymore. When a requesting team asks why certain information is below the fold, we have 40 customers who told us so. Research-backed standards are much harder to override than designer preference.
Phase 3 — The full standards suite
The hard parts
The most important decision I made was how to build the principles — bottom-up, not top-down. I could have written a first draft myself and asked for feedback. Instead, I surveyed the team first. That choice made a meaningful difference: when the principles were finalized, people recognized their own thinking in them. Adoption wasn't a fight because the team already felt ownership.
The second tension was scope. Each new standards document represented additional work that wasn't in anyone's roadmap. I had to make the case for each one — not just that it was a good idea, but that it would save more time than it cost to create. The component guidelines are the clearest example: we were having the same conversation about order summary placement repeatedly. Codifying it once ended that loop.
I recognized early that standards only have power if they're grounded in something other than the opinion of the person who wrote them. That's why every document in this suite has a clear origin — a survey, a research study, a cross-functional discussion. The source of the standard is part of the standard.
"Before this, every conversation with a requesting team was a negotiation based on opinion. Now we have documents. We have research. We have a director's sign-off. The conversation is different."
A team with a foundation it built itself
The Delivery Experience communications team now has four living standards documents covering principles, email layout, component usage, and fraud. All of them are grounded in research or structured team input — none of them are designer opinion dressed up as rules.
The practical impact: design reviews are faster because the standard is documented. Conversations with requesting teams are more decisive because we have a principled, director-approved rationale for our decisions. New designers joining the team have a reference point that didn't exist before.
The work is ongoing. These are living documents — they evolve as we learn more. But the infrastructure exists, and the team knows how to use it.
What I'd do differently
I'd build the measurement layer earlier. We have standards now, but we don't yet have a systematic way to track whether we're adhering to them or whether they're improving outcomes. The principles work from Case Study 1 — building CSAT and the trust metric — taught me that a standard without a feedback loop is just a document. The next evolution of this work is connecting these standards to measurable signals so we can tell whether they're actually making our communications better.
This work is still in progress and not yet ready for public sharing. If you'd like to walk through the full standards suite, I'm happy to do that in conversation.