Building Job Site Delivery

Helping Contractors Get Materials To The Job

How would you like to haul 26,483 pounds of drywall up and down stairs, spreading it throughout a 3-story home?

Meet Bryan.

Bryan is a sales associate with Home Depot. His store is situated in a suburb of Minneapolis and has regular customers ranging from DIY-ers to professional contractors. He has learned how to handle a wide variety of customer needs during his year at the Pro Desk and his commitment to providing excellent customer service is a huge factor in Bryan’s success.

“When a customer is spending $200k+, we need to set them apart and treat them different than our regular customers.”

Like all big box retailers, Home Depot must handle the entire gamut of customer needs, from simple “cash and carry” purchases at the register to large, multiphase orders involving complex deliveries. Importantly, the company must equip its employees – particularly sales associates like Bryan – to deftly handle these situations and do what is necessary to serve the customer.

Blaisdell Ave is a single-lane street running through a series of quaint, 60s-era homes in the Lyndale neighborhood south of Minneapolis. Bryan had been working up a drywall quote for a contractor who was renovating a rental home on Blaisdell.

He instinctively knew that the customer would prefer their drywall to be delivered to each floor in the house. “The customer will pay more, but will get it delivered where they need it.”

Unfortunately, this was not destined to be a simple, “textbook” delivery.

This customer was ordering a TON of drywall – well, 10.5 tons to be exact

“The customer texted me pictures, and I forwarded them to the delivery team. The major things that happened were the power lines and vehicles we couldn’t control. This delivery lasted 3 days because of issues that none of us could control or fix.”

Bryan knows he will need a lot of details up front when setting up deliveries like this one.

“The customer will say ‘yeah, it’s clear,’ when there are actually cars in the way, there’s only one entrance, and you have to go through the back in order to access the basement… In the outer suburbs power lines may not interfere with driveways, whereas in the city they interfere with just about everything. The alleyways are important, too. Can we get 12 foot sheet rock down there?”

“This delivery lasted 3 days because of issues that none of us could control or fix.”

My team at QuoteCenter builds software to help associates just like Bryan handle complicated processes like these. We believe that innovative technology coupled with human resourcefulness can make Home Depot become the #1 customer service retailer in the world!


QuoteCenter, an e-commerce application used by Home Depot’s internal salesforce across 2,000 stores


Product Manager
4 Associate Product Managers *
6 Developers
UX Designer (me)
UX Architect
User Researcher

My Role

User Research
Interaction Design
Information Architecture

* Throughout the course of this project we had 4 different APMs rotate through… Needless to say, there were a lot of transitions!

The Challenge

We were intent on retiring the legacy version of QuoteCenter, our e-commerce application for Home Depot’s internal salesforce. The new version was up and running, but it lacked some important features and we weren’t seeing the adoption rate we wanted.

One such feature was job site delivery. This feature catered to the needs of professional contractors, who place a premium on having their materials delivered. Incidentally, this market segment has become a huge focus for Home Depot’s growth strategy and our team was uniquely positioned to serve them.

We could capitalize on this opportunity only if we solved the “real-world” problem for contractors and got Home Depot associates to adopt our solution.

Business Goals

Enable $973M in quotes and $173M in sales through the new app

Achieve the necessary level of user adoption on the new app to be able to retire the legacy version

Foundational Questions

In order to achieve these goals we needed to take a hard look at the legacy feature. Our team’s product manager started with some simple, but important, questions.

What is the underlying problem we’re trying to solve?

What are the biggest flaws and opportunities with the legacy feature?

How do we implement a new solution without bloating the product experience?


Looking Back, Looking Ahead

We began by looking at the legacy feature. The Analytics team pulled some data and analyzed user behaviors. The Support team provided a list of the top issues they had encountered with job site delivery. Everyone became more familiar with how the feature worked.

We now understood what we had built. Some people were advocating that we just build the same thing again, but most were genuinely curious… Is there a better way to solve this problem?

Quantitative reporting revealed the "what" and prompted further research into the "why"

The legacy feature had been built over 3 years prior. I remember that project. It had been rushed, was based on many assumptions, and had undergone very little testing. Even though it had stood the test of time, there was no guarantee that it would drive the type of market growth that we sought.

As a team, we suspended certain decisions about the project’s scope until we could increase our confidence that we were building the right thing.

That said, the legacy feature and our past decisions exerted a huge gravitational pull throughout the project. While there was support for a new approach, it was incumbent upon me and my product manager to provide a compelling argument for any big changes.

Boots on the Ground

John on our Vendor Operations team worked his magic to give us the opportunity to tag along with a local supplier to witness a rooftop delivery. We jumped at the chance! In the process, we were able to interview their staff, find out how they run their business with Home Depot, and dig into the details of their process.

We got a lot of insight into how this supplier operates
At the job site getting things ready for the truck
A boom truck lifting shingles up to the roof

Forming The Backlog

Our first backlog had about 20 user stories. As I mentioned earlier, the legacy feature had a strong influence on our decisions and these stories showed it! They were just flat restatements of the old functionality.

I took the initiative to improve them, adding pertinent details about the underlying problems and making them less solution-oriented.

To validate whether we were on the right track, I visited one of our local stores to review these stories directly with users. This led to further refinements and a much stronger sense of their relative priority

I sketched a few concepts on the fly. This provoked even clearer feedback.
I printed off the list of stories and asked associates to evaluate their accuracy and prioritize their top 5.
Our associates are awesome! They took time out of their busy day to help me better understand their world.

Exploring New Workflows​

We now had a pretty good idea of how our sales associates and vendors work together to coordinate deliveries – at least we knew enough to get started. My next step was to make this understanding more concrete and practical.

I turned to the whiteboard and began drawing the first (of many) workflow diagram. It illustrated some of the key decisions and actions an associate would take.

This diagram became a touchstone for me as I worked through designing specific screens. I used it extensively to align with my product management partners and with the development team. We had discussions that were grounded in reality but gave us room to think freely about the actual software. This diagram made a bigger difference to the project than any other design artifact I produced!

An early whiteboard sketch of my proposed workflow
Based on this workflow, I generated a number of different approaches to the information architecture
A cleaned up version of my whiteboard diagram

Collaborating With Development

After a couple sprints, I realized that I was out of touch with the development team. I was not physically sitting with the team – my workspace was across the parking lot – so it was critical that I learn how to collaborate “from a distance”.

We didn’t have any “completed” designs at this point, yet the team was being asked to provide some high-level estimates for the project. It was very important to help the team be able to estimate the work ahead with higher confidence. To do that, I needed to find a way to cast light on what that work might actually be. 

Me with two of the developers - drawing something genius
My theory of "detail thresholds" - it turns out there's one threshold for estimating and another for executing

I met with each member of the development team and showed them an example user story from our backlog. Then I asked what would prevent them from giving an 80% confident estimate for this particular story. In nearly every case, they mentioned needing to know roughly what the screen would look like.

In response, I sketched a simple UI concept on the whiteboard and asked them about their confidence. A quick whiteboard sketch was enough to raise their confidence tremendously. This told me that visual details were not the main impediment to confident estimation.

Nobody was actually asking for highly detailed mockups. Instead, the team needed details about which data  would need to display, what the functional flows would be, and how many new UI patterns would be involved.

I drew this on the whiteboard and it was enough to significantly raise the team's confidence to estimate

The Bombshell

Happy New Year 2018!! 

January 2 was my first day back in the office for 2018. I noticed a 4:00pm meeting that afternoon to revisit the topic of the project’s scope and provide an update to stakeholders on our progress. It’s highly unusual to have an hour-long meeting scheduled at 4:00pm, but there it was.

After we were all seated, someone glanced my way and then toward another individual before asking, “You want to tell Ben?”

My heart skipped a beat.

It turns out, this particular project had begun to receive a tremendous amount of attention from upper management. A team back at headquarters was dependent on us releasing this feature before they could pilot their new pricing initiative. We were a dependency and our original estimate of an August-October release was not good enough.

Everything came down to getting a more accurate and aggressive estimate. Someone asked me, “How close are we on the design?” Unfortunately, that’s often a question without a simple answer. In this case, it was even worse because I wasn’t clear on what our priorities were any more. Was this becoming a case of “just ship something” or did we still care about delivering a better-than-legacy experience?

Racing Against Time

How close are we on the design?

That question haunted me. Design is never really “done”, you just decide when to stop. Sometimes the ROI isn’t there. Was this one of those cases? What level of investment was appropriate given the desired return (i.e. no longer being a blocker for a big corporate initiative)?

I sought resolution to this problem by partnering with our UX Architect to outline a basic project plan. We defined some concrete milestones in the design, trying to strike a good balance between speed and quality.

This plan was a lifesaver. It allowed me to work more transparently with our product manager, and helped her lay track ahead of the team while I dove into the finer details.

Diving Into The Details

Over the next 3 months I spent considerable time and energy going deep into the intricacies of the design. There were a lot of things to consider! Here are some of the screens I worked on.

Enter Your Address

Unlike many checkout flows where you enter your address at the end, we decided it was important to allow associates to enter an address at any time. Why? Because this way they could see more accurate pricing as they shopped.

For this to work, however, the address needed to be valid. A search-based approach using Bing Maps in the background seemed like the best approach. 

I also tried the idea of a map visualization to help associates with accuracy, but that idea was scrapped because there wasn’t enough evidence for its ROI.

I generated a series of concepts for address entry, focusing on the basic structure
With the structure of the address modal in place, I moved into the interactions, specifically, how to represent a selected address
Once I had explored a variety of possibilities on paper, I committed to a specific design and mocked it up in Balsamiq; we ended up abandoning the map idea for the sake of time

Select A Supplier

Our product catalog offers associates many options. The key was to surface these options in a way that made them easy to evaluate.

Job site delivery introduced a whole new set of decisions – which was exciting, but difficult to design into the existing workflow and interfaces.

I needed to introduce new information about delivery options into the workflow, so I started by sketching the information as "building blocks" that could be rearranged
Once I had the building blocks, I got into Balsamiq to explore design variations and how to make the layout responsive
This design involved modifications to an existing part of the interface, so I had to be very careful with my changes

Set Up Delivery

We implemented a highly-requested change to the workflow where you could now select your delivery options by supplier.

This may seem like no big deal, but our associates were frustrated by the legacy feature, where they had to opt in for job site delivery across the board for all suppliers. No longer!

The implication, though, was that each supplier needed their own “sub-flow” for delivery. I.e. an associate would have to make more decisions overall. We felt it was worth the tradeoff and I did my best to make the decisions easy.

Using the legacy app (QC1) and another major system used by associates (eSVS) as benchmarks, I examined how delivery decisions would impact the underlying data model
The form itself needed to handle some branching logic; I explored ways to use "progressive disclosure" (i.e. have information appear based on another interaction)
Each supplier has different rules governing how far they will deliver, so my design helps associates verify whether the delivery can take place

Logic & Interactions

I refined and updated this workflow diagram throughout the entire project, using it to stay aligned with my team and our stakeholders
This diagram provided a valuable "birds-eye view" of the navigation for the developers, and also helped me vet my clickable prototype for testing with users
In an effort to simplify the navigation and use more consistent patterns, I mapped out the basic navigation between screens along with the exact button styles and copy we were using
Since data and functional flows are so critical to developers (a lesson I learned earlier in the project), I created this "state matrix" explaining the logical conditions that impacted each screen

Testing The Design

Testing came very late in the process, unfortunately. While I had spent some time early on validating our backlog with store associates, I had not yet subjected the design itself to any testing.

Still, better late than never! I visited two of our local stores with a clickable prototype and ran a task-based usability study with 4 associates.

The study focused on 5 critical assumptions, and 16 less critical. All 5 of the critical assumptions appeared to be valid, but I identified 2 with cause for concern:

  1. How we show which delivery option is selected
  2. How and when we display fees

“This would scare people, in my opinion. We’ve already told them it’s going to be a $120 charge and they’re going to see an additional rooftop delivery charge… You need that in the pricing early on. If you tell them after the fact, it feels like a hidden cost… If I told somebody $120, and then another $80, they would feel fooled.”

Based on these results, I made a few changes and re-tested the design with 2 more associates. Unfortunately, the changes made little impact.

The good news was, we now knew much more about the potential usability problems we might encounter after the release. We decided to accept the risk and move forward without investing more in iteration and testing.

As I explained earlier, this project was being fast-tracked for political reasons. Our budget for testing was unusually tight. This wasn’t ideal, but I worked with it!

The Elephant

We were nearly ready to launch. There was just one problem.

When we built the legacy feature, we implemented a step to help associates “prequalify” the job site to receive a particular type of delivery. For example, associates need to ask some standard questions like “are there any power lines?”. This helps the supplier know what to expect when they come to perform a delivery.

Trees, power lines, tight streets, limited roof access, parked cars... There are many variables to think about!

We had solved this problem in the legacy app by presenting users with a brief questionnaire, but we weren’t sure whether this was even necessary. That’s why we had deliberately kept this feature out of scope for the first release. Analytics showed that it was clearly being used, but that didn’t mean it was necessarily useful. We needed to reduce our uncertainty.

Our product manager asked me to investigate this aspect of the legacy feature and provide a recommendation on three specific points.

What is the value of this feature in the legacy app?

Is this feature required in the new version?

Would it be a “copy/paste” effort or would it require deeper work?

I conducted 23 interviews. What I learned was that this feature did, indeed, have some value to store associates. However, the underlying problem was different than we had thought and could, potentially, be solved more simply! Even though we didn’t implement anything to address this problem in the first release, we were much more confident in our decision not to. It was also much clearer what a good solution might be.

Time for Launch!

Finally, it was time to launch. We rolled out the feature over the course of several weeks and it went pretty smoothly. It’s too early to tell whether we accomplished our financial business goal, but we have seen user adoption go up.

Lessons Learned

This project challenged me like few ever have. Looking back, I’m happy to have faced so many challenges because they taught me some important lessons that will help me do better in the future.

Be more transparent with stakeholders on my progress

Ask for help when I get stuck

Get to some more concrete end-to-end concepts earlier

Test early and often

“Spike” the details, don’t go deep on everything right away