Project Brief

I took over the project with this brief: redesign the existing PDA as a lower-cost tool for purchase invoice registration and faster inventory correction, with the goal of increasing store engagement and improving product variety and availability on Akala. Based on the available data and a survey of stores, the Product team considered PDA to be an appropriate solution to this problem.

Customer Segment

Stores that met the following conditions:

• Had a high product variety, with more than 1,500 SKUs;

• Had high in-store sales;

• And as a result, the quality of their inventory had a direct impact on the variety of products available for sale on Akala.

01 — First, I Turned the Brief into a Testable Question

I interpreted the brief as follows:

Business Problem:
Recorded store inventory is inaccurate → products that are physically available in the store cannot be sold on Akala → online product variety and sales decrease.

Product Hypothesis:
If purchase invoice registration and inventory correction become easier and faster, stores will use PDA more, and as a result, inventory data quality will improve.

But there was still one thing I did not know:

Is the problem really that the tool is difficult to use?

Because if the main problem is motivation, perceived value, training, workflow, or something else, simply redesigning PDA will not solve the problem.

Therefore, my first question was:

Exactly where does Adoption and Workflow break down?

02 — Next, I Examined the Current State and PDA Usage Patterns

Before designing anything, I wanted to understand:

1. Which stores have PDA?

2. Which stores actually use it?

3. What do they use PDA for?

4. Where do they stop using PDA and return to POS?

5. How is the purchase invoice registration and inventory correction process handled without PDA?

6. What is the difference between the behavior of active and inactive users?

I used three methods to answer these questions.

2.1 Data Analysis

To first develop a quantitative picture of the current state, I asked the Data team to extract PDA usage patterns at the store level, including the extent to which PDA was used for purchase invoice registration and inventory correction, as well as the inventory status of stores.

I divided stores into several groups based on their level of PDA usage so that I could compare their behavior and performance with one another. The results from this analysis were as follows:

Very important conclusion:

• The results in the table above showed that canceling or editing online orders did not have a meaningful relationship with inaccurate store inventory. Another factor was probably causing stores to edit or cancel online orders. At this stage, investigating and following up on this issue was therefore considered outside the scope of the PDA redesign and was handled and resolved by a separate team.

• The results above also showed that even stores that regularly registered purchase invoices did not register all invoices using PDA, and the root cause of this issue needed to be investigated.

02.2 — Behavioral Research | How Do Users Actually Work?

To understand users’ actual behavior, I contacted stores that currently had PDA and interviewed them about their actual workflow from the moment they received goods through purchase invoice registration, inventory correction, and price updates.

Instead of simply asking, “What problems do you have with PDA?”, I designed the questions around their actual behavior. For example:

• When a new product arrives at the store, what do you do from the beginning?

• Where and how do you register the purchase invoice?

• If the inventory in the system is incorrect, what do you do?

• When do you use PDA and when do you switch to POS?

• What tasks are you willing to spend time on?

• What tasks do you not do, and why?

• What do you do if a product does not have a barcode?

• When the purchase price of a product changes, how do you update its price in the system?

Very Important Conclusion:

First Output: PDA Alone Did Not Solve the Adoption Problem

The most important finding was that the problem was not only about speed or usability.

Users were willing to spend time on certain operations, such as updating product prices, but they did not have the same motivation to register purchase invoices and correct inventory.

The reason was that some stores did not understand the direct value of the online service. They had adequate in-store sales, while at the same time, because of negative inventory and some products not being displayed for online sale, they experienced lower online sales. Therefore, when they compared their online sales performance with their in-store sales, they did not see purchase invoice registration and inventory correction as activities with sufficient value.

Conclusion:

Improving PDA could reduce operational friction, but it could not, by itself, solve the problem of Value Perception / Motivation. We needed a separate product or business solution for this part.

Second Output: The High Number of Products with Negative Inventory Was a Barrier to Starting Inventory Correction

Some stores understood the profitability of selling through the online service, but because they had a large number of items requiring correction, they never found the motivation to start. The reason was that they did not clearly know which products they should correct.

Third Output: PDA Itself Also Had Several Adoption Barriers

During the interviews, in addition to the motivation issue, I identified several specific barriers within the product itself:

1. Lack of Search

PDA was primarily designed around barcode scanning and did not provide an appropriate product search capability. As a result, for products without barcodes, such as some bulk products, users could not easily perform the operation.

2. Need to Support Multi-Price Products / Jet Print

Some stores had the same product in inventory at different prices; particularly under inflationary conditions, products purchased at different times and at different prices. This created the need for Jet Print / support for multiple prices for a single product.

3. Store Manager’s Lack of Trust in the Receiving Worker to Register Purchase Invoices During Delivery Using PDA

The store manager believed that the worker receiving the goods did not have sufficient expertise and could not register the purchase invoice, while registering the invoice with PDA directly records it in the checkout system.

3. Limited User Patience with Long Processes

In multi-step flows, users expected operations to be completed quickly. When a process became long or required too many interactions, the likelihood of abandoning it increased.

Therefore, Behavioral Research led me to two categories of problems:

This distinction was very important because it showed that not all problems should be solved through a redesign of PDA itself.

02.3 — Event Tracking & Task Analysis | Exactly Where Does Friction Occur?

After understanding who was not using PDA and why, I focused on users who intended to use PDA.

The new question was:

Within the purchase invoice registration and inventory correction process itself, exactly which step takes the most time or requires the most interaction from the user?

To answer this question, I broke the processes down into Micro-tasks and defined Event Tracking for the main steps so that we could measure time, number of interactions, and drop-off points.

Metrics Defined for Tracking

Output of This Stage

This Tracking allowed me to transform the process from a “high-level flow” into a set of measurable points and understand:

Where does the user pause the most?
Where do they have additional interactions?
Where do they make errors?
Where do they abandon the process?
And which part contributes the most to the total operation time?

The results obtained from the Events above were as follows:

03 — From Insight to Solution

Data analysis and behavioral research showed that the problem was not simply that “PDA was difficult to use.” In reality, we were dealing with several different barriers:

1. Some stores did not understand the value of correcting inventory for online sales.

2. Some stores understood the value, but the large number of items with incorrect inventory made it difficult for them to get started.

3. Some users could not cover all of their scenarios with PDA because of product limitations.

4. For some users, trust in the invoice registration process and how information was controlled was an issue.

5. Even in stores that intended to use PDA, the workflow itself contained friction and unnecessary interactions.

Therefore, instead of trying to solve all problems through one redesign, we considered a separate solution for each barrier.

03.1 — Creating Motivation to Correct Inventory

Problem

For some stores, the main issue was lack of motivation, not the difficulty of using PDA.

The user could not see a direct benefit of correcting inventory for their business. Therefore, even if the process became simpler, they were not necessarily willing to spend time on it.

Proposed Solutions

To create a direct connection between incorrect inventory → lost sales → store benefit, we proposed several communication models and planned to measure their effectiveness through an Experiment:

Hypothesis

If a store can see the direct impact of inaccurate inventory on its online sales and, in return, receive a tangible benefit from correcting inventory, its likelihood of participating in the inventory correction process will increase.

03.2 — When the Problem Was “Too Much Work,” I Broke the Work Down

Problem

In the interviews, I encountered stores that understood the value of online sales but were faced with a large volume of incorrect inventory.

For a store with hundreds or thousands of SKUs with negative inventory, the message “Correct your inventory” is effectively a very large Task.

The user did not know:

“Where should I start among all these products?”

Solution: Daily Recommendations

Instead of showing all incorrect inventory at once, it was proposed that the system recommend a limited number of the most important products each day.

Initial logic:

Top-selling products on Akala
↓
Compare with store inventory
↓
Identify important products with incorrect inventory
↓
Display several higher-priority items
↓
Correct the inventory of those items

For example, instead of presenting the user with a list of 200 SKUs:

Review these 3 products today.

This Recommendation could be placed both in PDA and on the sales page.

Goal

Reduce Cognitive Load and turn a large and ambiguous task into a set of small, actionable Tasks.

03.3 — Covering Scenarios That the Current PDA Did Not Support

Behavioral Research showed that even users who intended to use PDA were forced to return to POS in certain scenarios.

Several specific needs were identified:

Search

PDA was primarily based on Barcode Scan, and for products without barcodes, such as some bulk products, users did not have an appropriate way to find the product.

Solution: Add Search to the product selection flow.

Multi-Price Products / Jet Print

Stores might purchase the same SKU multiple times at different purchase prices. Therefore, registering a single price for all inventory was not always consistent with the store’s actual situation.

Solution: Support multiple prices for a single product / Jet Print.

03.4 — Reducing the Risk of Invoice Registration for Less-Experienced Users

One finding from Behavioral Research was that some users, particularly in stores with less-experienced staff, did not feel confident about directly registering purchase information in the system.

When examining competitor patterns, we saw that in some similar products, invoice registration was not finalized immediately and was first placed in Draft status.

Solution

We converted the invoice registration process into a two-step flow:

Register invoice information
↓
Draft
↓
Review / Confirm
↓
Final Submission

This model allowed the user to review and confirm the information before it had a final impact on the system.

03.5 — And Finally, I Simplified the Workflow Itself

By this point, we had identified several Adoption and Workflow problems and considered solutions for them.

But for users who actually wanted to use PDA, one question remained:

Could the PDA process itself become faster and lower-friction?

This is where I moved into the main design work.

04 — Designing PDA Based on Measured Friction

Using the Micro-tasks and Events I had defined in the previous stage, I designed based on the points that created the most time, interaction, and drop-off.

The goal was not simply to change the visual appearance; rather, I wanted to:

• Reduce the number of interactions;

• Reduce the time required to register each item;

• Make more information available without navigating between pages;

• Reduce the likelihood of errors and process abandonment;

• And turn invoice registration into a fast and repeatable Workflow.

In the new design, I simplified different parts of the process and, for flows containing a large number of items, removed unnecessary information and controls from the main path.

One important decision was reducing the number of visible Steps in the invoice registration process. Instead of presenting the user with multiple sections and controls, the main flow was reduced to a few clear and focused actions.

04.1 — Prototype Validation

After the initial design, I reviewed the Prototype with team members before implementation and also tested it during the QA process for technical and behavioral validation.

At this stage, the goal was not only to find Bugs; we also evaluated whether:

• Does the user understand the path for completing the Task?

• Are the CTAs recognizable?

• Is the necessary information accessible?

• Is the process compatible with the store’s operational logic?

• Does the new design create technical or implementation constraints?

After implementation, I also reviewed real user behavior using Clarity to see whether the friction points I had anticipated in the design had actually been resolved in real-world usage.

04.2 — Measurement | Did the Workflow Actually Improve?

Here, I recommend that you definitely include the Metrics table, but do not use fabricated numbers. This can be one of the strongest pieces of Evidence in your Case Study.

Table structure:

04.3 — Iteration | The Data Showed That One Problem Still Remained

After implementation, I reviewed the Events again.

I noticed an unexpected pattern:

In some stores, invoice registration time per item was still high.

This time, instead of making another assumption, I reviewed the Sessions of these stores in Clarity.

What I Saw in the Sessions

After adding several products, the user repeatedly scrolled through the item list to check:

“Did I register this product or not?”

Further investigation showed that the problem was not scanning speed.

The display space for Line Items had become too small.

A large portion of the screen was occupied by Inputs, leaving the user with insufficient space to view the list of registered products.

This was an important Insight:

The friction here was not caused by “data entry”; it was caused by “reviewing the entered information.”

04.4 — Second Iteration: I Refined the Design Based on Real User Behavior

To solve this problem, I moved the Input section out of the main Workflow space and into a Bottom Sheet.

As a result:

Before

Large Inputs
↓
Limited space for Line Items
↓
Excessive Scrolling
↓
More time spent on Review

After

More space for Line Items
↕
Bottom Sheet for entering / editing information

This change allowed the user to see more of the registered items at the same time and review them without repeated scrolling.

At the same time, I realized that the information table was too dense and that some columns did not provide enough operational value for this Task.

Therefore, I reprioritized the information and removed unnecessary columns, such as selling price at this stage of the Workflow, so that more space remained for essential information and the readability of Line Items improved.