IXT

Design Rationale

Workbench pages are long and information-dense. The UI needs to help users stay oriented, scan key status quickly, and move between sections without losing context.

Result

• A consistent page frame: left navigation + a central content canvas with generous spacing for readability.
• A context header that keeps entity identity and status visible (e.g., policy/product ID, current status, key timestamps).
• Card-based sections to break dense content into scannable blocks, with tables used only where list comparison is needed.

Design Rationale

After editing, users often need a stable “review” view for checking details, sharing, or confirming correctness. The UI should clearly communicate read-only vs. editable states and reduce accidental changes.

Result

• A distinct view mode that presents information as structured blocks/cards for top-to-bottom reading.
• Clear state cues (e.g., disabled fields, read-only styling) to differentiate viewing from editing.
• Content grouped by hierarchy so users can verify key information quickly without scrolling through raw form fields.

Design Rationale

Users frequently jump across areas during decision-heavy workflows. Navigation should support fast switching while preserving a stable mental model.

Result

• A two-layer navigation: a fixed icon rail for global areas and an inner section list for the current workspace.
• Consistent labeling and hierarchy (including expandable groups) so users can predict where settings live.
• Optional collapse behavior when users want maximum space for dense content.

Design Rationale

1. Keep critical context always visible
   Users need immediate answers to “What policy is this?”, “What’s its status?”, and “What period am I looking at?” I anchored a summary header that surfaces the policy number, primary/secondary status, key metadata, and actions (e.g., Change Status) so users don’t lose context while navigating long content.
2. Separate review from actions to reduce mistakes
   Policy servicing often involves high-impact operations. I structured the page so the default experience is review-first (readable, card-based sections), with actions clearly separated (top-right global actions, row-level actions in tables, and contextual actions like “Add Excluded Item”). This reduces accidental edits and supports confident decision-making.
3. Use consistent information hierarchy across tabs
   To reduce learning cost, each tab follows the same pattern:
   (a) policy context → (b) section navigation → (c) card-based blocks → (d) tables for dense lists.
   This creates a predictable rhythm for scanning and helps users build a stable mental model across “Policy Parties / Policy Details / Billing / Excluded Item.”
4. Turn dense content into scannable blocks
   Insurance data is inherently dense (multiple parties, plans, documents, billing schedules). I used card sections and grouped fields to make long content readable, then used tables only where list comparison is required—keeping each area focused on a single decision.
5. Make state and exceptions explicit
   Servicing workflows depend on understanding state: Effective vs. Pending, Overdue vs. Paid, renewed relationships, etc. I emphasized state with clear labels/badges, surfaced exception signals (e.g., overdue indicator), and provided status-change entry points in consistent locations.

Result

• Persistent context header with policy identity, primary/secondary status, key dates, and a clear “Change Status” action—supporting quick verification and reducing back-and-forth.
• Tabbed navigation (Policy Parties / Policy Details / Billing / Excluded Item) to separate tasks while keeping the same information structure across sections.
• Policy Parties organized into scannable card blocks (e.g., Policyholder, Beneficiary) with compact tables for multiple entries, enabling quick review and targeted actions.
• Policy Details presented as stacked plan cards (core/rider plans) plus supporting sections (campaigns, policy documents, agreements), enabling users to review coverage composition without digging through multiple pages.
• Billing designed around “what needs attention now” (next payment + payment method summary) and a detailed Billing Schedule table with status tags for fast reconciliation.
• Excluded Item built as an exception-handling workspace with a clear “Add” entry point and row-level actions (edit/delete) so users can manage exclusions safely and efficiently.

Design Rationale

Plan content is often contract-like and dense, with nested structure (main clauses, conditions, riders). The UI should improve readability without “simplifying away” important details.

Result

• A document-style viewer with clear typographic hierarchy and spacing to support dense reading.
• Structured grouping to reflect clause relationships (main items → sub-items / conditions).

Design Rationale

Workbench lists require flexible filtering, but the UI should remain lightweight and safe. Users need to refine criteria without losing their place or triggering unintended changes.

Result

• A top-down drop-down filter panel from the header to keep list context and scroll position.
• A consistent rule structure (Field × Operator × Value) that scales to multi-condition filtering.
• Autocomplete with type labels to reduce mismatches.
• Apply / Cancel to allow safe iteration before committing changes.

Design Rationale

Across the platform, editing screens are rule-driven and input-heavy. Many fields affect calculations and downstream behavior, so the key UI challenge is making complex inputs scannable, unambiguous, and hard to misconfigure—without forcing users to relearn patterns in every module.

UI Focus

• Hierarchy and grouping
  Structured long forms into consistent sections and blocks, using headings, spacing, and alignment to clarify what belongs together and what depends on what.
• Reusable patterns across forms and tables
  Standardized common components (dropdowns, toggles, add-another rows, inline help, table actions) so the same interaction behaves consistently across different editing contexts.
• Clear states and feedback
  Emphasized editable vs. read-only states, required/optional cues, validation, and warnings to reduce mistakes in calculation-sensitive setups.

Result

A consistent editing experience where users can scan structure quickly, understand field relationships, and complete configurations with fewer errors and less cognitive load.

Design Rationale

To support advanced rule authoring, I designed a dedicated workspace that still feels consistent with the rest of the platform. The UI needed to balance two modes: focused code writing and fast attribute discovery, while keeping feedback readable when errors occur.

Result

• A consistent left-tools / right-content layout to match the platform’s Workbench structure and reduce context switching.
• A collapsible Attribute Selector so users can expand it when searching for fields and collapse it to maximize editor focus.
• Two discovery patterns: hierarchical layer filters for browsing and search + type cues (e.g., Num / Enum) for faster, safer selection.
• Quick “add/insert” actions from the selector to reduce copy/paste and memory load when writing rules.
• A dedicated feedback area with Compile Result (errors/logs) and Syntax Rule guidance, keeping debugging readable without leaving the page.
• A dark editor surface paired with lighter surrounding UI to create a clear visual hierarchy and a familiar coding feel.

Design Rationale

‍Cancellation is a high-stakes operation: a small mistake can cascade into incorrect refunds, billing updates, or document mismatches. I designed a step-by-step wizard to make decisions explicit, reduce cognitive load, and keep each step focused and reviewable—especially when users handle partial cancellations (rider plans) and rule-driven refund outcomes.

Result

• Made risk-heavy actions safer with a clear 3-step flow
  Target Selection → Cancellation Info → Refund Calculation, with a persistent progress indicator so users always know where they are and what they’re about to confirm.
• Used progressive disclosure to keep the UI lightweight
  The default screen stays minimal (full policy), and rider selection only appears when users choose partial cancellation—supporting fast scanning without losing verification capability.
• Improved form completion accuracy through hierarchy and spacing
  A centered, single-column layout with clear grouping and “Optional” labeling guides attention to the fields that matter, reducing input errors under time pressure.
• Built confidence before submission with a refund preview and breakdown
  Users can choose system rule / manual amount / no refund, then verify a plan-by-plan breakdown before totals—making calculation context and outcomes transparent.

Design Rationale

‍As the platform expanded across multiple modules and workflows, we needed a shared UI language that could scale without increasing design or engineering rework. I established a systemized visual foundation aligned with the corporate identity, then translated it into reusable rules for layout, typography, color, and interaction components—so teams could build new screens with consistent behavior and predictable implementation.

What it enabled

• A system that mirrors real product structure
  Organized from global layout to reusable UI building blocks: Area → Fundamentals → Components & Patterns, making the guideline easier to navigate and apply in day-to-day production.
• Cross-module consistency through shared layout and spacing rules
  Area-level definitions ensured navigation, headers, and content regions behaved consistently across workbenches, reducing relearning and preventing UI drift.
• Reusable components that accelerate complex form building
  Components shipped with layout rules, states, and usage examples (e.g., fields, selection, dropdown + search), enabling teams to assemble workflows faster with fewer one-off designs.
• Clear interaction rules that reduce handoff friction
  Documented patterns (selection behaviors, action placement, validation states) reduced interpretation gaps and supported predictable implementation as the platform evolved.