설명이 필요한 UI는 실패한 디자인입니다.

사용자는 가이드를 정독하지 않습니다.

Jan 26. 2026

*원문 출처를 번역한 글입니다.

지난달 한 사용성 테스트를 참관했는데 어떤 사용자가 저장 버튼을 찾느라 3분이나 헤매는 모습을 보았습니다. 버튼은 바로 그 자리에 있었죠. 우측 상단에 크고 파란색으로요. 하지만 버튼에는 '저장' 대신 '변경 사항 전송'이라고 적혀 있었습니다. 결국 사용자는 포기하고 탭을 닫아버렸고, 2시간 동안 작업한 결과물은 날아가 버렸습니다.

그때 깨달았습니다. 사용자가 인터페이스 사용법을 고민해야 하는 시점에 이미 디자인은 실패한 것이라는 사실을요. 좋은 UI는 매뉴얼이 필요 없습니다. 모든 버튼을 설명하는 툴팁도 필요 없죠. 그저 사용자가 예상한 방식대로 즉각 작동할 뿐입니다.

불편한 진실은 이렇습니다. 사용자는 별도의 지침 없이도 무엇을 해야 할지 알아야 합니다. 만약 인터페이스를 설명하기 위해 문서를 작성하고 있다면 당신은 엉뚱한 문제를 해결하려 애쓰는 중입니다. 진짜 문제는 당신이 사용자가 아닌 '당신 자신'을 위해 디자인하고 있다는 점입니다.

대부분의 디자이너가 이 함정에 빠지곤 합니다. 몇 주 동안 기능을 만들다 보면 본인은 그것이 어떻게 작동하는지 속속들이 알게 되고, 모든 버튼이 당연하게 느껴지기 때문입니다.

하지만 사용자는 앱을 열자마자 10초도 안 되어 혼란에 빠집니다.

왜 이런 일이 벌어질까요? 당신은 기능을 안팎으로 완벽히 꿰고 있지만,

사용자는 그렇지 않기 때문입니다.

그들은 기능을 처음 접할뿐더러 아마 다른 일을 하는 와중에 접속했을 것이고, 당신이 공들여 만든 온보딩 플로우는 당연히 읽지 않을 겁니다.

'직관적인 UI 디자인'에서 '직관적'이라는 말은 도움 없이도 UI의 동작 방식을 이해할 수 있다는 뜻입니다.

만약 인터페이스에 설명이 필요하다면 그건 직관적인 게 아닙니다. 그게 전부입니다.

무엇이 인터페이스를 직관적이게 만드는가.

좋은 UI는 사용자가 이미 알고 있는 패턴을 따릅니다. 사용자를 가르치려 들지 마세요. 그저 그들의 기대치를 충족시켜 주면 됩니다.

휴지통 아이콘은 삭제를 의미합니다. 이를 설명하기 위해 툴팁을 붙일 필요는 없습니다. 휴지통처럼 생겼고, 보통 삭제 버튼이 있어야 할 위치에 있으며 마우스를 올리면 '삭제'라고 뜨기 때문입니다.

'+' 버튼은 무언가를 추가할 때 씁니다. 할 일을 추가하든, 파일을 만들든, 새 프로젝트를 시작하든 사용자는 '+'가 무엇을 뜻하는지 이미 알고 있습니다.

밑줄이 그어진 파란색 텍스트는 링크입니다. 이 패턴은 너무나 뿌리 깊게 박혀 있어서 파란색 밑줄이 그어진 요소가 클릭 되지 않는다면 사용자는 큰 좌절감을 느낄 것입니다.

이것들은 우연히 만들어진 것이 아닙니다. 익숙한 패턴을 활용해 학습 곡선을 낮추는 일종의 '약속'입니다.

설명이 필요 없는 디자인은 다음과 같은 특징을 갖습니다.

버튼답게 생긴 버튼 (돌출된 형태, 테두리 또는 그림자 활용)

기능과 일치하는 아이콘 (삭제는 휴지통, 편집은 연필)

사용자가 예상하는 위치에 배치된 액션 (우측 상단 '저장', 좌측 하단 '취소')

명확한 시각적 위계 (가장 중요한 액션을 가장 크고 진하게 표현)

옵션, 액션, 흐름을 직관적으로 인지하게 만드는 어포던스

사용자가 고민할 필요조차 없어야 할 다섯 가지.

사용자가 인터페이스를 열었을 때, 다음의 질문들에 대해서는 별도의 생각이나 읽기, 추측 없이 즉각적으로 답을 얻을 수 있어야 합니다.

1. 나는 지금 어디에 있는가?

사용자는 현재 자신이 어떤 화면에 있는지, 그리고 어떤 경로로 여기까지 왔는지 알아야 합니다.

나쁜 예: '대시보드'와 같은 일반적이고 모호한 페이지 타이틀

좋은 예: '분석 대시보드 > 월간 리포트 > 2025년 12월'.

브레드크럼, 명확한 헤딩, 하이라이트된 내비게이션 아이템 등은 이 질문에 소리 없이 답해주는 훌륭한 장치입니다.

2. 여기서 무엇을 할 수 있는가?

수행 가능한 액션은 한눈에 봐도 명확해야 합니다.

나쁜 예: 이해하기 어려운 라벨이 붙은 똑같이 생긴 회색 박스들의 나열

좋은 예: '새 프로젝트', '파일 가져오기', '아카이브 보기'처럼 아이콘과 함께 명확한 라벨이 붙은 버튼.

만약 사용자가 기능을 파악하기 위해 모든 요소에 마우스를 호버해야 한다면 당신이 붙인 라벨은 잘못된 것입니다.

3. 핵심 과업을 어떻게 수행하는가?

주요 액션은 결코 놓칠 수 없게 디자인되어야 합니다.

나쁜 예: 한 줄에 똑같은 크기로 배치된 다섯 개의 버튼

좋은 예: 메인 액션에는 크고 색이 채워진 버튼을, 보조 액션에는 작은 아웃라인 버튼을 사용.

플랫폼에서 사용자가 취하게 될 가장 중요한 행동이 무엇인지 파악하고 그것이 눈에 띄게 표시되도록 하세요.

4. 이걸 클릭하면 무슨 일이 벌어지는가?

사용자가 클릭 후의 결과를 두려워하게 해서는 안 됩니다. 버튼은 수행할 동작을 명확히 명시해야 합니다.

나쁜 예: '제출', '진행', '계속'

좋은 예: '계정 생성', '프로젝트 삭제', '리포트 다운로드'. 구체적이어야 합니다.

'제출'은 사용자에게 아무것도 알려주지 못합니다. '계정 생성'은 클릭 시 어떤 일이 벌어질지 정확히 알려줍니다.

5. 실수했다면 되돌릴 수 있는가?

데이터가 손실될 수 있는 '파괴적 액션'은 더욱 명확한 안내와 확인 과정이 필요합니다.

나쁜 예: 경고 없는 단일 '삭제' 버튼

좋은 예: '프로젝트 삭제' 클릭 시 → 다이얼로그 노출: "[프로젝트명]을 삭제하시겠습니까? 이 작업은 되돌릴 수 없습니다." → [취소] [네, 삭제합니다].

사용자가 실수로 자신의 작업물을 날려버리지 않을 것이라는 확신을 주어야 합니다.

이러한 '목발'들에 의존하는 것을 멈추세요.

만약 여러분의 인터페이스가 다음에 열거된 요소들에 의존하고 있다면 그것은 직관적인 디자인이라고 볼 수 없습니다.

도처에 깔린 툴팁. 고급 기능을 위해 한두 개의 툴팁을 사용하는 것까지는 괜찮습니다. 하지만 모든 버튼마다 툴팁이 달려 있다면, 그것은 여러분이 붙인 라벨이 엉망이라는 증거입니다.

온보딩 투어. 앱을 사용하기도 전에 다섯 페이지 분량의 튜토리얼을 읽어야 한다면 그 UI는 너무 복잡한 것입니다. 온보딩을 고민하기 전에 먼저 디자인부터 단순화하세요.

기본 기능을 설명하는 도움말 문서. '파일 저장하는 법' 같은 내용이 문서에 포함되어서는 안 됩니다. 만약 사용자가 핵심 과업을 수행하기 위해 문서를 뒤져봐야 한다면 그 과업의 프로세스 자체를 다시 설계해야 합니다.

입력 가이드로 사용하는 플레이스홀더. 플레이스홀더 텍스트는 입력을 시작하는 순간 사라져 버립니다. 안내 문구는 입력 필드 외부에 별도의 라벨로 제공하세요.

모든 필드 옆에 붙은 '?' 도움말 아이콘. 모든 입력 항목에 설명이 필요하다면 필드 라벨 자체가 불충분하다는 뜻입니다. 이러한 장치들은 해결책이 아닙니다. 그저 잘못된 디자인을 가리기 위한 '반창고'일 뿐입니다.

내 UI가 얼마나 직관적인지 테스트하는 법.

여러분의 인터페이스를 한 번도 본 적 없는 사람을 한 명 섭외하세요. 어떠한 배경 설명도 하지 마세요. 그저 "이 서비스로 [핵심 과업]을 해보세요"라고만 말하면 됩니다.

그리고 어떤 일이 벌어지는지 관찰하세요.

그들이 어디를 클릭해야 할지 즉각적으로 아나요?

힌트를 찾기 위해 여기저기 마우스를 올려보나요?

엉뚱한 버튼을 먼저 클릭하지는 않나요?

당신에게 질문을 던지나요? 혹은 포기해 버리나요?

실제 사용자로부터 얻은 데이터는 직관적인 인터페이스를 설계하는 데 결정적인 열쇠가 됩니다.

만약 사용자가 헤맨다면 그 인터페이스는 직관적이지 않은 것입니다. 기억하세요. 툴팁을 추가한다고 해결될 문제가 아닙니다. 혼란을 주는 그 부분 자체를 다시 디자인해야만 해결됩니다.

'10초의 법칙':

사용자는 인터페이스를 처음 본 순간부터 10초 이내에 핵심 과업을 완료할 수 있어야 합니다. 그보다 오래 걸린다면, 설계 어딘가에 분명히 문제가 있는 것입니다.

실제 사례: 비포 & 애프터.

사례 1: 폼 제출.

변경 전: 버튼 라벨 '제출' (모호하며, 클릭 후 어떤 일이 벌어질지 알 수 없음)

변경 후: 버튼 라벨 '계정 생성' (명확하며, 구체적인 결과를 알려줌)

사례 2: 파일 액션.

변경 전: 옵션들이 숨겨진 '더 보기(점 세 개)' 메뉴

변경 후: 아이콘과 함께 노출된 '이름 변경', '다운로드', '삭제' 버튼

사례 3: 설정 토글.

변경 전: '고급 모드 활성화'라는 라벨이 붙은 체크박스 (사용자는 이것이 무엇을 뜻하는지 알 수 없음)

변경 후: '개발자 도구 표시'라는 라벨이 붙은 토글 (수행하는 기능이 명확함)

사례 4: 내비게이션.

변경 전: 모든 옵션을 숨겨놓은 햄버거 메뉴

변경 후: 가장 중요한 4~5개 메뉴가 노출된 탭 바. 핵심 패턴은 이것입니다. 명시적이고, 눈에 보이며, 명확해야 한다는 것.

모든 문제를 해결하는 하나의 질문

UI 요소를 추가하기 전 스스로에게 물어보세요. "처음 사용하는 사용자가 이것이 무엇인지, 그리고 어떻게 쓰는지 바로 이해할 수 있는가?"

만약 대답이 "아마도요"라거나 "툴팁을 읽어보면 알 거예요"라면 다시 디자인하세요. 대답이 "네, 즉시 알 수 있습니다"라면, 설계는 끝난 것입니다.

인터페이스는 사용자가 상호작용 방식을 고민하지 않을 때 비로소 직관적이라고 할 수 있습니다. 이것이 바로 우리가 지향해야 할 기준점입니다. "온보딩을 거치면 직관적인" 것이나 "도움말 아이콘이 있으면 직관적인" 것이 아닙니다. 아무런 설명 없이도, 그 즉시 직관적이어야 합니다.