From Paper to a Smooth Digital Flow:UX Optimization for a Contractor Payment System

Originally the columns led with general data fields, putting email and ID number up front. But when actually looking up a contractor, users first need to confirm the name, registered address and remittance details to quickly judge whether it's the right person.

After the change, the column order became "Name → Registered address → Passbook → ID number → Email," moving low-volatility, high-recognition information directly tied to payment to the front — lowering horizontal scanning cost and improving lookup and cross-checking efficiency.

When creating a labor form, tax information appeared in the amount block but lacked an explicit tax-rate percentage and explanation. Users knew the tax for categories they filed often, but for less common filing categories they easily forgot the applicable rules, leading to extra lookups or manual checks.

After the change, a "Learn more" entry was added beside the filing category so users can view each category's withholding explanation; a reminder below the payment date notes it must fall after the work period, preventing unreasonable payment times. The amount block now directly shows the withholding percentages for income tax and supplementary health insurance, letting both filer and checker confirm the calculation basis quickly, while flagging that foreign residents' rates may differ — reducing the risk of amount and tax mismatches.

The "filler" block originally used "Have the income recipient fill it in" and "Fill in yourself" as option labels, but "income recipient" was unintuitive — users weren't sure whether it meant the contractor, internal staff, or the form creator. The "New staff / Existing labor personnel" options below were also misread as whether a record already existed, rather than distinguishing the contractor's status.

After the change, the options were corrected to "Contractor fills in" and "Fill in yourself," directly stating who enters the data so users grasp the difference faster. The lower options became "First-time contractor / Existing contractor," clearly distinguishing a contractor recorded for the first time from one already on the list — lowering the judgment cost caused by wording.

The labor-form list already showed creation date, name, work details, amount and counter-sign progress, but the presentation read like an ordinary list, lacking visual cues to help users judge time ranges and batches quickly. As forms grew, users had to scan dates row by row to tell which belonged to the same year, batch, or priority period — making lookup inefficient.

After the change, the "Creation date" column was made more prominent, using different years as a visual divider so users grasp form creation time and data ranges faster. Pagination was added below the list to avoid the reading burden of expanding all data at once, letting users review created forms in batches.

Originally, after filling in the data users went straight to the notification-email editor. They could edit the email's title and content but couldn't fully preview the labor form's actual content before sending. This created uncertainty about whether the data was correct and what the recipient would see — and since labor forms involve names, addresses, amounts, taxes and payment dates, without a final check step users easily felt anxious before sending.

After the change, a "Preview document" state was added before sending, so users can enter the labor-form preview from the email editor and fully check basic info, work details, amount and related fields. Once confirmed correct, they press the button to complete the send.

Originally, when merging multiple forms, after selecting items the list showed the result as plain text or a single row, making it hard to tell which forms had been combined into the same merged form. Especially when one contractor had several records of different dates or work content, users had to re-compare the list to confirm which records were merged — adding checking cost.

After the change, merged forms are shown as a group, with a background-colored block clearly marking the merge scope so users can see at a glance which records are folded into the same merged form. A merge number and merge status were added in the notes column, making the merged data's source and relationships clearer.