▲

내 컨트롤을 숨기지 마세요: 숨겨진 인터페이스 컨트롤이 사용성에 영향을 미침

 (interactions.acm.org)
1P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • 숨겨진 컨트롤로 인해 사용자 인터페이스의 사용성이 저하됨
  • 과거에는 화면에 드러난 메뉴가 사용성을 크게 개선하는 전환점 역할을 수행함
  • 최근 모바일 및 각종 기기에서 다시 기억 기반 조작이 요구되는 방향으로 회귀 현상 발생함
  • 인터페이스 디자인 복잡성과 미적인 요소가 숨겨진 컨트롤 증가의 핵심 원인임
  • 디자이너는 이제 모든 주요 기능을 드러내어 사용자가 탐색 가능하도록 구조를 재고해야 할 필요성 대두됨

서론: 지식의 위치와 인터페이스

  • 1960년대 Douglas Engelbart가 ‘지식이 세상에 있는가, 머릿속에 있는가’ 라는 개념을 제시함
  • ‘지식 in the world’ 란 조작 컨트롤이 인터페이스에 드러나 사용자는 기억 없이 직접 찾고 사용할 수 있음을 의미함
    • 예시: 드롭다운 메뉴가 있는 그래픽 인터페이스
  • ‘지식 in the head’ 란 사용자가 모든 컨트롤 및 명령어를 외워야 하는 환경을 뜻함
    • 예시: DOS 명령 프롬프트에서는 명령어(DIR 등)를 모르면 아무 동작도 할 수 없음

숨겨진 컨트롤이 늘어나는 이유와 역효과

  • 인터페이스의 복잡성이 증가할수록 더 많은 컨트롤이 시각적으로 숨겨지고 있음
  • 겉보기에는 더 간결해 보일 수 있으나, 초보 사용자 입장에서는 조작이 훨씬 더 어려워짐
  • 초창기 드롭다운 메뉴 등 ‘보이는 컨트롤’이 등장하며 컴퓨터 대중화와 생산성을 획기적으로 높임
  • 하지만 모바일 기기와 신형 전자기기에서 다시 ‘기억 지도 기반’ 조작이 요구되는 상황이 확대되고 있음
    • 예시: 아이폰의 플래시 조명, 알림 보기, Apple Pay 실행 등의 경우 적절한 ‘힌트’ 없이 숨겨진 동작이나 특정 제스처를 숙지해야만 접근 가능함

일상 속 숨겨진 컨트롤 사례

  • 자동차 무선 키, 문 손잡이 등에도 숨겨진 컨트롤이 존재하여, 사용법을 알지 못하면 기본적인 접근조차 어려움
    • 예: 내부 키 위치나 감춰진 키홀, 특정 버튼 시퀀스 등
  • 차량 내비게이션 시스템(Apple Maps on CarPlay 등) 역시 지도를 넓게 보여주기 위해 필수 컨트롤을 숨기는 경향이 있어, 특정 영역 터치를 반드시 알아야 기능 사용 가능
  • 시간 기반 컨트롤도 숨은 형태의 컨트롤로 작동
    • 예: 컴퓨터 전원 버튼은 길게 누를 때만 정상 종료, 전자 도어락의 잠금은 별도의 키나 오래 누르기 등 특별한 조작법 필요

숨겨진 컨트롤로 인한 일반적 문제 및 전문 사용자 영향

  • 볼륨을 0으로 해도 앱이 임의로 소리를 내는 등, ‘숨은 설정’ 으로 인해 사용자의 직접적 명령을 덮어쓰는 현상 발생
  • 고급 사용자도 명령형 인터페이스(예: R, DOS 창 등)에선 심각한 ‘지식 in the head’ 의존성을 경험
  • 점차 원시적 인터페이스로 회귀하는 경향

왜 숨겨진 컨트롤이 늘어나는가

  • 기능이 지나치게 많아 화면에 전부 표시 불가해 가시성 저하
  • 시스템 모드 간 상호작용, 복잡도 증가, 디자이너의 미적 또는 구현 편의 추구 등으로 컨트롤 은닉화가 빈번해짐
  • 실제로는, 사용자 배려보다는 디자인 목적(미적 완성도 등)이 우선되어 발생함

성공적인 사례와 미션 크리티컬 시스템의 차이

  • General Motors 내비게이션 등 일부 시스템은 모든 필요한 컨트롤을 항상 화면에 잘 드러내, 초보자도 탐색이 쉬움
    • 예: Buick LaCrosse의 물리적 다이얼을 통한 줌 기능 등
  • 미션 크리티컬 시스템(항공기, 공장 등)에서는 거의 반드시 영구히 보이는 컨트롤 중심으로 설계함
    • 누구도 숨겨진 컨트롤로 빠른 조작이 저해되는 위험을 감수하지 않음

숨겨진 인터페이스 옹호와 그 한계

  • ‘숨겨진 컨트롤’은 세대 간 불평의 문제가 아니라 실질적 사용성 문제임
  • 일부에서는 ‘숨은 기능’ 탐색 자체를 장점으로 홍보하지만, 실상은 접근성 하락이 명확함
  • 사용자 입장에서 찾을 수 없는 컨트롤은 존재하지 않는 것과 같음

유비쿼터스 컴퓨팅과 컨트롤의 자동/투명화

  • Mark Weiser와 Donald Norman은 기술이 ‘투명하게’ 배경으로 물러나 작동하는 미래를 예견함
    • 예: 자동차 엔진 제어는 사용자가 조작할 필요 없도록 완전히 백그라운드에서 자동 조정
  • 자동화로 인해 컨트롤이 완전히 숨겨지는 사례는 필요성과 맥락이 명확함
    • 하지만 사용자 조작이 필요한 상황에서는 반드시 명시적 컨트롤이 필요

결론 및 인터페이스 디자이너의 방향성

  • 인터페이스 디자이너는 숨겨진 컨트롤 사용을 지양하고, 모든 기능을 ‘세계에 드러난 지식’ 기반으로 전환해야 함
  • 컨트롤 발견성(discoverability) 은 여전히 핵심 설계 원칙임
  • 현대적 인터페이스에서 발견성 저하는 오히려 초기 컴퓨터 시절로의 퇴보 현상임

참고문헌

  • Engelbart, D.C. (1962) 등 핵심 문헌 정리
  • Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer 등 관련 서적과 논문 인용

저자 정보

  • Philip Kortum: Rice University 심리 과학과 교수, 사용성과 신뢰평가, 글로벌 헬스 및 모바일 시스템 등 다양한 분야에서 사용성 중심 시스템 개발 연구 수행
▲
GN⁺ 15시간전  [-]
Hacker News 의견
  • 최근 스크롤바를 숨기는 디자인에서 불편함을 느끼는 사용자 경험 공유, 기사 내용 중 일부 직관적인 피지컬 노브 사례엔 비용-실용성 한계가 있다는 점 언급, 토글 스위치의 라벨이 현재 상태가 아닌 전환될 상태를 의미한 경험에서 혼란을 느낌
    • 실제 토글 스위치도 애매모호해서 싫은 입장, 체크박스나 눌러진 버튼이 훨씬 명확하지만 현대화 흐름에서 희생된 점 아쉬움
    • 오스트리아 기차 표 자판기에서 즉시 검증 토글 스위치가 혼란을 줬던 기억, 스크롤바도 너무 얇아서 FPS 게임 실력까지 필요할 지경이며, 수평 스크롤바가 더 편리할 때도 있음, Firefox와 CSS 표준에 일침
    • macOS에서는 시스템 설정이나 터미널 명령으로 항상 스크롤바 표시 가능성 안내
    • 토글이 동작을 의미한다면 반드시 동사("TURN ON")를 써야 확실함, 상태를 보여주는 것도 "IS ON"처럼 명확한 방식 제안, 문맥상 혼동될 만한 극히 일부 경우만 빼고는 동사를 쓰면 거의 확실해진다고 생각함
    • PgUp과 PgDn 지원도 부탁
  • 오래된 Toyota를 운전 중이며, 모든 컨트롤이 항상 눈에 띄고, 명확하게 라벨링 되어 있고, 손끝으로 구분 가능함, 이는 복제 자체도 쉽고 최소한의 엔지니어링이라고 보지만 현재 자동차 업체 대부분은 이조차 하지 못한다고 판단, 그들의 실력이 부족하다고 평가
    • 동의하는 부분 있지만, "모든 컨트롤이 보여야 한다"고 주장하는 건 디자이너를 과소평가하는 시각임, 실질적으로는 운전 중 반드시 필요한 컨트롤만 노출되고 나머지는 작고 복잡하거나 숨겨져 있음, 좌석 높이 조절 레버, 보닛 오픈 레버 등은 숨겨져 있으나 접근성 확보, 다양한 디테일을 고려한 디자인 과정이 단순하지도, trivial하지도 않다는 입장, 이런 부분을 단순하게 치부하는 것이 오히려 현재 UX 나빠지는 이유
    • 이는 실력 문제가 아니라 비용 문제라는 시각, 요즘은 많은 버튼과 노브를 따로 만들고 조립하는 것보다 터치스크린이 저렴하고 제작이 쉬움
    • 미국 자동차 제조사가 시스템 개발자로 채용 제안을 대거 보내왔지만 Hacker News 커뮤니티에선 “정신 건강을 지키고 싶으면 피하라”는 의견이 많았던 경험 공유
    • 개인적으로도 노브 등 기계식 파츠를 다르게 만들면 커스텀 몰드 등 제조비용이 증가한다고 설명, 화면에 넣는 게 비용상 훨씬 효율적임
  • 화면 공간 효율을 위해 UI 요소를 숨기는 건 이해하지만, 쓴 공간을 비워두고 숨기는 것은 납득 불가, IntelliJ에서 프로젝트 트리 위에 아이콘이 숨겨져 있다가 마우스를 갖다대야 나오는데, 이걸 굳이 그렇게 만들 필요가 있었는지 의문
    • 모바일, 데스크톱, 노트북 화면이 그 어느 때보다 커진 상황에서 화면 요소를 가리게 만드는 근거에 의문, 1984년 매킨토시 소형 흑백 화면도 명확성, 가시성 위해 화면 비율을 희생해서라도 버튼을 배치했다는 점 회상
    • 일부는 시각적 "잡음"이 집중력 해친다고 불평하고, 다른 일부는 계기판처럼 모든 컨트롤과 표시등을 항상 보이길 원함, IDE 기본 설정은 이런 극단의 취향을 모두 만족시키려 균형을 잡는 절충안임, 사실상 타협이며, 일부 툴은 "no distractions mode" 같은 모드로 세부 설정을 제공함
    • Intellij Windows 버전 메뉴도 햄버거 아이콘 속에 숨어서 빈 공간이 많아지는 문제, 다행히 설정에서 복구 가능하지만 기본값이 이해 불가
    • 버튼의 존재를 알고, 어떻게 나타나는지도 기억하는데도 가끔 어디 있었는지 까먹고 멍하니 화면만 볼 때 있음
    • 일부 앱은 오히려 추가 버튼을 숨기지 않고, 오히려 숨기는 옵션이 있었으면 원하는 마음, Google Maps 언급
  • 자동차 스마트 키 사용 중 실제 열쇠가 숨어 있고, 심지어 차 문 손잡이 분해까지 해야 키 구멍이 나오는 등, 중요한 컨트롤을 숨기는 건 사용자에게 매우 불친절한 엔지니어링이라고 지적
    • 자신도 렌트카에서 비슷한 상황 경험, 원격키가 고장나서 모든 짐이 차에 갇혔던 일이 있었음, 신체적 키가 존재한다는 건 알았지만 문고리 주변이 이전 사용자가 열려고 긁힌 흔적으로 가득 찼던 것에서 바로 키홀 위치를 알아낼 수 있었음
    • 이러한 상황은 유저가 기본적으로 알고 있어야 하며, 구글 등에서 정보를 찾을 수 있다는 주장, 신형 자동차를 받고 바로 백업 옵션과 동작 방식을 확인했던 실례 제시, 소유한 제품에 대한 기본 파악 중요성을 강조
  • iPhone에서 홈버튼이 사라지고, Android로 넘어간 이유 중 하나가 가족 내 고령층 설명 및 사용이 더 어려워졌기 때문, 새 Pixel 폰 구입 시 3버튼 내비게이션부터 활성화하지만, 요즘 앱들은 바텀 내비게이션바만 가정하고 3버튼에 덮여 내용이 가려지는 등 UI 단점 지적
    • 핵심 UI 요소는 반드시 눈에 보여야 한다는 주장, Apple도 이 원칙을 가끔 위반한다고 보지만 대부분은 저항하는 편이라고 평가, 홈버튼 삭제는 UI요소를 숨겼다기보단 상호작용의 변환으로 해석, 직관성·우수성 논란은 있을 수 있으나 적응이 되면 사용에 마찰이 거의 없다는 점 언급, iOS엔 스크린에 드래그할 수 있는 작은 원형 단축키(텍스트 라벨 포함)를 두는 접근성 기능 안내
    • 일반 소프트웨어의 소리 없이 사라지는 메뉴 아이템 현상도 유사, 예로 MS Word에서 읽기 전용 파일 저장 기능 아이콘이 아예 사라진 점, 차라리 비활성화로 두고 저장 시 원인 알림 후 해결 방법 안내가 더 나은 경험일 것이라는 제안
    • Android 장기 사용자인데 종종 iPhone 빌릴 때마다 비직관적이거나 없는 상호작용으로 답답함, Pixel·Samsung 카메라 품질도 좋아져서 Apple 생태계로 넘어갈 이유 없음
  • 기사에서 UI가 사라지는 것이 우연이나 실수가 아니라, 사용자 락인을 위한 현상이라는 점이 제대로 다뤄지지 않았다는 의견, saturated(성장 한계치) Point에 도달한 소프트웨어에서 기존 사용자 떠나는 걸 막기 위해 직관적이지 않은 방식으로 UI를 바꾼다고 해석, 기기를 "사용"하는 대상 아닌 "내재화"된 존재로 만들어 이탈 장벽 생성, UI 습득 과정에서 새 제품 전환 공포 유도, 대다수 주요 소프트웨어 기업이 이 방식을 취하는 이유 설명
    • 이런 가설은 단편적으로만 보면 맞을 수도 있지만, 실제로는 "복잡하고 붐비는 인터페이스"에 대한 반발도 많음, 미니멀리즘 트렌드와 /r/unixporn 등 다양한 사용층이 자체적으로 컨트롤을 숨기는 경향도 큼, GNOME 등도 최근 미니멀 인터페이스가 대세, 많은 사용자는 필요할 때만 기능을 찾아 쓸 줄도 알기 때문에 선택적이라고 해석
    • 이 방법은 양날의 검이라 낯선 사용자 유입엔 저해가 됨, Apple의 모든 인터페이스가 한 버튼에 집중된 점이 싫어서 Android가 더 익숙한 사례 공유, Apple에 대한 여러 불호는 별도 이유로도 존재
    • 비영리 OSS에서도 무비판적 트렌드 따라 한다고 보임, Firefox의 자주 반복되는 디자인 변화, GNOME 등도 같은 맥락
  • "아티스트" 타입 디자이너가 UI 결정권을 쥐면 깔끔함에 집착해 직관적 사용법(affordance)과 학습 기회를 무시, 에어플레인 콕핏(비전문가에겐 압도적이나 전문가에겐 모든 게 라벨링)이 대표적 대비 사례
    • 일반 가정 수도꼭지에도 방향 라벨 달릴 필요는 없다는 반박, 비행기 콕핏은 초보에겐 오히려 과도하게 압도적임을 예시, 인터페이스 디자이너는 무엇이 직관적인지 잘 알고 복잡한 기능도 단순한 폼팩터에 잘 압축하는 능력 보유, 디자인 교육 없는 사람이 더 나은 결과를 낼 수 있다고 생각하는 건 자만과 무시에 불과, 실제로 많은 사용자가 훈련 없이도 현대 스마트폰을 능숙하게 잘 사용하는 것은 훌륭한 성과라는 점 강조
  • Hacker News 관련 데스크탑 소프트웨어 rant 및 현황 질문
  • 자사 UI 설계 원칙 중 하나가 키보드 단축키, 컨텍스트 메뉴는 반드시 명확히 드러난 버튼이나 메뉴로 접근 가능해야 한다는 것, 다소 올드패션한 방식이지만 중요성 강조, 화면 네 모퉁이는 마우스가 빠르게 이동 가능해서 UI상 핵심 부위, Windows 11에서 시작 메뉴를 중앙으로 옮긴 것은 사용자 불편의 예시로 듦, 모바일이 아닌 터치 우선 정책일지도 모름
  • 접근성 및 UI의 직관성 저하가 장애인·고령층에게 크게 영향을 미친다고 강조, 터치와 제스처가 대세가 되었지만 초기 모바일 UI가 오히려 더 접근성이 좋았던 점 지적, 과도하게 미니멀하고 플랫해진 경향이 본질적 요인, palm, compaq pilot, 아이팟, 초기 아이폰 UI 체계를 긍정적으로 회상, 이후로는 오히려 퇴보라고 평가
    • 이에 반해 HN 댓글을 폰으로 볼 때처럼, 여러 UI 컨트롤이 숨겨져 실제 컨텐츠에 집중 가능한 게 더 아름답고 쾌적하다는 생각도 있음, palm pilot 시절엔 버튼과 컨트롤이 화면 절반을 차지해 오히려 컨텐츠 영역이 줄었다고 지적, 숨겨진 컨트롤은 반드시 나쁜 게 아니고, 한 번 습득하면 전문가에겐 강력한 도구임을 긍정, 사용자에게 UI 학습을 요구하는 건 어느 정도 불가피하고, 내 코드에디터/ git 등 고기능 툴은 단순화와 힘 사이의 트레이드오프, 다만 최근 지나치게 앱마다 독자 컨트롤 커스텀으로 UI 학습 전이성이 떨어지는 건 문제, palm pilot 플랫폼처럼 한번 배우면 모든 앱이 동일하게 쓸 수 있는 구조가 이상적임
답변달기