The current system is built around weekly recurring rules.

While this works well for most merchants,it fails to support irregular scheduling scenarios.

• Time-consuming manual setup
• High risk of misconfiguration
• Inefficient for non-recurring use cases

As a result, merchants rely on workarounds or inefficient processes.

Instead of redesigning the entire system,introducing a parallel path for irregular scenarios is a more scalable and less disruptive solution.

This allows the system to remain efficient for the majority while supporting edge cases effectively.

• Preserve the existing workflow for recurring users
• Introduce a guided entry point for irregular scenarios
• Minimize disruption to current user habits

Introduced a short questionnaire to guide users into the appropriate configuration path.

• Reduces decision friction
• Prevents misconfiguration
• Matches user mental model

A. Dependency on legacy configuration logic
The "Specific Dates" feature needed to align with existing base settings, which introduced constraints and potential confusion in pricing relationships.
This required careful restructuring of the interaction flow to avoid conflicting logic.

B. Handling wide variations in date scale
Specific dates can range from a few days to over 200 days.
This required a flexible layout that could scale without overwhelming users, while still keeping pricing information visible within the first viewport.

1. Split the configuration into two modes
To address two fundamentally different use cases—recurring schedules and irregular dates—we separated the flow into distinct modes.
This prevents users from combining incompatible rules and reduces configuration errors caused by misaligned mental models.

2. Focus on one pricing rule at a time
Instead of displaying multiple special pricing rules simultaneously, we simplified the interface to show only one active configuration.
This reduces cognitive load and allows users to focus on a single task, improving both accuracy and confidence during setup.

3. Remove non-essential visual cues when not applicable
Color indicators for special pricing were removed when no pricing rules were applied.
This ensures the interface reflects the actual system state, avoids unnecessary visual noise, and keeps users focused on their primary task—setting prices.

1. Ensure all selected dates are visible at a glance
2. Keep interactions intuitive with no learning curve
3. Use color to differentiate without introducing ambiguity
4. Maintain a constrained layout height to preserve pricing visibility
5. Present only one pricing rule at a time to reduce complexity
6. Ensure validation and error states remain visible and actionables

To align on business priorities and technical feasibility, I initiated a cross-functional kickoff with PMs and engineers early in the process.

This helped surface key constraints—such as system dependencies and component limitations—before design execution.

During the design phase, we conducted iterative reviews in small groups, enabling faster feedback loops and more informed design decisions.

The sessions were jointly organized by the Design and PM teams, with members taking turns as moderators, observers, and summary facilitators.

• Four user test sessions were conducted based on job roles and departments: Pilot Test 1 (RD), Pilot Test 2 (PM), Formal Test 1 (AM), and Formal Test 2 (BO).
• Participants and observers sat in pairs, while the moderator projected the test tasks to ensure everyone stayed synchronized and on schedule.
• Each session was limited to one hour. After completing the tasks, the moderator and participants stayed to fill out the questionnaire.
• Observers moved to another meeting room to discuss and consolidate their findings, then returned to the main room for a debrief led by the summary facilitator.
• After the sessions, we used the SUS to evaluate usability and collaborated with the PMs to refine and adjust the features that needed improvement.

1. The text space for the Special Price menu has been expanded.
In the previous design, all special prices were shown at once and distinguished by color. The new design simplifies the view by displaying only the price that needs to be edited at the moment, resulting in a clearer and more focused user flow.

2. Only display necessary information
Display a specific date badge when adding a special selling price

3. Display one price date or session at a time
In the previous design, all special prices were shown at once and distinguished by color.

4. The pricing table's design system underwent only minor adjustments
The input error style in the Design System remains unchanged, but the Field component now includes a new error style with red text displayed at the bottom left.