HD Supply – 2018
February – May 2018 (I was on for 12 weeks of 14) – Atlanta, Georgia
My Employer: Deloitte Digital (Seattle, U.S.A)
The Brief
Wanting to refresh their B2B purchasing portal, HD Supply contacted Deloitte Digital to provide creative direction, wireframes and conceptual designs for hdsupplysolutions.com. The current site, whilst bringing in billions of dollars for the company, was outdated, clunky, didn’t provide enough detailed information for users (particularly technical specifications), lacked a useful search function, and didn’t clearly call out caveats (particularly around shipping delays).
As a part of the UX team, my brief was to:
- Research – with a small group of customers, field sales representatives; and online (competitor and benchmarking analysis, heuristic analysis)
- Refresh the eCommerce templates, making them responsive (due to time constraints, we did wireframes for desktop and mobile)
- Work on making search results more intuitive
- Rework the information architecture
- Ensure there was a better level of detail on the product description pages (such as technical specifications and shipping information)
- Conduct two rounds of user testing with customers
Examples of the existing site – Home page, Category, Sub-Category, Product Description Page, and Shopping Cart
My Role and Process
My role was to lead and plan the UX stream of work. The team consisted of a Project Manager, Creative Director, myself and a Junior UXer, and 2 Visual Designers. We planned for the first four weeks of the project to consist of research activities, and the final eight being dedicated to design and user testing.
Working in one week sprints, I planned the research activities in order for us to have a report ready at the end of the fourth week full of insights and recommendations; and the design cards split so we could tackle big and small templates each sprint.
The research phase consisted of three main activities:
- Business research: In-store observations, sales ride-alongs and sales interviews. At the start of the project, we didn’t get access to customers, or a log-in for the site. I proposed a site visit to one of their stores, which we did in Seattle, observing customers and the questions they were asking of staff, how they priced their products, and sales and advertising. We also took many photos, and quickly realized that the customers were mostly business customers – and that each business had a different pricing system in place with HD Supply, leading to no price advertisements in store per item. This perspective helped us in understanding price-points on the site (which were shown for some products).
A couple of weeks into the project, we were invited to ride along with two field sales representatives (FSRs). These FSRs aim to visit 7-10 customers per day, driving to their locations and checking in, suggesting new products, and generally helping out with the catalog and site. As many customers place large orders frequently – outfitting hotels, housing complexes, universities – the orders can be quite large, and all customers appreciate a monthly check-in in-person. The UXer and I each took a ride-along on the same day, in different locations, and spent a half-day driving around, and visiting 4-5 locations each. We really learnt about the scale of orders being placed, the troubles customers have between using the annual paper catalog (“The Bible”, as referred to by one user) and the digital site, and the problems with navigating around the current site. We were able to perform short contextual inquiries with each customer, watching the interaction between the customer and FSRs, and the questions they were asking.
As well as spending a half-day with the FSRs, we were also able to interview a handful of FSRs across the country, asking them the questions their customers were asking of them, and learning about the ‘quote’ function, whereby the FSRs would create quotes in each account of suggested products for a job or frequently purchased items, enabling purchasers to then look through the list and quickly order.
2. Customer interviews: closer to the end of the research phase, we were able to speak with a handful of customers selected by the FSRs and Account Managers. We requested a range in locations, and industry types, with all interviewees using the current HDS site. These hour-long interviews over the phone taught us that users relied heavily on the search function over navigation, but that the search results “weren’t trusted”. We also learnt of the level of detail required to make a purchasing decision on an item, the importance of related items (such as linking a repair part to the original item’s page), and the troubles in the account section of the site (such as the lack of workflows and self-service, leading to many calls to the HDS service center around password resets, and approvals for orders. This second issue was a big problem in some companies, in that an approver needs to authorize orders placed by the purchasers – which had some approvers called 8 or more times a day by HDS). These insights helped us with search, navigating, the product description page, and account area.
- Online research: To supplement our understanding of the industry, view the industry benchmark sites, competition, and accelerate our design knowledge, we researched a few online examples. Looking at Lowe’s, Grainger, Wilmar and McMaster-Carr for industry examples, and other eCommerce sites such as Amazon (PDP, delivery tracking, account settings); Nordstrom, Mr Porter & Net-a-Porter (search, navigation, product description page, shopping cart); and LG, Fisher-Paykell for product research (tech specs, imagery) as some examples, we analyzed patterns and behaviors for many interactions.
Research Insights
To conclude the research phase and understand the insights, I created a big affinity analysis – on the wall, and in an Excel sheet. Guiding the Junior UXer on his first affinity analysis, we categorized all insights into pain points, delight points, wishlist items, and insights we learnt about the customers (e.g. some customers still fax in orders). We also split these up by research activity, and assigned each research participant an ID. The wall post-its helped with being able to identify patterns and sort into an order; and the Excel sheet helped when designing each screen, using filters and sorts to look at the information per screen being designed.
The affinity analysis – on the wall (whole, and zoomed into the pain points segregated by activity), and in Excel (showing some of the Pain Point tab)
Analyzing the analysis in Excel, I categorized all 217 findings into eight main themes, which we referred to when designing the screens.
Research Report
We concluded the research phase with a research report, listing out the 8 themes, research insights, competitor/industry examples, and also listing the features and a rough sketch of the features on a screen. Each week during the research phase, the client stakeholders were keen to see designs, and so for them to value the research and what their insights could mean, I mocked up some very rough Balsamic sketches per theme. We also proposed a recommended information architecture, making slight modifications based on the interviews, and competitor examples. I quickly mocked this up in Axure, and was later informed by the client to focus more on the designs than the site structure, as limited development time meant a restructure wouldn’t be possible in the MVP phase. The appendix of the document then included all research insights.
1-3: The eight main themes (as found from the affinity analysis) supplemented with user quotes, and the top 5 recommendations; 4: High-level problem solving for recommendation #1, using basic Balsamic mock-ups, and customer wishlist items for the feature list
An example from the Appendix; showing the need for better content in this example. Each category would list the raw insights for pain, delight, and wishlist items (this example showing pain points for the content category).
Wireframing
The wireframing phase ran for 8 weeks, covering 13 main sections, with desktop and mobile designs, and authenticated and unauthenticated states. We ran reviews with the client once a week (and later with third-party developers joining as they were onboarded), as well as holding sprint kick-offs, requirement sessions, feedback sessions, and exploration sessions.
The (aggressive!) design sprint plan
I made a few foundational decisions for the wireframing phase:
- One UXer would do the one screen for both form factors (desktop and mobile) – rather than splitting by form factor. This approach made sense to not hold up and block each other, and also all decisions made by one UXer going into a screen would help preserve the integrity of the screen across both form factors
- We would use Axure due to it’s shared project capability, enabling us to check in and out screens easily, and pulling from a joint masters section; as well as it’s RWD capability; and specification capability for the developers
- Each main section would have a screen flow, to help the developers
It was my role to divvy the work between myself and the Junior UXer, and update the plan above as required. One of the wireframe sets I owned and worked on is the Product Description Page (PDP), outlined below as we presented it to the client and developers:
Each section was preceded with an input screen, informing the developers which templates we had used from IBM WebSphere using the WebSphere library
The widget list would follow, showing the developers which widgets we had used, and where
We would outline how the design changed from the current state, and addressed issues and pain points
We would then run through use case examples – this one showing the mobile & desktop unauthenticated state, when there are multiple SKUs on one page (e.g. the item comes in multiple colors, or sizes)
A few interesting interaction design issues I solved included the navigation when on mobile, the menu for desktop and mobile, and the shipping indicators.
- Navigation on mobile. When I started designing the deeper level pages on mobile, I discovered the issue of the navigation (breadcrumb) wrapping on more than one line. This then made the starting point of the page inconsistent, the longer the breadcrumb was running (particularly for long page names, and deeper in the flow). I did some best practice research, worked on a few designs, tested it against the pages we had and had to do, and decided to show only the page prior, and the Home page on mobile. I outlined the rules below for the developers:
Outlining the breadcrumb behavior
2. Menu for Desktop & Mobile. The trickiness around the menu came about when we looked at the product categories. The client really wanted to give prominence to the products section (‘Shop By Category’) of the site, and wanted customers to be able to drill into a sub-category very quickly. With this in mind, I designed a multi-level menu. Due to the sheer number of sub-categories (and differing number of sub-categories per category) I shied away from a vertical, or accordion menu, and opted for a clearer horizontal menu. This large and deep of a menu was trickier on mobile. I explored multiple designs, soon ruling out the accordion style menu (having just one accordion open make the vertical height huge, and hide anything below it; the large amount of scrolling for users to be able to compare sub-categories if multiple accordions were open; and the performance implications of having a huge menu accessible on one screen), and relying on in-screen navigation alone (as per client request). I designed a multiple-level and -page mobile menu, which would open a deeper page when exploring categories. I kept an easy-to-reach ‘return [to prior menu level]’ at the top, as well as being able to opt out of the deeper menu by landing on the ‘All [sub-category]’ page.
The desktop menu utilizes a fly-out design, activated by clicking. Due to the multi-level of menus, I discarded a hover approach, since there were multiple columns per menu. Thus, a user clicks on a menu item to expose the deeper level, and if the user wants to visit that page, they click on the ‘All [category]’ link at the top of the deeper menu.
The mobile menu shows the main menu, and then the three Product (‘Shop By Category’) deeper menus. The ‘Return to’ and ‘All’ pages were highlighted at the top in a different shading, highlighting their prominence.
3. Informative Shipping Indicators. One of the biggest customer complaints was on the display of the shipping lead times. As HD Supply started adding in products which would ship directly from the manufacturer, and could no longer guarantee that every product they sell could be shipped overnight, a disparity in expectation and reality started to exist. HD Supply were known for overnight delivery, and so this change made customers upset when they couldn’t easily tell that they weren’t receiving the item the next day. As products could be added to the shopping cart from multiple methods, I had to consider how this information could be brought to light on different screens, while remaining uniform. The trickiest screen to display this on was in the shopping cart. In the current state, users would see a list of items in their cart, and if they didn’t scroll down to view the expected delivery dates per item, they could miss the information. This particular use case was causing a lot of frustration for customers, leading them to believe that HD Supply was breaking their guarantee of overnight delivery. I solved this through the use of accordions (and dates and warning icons in the accordion labels), warnings at the top of the screen, anchor points to the instances in the accordions, and warnings on each individual item. The default state of the cart page is to have the accordions closed.
These desktop and mobile examples of the Shopping Cart show the warning indicators at the top of the screen, items organized in accordions by delivery date (with delivery date as the header on each accordion), and warning messages at the individual item level as well.
Usability Testing
We also ran two usability testing sessions with customers and customer service representatives, which I set-up due to the tight timeline and familiarity with usability testing. I wrote the scripts based on the questions & concerns raised during the review sessions, questions we as designers had, and concerns brought up in the original research sessions which we had hoped to have solved. After client approval of the goals and scripts, I would upload them into Loop11, work with the designers to get the use cases needed for the visual designs, and set up the test to be unmoderated online, for approx. 25-35mins. The results really helped us decide where to pivot, provide recommendations, and tweaks.
The start of the usability testing results report listed the outline, goals of testing, and then insights and recommendations for each task.
The ‘Raw data’ part of the report explained the task, and showed the results.
Lessons learnt
- Axure Hygiene and Education. We learnt early on that the client was inexperienced when it came to wireframes and reviewing designs in Axure (we gave them the Axshare link to review at any time). To assist with this, in our sprint review document we would outline how to navigate to and through Axshare; and then starting off the Axure document with some education pages. We were also diligent in explaining all of the screens, keeping the file tidy, and implemented unique numbering for all screens (see point below).
As we sent out our design review document after every sprint review, we always started off the wireframe section with this slide. We didn’t know how far and wide the document might be sent, and so this was a constant slide for anyone in HD Supply to access the wireframes.
These two pages were at the start of the Axure file. We realised that even though we were using the client’s web fonts, they didn’t necessarily have them installed on their machines, meaning that the wireframes were showing in Times New Roman. The annotations guidance showed both the client and developers where to access the interaction detail for the widgets.
- Numbering every screen with a unique number. Initially, I started off numbering each primary screen. For example, a PDP was 4.0. As I started tweaking the PDP screen for different use cases, I might use 4.1 for the first case, but then a couple of repeating screens, with just a small tweak, would be relabled, but not uniquely numbered. As the use cases increased, this became slightly unwieldy for the developers to follow, as I would be calling out the name of each screen with the use case information, rather than a unique number. On the Project Manager’s advice, I went through and numbered every screen a unique number, and set up a numbering system to carry the project forward. This was accomplished by setting up folders for every template and numbering and naming them, even if the screens hadn’t been started in that folder yet. The screens themselves ran on a 6-digit system. For example, The PDP folder was 4.00. The first screen was 4.01.00. For use cases with slight tweaks, we would use an alpha appendage. For example, 4.01.00A was for the first use case tweak.
Axure number sequencing
- Hand offs to a third party developer. While the project timeline didn’t allow for user stories, a functional specification, or detailed run through of screens, we knew it was important to ensure the developers were able to receive a hand-over. We would invite the developers to the client run-throughs of the work, and then run through any questions the developers had from the previous review. As it was difficult to answer some questions without research, we instead implemented a system of requesting written questions the day before the review, so we had time to properly think through scenarios. We also had to design the wires in a way that enabled them to be understood when we left the project, and so we started doing screen flows for sections earlier in our process, and widget run-throughs. We would tie the widgets we had designed, to what was available in the WebSphere library (see the Wireframing – Product Description Page example). We annotated our wireframes with detail (see Lessons Learnt – Axure Hygiene and Education above), and added to each screen label the level of the page in the IA (e.g. [L4] for four levels deep) (see Axure number sequencing above).
An example of the sign-in/register flow, I completed once I had finished the section for the developers to understand where each CTA went
- Guiding a junior. The Junior UXer I worked with hadn’t completed research activities or a report before, and so there was a big mentoring opportunity. I taught him the value of research; how to ask open, non-leading questions; designing for outcomes; and how to gather patterns through an affinity analysis. He had never completed a heuristic evaluation or captured a site map, and so I asked him to own these deliverables, and I would guide by providing templates, prior examples, and feedback along the way. When it came to wireframing, he learnt from me why I made the foundational set-up decisions that I did, and how they benefitted us; the different use cases possible (asking questions like “if you click/tap here, what’s the flow? What does the user see?”), and generally playing devil’s advocate to ensure the designs were tight.
- Selling the importance of research. The client didn’t appreciate the value of user research (they had, in fact, reduced down the original SoW from 8 weeks of research down to 4), and so it was my role to ensure that I really delivered not only the insights, but the value in having the insights to inform the research. I did this by weaving user quotes throughout the themes, highlighting the pain points and wishlist items, outlining the various users (primary users, as well as the less-expected secondary users, being consumer customers (i.e. not buying on behalf of a business), and the service center staff), and writing the top recommendations with backing from the user insights. As I walked through the report when presenting to the client, I ensured to weave in anecdotes that I had seen and/or heard throughout the research. To quell the ‘need to see something’, I did some really basic designs in Balsamic of screens, highlighting the wishlist of features and high-level solving some of the pain points.
- Working with a Creative Director. Learning from a Creative Director and being able to watch how she structured the project as a whole, delivered to the client, and worked on the broader goals, design direction, themes and principles. She tied the work streams together, ensuring that everything flowed as a holistic design to the client. In presenting to the client, she was also clear on the approaches we took for our work, and reiterated the guiding principles and how we adhered to them with every widget and screen we designed. I learnt a lot from her and used this experience to guide me when I moved into the Creative Director role for my subsequent projects.
Results
The HD Supply Solutions website went live at the end of 2018. Although not design-perfect (we worked with third-party developers), many of our improvements have been implemented, providing an intuitive design, easier user flow, and providing clearer information for customers (such as around shipping times). The website can be viewed at www.hdsupplysolutions.com