Data Monster

The goal of this application was to serve as a centralized system where all new items, item changes, price changes, and general issues are submitted, reviewed, and implemented, establishing a single point of entry with a consistent experience to improving the day to day operations of the company.

Whole Foods began a major restructuring process to unify and simplify a large number of processes that had previously been inconsistent, redundant, inefficient, and used differently by each of the company's regions. Numerous SharePoint sites were being maintained, or not maintained, which led to a lack of visibility into completion times and an overall poor experience for the various users. A single request could be directed to several additional sites which would delay the completion process and make it difficult for the submitter to follow their request and know its current status.

As our team strategized each feature of the application, I performed user tests to verify our design, allowing us to make refinements as we went.

Intuitive Design

From the beginning of our work, we knew we needed to create a clear and simple application. One that was easy to understand and didn't require extensive instructions or training sessions. It should be intuitive, as this application is used by a wide variety of users:

• store teams

• regional product teams

• regional data teams

• global data teams

• global product teams

Our testing showed our store users may have limited computer skills so we knew we wanted to provide a simple and clear interface that would be understandable by the most novice of users.

A second issue that became apparent was a terminology discrepancy. Data teams made references based on legacy databases while stores users called out terminology of register errors. We developed different methods to address these issues, from aligning terms whenever possible to allowing the application to have custom headers for each section based on user groups.

Testing

For each enhancement my team began by assessing the current steps users were going through to accomplish the desired tasks. Processes varied in each department and often revolved around gathering information from multiple applications. Users rarely had a clear expected timeline for completion. I developed user stories in order to contextualize the user’s behavior and guide the application design. From there, I created wireframes that gave an initial visual to the project. I performed a small scale user test, to find any usability issues before creating more detailed prototypes.

Even now, as we continue to update the application, we bring users into the development process to ensure we are providing a clear and intuitive experience. 

Workflows

One particular challenge was the Item Maintenance Request workflow, which required a variety of routing stages. Each different type of item change required a different approval and implementation process depending on the origin of the request, the changes being made, and who was responsible for approving and completing each task. We created user journeys to account for the different user persona in order to visualize the workflow steps. See simplified information architecture diagram below:

In addition, by developing a customizable Settings page, site administrators are able to adjust the workflow to meet their ever changing business needs. In the example below, the site administrator can highlight in blue to direct implementation to Regional teams, and brown to direct to Global teams.

Export Strategy