Skip to content

design-guidelines.md

Latest commit

 

History

History
362 lines (257 loc) · 14.5 KB

design-guidelines.md

File metadata and controls

362 lines (257 loc) · 14.5 KB
Raw

디자인 가이드라인

이 문서는 MOBA Esports Manager Lite의 UI 작업 기준을 모아둔 디자인 규약이다.

새 화면을 만들거나 기존 화면을 고칠 때는 이 문서를 먼저 확인한다. docs/ui-design-decisions.md가 지금까지의 UI 결정 기록이라면, 이 문서는 앞으로의 작업에서 지켜야 할 기본 원칙이다.

1. 디자인 방향

MOBA Esports Manager Lite는 League of Legends e스포츠 팀을 운영하는 매니지먼트 게임이다. UI는 화려한 랜딩 페이지가 아니라, 플레이어가 시즌과 선수단을 빠르게 판단하는 운영 대시보드에 가깝다.

핵심 방향:

  • Football Manager식 정보 밀도
  • e스포츠 팀 운영실 같은 어두운 대시보드 톤
  • 시즌 흐름, 다음 경기, 로스터 상태가 빠르게 읽히는 구조
  • 장식보다 판단에 필요한 정보 우선
  • 16:9 PC/노트북 화면 우선
  • 모바일 세로 화면은 정식 지원 대상이 아님

화면은 “멋있지만 비어 있는 UI”보다 “조금 단단하고 읽기 쉬운 UI”를 우선한다.

2. 작업 원칙

UI를 수정할 때의 기본 원칙:

  • 첫 화면에는 해당 메뉴에서 가장 중요한 정보가 보여야 한다.
  • 전체 페이지 스크롤은 최소화하고, 필요한 목록만 패널 내부에서 스크롤한다.
  • 텍스트는 카드 밖으로 밀리거나 잘리지 않아야 한다.
  • 같은 종류의 버튼, 탭, 카드, 배지는 같은 톤과 위치 규칙을 따른다.
  • 기능 설명 문구를 과하게 늘어놓지 않는다.
  • 큰 화면을 무조건 카드로 감싸지 않는다.
  • 카드 안에 또 카드가 들어가는 중첩 카드 구조는 피한다.
  • 사용자가 클릭해야 하는 주요 행동은 명확한 버튼으로 둔다.
  • 단순 이동성 영역은 카드 전체 클릭을 허용해도 된다.
  • 신규 색상은 즉흥적으로 추가하지 않고 기존 색상 체계 안에서 고른다.

AI 에이전트가 UI 작업을 할 때:

  • 먼저 이 문서와 docs/ui-design-decisions.md를 확인한다.
  • 화면을 실제 브라우저에서 열어 16:9 기준으로 확인한다.
  • 가능하면 스크린샷을 남기고, 텍스트 겹침/잘림/과도한 빈 공간을 확인한다.
  • CSS 색상 하드코딩을 추가하기보다 기존 변수화 후보를 고려한다.

3. 레이아웃 규칙

기본 앱 프레임:

  • 좌측 사이드바
  • 상단 헤더
  • 우측 상단 진행 버튼
  • 중앙 콘텐츠
  • 메뉴별 하위 탭 또는 하위 네비게이션

레이아웃 기준:

  • 기본 목표 해상도는 1280x720 이상 16:9 화면이다.
  • 1440x900 화면에서도 과도하게 늘어지는 카드가 없어야 한다.
  • 중앙 콘텐츠는 메뉴별로 넓게 쓰되, 가로로 긴 단일 박스가 반복되는 구조는 피한다.
  • 화면이 길어질 때는 정보 우선순위를 정해서 접거나, 탭을 분리하거나, 카드 밀도를 조정한다.
  • 반복 아이템은 grid 또는 list로 배치하고, 아이템 하나만 있을 때 지나치게 길게 늘어나지 않게 한다.
  • 대시보드 화면은 한눈에 들어오는 압축성을 우선한다.
  • 데이터가 많은 화면은 스크롤이 생겨도 괜찮지만, 스크롤 영역이 어디인지 명확해야 한다.

공식 화면군:

화면군 기준 정책
모바일 세로/소형 화면 폭 900px 미만 또는 세로 태블릿 정식 지원 대상이 아니며 작은 화면 안내 오버레이를 표시한다.
태블릿 가로/소형 노트북 1024px 이상 가로 화면 핵심 정보가 잘리지 않는 최소 호환 영역으로 본다.
PC 기본 검증 1280x720 모든 주요 UI 이슈의 1차 완료 기준이다.
PC 확장 검증 1440x900 16:9 stage와 상하 레터박스 안에서 카드가 의미 없이 늘어나지 않는지 확인하는 2차 기준이다.
더 넓은 PC 화면 1440px 초과 16:9 stage를 유지하고 남는 좌우 또는 상하 공간은 레터박스로 둔다.

PC 화면 정책:

  • 모든 PC 화면비를 개별 대응하지 않는다.
  • 게임 화면은 전역 16:9 stage 안에서 렌더링한다.
  • 기준 화면비와 다른 화면에서는 상하 또는 좌우 레터박스를 남긴다.
  • 기준보다 넓은 stage 안에서는 카드 하나를 무작정 늘리지 않고, 요약 패널/목록/상세 패널로 폭을 나눈다.
  • 기준보다 좁지만 작은 화면 안내 대상이 아닌 경우에는 1열 fallback으로 정보 잘림을 막는다.
  • 게임 내부 모달과 진행 오버레이는 stage 안에서 뜨고, 작은 화면 안내 오버레이만 브라우저 전체를 덮는다.

권장 패턴:

  • 요약 정보: 2~5개 작은 패널
  • 목록: 일정/메시지/선수/팀 단위의 반복 카드
  • 세부 정보: 선택된 항목의 오른쪽 또는 아래쪽 상세 패널
  • 대회/브래킷: 넓은 패널 1개 안에 흐름을 표시

피해야 할 패턴:

  • 의미 없는 16:9 와이드 박스
  • 내부 정보는 적은데 카드 높이만 큰 패널
  • 한 줄 버튼 하나 때문에 하단이 길어지는 카드
  • 같은 정보가 홈, 대회, 상세 화면에 중복 표시되는 구조

4. 색상과 테마

현재 기본 테마는 다크 테마이다.

현재 톤:

  • 배경: 어두운 네이비/블랙 계열
  • 패널: 배경보다 조금 밝은 네이비 계열
  • 테두리: 낮은 대비의 블루그레이
  • 주요 강조: 보라/분홍 계열
  • 성공: 초록 계열
  • 경고: 노랑/주황 계열
  • 위험/패배: 빨강 계열

색상 사용 규칙:

  • 승리/성공은 초록 계열
  • 패배/위험은 빨강 계열
  • 중요 알림은 보라/분홍 또는 노랑 계열
  • 비활성/대기 상태는 블루그레이 계열
  • 사용자 팀 하이라이트는 강하지 않게, 테두리나 얇은 accent로 표시한다.
  • 배경색을 화면마다 새로 만들지 않는다.

향후 테마화를 위해 신규 CSS는 가능한 한 아래 의미를 가진 토큰으로 옮길 수 있게 작성한다.

--color-bg;
--color-surface;
--color-surface-raised;
--color-border;
--color-text;
--color-muted;
--color-accent;
--color-accent-strong;
--color-success;
--color-warning;
--color-danger;

아직 모든 CSS가 토큰화되어 있지는 않다. 새 작업에서는 색상 하드코딩을 늘리기보다 기존 색상과 의미를 맞추고, 큰 리팩터링 시점에 토큰으로 옮긴다.

5. 타이포그래피

텍스트 규칙:

  • 제목은 짧고 명확하게 쓴다.
  • 화면 첫 H1/H2는 메뉴명이나 실제 대상명을 우선한다.
  • 설명 문구는 한두 문장 안에서 끝낸다.
  • 같은 카드 안에서 숫자, 날짜, 상태값은 짧은 라벨과 함께 표시한다.
  • 작은 보조 문구는 흐린 색으로 표시하되, 핵심 값보다 먼저 눈에 띄지 않게 한다.

피해야 할 표현:

  • 게임 규칙과 무관한 장식 문구
  • 선수 커리어/팀 역사에서 평가성 문장을 길게 덧붙이는 방식
  • 카드마다 반복되는 긴 설명
  • 영어 UI 버튼이 섞이는 상태

버튼, 탭, 주요 상태값은 가능하면 한국어로 표시한다. 실제 대회명, 팀명, 선수명은 프로젝트의 데이터 정책을 따른다.

6. 공통 컴포넌트 규칙

버튼

  • 주요 행동은 명확한 텍스트 버튼으로 둔다.
  • 같은 화면에서 primary 버튼은 1~2개 이하로 유지한다.
  • 위험 행동은 빨강 계열과 확인 단계를 사용한다.
  • 아이콘만 있는 버튼은 의미가 분명할 때만 사용한다.

탭

  • 하위 메뉴 전환은 탭을 사용한다.
  • 탭 이름은 짧게 쓴다.
  • 현재 선택된 탭은 테두리, 배경, 색상으로 명확히 구분한다.
  • 한 화면에 탭이 너무 많아지면 기능을 다시 묶는다.

카드와 패널

  • 카드는 반복 아이템, 모달, 선택 가능한 항목에 주로 사용한다.
  • 큰 섹션 전체를 카드로 겹겹이 감싸지 않는다.
  • 카드 radius는 작게 유지한다.
  • 카드 내부 여백은 정보 밀도에 맞게 조정한다.
  • 하나의 카드가 화면 너비 전체로 과도하게 늘어지면 grid 폭 제한을 둔다.

테이블과 리스트

  • 순위표와 일정은 표/리스트의 읽기 흐름을 우선한다.
  • 내 팀은 과하지 않게 하이라이트한다.
  • 승/패/대기 상태는 색상과 텍스트를 함께 사용한다.
  • 필터와 탭은 목록 위에 가깝게 배치한다.

모달

  • 최초 안내, 확인, 세부 설정처럼 집중이 필요한 경우에만 사용한다.
  • 모달은 닫기 버튼이 명확해야 한다.
  • 안내 모달은 한 화면에 너무 많은 규칙을 넣지 않는다.
  • 반복 노출되는 모달은 설정에서 제어 가능해야 한다.

7. 화면별 규칙

홈

홈은 현재 상황을 빠르게 판단하는 화면이다.

보여줄 것:

  • 현재 날짜
  • 다음 경기 또는 최근 경기
  • 중요한 메시지 1개
  • 선발 로스터 또는 로스터 바로가기
  • 경기 준비 상태

피할 것:

  • 특정 대회 화면에서만 의미 있는 세부 지표
  • 홈에서 바로 판단하기 어려운 긴 순위표
  • 카드 하단 정보가 첫 화면 아래로 밀리는 배치

메시지함

메시지함은 너무 많은 알림을 쌓는 공간이 아니다. 플레이어가 확인할 가치가 있는 요약과 중요한 이벤트를 우선한다.

원칙:

  • 주간 리포트와 요약 메시지를 활용한다.
  • 무관한 선수 이적 소식은 노출하지 않는다.
  • 메시지에는 필요한 경우 관련 메뉴로 이동하는 버튼을 둔다.
  • 긴 본문은 리포트형 구조로 나눈다.
  • 같은 문구가 반복되지 않게 변주한다.

로스터 관리

로스터는 선수 상태를 빠르게 비교하는 화면이다.

원칙:

  • 1군 선발, 1군 후보, 아카데미의 역할이 명확해야 한다.
  • 카드가 하나만 있어도 지나치게 길게 늘어나지 않게 한다.
  • 사진, 이름, 포지션, 평가, 상태값이 잘리지 않아야 한다.
  • 드래그 조작과 클릭 조작이 충돌하지 않아야 한다.

전략/훈련

전략/훈련은 경기 전 준비 공간이다.

하위 메뉴:

  • 상대 리포트
  • 주간 계획
  • 전략
  • 스크림

원칙:

  • 상대 리포트는 상대 리포트 메뉴에만 둔다.
  • 전략 화면은 실제 전략 선택과 비교에 집중한다.
  • 스크림은 일정 요청/진행/결과 확인이 분리되어야 한다.
  • 결과 숫자를 과도하게 노출하기보다 판단 가능한 등급과 설명을 우선한다.

대회 현황

대회 화면은 시즌 흐름을 읽는 화면이다.

원칙:

  • 대회명, 현재 단계, 일정, 순위표, 토너먼트 흐름을 분리한다.
  • 탭 이름은 한국어로 통일한다.
  • 토너먼트는 경기 흐름이 왼쪽에서 오른쪽으로 읽혀야 한다.
  • 비어 있는 슬롯도 왜 비어 있는지 설명한다.
  • 브래킷은 지나친 빈 공간 없이 압축하되, 대진 관계가 흐트러지면 안 된다.

스토브리그

스토브리그는 계약 판단 화면이다.

원칙:

  • 1군 5인 구성 우선이라는 게임 규칙을 명확히 안내한다.
  • 2군은 선택 영입이며 부족 인원은 자동 보충된다는 사실을 알려준다.
  • 예산, 요구액, 역할, 확정 대기 상태가 한눈에 보여야 한다.
  • 이적 로그는 읽기 쉽고, 불필요한 내부 표현을 노출하지 않는다.

팀 상세/구단 정보

구단 정보는 다른 팀을 이해하는 화면이다.

원칙:

  • 팀 목록은 10개 팀의 상대적 위치와 전력 비교가 읽혀야 한다.
  • 팀 상세는 로스터, 역사, 우승 기록을 분리한다.
  • 팀 역사에는 잡다한 하위 분류보다 간결한 기록 설명을 우선한다.
  • 과거 팀명/삼성 시절 기록처럼 필요한 맥락은 우승 기록 옆에 짧게 표시한다.

8. 이미지와 에셋

이미지가 필요한 화면:

  • 선수 카드
  • 선수 프로필
  • 팀 상세
  • 구단 정보

원칙:

  • 선수 사진은 가능한 최신 시즌 기준으로 맞춘다.
  • 실제 이미지 URL은 데이터로 관리한다.
  • 공개 저장소에 저작권 리스크가 있는 이미지 파일을 직접 포함하지 않는다.
  • 로고는 흰 박스 안에서 중앙 정렬되어야 한다.
  • 로고 크기는 팀마다 크게 차이나지 않도록 보정한다.

커스텀 테마와 에셋 전략은 docs/custom-theme.md를 따른다.

9. 접근성과 상태 표현

상태는 색상만으로 전달하지 않는다.

권장:

  • 승리: 색상 + 승리
  • 패배: 색상 + 패배
  • 대기: 색상 + 대기
  • 중요: 색상 + 중요
  • 비활성: 흐린 색 + 비활성 설명

버튼과 클릭 가능한 카드:

  • 클릭 가능한 요소는 hover/focus 상태가 있어야 한다.
  • 비활성 상태는 클릭되지 않아야 하고, 이유가 짧게 보여야 한다.
  • 날짜 선택처럼 선택 가능한 옵션은 가능/불가능 상태가 명확해야 한다.

10. 테마화 로드맵

나중에 화이트/블랙/다크 모드 또는 전면 디자인 변경을 하려면 아래 순서로 진행한다.

  1. 전역 CSS 색상을 의미 기반 토큰으로 정리한다.
  2. AppShell, 버튼, 카드, 탭, 모달부터 토큰을 적용한다.
  3. 홈, 로스터, 대회, 스토브리그 같은 대형 화면의 하드코딩 색상을 줄인다.
  4. 앱 루트에 data-theme 속성을 붙인다.
  5. 설정 메뉴에서 다크 / 라이트 / 시스템 기본값을 선택할 수 있게 한다.
  6. 16:9 스크린샷으로 주요 화면을 비교 검증한다.

테마화 작업은 기능 구현과 섞기보다 별도 이슈 또는 epic으로 다룬다.

11. UI 변경 검증 체크리스트

UI 변경 후 확인할 것:

  • 1280x720에서 첫 화면 핵심 정보가 보이는가
  • 1440x900에서 카드가 의미 없이 늘어나지 않는가
  • 태블릿 가로/소형 노트북 영역에서 텍스트와 버튼이 잘리지 않는가
  • 모바일 세로/소형 화면에서는 작은 화면 안내 오버레이가 정상 표시되는가
  • 텍스트가 잘리거나 겹치지 않는가
  • 전체 페이지 스크롤이 과하게 생기지 않는가
  • 내부 스크롤 영역이 명확한가
  • 버튼과 탭의 선택 상태가 분명한가
  • 내 팀 하이라이트가 과하지 않은가
  • 승리/패배/대기/중요 상태가 색상과 텍스트로 함께 전달되는가
  • 신규 UI가 기존 화면의 톤과 어울리는가
  • 필요하면 docs/qa-screenshots/ 아래에 스크린샷을 저장했는가

12. 관련 문서

  • docs/ui-design-decisions.md: 지금까지의 UI 결정 기록
  • docs/custom-theme.md: 커스텀 테마와 에셋 전략
  • docs/architecture.md: 컴포넌트와 도메인 구조
  • docs/risks-and-ai-workflow.md: AI 협업과 UI 검증 리스크