HUGE INC. x SK-II

HUGE Inc. is a design agency headquartered in Brooklyn with thirteen offices worldwide. I worked as an Interaction Designer with their Singapore branch on a project for SK-II, a global cosmetics brand based in Japan.

SK-II

Main Project: Inventory

With masks, online meetings, and coordination we were able to organize and send the Japanese PM team for onsite visits.

UX Research

Research Results for Inventory

Main Project Goals

• Create and inventory system for SK-II retail staff

• Run on an iPad

• Work across three markets Japan, China, Singapore

• Inventory data must be reported back to SK-II

• Fit within SK-II’s budgets and timeline

• Take into account research results mentioned above

Option 1: Increase user count to solve for time

Option 2: Count by location

I thought about counting by location, but unfortunately this would not work either. The same SKUs can be stored across multiple locations. While users would be isolated by location, they would not be isolated by SKU which was the main obstacle.

Option 3: Count by category

Wireframe

A wireframe I made for how the sort by category feature would work if implemented within the existing app.

Option 4: Organize database further

Limitations

This solution was possible but, the entire business model for China would have to change since they relied heavily on how the database was set up in Option 3. Everything from marketing, accounting, etc. would be affected. While it was possible to do, it did not fit into SK-II’s budget or timeline.

Wireframe

Just in case they changed their mind, I made a wireframe to show this solution was possible. Unfortunately, it would cost too much to redevelop everything for SK-II China. The budget for this solution did not exist.

Solution

I thought of a few more solutions, but they were either met by budget constraints or the limitations of the server/database. The best way forward was to let users count by category (option 3).

• This increased user count from one to up to three

• Allowed user to organize the inventory into three categories making it easier to find items in a list

I thought it may be useful for users to be able to switch between counting by SKU and counting by location. This would allow them to filter the category they are counting and organize the list further without disrupting the server.

But looking back upon recorded observations and talking to a SK-II retail staff manager, this was not the case. Retail floor staff are usually assigned sections of the store and communicated with one another if they were relocating to another section. This was so areas of the store were not understaffed. Due to this, they naturally counted by location. Thus, the decision to only filter by location was made.

SKUs were also being listed alphabetically in the app, which does not map to the layout of SKUs displayed in physical retail stores. In addition, not all retail stores have the same layout, so the order of items cannot be predetermined. Due to this, the option of reordering items within a list was added as well.

Retail staff were also worried about accidentally changing the quantities for SKU as they were navigating the app. They wanted a way to “complete” a count for a SKU, but also come back to it later if necessary. This was tricky as using words like “done” implied the user was finishing something. “Save” implied the user was saving information to the device, when in fact it wasn’t doing anything. A check mark icon was similar to the “done” button, where it implied the use was finishing an action.

The lock icon worked perfectly as it did not communicate that an action was completed or saved. Users understood that they could lock/unlock line items and go back and forth until the inventory was submitted.

I also added a Search By Keyword or Search By Scan function to help users find items.

The next step after users count inventory was reporting any positive or negative discrepancy in SKUs. Users had to have a reason as to why there was a positive/negative count and attach photos if necessary.

Up until this point, users were manually reporting each reason. I looked through an excel sheet of discrepancy reasons within the last year and consolidated similar ones. For example, stolen items could be reported as “stolen”, “shoplifting”, “theft”, “product was shoplifted”, etc. 

I then ranked each reason from most to least common and used these as options for the drop down menu. This made it easier for HQ to keep track of discrepancy reasons as everyone used the same definitions and saved time for users as they didn’t have to type a reason every time.

Final thoughts

I enjoyed working with HUGE Inc. and SK-II on various briefs for SK-II’s website, CRM, Inventory, and POS.

I wish the project was not limited by the shortcomings of the server and database. Because of their limits, my solutions tailored the user around the technology. I wanted to customize the technology for the users.

However, I learned that not every project has the perfect solution. It was interesting for me to solve the “UX/UI puzzle” and to deliver the best possible experience with the constraints in place.

This is a part of the final design that I can show you without breaking NDA.

Here are other features I had to think of for inventory:

• SKU is added/discontinued

• User tries to add an existing SKU

• SKU is found in a new location

• Inventory count is paused/resumed

• Location is added/removed

• Location name is edited

• Store layout changes