도움 방식은 하나로

KRDS CP-380 — 한 화면에 아이콘 툴팁과 맥락적 도움말 또는 도움말 패널을 혼용하여 사용하지 않는다.

0. 들어가며 — 500편, 도움 방식의 일관성

이번 500편은 한 화면에 아이콘 툴팁과 맥락적 도움말 또는 도움말 패널을 혼용하지 않게 하라는 규칙입니다. 시리즈 500편째 — 절반을 훌쩍 넘겼네요.

툴팁(호버 말풍선)·맥락적 도움말(클릭 팝오버)·도움 패널(큰 영역)은 — 모두 도움을 주지만 방식이 다르죠. 한 화면에 섞이면 — 사용자가 ‘도움이 어디서 어떻게 나오는지’ 헷갈립니다. CP-380은 도움 방식의 혼용을 금지합니다. 맥락적 도움말 CP-360과 같은 정신이죠. 이번 편을 풀어냅니다.

1. 원문 — 도움 컴포넌트 혼용 금지

CP-380 (컴포넌트 > 툴팁) “한 화면에 아이콘 툴팁과 맥락적 도움말 또는 도움말 패널을 혼용하여 사용하지 않는다.”

같은 화면에서 아이콘 툴팁과 맥락적 도움말, 도움 패널을 섞어 쓰지 말고 한 가지 도움 방식으로 통일하라는 뜻입니다.

정리: 툴팁·맥락적 도움말·도움 패널을 한 화면에 혼용하지 마라. 이게 CP-380입니다.

2. 왜 혼용을 금지하나

KRDS에는 — 도움을 주는 인라인 컴포넌트가 셋 있습니다:

아이콘 툴팁(Tooltip) — 호버/포커스 시 잠깐 뜨는 작은 말풍선. 짧은 부가 정보·아이콘 이름(150자 이내, CP-376·378).

맥락적 도움말(Contextual help) — 클릭으로 여는 풍부한 팝오버. ⓘ/? 아이콘으로(CP-355~365).

도움 패널(Help panel) — 본문 옆 펼쳐지는 큰 영역. 체계적 도움(CP-335~348).

셋 다 — 도움을 준다는 목적은 같지만, 트리거(호버/클릭)·위치·무게가 다릅니다. 이들을 한 화면에 섞어 쓰면 문제가 생기죠.

혼용의 문제:

예측 불가 — 어떤 아이콘은 호버하면 툴팁이 뜨고, 어떤 아이콘은 클릭하면 맥락적 도움말이 뜨고, 또 어디선 도움 패널이 펼쳐지면 — 사용자는 ‘도움이 어떻게 나오는지’ 예측 못 합니다. 매번 ‘이건 호버? 클릭?’ 추론해야 하죠.

트리거 충돌 — 툴팁(호버)과 맥락적 도움말(클릭)이 같은 영역에 섞이면 — 호버했더니 툴팁, 클릭했더니 또 다른 도움말이 떠 혼란스럽습니다.

중복·복잡 — 같은 정보를 여러 방식으로 주거나, 화면이 여러 도움 UI로 복잡해지죠.

그래서 CP-380은 — 한 화면에서 한 가지 도움 방식으로 통일하라고 합니다:

하나 선택 — 그 화면의 도움 성격에 맞는 한 방식을 고릅니다:

툴팁 — 짧은 부가 정보·아이콘 이름이 주로 필요할 때. 가벼운 호버 도움.

맥락적 도움말 — 요소별로 풍부한 도움이 필요할 때. 클릭 팝오버.

도움 패널 — 여러 항목의 체계적 도움이 필요할 때. 큰 영역.

일관 적용 — 고른 방식을 그 화면 전체에 일관되게. 도움이 항상 같은 방식으로 나오면 사용자가 예측하죠.

맥락적 도움말 CP-360과의 관계. CP-360은 ’맥락적 도움말과 도움 패널 병용 금지’였죠. CP-380은 거기에 툴팁까지 포함해, 세 도움 컴포넌트를 한 화면에 섞지 말라는 것입니다. 두 규칙이 함께 도움 방식의 일관성을 보장하죠. 어느 컴포넌트 관점에서 보든 ’도움은 한 화면에 한 방식’이 원칙입니다.

예외적 보완. 엄밀히는 — 툴팁(아이콘 이름)과 다른 도움이 성격이 아주 다를 때 보완적으로 쓰일 여지도 있지만, KRDS는 — 혼란 방지를 위해 혼용하지 않기를 명확히 규정합니다. 한 화면의 도움 경험을 단일하게 유지하는 게 사용성에 낫다는 거죠.

이 규칙은 툴팁의 ’도움 방식 일관성’을 담당합니다 — 툴팁·맥락적 도움말·도움 패널을 안 섞어(380), 사용자가 도움이 어떻게 나올지 예측하게 하죠. 컴포넌트 선택 일관성(CP-360)의 툴팁 포함 확장판입니다.

정리하면 — 툴팁·맥락적 도움말·도움 패널을 한 화면에 섞으면 도움이 어떻게 나올지 예측 못 하고 트리거가 충돌하므로, 화면 성격에 맞는 한 가지 도움 방식으로 통일해야 합니다.

3. 점검 / 개선

무엇을 점검하나

혼용 없음 — 한 화면에 툴팁·맥락적 도움말·도움 패널이 섞여 있지 않은가.

방식 통일 — 화면 성격에 맞는 한 도움 방식으로 일관되는가.

트리거 일관 — 도움이 항상 같은 방식(호버/클릭)으로 나오는가.

개선 방향

화면 성격으로 한 방식 선택: 짧은 부가=툴팁, 풍부한 요소별=맥락적 도움말, 체계적=도움 패널.

고른 방식을 화면 전체에 일관 적용. 혼용 제거.

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
기획/UX	화면별 도움 방식 선택·통일 정책
퍼블리셔/개발	단일 도움 방식 구현

기관 유형	CP-380 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 조건부 (도움 컴포넌트 사용 시)

도움 컴포넌트를 쓰는 사이트에 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 한 화면에 툴팁·맥락적 도움말·도움 패널이 섞여 있지 않나요?

□ 화면 성격에 맞는 한 도움 방식으로 일관되나요?

□ 도움이 항상 같은 방식(호버/클릭)으로 나오나요?

❓ FAQ

Q1. 셋 다 쓰면 더 친절하지 않나요? 오히려 도움이 어떻게 나올지 예측 못 하고 트리거가 충돌합니다. 한 방식으로 통일하는 게 낫죠. Q2. 어떤 걸 고르나요? 짧은 부가 정보·아이콘 이름은 툴팁, 풍부한 요소별 도움은 맥락적 도움말, 체계적 도움은 도움 패널입니다. Q3. CP-360과 뭐가 다른가요? CP-360은 맥락적 도움말·도움 패널 병용 금지, CP-380은 거기에 툴팁까지 포함입니다. 함께 ’한 화면 한 방식’을 보장하죠.

6. 마무리

CP-380의 메시지:

도움 방식은 하나로 — 툴팁·맥락적 도움말·도움 패널을 한 화면에 혼용하지 마라.

세 도움 방식을 섞으면 도움이 어떻게 나올지 예측 못 하고 트리거가 충돌합니다. 화면 성격에 맞는 한 방식으로 통일해 예측 가능성을 주는 게 핵심이죠. 다음 편은 모바일 터치 사용성입니다.

다음 편 예고 ▶ 「501. (CP-381) [모바일] 터치 인터페이스에서의 사용성을 고려하고 있다.」

ViewCheck는 툴팁·맥락적 도움말·도움 패널이 혼용되지 않는지를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 툴팁(Tooltip) 가이드 — https://www.krds.go.kr/html/site/component/component_37.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준