Sep 2019
Casino Accounting Back Office — Operational system redesign
Redesigning a casino accounting back office to reduce calculation risk, simplify role-based workflows, and establish a reusable interface foundation.
Overview
Project overview
A casino accounting back-office system used for account, transaction, shift-handover, reporting, and financial operations.
My role and ownership
Individual designer responsible for research synthesis, information architecture, interface design, and the component guidelines.
Team and collaborators
Individual designer responsible for research synthesis, information architecture, interface design, and the component guidelines.
Timeline and product stage
April–September 2019 · Six-month redesign and development effort.
Primary constraint
The redesign had to improve front-end usability without compromising the correctness of calculations stored in the database.
To comply with my non-disclosure agreement, I have omitted confidential information in this portfolio. All information in this portfolio is my own and does not necessarily reflect the views of Kooppi Limited.
Problem evidence
The short-term goal was to reduce calculation mistakes in the client’s existing system. The longer-term goal was to prepare a reusable KOOPPI solution for a broader casino market.
Usability baseline
The research plan used individual SUS questions to locate specific pain points and establish a basis for evaluating the redesign after release.
- Target sample: at least five participants
- Roles in scope: cashiers and finance specialists
- Roles outside the study: IT managers, cash managers, and customer service
- Recorded SUS score: 60.3
- Lowest-rated statement: “I found the various functions in this system were well integrated.”
- Highest-rated statement: “I thought there was too much inconsistency in this system.”
Navigation and terminology
The heuristic evaluation identified 3 recurring barriers:
“The side menu contained more than 17 entries, making information difficult for inexperienced users to locate.
“Experienced users relied on shortcuts, but those shortcuts differed by role.”
“The system used different terms for the same concept”
Process
Above findings clarified three design goals:
Goal 1
Simplify the menu and integrate related functions so users can complete daily tasks faster.
Goal 2
Standardize terminology so the system is easier to learn.
Goal 3
Refactor the front-end structure with React to support a future SaaS offering.
Restructuring operational workflows
I explored two information-architecture directions:
- A task- and permission-oriented structure
- A process-oriented structure
The comparison helped separate role access from the sequence of work and made the operational flow more explicit.
Wireframe testing
I translated the proposed structure into wireframes for account lists, B-number records, account creation, and closing workflows. This made it possible to evaluate information grouping and task sequence before committing to visual details.
Delivery
Building the interface system
Qualitative input about officer roles, working environments, and the desired look and feel led to two principles.
Efficient
- Present enough information to support decisions at a glance.
- Support keyboard access for repetitive input.
- Open reports and statistics in a new tab so users can preserve their working context.
Friendly
- Use three analogous colors to create a coherent visual language.
- Use icons that connect with objects and actions from users’ offline work.
Foundations and input patterns
I consolidated components that had been scattered across different pages. The initial foundation defined a type hierarchy and neutral color roles for important, normal, placeholder, disabled, and status content.
The input rules covered read-only, editable, required, select, amount, rate, time, and date fields. They also specified when validation feedback should appear and how system-generated values should behave.
UI iteration
With the principles and basic components established, I compared layout and visual directions on key screens. The iterations tested navigation density, information hierarchy, form structure, status colors, and table presentation.
Interaction guidelines
The finalized system documented behavior as well as appearance. It included editable and scrollable tables, empty and loading states, input focus and feedback, clickable labels, card actions, navigation states, spacing, buttons, and system notifications.
The component rules were aligned with the design principles and integrated with the front-end Sass structure using an atomic-design approach.
Business impact
Working with the front-end developer and applying the atomic-design approach reduced the recorded development period from two months to one month.