Enterprise UI Design

Enterprise UI Design

Overview

Use this skill when the product is mainly for internal company users rather than public consumer users, and when the user explicitly wants 기업형 디자인, 사내 시스템, or 업무용 UI direction.

The goal is to keep internal-system UI consistent, readable, efficient, and operations-friendly across planning, design, prototyping, frontend implementation, and review.

What Enterprise UI Design Means

기업형 디자인 means UI optimized for internal business work, not marketing presentation.

In this context, enterprise UI should prioritize:

• clarity of information
• simplicity without losing useful business context
• visibility of status, numbers, risks, and actions
• user convenience for repeated operational workflows
• consistency across screens, modules, and roles

Enterprise UI is usually characterized by:

• a clear page header
• stable left-side navigation for large systems
• top summary and filter areas
• table or queue-centered work areas
• detail, evidence, note, or history panels
• consistent action placement
• desktop-first information density

If a design choice looks stylish but makes operation slower or more ambiguous, it is not the correct enterprise choice.

Core Principles

1. Clarity of Information

• The user should immediately understand:
  • what this screen is for
  • what state the data is in
  • what action is available next
• Prefer explicit operational language over abstract labels.
• Titles, section names, statuses, and actions must be concrete.

2. Simplicity

• Simplicity means reducing unnecessary complexity, not removing useful information.
• Remove decorative elements that do not help the user make decisions or complete work.
• Keep one primary task per screen or per major section.

3. Visibility

• Important data, warnings, counts, and pending actions should be easy to scan.
• Status, priority, and error conditions must be visually obvious.
• History, evidence, or reason text should be reachable without hunting through the UI.

4. User Convenience

• Frequent tasks should take as few steps as possible.
• Search, filter, sort, download, retry, approve, and detail-view actions should appear in predictable positions.
• Repeated workflows must feel consistent across modules.

Layout Standards

1. Desktop-first by default.

• Internal systems are primarily workbench tools.
• Optimize for wide screens, dense data, and side-by-side comparison.

2. Use stable layout zones.

• top: title, breadcrumb, context, primary actions
• left: global navigation when the system is broad
• center: main working area
• right or lower area: details, logs, evidence, notes, or secondary actions

3. Keep navigation predictable.

• Use consistent menu naming and route structure.
• Do not move core actions unpredictably between screens.

Default Enterprise Layout

Apply this as the default layout for internal systems unless the docs clearly require a different structure.

1. Global Header

• almost always required
• includes:
  • service or module name
  • current page title
  • breadcrumb or location context
  • key context such as date range, organization, or current period
  • user info, notifications, and account actions

2. Left Navigation

• preferred when the system has multiple modules or deep workflows
• place major work groups here, such as:
  • dashboard
  • operations
  • approval
  • settlement
  • reporting
  • system management
• use top navigation only when the product scope is small

3. Main Work Area

• top row:
  • summary metrics
  • status counts
  • primary actions if needed
• next row:
  • filter bar
  • search
  • date range
  • view mode or tabs
• main body:
  • table
  • queue
  • card list only if the workflow truly needs it
• detail area:
  • side panel
  • bottom detail section
  • evidence, history, notes, or related records

4. Action Placement

• primary actions should be easy to find and consistently placed
• secondary actions should not compete visually with primary actions
• destructive actions should be clearly separated

5. Detail and History

• when the workflow involves review, approval, settlement, monitoring, or correction, include:
  • detail view
  • reason or evidence section
  • change history or timeline

6. Table-First Bias

• if users need to compare, sort, filter, scan, or bulk-handle records, prefer a table-first structure
• do not replace a useful table with decorative cards unless the task is overview-only

Information Standards

Prioritize these UI elements in internal systems:

• summary metrics
• filter bars
• search
• date range
• tables or queues
• detail panels
• status badges
• evidence or reason text
• history or logs
• primary and secondary actions

If the docs are ambiguous, default to:

• a summary row or top metrics
• a filter/search area
• a table or queue area
• a detail or evidence area
• a clear action area

Visual Standards

1. Favor restrained visual systems.

• neutral backgrounds
• limited accent colors
• strong contrast for important states
• clear typography hierarchy

2. Use color semantically.

• blue or neutral for context
• green for normal or success
• yellow for caution or review
• red for error or danger
• gray for inactive, pending, or unknown

3. Prefer consistency over novelty.

• The same kind of component should behave the same way across screens.
• The same status should look the same across modules.
• The same action hierarchy should repeat across flows.

Component Priorities

High-value enterprise components:

• filter bars
• data tables
• pagination
• status badges
• tabs for data modes
• detail drawers or panels
• timelines or history blocks
• comparison cards
• queue cards
• modal forms with explicit validation

Copy Standards

Use:

• short labels
• explicit statuses
• direct action names
• operational terminology used by the business

Avoid:

• marketing copy
• decorative slogans
• vague labels without context
• filler text that adds no operational meaning

Decision Rule

When unsure between a prettier UI and a clearer UI, choose the clearer UI.

When unsure between a novel layout and a repeatable layout, choose the repeatable layout.

When unsure whether to show more useful operational context, prefer the version that reduces user mistakes and speeds up work.

When To Apply This Skill

Use this skill for requests like:

• 기업형 디자인으로 바꿔줘
• 기업형 디자인 기준으로 정리해줘
• 사내 시스템 느낌으로 해줘
• 업무용 UI로 개선해줘
• 기업형 느낌으로 다듬어줘
• 사내 시스템답게 바꿔줘
• 업무용 UI로 정리해줘
• 가시성 좋게 바꿔줘
• 테이블/필터 중심으로 바꿔줘
• 일관성 있게 UI 정리해줘
• 운영 시스템 느낌으로 디자인해줘

This skill should also be applied implicitly when:

• the product is an admin console
• the product is an internal operations system
• the product is an approval, settlement, reporting, or monitoring tool
• the user wants consistent enterprise UI behavior across screens

Notes

• This skill provides design standards, not implementation steps by itself.
• Combine it with:
  • prototype-builder for internal-system prototypes
  • frontend-spec-builder for real frontend implementation
  • feature-review for UI consistency review