Project Overview

In order to serve the commerce demands well, Retail executives and merchandisers need to control the exposure of inventory to various selling channels such as online, in-store and call centers. While there was an existing availability determination feature in the older versions of DOM application, it was very limited in its functionality and was primarily code driven. Additionally, it was quite limited in creating exclusion rules and did not have business objects to cater to the changing needs of the market.

With new sales channels on web and mobile, store inventory getting exposed to online channels, and new supply types like Ship to Home, Pickup in Store etc., there were newer capabilities that needed to control inventory exposure based on location type and inventory characteristics.

ATC product was conceptualized to regulate the availability of inventory based on the specific kind of need of the market from the supply chain.

High-Level Product Goals

• Provide capability to create synchronized views of “what’s available” between the web store and allocation.
• Ability to view what commerce sees.
• Ability to exclude inventory easily and manage different kind of exclusions.
• Real-time factoring and publishing of all inventory events (sales, returns, receipts, etc).

Design Level Goals

• A UI that allows setting up different kinds of rules/ rule sets to create views for commerce availability.
• Allow users to set salience in the rule groups within a configuration.
• The rules configuration that is flexible, scalable and yet easy, not necessarily requiring a trained IT analyst to setup.
• The user experience should be consistent, regardless of whether the view is persisted at the facility or the network level.
• UI that supports basic CRUD operations and to support frequent updates by Ecom. executives, merchandiser and store operators.
• Provide a means to view summary and reports that help in visualize the critical elements at the time of setup, updates and protect fat-finger errors.

Initial Challenges

• Availability decisions are not straight-forward – the decision spans multiple departments, many of whom have competing / conflicting objectives.
• Users did not have a way of knowing what is happening in the view.
  • How many stores are at maximum capacity?
  • How much of my inventory is out of stock?
  • Did that store outage get applied?
  • Is it working?
  This created a lack of trust in the system and user compensated for it by assuming the worst case.

UX Process

We started the work on the project by interviewing the end users involved in the current process. Current process: Business analysts from the customer would call for a monthly/weekly meeting. The allocation settings were discussed and agreed upon during these meetings. Then, the business analyst would communicate the settings the IT Analyst, who would code, configure and test this in the QA environments. Once the results of the testing are approved by all stakeholders, the code was migrated to production environment during cutover. The process was cumbersome.

Though this work would require a lot of research and analysis, we needed to work on iterative designing to ensure the correct product that satisfies all user requirements. We decided to follow the process showcased below:

The next step (after understanding the current process) is to identify the personas used in the project.

We conducted a user research and identified 5 different personas who would be impacted by this algorithm and screens:

1. Merchandiser wants to see how inventory is distributed across facilities, for a particular item. This person is also concerned about exposing the “right inventory” to the “right” channel.
2. eComm Channel Manager who is concerned about the number of units exposed to eComm / item assortment available for eComm (the more the better).
3. IT Analyst - Responsible for making config changes/activation. Most familiar with the system and takes input from business.
4. Store Ops who is concerned about store capacity, fulfillment outages and accuracy.
5. Online Buyer - wants to see how many units of a particular item are available to sell on a website.

Each of them had different goals, different concerns and conflicting interests. We had meetings with these users and spoke about the gaps that they have with the existing feature.

Navigation Planning - We understood how the current navigation path and decipher the mental models of each of these users. We ensured that the user knows where they are, where they have been and where they are going! We worked with the product managers to figure out what kind of features the product offers and the hierarchy in which information should be displayed.

Initially, all this info was available in the DB, and we did not display in UI. One important consideration was to identify a “bad” configuration before it was too late. They needed a mechanism to preview changes before committing to it.

We approached this problem in a sophisticated rule-based manner. The focus was more on getting all possible flexibility to get validation from the stakeholders. However, we soon realized that the need for reconfiguring is more frequent, and simplification was necessary to enable eComm Manager and Store Manager tweak it without needing an IT analyst.

We resorted to a more wizard-like flow that mapped to the mental model of the user. Within a configuration, the user would define the scope (what, where) and then set conditions to set the exposure.

Bring clarity in purpose early on – this was the guiding principle. The idea was to get the ball rolling very fast. We initially got some blessings when we did some early research on the information hierarchy. Next, we moved on to get some validations on broad level layouts. No details and only very high-level layouts.

If a picture is worth 1000 words, a prototype is worth 1000 meetings.

We provided the visual specifications of these screens to developers for further development.