← UI/UX Work

Stey Console

Making complex
financial workflows clear.

Translating business rules into understandable states, dependencies, and interactions for a hospitality PMS.

UI designEnterprise financeHospitality PMS
Stey Console — Finance module and contract summaries interface
Stey Console / Enterprise finance experience
Role
UI Designer
Product
B2B SaaS · Hospitality PMS
Collaboration
PM, Front-end & Back-end Engineers
Timeline
2023

01 / Stey Console

From business rules to system behavior.

Stey Console's Finance module runs billing for a hybrid long-term-apartment and boutique-hotel PMS. Requirements arrived as dense business rules, not UI specs, and many depended on one another in ways no single screen made visible.

Four cases below, across different levels of complexity: a rule-heavy configuration page, a hierarchical rule engine, a cross-module dependency, and a small but high-frequency fix.

The problem

Finance requirements rarely described a single interaction. A single requirement could combine conditional fields, parent-child dependencies, effective dates, calculation logic, validation, and downstream effects.

The challenge was turning these business rules into a coherent interaction model — making system states and dependencies explicit before translating them into UI.

Design process

  1. 01Business rules
  2. 02States & dependencies
  3. 03Interaction model
  4. 04Interface
  5. 05Engineering check

An iterative loop: revisit the model whenever engineering walkthroughs reveal an incomplete state.

How the process worked

Process: Business Rules → States & Dependencies → Interaction Model → Interface → Engineering Check — I looped back whenever a modeled state turned out to be incomplete, often catching gaps during engineering walkthroughs.

02 / Stey Console

Apartment Contract

Five connected settings. One coherent contract configuration.

Problem: Apartment Contract wasn't one page — it was five tabs (Default Settings, Discount Scheme, Contract Template, Utility Charge, HSKP Charge) that together define the rules and content of an apartment contract: baseline fees, pricing, the legal contract, utility billing, and housekeeping charges. Each tab arrived as a separate business document, but the five had to be designed as one coherent contract configuration rather than five disconnected settings pages.

  • Default Settings
  • Discount Scheme
  • Contract Template
  • Utility Charge
  • HSKP Charge
Interaction model / Charge boundary

One switch. A clear boundary.

Explore how the parent setting affects future configuration.

Utility charge
Rate configurationAvailable to edit

Unit-price fields can be configured. Rate changes apply going forward.

Previously generated billsRemain unchanged

Switching the charge on or off does not rewrite billing history.

Illustrative interaction model · Based on the Utility Charge specification

Shared configuration / Utility & housekeeping

Found one repeating pattern and reused it

Utility Charge and HSKP Charge were specified independently, but both solved the same underlying problem: toggle a charge on or off without touching historical bills, and apply rate changes going forward only. That shared problem is what produced a shared skeleton — switch, effective date, rate config, billing/payment behavior — rather than two independently-designed pages.

Made the parent switch's boundary explicit

In Utility Charge, disabling the switch visibly disables the three unit-price fields, while already-generated bills remain untouched. I documented this boundary directly in the spec to prevent implementation ambiguity.

Utility Charge / Parent switch and rates

Simplified HSKP Charge's percentage-tier system

Reward/penalty tiers (0–25%, 25–50%, etc.) only require paired inputs for each band, so I represented them as compact tier rows rather than a lookup table.

HSKP Charge / Percentage tiers
Pricing / Discount Scheme

Kept Discount Scheme editable in place

A directly-editable matrix (contract period × rate/deposit) rather than a separate form for each row. When the business later added a new pricing dimension (High Demand Rate), it only needed a new column — not a new page.

Discount Scheme / Editable pricing matrix
Legal / Contract Template

Added version control where the content was legal, not numeric

Contract Template governs the legal agreement rather than a billing rule, so edits are recorded with operator, timestamp, and change details in an Operation Log. The same pattern was later reused for PDF templates elsewhere in Finance.

Apartment Contract

FinanceApartment Contract
Default Settings
Discount Scheme
Contract Template
Utility Charge
HSKP Charge
Template version2.2
公寓式酒店(长住)服务合同
Service Agreement of Apartment Hotel (Long Term)
本合同于[ ]年[ ]月[ ]日由以下各方在[北京]签署:
This agreement (hereinafter referred to as Agreement) is signed in [Beijing] on [ ] (Year) [ ] (Month) [ ] (Day) by and between the parties below:
甲方:[ ]
Party A: [ ]
乙方:[ ];
Party B: [ ];
证照类型及号码:[ ];
ID type and number: [ ];
乙方指定住宿人员:[ ];
Designated Resident of Party B: [ ];
证照类型及号码:[ ];
ID type and number: [ ];
依据中华人民共和国有关法律法规的规定,甲方作为服务提供方及公寓式酒店管理方,乙方作为公寓式酒店住宿客人,双方在平等自愿的基础上,经协商一致,就甲方利用其酒店为乙方提供长租住宿服务有关事宜达成如下条款:
In accordance with relevant laws and regulations of the People's Republic of China, Party A, as the Service Provider controlling the management of the Apartment Hotel, reached the following terms of agreement on the relevant matters of long-term service providing by consensus with Party B, as the customer of the serviced Apartment Hotel, on the basis of equality and voluntariness:
一、
客房位置及类型
Location and Type of the Long-term Service Room
1.1
甲方为乙方提供长租住宿服务的客房为位于[ ]市[ ]区[ ]号楼[ ]的物业(简称“公寓”)的[ ]号房间(以下简称“客房”),使用面积约为[ ]平方米。
The long-term service room (hereinafter referred to as the Room) that Party A provides long-term accommodation services for Party B is the property of Room [ ], at [ ] (hereinafter referred to as Apartment Hotel) located at [ ], with a usable area of about [ ] square meters.
Contract Template / Editable template, version history and operation log

03 / Stey Console

Transaction Rules

Make hierarchy and calculation logic visible before a rule is applied.

Transaction Rules define how hotel charges such as room fees, service fees, and taxes are calculated and mapped to accounting accounts. Rules use a Group / Sub Group hierarchy, with each rule supporting different calculation methods and transaction codes.

01 / Design challenge

Complex hierarchy

Make parent-child relationships and generated rules easy to understand at a glance.

02 / Design challenge

Multiple rule types

Support different field requirements within one consistent configuration flow.

03 / Design challenge

Hidden calculation logic

Make the calculation basis explicit to prevent accounting errors.

Parent

Group

Calculation method & transaction code

Derived rules

Sub Groups

Explicit parent-child relationships and calculation basis

Transaction Rules / Group hierarchy and progressive creation
Group and Sub Group / Calculation methods and edit states

Rule configuration / Design decisions

01

Hierarchy Visualization

Used indentation, expand/collapse arrows, and derivation symbols to make Group / Sub Group relationships and generated rules visible directly in the list.

02

Progressive Creation

Kept initial rule creation lightweight—users only enter the name and category, while detailed configuration is completed in the edit state.

03

Unified Dynamic Form

Used one shared modal for Groups and Sub Groups, with fields dynamically changing based on the selected calculation method.

04

Explicit Calculation Basis

Exposed whether calculations apply to the original transaction or include amounts generated by Sub Groups, making previously hidden business logic visible.

04 / Stey Console

Project Setting

A consistent home for settings with system-wide consequences.

Project Setting is the project-level financial configuration hub, covering legal information, payment channels, accounting mappings, and financial document templates. These settings directly affect payment options, posting logic, and customer-facing financial documents across the system.

01 / Design challenge

Heterogeneous configurations

Bring together multilingual content, banking information, transaction codes, payment settings, and HTML templates within one consistent structure.

02 / Design challenge

Cross-module dependencies

Make downstream effects visible when a setting changes, preventing configuration and actual system behavior from becoming inconsistent.

03 / Design challenge

High-risk template editing

Make financial PDF template changes traceable and previewable to prevent unintended changes to customer-facing documents.

Cross-module dependency / Online Payment

Project Setting

Alipay selection

Controls channel availability

  • CRS Booking Flow
  • Stey Plus
  • Mobile CI
  • Distribution Center
Configuration / 01

Project Info — Field-Level Multilingual Switching

Added independent ZH/EN/SV switching for legal information fields, while keeping VAT Info as plain text because it is legally registered information and does not require translation.

Project information / Independent language controls
Configuration / 02

Bank Details — Basic Account Information

Used a standard form for four core fields—Account Name, Bank Account, SWIFT Code, and Bank Name—to maintain the single receiving account and display payee information on invoices, receipts, and other financial documents.

Bank details / Receiving account information
Configuration / 03

Room Charge Posting — Scoped Autocomplete

Limited selectable transaction codes to revenue accounts (is_revenue = true) and used searchable Autocomplete to reduce incorrect account mapping.

Room charge posting / Revenue-account autocomplete
Configuration / 04

AR Account — Restricted Selection

Limited the dropdown to AR transaction codes, narrowing the selection to accounts relevant to the configuration.

AR account / Restricted transaction-code selection
Configuration / 05

Payment — Explicit Cross-Module Dependencies

Supported multiple optional payment channels with dynamic transaction-code fields. Made downstream dependencies explicit—for example, selecting Alipay under Online Payment determines whether Alipay is available in CRS Booking Flow, Stey Plus, Mobile CI, and Distribution Center.

Payment settings / Channel configuration
Payment channels / Distribution Center dependencies
Configuration / 06

Finance PDF Templates — Versioning + Audit Log

Used a template list with a code editor, independent version numbers, modification logs, and real-time PDF preview, giving administrators control and traceability when editing customer-facing financial documents.

Finance PDF templates / Editor and preview

05 / Stey Console

Process & gaps

Making the system legible—and recognizing where validation could go further.

How I worked

Understand the rule → model the states → pick the interaction only once behavior is clear → document it in the spec → check it against engineering before build. That last step is where gaps got caught, including the Transaction Rules ambiguity above.

What I’d change

I didn't run structured usability testing on this module — validation came from engineering walkthroughs and PM review, not observed use by finance staff. For higher-risk screens, I would add lightweight usability checks before build. I'd also model states earlier, before high-fidelity design and with engineering in the room from the start, and push for measurable acceptance criteria upfront so decisions can be judged against outcomes, not just spec compliance.

This project sharpened what I care about in enterprise design — not the individual screen, but making a complicated system legible: business rules → system behavior → interaction → interface.