The Home Depot is the largest home improvement retailer in the United States, and the sixth largest private employer in the United States.

I was the sole UX Researcher/Designer assigned to design a web-based app for Home Depot's corporate Event Planning department. This app was to help event planners share information, for process improvement and to support budget inquiries. This was a new app replacing a manual process: before, all information for 70+ events per year were contained in individual Excel spreadsheets, or in 3-ring binders filled with paper. 

This was a summer internship with an Agile distributed team. I was based in Atlanta with the users. The Development team (all interns) and the product owner/project manager were based in Austin, TX. 
The research I conducted on this project included reviewing source documents and conducting interviews with associates and management in the Event Planning department. My interview guides and meeting recaps were posted to the Corporate UX WordPress site. (They are not posted here, as some may contain proprietary information.)

During the discovery process, as I further defined the requirements for this system, I wrote and updated user stories as needed, to support the product owner. 

Problem: During interviews, I discovered that an external vendor managed a consequential number of events. There was a benefit to including this information in our system, but that was both a scope issue and could affect technical architecture for user authorization. 

My solution: I led the discussions to determine the scope impact and gain approval. For that feature, I wrote these user stories:
As an authorized Event Producer or Director,
I want to authorize an external Agency to have access to an Event,
So that Contract Event Producers can access this system and update it with information for this Event, and THD retains control over information about all Events.
Given I decided to delegate the management of an Event to an external Agency,
When I authorize an external Agency to manage an Event,
Then Contract Event Producers associated with that Agency will be able to view and update that Event in this system.
As a Contract Event Producer,
I want to access only the Events delegated to my external Agency to manage,
So that THD retains control over information about all Events.
Given I have been authorized and authenticated as a Contract Event Producer for my external Agency,
When I inquire on Events,
Then I will only see Events delegated to my Agency to manage.
I started with pencil sketches, to get quick feedback from the users. Below (left and center) are the first two screens (Event and Vendor) that I reviewed with users within a few days of our first meeting. The oval blurs are to hide some of the "real" data that I incorporated into the pencil sketches.

The Event Details sketch (right) was in a later iteration, when I was just beginning to explore how budget information would be displayed and maintained. 
Problem: Users and management needed to see summaries of upcoming Events, and easily navigate to details.

My solution: During a meeting, I sketched this “Dashboard” feature for the home screen. This sketch facilitated discussion of details (how many Events, ability to sort by date or by assigned Event Planner, what data elements were required). For later prototypes, I created test data in Excel, and incorporated the image into the home screen.
Prototyping and User Evaluation
Problem: How to productively develop a medium-fidelity click-through interactive prototype with many screens?

My solution: I created a document outlining the expected steps/screens through a specific task, and used those letters/numbers when naming the screen images created in Sketch. This made it easy to link the screens together in InVision.

Later, I found it effective to add "test script" information to the same document, and use that document during User Evaluation. This made it easy to identify where in the prototype (or on which screen image) changes needed to be made. Below is an example of that planning and testing document. 
Click on the thumbnail below to download a PDF of the entire document.
I constructed five different medium-fidelity click-through interactiveprototypes, using InVision and screen images created in Sketch following THD’s UX design standards. The prototype for each iteration addressed a specific scope, and also included changes to address any issues discovered while evaluating the previous iteration. Prototypes were evaluated with Event Producers; test plans and results were posted to the Corporate UX WordPress site.

Below are a few screens from the second iteration prototype. You can access and run this prototype from InVision.
Problem: Users wanted the power of a spreadsheet to calculate a total from entered details and allow an easy change to any assumption to ripple to total costs. I also wanted to avoid lots of columns, and left-to-right scrolling.

My solution: I thought of the "TurboTax" concept where you can just enter a number, or "drill down" to a screen to enter the details (and have the number calculated). That concept informed the design shown below, where users can enter a simple number, or click on the pencil icon to bring up a modal dialog to enter details (example on the right).
Problem: How to reduce risk? This modal dialog was a new concept. If it worked, it could be used consistently on three fields, but perhaps it was risky to try this concept for three fields in a single iteration.

My solution: To reduce the risk, I decided the next interactive prototype and development iteration would evaluate this concept on just one field. When it was successful, in later iterations we used a similar concept for the other two fields.
Below is the test script for this prototype. Click on the thumbnail below to download a PDF of the entire document.
Planning and Communication
Problem: It was difficult for the remote development team to observe user evaluations, and difficult for me to walk through a prototype with the remote development team.

My solution: After user evaluation of a prototype, I produced a video with a screen-capture of the prototype being demonstrated, which I narrated with summarized user comments and comments to call developer attention to certain design aspects. For co-located teams this video might not be necessary, however in our distributed situation the Dev team found it valuable. Even for a co-located team, I think it would be important for archival purposes.
Problem: With frequent iterations and multiple prototypes, it was easy for the development team to be confused on the latest prototype, and what features were targeted in each prototype.

My solution: I created a grid (see below) to serve as a "Table of Contents" for all design prototypes, and share status with the project team. Two quick notes about this grid:

1) Links to prototypes and user evaluation documentation aren't shown in this example (they were internal THD links). 
2) Iterations 1 and 2 were conducted on paper (pencil-sketched wireframes, and high-fidelity mockups with Sketch).
Problem: Our entire team (1 UX design and 4 Programmers) consisted of summer interns, and staffing for support and future phases was uncertain. How should we handoff the application to a future project team not yet identified.

My solution: I wrote a "Letter to the next project team", to bring new project team members up to speed. This was not a design document; it focused on describing the fundamental concepts and decisions associated with this app as completed in Summer 2017, along with some discussion of future possible features.
Click on the thumbnail below to view a sample of this document. 
Results and Retrospective
What was delivered: I researched, designed, and evaluated five UX design iterations in nine weeks. The development team completed development of the code base that fulfilled those designs. At the end of the internship, the Product Owner began the process of turning over the code for QA review.
What I learned as a designer: From a design perspective, working with Home Depot’s design standards helped me understand the importance of the “Call to Action” button, and how that can clarify the path to the primary outcome. 
I think the scale and number of prototypes helped me learn a productive way to organize my design process, as described in the Prototyping and User Evaluation section. 

From a process perspective, I think I developed a good instinct to tightly focus iteration scope. This enables increasing the speed of iteration and lets the users evaluate the system design more frequently, without being overwhelmed by a large amount of content in each session. When a user evaluation identified changes, I incorporated them into the next iterations’ prototype. This allowed the user to verify those changes, while exploring new features.

You may also like

Back to Top