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?
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.
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.
“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?”
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
4 Associate Product Managers *
UX Designer (me)
* Throughout the course of this project we had 4 different APMs rotate through… Needless to say, there were a lot of transitions!
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.
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
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?
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.
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
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!
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.
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.
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.
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.
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.
Logic & Interactions
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:
- How we show which delivery option is selected
- 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!
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.
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?
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.
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