컨트롤을 숨기지 마세요: 숨겨진 인터페이스 컨트롤이 사용성을 해침

• 기능이 늘어난 현대 인터페이스가 조작 요소를 화면 밖으로 숨기면서, 사용자는 보이는 단서를 인식하기보다 사용법을 외워야 하는 knowledge in the head 상태로 되돌아가고 있음
• 드롭다운 메뉴는 가능한 행동을 탐색하게 해 knowledge in the world를 제공했지만, 스마트폰·자동차·가전은 스와이프, 길게 누르기, 버튼 조합처럼 보이지 않는 조작에 자주 의존함
• iPhone 손전등·알림·Apple Pay, 자동차 키 fob, CarPlay의 Apple Maps, 전자 도어락, 앱 알림음, R의 빈 화면은 숨겨진 컨트롤이 실제 사용성을 어떻게 떨어뜨리는지 보여줌
• 이 문제는 초보자만의 문제가 아니며, 통계 소프트웨어처럼 전문 사용자가 쓰는 도구도 메뉴 기반 시스템에서 명령줄 중심 도구로 이동하면 접근성이 낮아질 수 있음
• 설계자는 미적 단순화나 화면 공간 절약만으로 컨트롤을 숨기지 말고, 자동화가 어려운 기능에는 발견 가능성과 지속적으로 보이는 조작 요소를 우선해야 함

---

보이는 컨트롤과 기억해야 하는 컨트롤

• Douglas Engelbart는 1960년대 초 컴퓨터 인터페이스에서 knowledge in the world와 knowledge in the head 개념을 제시했고, Donald Norman은 이를 The Psychology of Everyday Things에서 정식화하고 대중화함
• knowledge in the world는 필요한 컨트롤이 보이고, 사용자가 기억이 아니라 인식으로 식별하고 조작할 수 있는 상태임
  • 현대 그래픽 인터페이스의 드롭다운 메뉴는 명령어나 위치를 외우지 않아도 메뉴 구조를 탐색해 원하는 조작을 찾게 해줌
• knowledge in the head는 특정 장치를 쓰기 위해 명령과 조작법을 사용자가 기억해야 하는 상태임
  • DOS 기반 시스템에서 파일 목록을 보려면 DIR 명령을 알아야 했고, 다른 시스템에서는 명령이 달라질 수 있었음
  • 이런 시스템은 필요한 지식을 거의 전부 머릿속에 갖고 있어야 하므로 숨겨진 컨트롤의 극단적인 형태에 가까움

드롭다운 메뉴가 바꾼 접근성

• HCI 전문가들은 과도한 knowledge in the head 요구가 비전문 사용자의 시스템 접근을 막는다는 점을 빠르게 인식함
• 드롭다운 메뉴는 지식을 화면에 배치해, 사용자가 가능한 행동을 확인한 뒤 필요한 기능을 선택할 수 있게 함
• 이 변화는 세부 명령 훈련 없이도 다양한 컴퓨터 작업을 효과적이고 효율적으로 수행하게 만들었고, 컴퓨터 채택을 가속하는 데 기여함

스마트폰과 자동차에서 되살아난 숨겨진 조작

• 최근 40년 사이 컴퓨터의 형태가 크게 바뀌었고, 데스크톱은 여전히 1980년대식 보이는 컨트롤 모델을 따르는 경우가 많지만 스마트폰은 다시 기억 기반 조작을 요구함
• iPhone 손전등은 제어 패널을 열기 위해 왼쪽 아래에서 위로 스와이프해야 하지만, 인터페이스 자체에는 이 행동이 가능하다는 표시가 없음
  • 알림을 보려면 위쪽 모서리에서 아래로 스와이프해야 함
  • Apple Pay는 라벨 없는 다기능 버튼을 두 번 눌러야 함
  • 단순한 작업도 숨겨진 컨트롤 수가 늘어나면 어려워짐
• 자동차 잠금 해제 사례에서는 key fob 버튼과 문손잡이 버튼이 작동하지 않을 때 모든 해결책이 숨겨져 있었음
  • fob 안에 숨겨진 물리 키가 있다는 사실을 알아야 함
  • 자동차 문손잡이 일부를 분해해야 열쇠구멍이 드러난다는 사실도 알아야 함
  • 차량은 no remote unlock 모드에 들어가 있었고, 깜박이의 특정 점멸 패턴만 단서로 제공됨
  • 해결하려면 key fob의 난해한 버튼 입력 순서로 차량을 올바른 모드로 되돌려야 했음
  • 문제를 알리는 숨겨진 코드와 기계적·컴퓨터적 해결책이 모두 보이지 않아 약 30분 동안 차에 들어가지 못함

차량 내 그래픽 인터페이스와 시간 기반 컨트롤

• CarPlay의 Apple Maps는 지도를 최대한 크게 보여주려는 설계 때문에 검색과 확대·축소 컨트롤을 기본 화면에서 숨김
  • 목적지를 입력하거나 지도를 확대하려면 화면 왼쪽 아래를 터치해야 하고, 그때 검색과 확대·축소 아이콘이 나타남
• 시간 기반 컨트롤도 흔한 숨겨진 조작 형태임
  • 컴퓨터 전원 버튼은 라벨이 있어도 단순히 누르는 것만으로 원하는 동작이 일어나지 않을 수 있고, 특정 시간 동안 길게 눌러야 함
  • 사전 훈련이나 지식이 없으면 조작 방식 자체가 숨겨짐
• 전자 도어락은 숨겨진 컨트롤과 시간 기반 컨트롤이 결합된 사례임
  • 잠금 해제는 큰 중앙 버튼이 손가락을 올리라는 어포던스를 제공함
  • 잠금은 # 키가 숨겨진 컨트롤이며, 단순 누르기가 아니라 5초 동안 눌러야 활성화됨
  • 긴 시간 조건과 숨겨진 컨트롤이 겹치면 시스템을 잘 아는 사용자가 아니면 잠그기 어려움

사용자의 명령을 우회하는 숨겨진 제어

• 스테레오 볼륨을 0으로 낮추면 사용자는 다시 올리기 전까지 소리가 나지 않을 것이라고 기대함
• iPhone에서는 볼륨을 완전히 낮추거나 무음 스위치를 켜도 앱이 숨겨진 제어를 통해 소리를 낼 수 있음
  • 예로 인터넷 연결 고양이 화장실이 자정에 청소 완료를 알리거나, Instagram이 오전 3시 30분에 자녀가 영상을 올렸다고 알릴 수 있음
• 이런 동작은 사용자가 내린 단순한 침묵 명령을 앱이 우회하는 형태로 나타남

전문 사용자도 피하기 어려운 빈 화면

• 숨겨진 인터페이스 문제는 초보자에게만 영향을 주지 않음
• 통계 분석 소프트웨어에서는 많은 전문 연구 인력이 SPSS 같은 메뉴 기반 시스템에서 R 같은 라인 편집 프로그램으로 이동해야 하는 상황이 있음
• 기본 형태의 R은 DOS 창처럼 빈 화면의 압박이 큰 인터페이스이며, 가장 단순한 작업에도 통계 지식 외의 상당한 사용 지식을 요구함

숨겨진 컨트롤이 늘어난 이유

• Donald Norman은 35년 전쯤 가시성, 이후 발견 가능성으로 불린 원칙을 기본 설계 원칙 중 하나로 제시함
  • 사용자는 컨트롤과 메뉴를 체계적으로 탐색해 시스템이 무엇을 할 수 있는지 판단할 수 있어야 함
• 현대 기기에 너무 많은 기능이 들어가면서 모든 컨트롤을 화면에 보이게 배치할 공간이 부족해짐
• 시스템의 복잡성과 사용자가 알지 못하거나 오해하는 상호의존성도 컨트롤이 숨겨진 것처럼 느껴지게 만듦
  • 어떤 모드에서는 컨트롤이 보이고, 다른 모드에서는 보이지 않을 수 있음
  • 사용자가 이 의존성을 이해하지 못하면 컨트롤이 숨겨진 것처럼 느껴짐
• 기존 컨트롤에 여러 기능을 덧씌우거나, 화면의 표시 없는 위치를 탭하게 만드는 방식은 보이고 지속적인 버튼을 설계하는 것보다 쉬움
• 컴퓨터 전원 버튼은 우발적 종료를 막는 목적을 가질 수 있지만, 잘 라벨링된 회전식 컨트롤은 기능과 사용성을 유지하면서 숨겨진 조작을 줄일 수 있음

보이는 컨트롤을 유지한 설계 사례

• General Motors의 지도 인터페이스는 Apple Maps와 달리 필요한 컨트롤을 주 내비게이션 화면에 보이고 지속적으로 배치함
  • 검색과 확대·축소 컨트롤을 숨기지 않으면서 지도 기능성과 사용성을 해치지 않음
  • 초보자에게 더 매끄럽고 쉬운 경험을 제공함
• Buick LaCrosse의 지도 확대·축소는 물리 노브로 구현됐고, 시계 방향으로 확대하고 반시계 방향으로 축소하는 간단한 조작을 제공함
• 임무 중요 시스템 대부분은 숨겨진 컨트롤 대신, 보이고 지속적이며 시스템 상태를 보여주는 컨트롤에 의존함
  • 설계자는 고도로 훈련된 운영자도 특정 행동을 수행하거나 접근하는 방법을 기억하지 않고 빠르게 조작해야 한다는 점을 인식함

사라지는 컴퓨팅과 숨겨진 컨트롤의 차이

• Mark Weiser는 1991년 컴퓨팅이 배경으로 사라져 인간과 거의 상호작용하지 않고 작업을 수행하는 disappearing computing을 제시함
• Donald Norman은 The Invisible Computer에서 기술이 보이지 않고 숨겨져야 한다고 했음
• 자동차 엔진 컴퓨터는 환경 변수와 운전 조건을 계속 측정해 엔진 매개변수를 자동 조정하며, 사용자가 옵션 화면을 보지 않아도 기대한 결과를 제공함
• 그러나 의도적으로 사용자 조작을 숨기는 것은 Norman과 Weiser가 말한 방향과 다름
  • 필요한 순간 컨트롤이 나타나거나, 기능을 자동으로 수행할 수 있으면 컨트롤이 아예 나타나지 않는 방식이어야 함
  • 엔진 컴퓨터는 사용자의 의도, 즉 차가 잘 달리기를 원한다는 점이 비교적 명확함
  • 스마트폰 손전등처럼 사용자가 언제 필요한지 자동으로 판단하기 어려운 기능은 컨트롤이 보이거나 강한 어포던스를 가져야 함

설계자가 다시 확인해야 할 원칙

• 상업용 인터페이스 설계자는 숨겨진 컨트롤 사용을 재검토하고, 기기 기능을 충분히 knowledge in the world만으로 접근할 수 있게 만들어야 함
• 컨트롤 발견 가능성은 여전히 중요한 인터페이스 설계 원칙임
• 새 인터페이스에서 숨겨진 컨트롤이 늘어나는 현상은 기능이 보이지 않아 컴퓨터 사용이 더 어려웠던 시대로 되돌아가는 회귀에 가까움

[GN⁺]

Hacker News 의견들

• 거의 미국 상원의원 출마 연령에 가까운 Toyota를 몰고 있는데, 차 안의 모든 조작부가 항상 보이고, 라벨이 명확하며, 손끝으로도 구분됨
  배터리 교체 같은 일상적인 유지보수 때문에 조작이 막히지도 않음
  이렇게 쉽게 복제 가능한 설계는 최소한의 공학 역량에 가까운데, 자동차 회사들은 이 수준조차 못 맞추는 경우가 많고, 합리적으로 보면 자기 일을 못하는 셈임

  • 공감은 하지만, 그렇게 표현하면 설계자들에게 불공정하다고 봄
    “모든 조작부가 보인다”가 아니라 운전 중 꼭 필요한 조작부가 보이고 접근 가능해야 함
    좌석 높이 조절 레버나 후드 여는 래치처럼 덜 중요한 조작부는 숨겨져 있어도 접근만 가능하면 되고, 인터페이스를 효율적으로 만들기 위해 미묘하고 주관적인 선택이 아주 많음
    이런 설계 과정은 전혀 사소하거나 단순하지 않고, 그걸 대충 넘기는 태도 자체가 자동차 회사들이 이런 고려를 무시하게 된 원인 중 하나라고 봄
  • 역량 문제가 아니라 비용 문제임
    요즘은 작은 버튼과 노브를 잔뜩 제조하고 조립하는 것보다 터치스크린 하나 만드는 편이 더 쉽고 싸다
  • 유럽에서는 Euro NCAP이 5성 안전 등급을 받으려면 물리 조작부 일부를 다시 넣도록 요구하기 시작해서 다행임
    내 차의 끔찍한 터치스크린 UI와 작별해도 전혀 아쉽지 않을 듯함
  • YouTuber이자 엔지니어인 William Osman이 새 전자레인지를 샀더니 버튼이 너무 많다며 한참 불평한 적이 있는데, 전자레인지는 사실 버튼 하나면 충분하고 이상적으로는 버튼보다 다이얼 하나면 된다는 주장이었음
    이전 전자레인지는 부모님이 유학 갈 때 사준 뒤 20년 넘게 썼고, 40대가 될 때까지 작동했지만 다이얼이 헐거워지고 외관이 낡아서 바꿨음
    새로 산 것은 요즘 방식대로 버튼이 잔뜩 달려 있는데, 솔직히 무슨 기능인지도 모르겠고 전원 세기 하나와 시간, 어쩌면 해동 기능 정도면 충분함
  • 80년대에 엔지니어로 커리어를 시작했고 최근 15년 정도 CEO로 일한 아버지와 비슷한 얘기를 나눈 적이 있음
    공학, 품질, 사용성 전반에 대한 더 넓은 얘기였는데, 아버지 관점에서는 회사가 처음엔 엔지니어에 의해 운영되다가 몇십 년 뒤엔 관리자, 그다음엔 마케팅이 운영하게 됐다고 봄
    다음은 뭘지 모르겠지만, 모두가 모든 단계에서 AI에게 물어보다가 의사결정이 우연히 AI에 의해 이뤄지는 “아무것도 없음”일 수도 있고, 지금의 마케팅 주도 세계보다 나을지도 모름

• 앱과 운영체제가 사용자 인터페이스의 행동 유도 단서를 숨기는 건 우연이 아니라고 봄
  사용자를 묶어두기 위한 안티패턴이고, 소프트웨어가 성장 포화점에 도달해 신규 사용자 유입보다 기존 사용자 이탈 방지가 중요해질 때 자주 나타남
  우리가 쓰는 소프트웨어 대부분이 Google, Apple, Microsoft, Meta처럼 바로 그런 위치에 있는 회사들이 만든 것이라는 점도 우연이 아님
  인터페이스를 숨기면 사용자가 떠나기 어렵다는 게 직관에 반할 수 있지만, 기기를 “사용하는” 대상이 아니라 “아는” 대상으로 바꾸기 때문에 효과가 있음
  예측 불가능한 방식으로 모서리에서 스와이프해야 필수 작업이 된다는 걸 익히고 나면, 새 휴대폰으로 옮겨 그걸 다시 배워야 한다는 생각 자체가 두려워짐

  • 가설 하나를 고른 뒤 참이라고 가정하고 밀어붙인 것처럼 보임
    Google, Apple, Microsoft, Meta 제품에 대해 “복잡하고 비대한 인터페이스”라는 불평도 흔하고, 빈 VS Code 화면을 보여주며 무인터페이스에 가까운 Vim 설정보다 복잡하다고 불평하는 사람들도 있음
    플랫 디자인과 미니멀리즘은 한동안 유행했고, /r/unixporn이나 Linux 배포판을 꾸미는 사람들도 미니멀리즘 때문에 앱의 조작부를 숨기는 경우가 많음
    최근 GNOME을 써본 적이 있다면 알겠지만, 조작부 대부분이 숨겨진 최소 인터페이스는 어떤 사람들이 선호하는 특정한 미감이기도 함
    “잡음”을 숨기고 필요할 때 찾아보면 된다고 느끼는 사람도 많고, 매뉴얼을 파야만 하는 것도 아님
  • 양날의 검이기도 함
    사용자가 그 인터페이스를 시도하지 못하게 만들 수 있음
    Apple 인터페이스는 모든 게 그 버튼 하나에서 시작하는 식이라 짜증나고, 설정에 어떻게 들어가는지도 자주 잊어버려서 Android가 더 자연스럽게 느껴짐
    Android는 락인 역할을 해냈지만 Apple은 스스로 손해를 본 셈임
  • 비영리 오픈소스 프로젝트들도 비슷하게 하고 있어서, 별생각 없이 유행만 따라가는 건 아닌지 의문임
    Firefox의 짜증나는 재설계나 GNOME 같은 것들이 여기에 들어감
  • 학습된 마찰을 심리적 락인으로 바꾸는 건 가장 어두운 UX 패턴 중 하나임

• 화면 공간을 다른 용도로 쓰려고 인터페이스 요소를 숨기는 건 이해함
  그런데 어떤 인터페이스는 요소를 숨겨놓고도 그 공간을 비워두는데, 그 이유는 모르겠음
  예를 들어 IntelliJ는 프로젝트 트리 위 아이콘들이 그렇고, 현재 활성 편집기 탭의 파일로 프로젝트 트리 선택을 이동시키는 작은 표적 아이콘이 있음
  화면의 비밀 위치를 알고 마우스를 빈 공간으로 옮겨야 마법처럼 나타남
  왜 굳이 이런 걸 구현하는지 근거가 궁금함

  • 어떤 사람들은 시각적 혼잡을 싫어함
    시야에 자극이 너무 많으면 주의력이 공격받고 집중이 깨진다고 느껴서, 현재 주목 대상이 아닌 것은 사라지거나 최소한 눈에 덜 띄길 원함
    반대로 항공기 조종사 같은 사람들은 모든 표시기가 바로 보이고 모든 조작부가 손 닿는 곳에 있길 좋아하며, 초점을 쉽게 전환할 수 있음
    기본 IDE 설정은 서로 다른 취향 사이에서 균형을 맞춰야 하므로 필연적으로 타협이 되고, 일부 도구는 “방해 금지 모드”, “전문가 모드”처럼 세부 수준을 미리 구성한 스위치를 제공함
  • Windows의 IntelliJ도 상단 메뉴를 햄버거 아이콘 안에 묻어놓고, 원래 메뉴가 있던 영역 전체를 비워둠
    설정 깊숙한 곳에서 되돌리는 옵션이 있긴 하지만, 이게 기본값이라는 건 정말 이해하기 어렵다
  • 화면 공간을 아끼려고 인터페이스 요소를 숨긴다는 말도 요즘은 설득력이 약함
    휴대폰, 태블릿, 노트북, 데스크톱 화면은 그 어느 때보다 커졌음
    1984년 오리지널 Macintosh는 9인치 흑백 저해상도 화면이었고, 당시의 그래픽 인터페이스가 낯설었다는 이유도 있었겠지만 Apple은 극도로 제한된 화면, 연산, 메모리 자원을 희생해서라도 명확성, 가시성, 발견 가능성을 택했음
    화면이 커진 뒤에는 이런 공간 비용이 거의 무시할 수준이 됨
  • 그 버튼들이 있다는 것도, 어떻게 활성화하는지도 아는데도 가끔 멍하니 화면을 보며 버튼이 어디 갔는지 찾다가 마우스를 올려야 한다는 걸 떠올림
  • UI가 그래픽 디자이너에게 장악되고 인간 상호작용 전문가는 밀려났다고 봄
    “사용자 인터페이스” 대신 “사용자 경험”이라고 부르기 시작하면서 도구로서의 역할보다 사용자의 감정 상태를 더 걱정하게 됐고, 기능보다 형태가 앞서게 됨
    이제는 “잘못 잡고 있다”는 걱정까지 해야 하는데, 실제로 기계는 인간을 섬기기 위해 있는 것이지 그 반대가 아님

• 얼마 전 차에서 잠겼는데 키팝 버튼이 작동하지 않았음
  그냥 열쇠를 쓰면 되지 않느냐고 할 수 있지만, 먼저 키팝 안에 숨겨진 열쇠가 있다는 걸 알아야 하고, 차 문에는 열쇠구멍이 보이지 않아서 손잡이 일부를 분해해야 열쇠구멍이 드러난다는 것도 알아야 함
  중요한 자동차 조작부를 숨기는 건 적대적인 공학이고, 현대 자동차 경험 전반에서 그리 튀는 일도 아님

  • 이런 차들은 렌터카로는 끔찍한 선택이지만, 차를 몇천 달러 주고 샀다면 하루 30분 정도는 매뉴얼을 읽었으면 함
    매뉴얼은 라디오 채널 바꾸는 법만 알려주는 게 아니라, 안전 정보와 문제가 생겼을 때 어떻게 해야 하는지도 담고 있음
    배터리가 방전돼도 차를 열 수 있다는 사실조차 모르는 운전자가 안전 최대 적재량 같은 걸 고려하리라 믿기 어렵다
  • 렌터카에서 같은 일을 겪었음
    주차장을 떠나 30분 떨어진 호텔에 도착한 뒤에야 리모컨이 고장난 걸 알았고, 모든 짐은 차 안에 잠겨 있었음
    물리 열쇠가 반드시 있을 거라고는 알았지만, 열쇠구멍을 찾을 수 있었던 건 이전 대여자가 같은 열쇠구멍을 찾으려다 문손잡이를 잔뜩 긁어놨기 때문이었음
  • 이런 건 알아두어야 하는 내용이고, 빠르게 검색해도 쉽게 찾을 수 있음
    물리 키가 없는 차를 받자마자 처음 든 질문은 “백업 옵션은 뭐고 어떻게 작동하나”였음
    자신이 소유한 물건에 대한 기본 지식은 어렵지 않다

• “디자이너”라는 이름의 예술가들이 UI 결정을 장악하면 이런 일이 생김
  이들은 발견 가능성을 희생해서라도 “깔끔하게” 보이길 원하고, 행동 유도 단서가 사람을 학습하게 만든다는 걸 잊음
  비행기 조종석처럼 전문 지식이 필요하고 조작부가 많더라도 모두 라벨이 붙어 있는 사례와 대비됨

  • 데스크톱 운영체제가 왜 이제 모바일식 작업 표시줄 아이콘을 쓰는지 아직도 이해가 안 됨
    필요한 것보다 두 배는 크고, 한데 묶여 있어서 어떤 인스턴스가 무엇인지 보려면 마우스를 올려야 하며, 실제 원하는 창으로 전환하려면 또 클릭해야 함
    썸네일만 보고 알아내야 하는데 모든 터미널 창은 똑같아 보임
    Windows NT부터 Vista까지의 방식, 즉 웹브라우저 탭처럼 아이콘과 라벨을 함께 보여주는 방식이 문맥 전환을 위한 데스크톱 UX의 정점이고, GNOME은 그런 작업 표시줄조차 제대로 렌더링하지 못함
  • 대부분의 사람은 비행기 조종석을 보면 압도됨
    특정 상황에 익숙한 전문가들은 시각적 밀도에 대한 허용치가 훨씬 높은데, 그들에게는 조밀한 것이 아니라 의미 있는 정보이기 때문임
    하지만 대부분의 사람은 대부분의 휴대폰 앱을 그렇게 익숙하게 쓰지 않음
    모바일 설계는 많은 기능을 제공하면서도 사용자가 편안함의 적정선 근처에 머물도록 점진적으로 드러내야 하며, 그래서 어떤 것은 숨기고 어떤 것은 더 깊은 단계에 노출하는 절충이 필요함
    모바일과 운영체제 설계가 행동 유도 단서를 너무 많이 줄였다는 데는 동의하지만, 전문 도구가 아니라면 비행기 조종석은 좋은 지침이 아님
  • “어떤 대가를 치르더라도 깔끔한 미학”을 추구하는 사고방식은 확실히 너무 멀리 갔음
  • 집 수도꼭지에도 돌려야 한다는 라벨과 방향 표시가 없다고 불평할 건가 싶음
    휴대폰은 747이 아니고, 조종사가 아닌 일반인이 비행기 조종석에 들어가면 수많은 조작부에 압도돼 뭐가 뭔지 모름
    인터페이스 디자이너들은 자신들이 뭘 하는지 알고 있고, 무엇이 직관적인지와 아닌지를 알며, 복잡한 기능 집합을 비교적 단순한 형태에 담는 방법을 예술의 경지까지 다듬어왔음
    디자인 훈련도 없는 사람들이 “소위 디자이너”보다 더 잘할 수 있다고 여기는 건 성숙한 연구 분야에 대한 오만과 무례에 가깝고, 실제로 사람들은 거의 훈련 없이도 휴대폰을 꽤 잘 쓰고 있음
    그 자체가 현대의 기적임

• 약간 다른 얘기지만, iPhone이 홈 버튼을 없앤 뒤 Android로 간 이유 중 하나가 이 흐름임
  가족 중 나이 든 사용자에게 상호작용을 설명하기가 확실히 더 어려워졌고, “Force Touch”를 겨우 익혔더니 그것도 사라졌음
  새 Pixel을 받으면 제일 먼저 3버튼 내비게이션을 켜지만, 요즘은 이것도 UI 관점에서 점점 밀려나고 있음
  앱들이 하단 내비게이션 바를 가정하고 3버튼 내비게이션의 더 큰 간격을 고려하지 않아 콘텐츠나 텍스트가 그 뒤에 깔리기도 함

  • 흔한 소프트웨어에서 메뉴 항목이 사라지는 것도 비슷함
    예를 들어 MS Word에서 읽기 전용 파일을 열면 저장 옵션이 보이지 않음
    왜 편집은 되는데 저장은 안 되는지 알기 어렵다
    훨씬 나은 사용자 경험은 저장 옵션을 숨기지 않고 활성화해두었다가, 사용자가 저장을 시도하면 “이 파일은 이런 이유로 저장할 수 없습니다”라고 알려주고 해결 방법을 제시하는 것임
  • 나도 마찬가지로 오래된 Android 사용자라서 아내의 iPhone을 빌리면 짜증나는 훈련처럼 느껴짐
    상호작용이 숨겨져 있거나, 직관적이지 않거나, 아예 빠져 있음
    이제 Pixel 카메라가 iPhone 카메라를 앞서고 Samsung도 비슷한 수준이니, Apple 생태계로 갈 이유가 정말 없다고 봄
  • 같은 이유로 할머니에게 마지막으로 사드린 휴대폰은 여전히 홈 버튼이 있는 iPhone SE였음
    어디에 있든 크고 분명한 버튼 하나를 누르면 익숙한 홈 화면으로 돌아갈 수 있기 때문임
  • 핵심 UI 요소는 보여야 한다는 쪽에 확고히 서 있고, Apple도 가끔 그 원칙을 어긴다는 데 동의함
    다만 전반적으로는 그 유혹에 꽤 잘 저항한다고 보고, 홈 버튼 제거가 UI 요소를 숨긴 것이라는 주장에는 동의하지 않음
    이는 “누르기”에서 “스와이프”로 상호작용이 바뀐 것이고, UI 요소는 버튼이 아니라 화면 가장자리 자체라고 봄
    직관적인지, 더 나은지는 논쟁할 수 있지만, 아이콘을 더블클릭해 앱을 실행하거나 우클릭으로 컨텍스트 메뉴를 여는 것과 비슷함
    둘 다 시각적 단서는 없지만 핵심 기능에 늘 쓰이고, 익숙해지면 마찰이 생기지 않음
    Apple이 새 직관을 너무 자유롭게 강요한다고 말할 수는 있고 Safari 주소창 끌기 같은 사례에는 동의하지만, 홈 버튼은 예외라고 봄
    iOS에는 화면에 작은 드래그 가능한 원을 띄우는 접근성 기능도 있어서, 누르면 텍스트 라벨이 붙은 홈 버튼과 여러 유용한 단축 기능을 표시할 수 있음
    실제로 하드웨어 홈 버튼이 있던 시절에도 그 버튼을 닳게 하기 싫어서 이 원을 켜두던 사람들을 알고 있음
  • 아직 홈 버튼 있는 iPhone을 쓰고 있음
    그것도 해결책임

• 우리에게는 키보드 단축키와 컨텍스트 메뉴는 명확한 버튼이나 메뉴로 발견 가능한 명령의 단축 수단이어야 한다는 UI 설계 규칙이 있음
  그래서 우리 앱들이 구식으로 보일 수도 있음
  예전에 화면 네 모서리는 마우스를 정밀하게 제어하지 않고도 빠르게 갈 수 있어서 가장 가치 있는 화면 공간이라고 배웠음
  그래서 Windows 11에서 Microsoft가 기본 시작 메뉴 위치를 가운데로 옮긴 건 사용자 적대적이라고 봄
  모바일 우선 때문이라고 보기도 어렵고, 마우스 이동이 적용되지 않는 “터치 우선”일 수는 있겠음

  • Windows 11의 가운데 아이콘은 오직 macOS 흉내 때문에 그렇게 했다고 봄
    아마 설계팀이 직접 쓰는 환경이라 익숙했을 것이고, 합리적인 UX 이유는 없음
    macOS에서도 그 방식은 인터페이스에 해가 됨
  • 바로 이래야 함
    추가로, 모든 메뉴 항목에는 작동시키는 키보드 단축키가 함께 보여야 함
    버튼 위에 마우스를 올렸을 때 뜨는 모든 도구 설명도 그 기능을 실행하는 단축키를 보여줘야 함
    초보 사용자가 다른 곳에서 찾아보지 않고도 자신에게 필요한 단축키를 알아차리는 가장 좋은 방법임
  • “최대화”가 “닫기” 옆에 있는 것도 사용자 적대적이라고 봄
    마우스를 멀리 움직인 뒤 최대화하려면 정밀 조작을 해야 하고, 프로그램을 더 크게 보려다 실패하면 파괴적으로 아무것도 남지 않게 됨
  • 모서리와 가장자리는 이런 식으로 거의 쓰이지 않지만, 쓰여야 함
    Fitts의 법칙을 보면 됨: https://en.wikipedia.org/wiki/Fitts%27s_law
    내 메타버스 클라이언트는 보통 깨끗한 3D 세계 화면을 보여주고, 커서를 화면 위나 아래로 가져가면 메뉴 바와 조작부가 나타남
    커서가 조작부 위에 있는 동안은 계속 보이고, 몇 초 뒤 사라짐
    일부러 설명하지 않아도 사용자는 마우스를 움직이다 가장자리에 닿기 때문에 자연스럽게 조작부를 찾음

• 현대 운영체제들이 데스크톱과 모바일 모두에서 파일 시스템 경로를 계속 숨기는 게 정말 화가 남
  예전 OSX에는 Finder에서 주소 표시줄을 보이게 하는 설정이 있었지만 기본값은 아니었고, 요즘은 서드파티 확장 없이는 불가능해 보여서 결국 터미널을 써야 함
  나중에 파일을 옮기거나 전송해야 할 때 위치를 찾을 수 없게 만드는 건 말이 안 됨

  • 내 나름의 작업 가설은, 신규 사용자 대상 사용성 테스트 포커스 그룹이나 A/B 테스트에서 잘 나오지 않는 것은 결국 사라진다는 것임
    문제는 그런 테스트를 하는 사람들이 의도했든 아니든 잘못된 지표, 즉 “처음 보는 사람이 이 작업을 얼마나 빠르고 쉽게 알아내는가”에 최적화한다는 점임
    거시적으로는 잘못된 최적화이고, 단기 전환율은 올릴 수 있어도 장기적으로 사용성, 기능성, 발견 가능성을 해쳐서 앱을 사랑하고 입소문 내줄 고급 충성 사용자들을 화나게 함
    큰 사회적 관점 없이 실험실이나 포커스 그룹에서 A/B 테스트와 사용성 테스트를 하면 즉각적인 단기 KPI를 올리는 지표에 집중하고, 그 결과 객관적으로 더 나쁜 UX 설계를 근거 기반, 데이터 기반이라고 홍보하게 됨
    지난 20년간 소프트웨어 사용성을 망가뜨렸고, 진정으로 사려 깊은 UX를 거의 접하지 못한 채 자라는 다음 세대에게도 큰 해를 끼치고 있다고 봄
  • SharePoint에서 파일로 직접 연결되는 링크가 공유될 때 이 문제가 있음
    파일 자체보다 그 파일이 들어 있는 디렉터리를 공유하는 편이 더 유용할 때가 많음
    MS Office에는 그 정보를 얻는 방법이 있긴 하지만, 찾아야 함
  • 아직 있음
    Finder → Show 메뉴 → Show Path Bar
  • UI에는 드러나 있지 않지만 이렇게 하면 됨
    defaults write com.apple.Finder _FXShowPosixPathInTitle -bool true

• UI 설계가 잘못되고 있다는 신호로, 요즘 자주 보이는 “음식은 냉장고에 있습니다” 안티패턴이 있음
  어떤 기능을 켜는 버튼을 직접 제공하는 대신, 엉뚱한 위치의 UI 텍스트가 어떤 단계를 밟아야 다른 기능을 활성화할 수 있는지 알려주는 방식임
  또 다른 변형은 버튼이나 메뉴 항목이 실제 동작을 하는 대신 다른 버튼으로 포커스를 옮기거나 다른 위치의 메뉴를 열어주고, 사용자가 다시 그걸 클릭하게 만드는 것임
  Microsoft 제품, 특히 VS Code에서 점점 더 많이 보임

  • World Quester 2의 사용자 인터페이스 설계와 메뉴 시스템을 분명 좋아할 것 같음
    Game Helpin' Squad: World Quester 2
    https://www.youtube.com/watch?v=0Gy9hJauXns
    Cursor에서 “Cursor => Settings => Cursor Settings”를 선택할 때마다 웃으면서 World Quester 2를 떠올림
    World Quester 2를 너무 좋아해서, 그 가장 혁신적인 기능인 “Space Inventory”를 Micropolis(SimCity)의 WASM 버전에 구현했음
    https://micropolisweb.com/
    경고: 스페이스바를 누르지 말 것!!!! 실수로 눌렀다면 절대 다시 누르지 말 것!!!! 또다시 누르지도 말 것!!!!
    SimCity Micropolis Tile Sets Space Inventory Cellular Automata To Jerry Martin's Chill Resolve:
    https://www.youtube.com/watch?v=319i7slXcbI

• 약간 곁가지이고 늙은이의 패배한 싸움처럼 보이지만, 제발 스크롤바를 숨기지 말았으면 함
  글은 흥미로웠지만 완전히 동의하지 않는 부분도 있었음
  자동차 지도 확대·축소용 물리 노브처럼 어떤 것에는 비용과 현실적 한계가 있음
  최근 새로 설치한 앱에서 토글을 눌렀는데 라벨과 반대 동작을 했음
  라벨이 현재 상태를 뜻한다고 생각했지만 실제로는 토글하면 바뀔 상태를 뜻했고, 바꾼 뒤에는 분명해졌지만 가장 도움이 안 되는 구현처럼 보였음

  • 현실의 토글 스위치도 싫어함
    거기서도 똑같이 모호함
    체크박스와 눌린 버튼이 훨씬 명확하지만, 안타깝게도 “현대성”의 제단에 희생됐음
  • 몇 년 전 오스트리아 기차표 발매기에도 그런 헷갈리는 토글이 있었음
    표를 즉시 검표 처리하는 기능이었고, 실수하면 비용이 발생할 수 있었음
    스크롤바도 너무 얇게 만들어서 맞추려면 FPS 실력이 필요하게 하지 말았으면 함
    Firefox가 특히 그렇고, 표준 CSS가 허용하는 문제일 수도 있음
    세로 스크롤은 할 수 있지만, 가로 스크롤은 다른 손으로 Shift를 누르는 것보다 스크롤바가 더 편함
  • 이런 모호한 스위치는 종종 옵트아웃 결함 기능과 연결됨
  • 동작을 나타내고 싶다면 동사를 넣어야 함
    “TURN ON”이면 완전히 명확하고, 상태를 보여주고 싶다면 “IS ON”도 분명함
    “INCREASE”처럼 동사가 보여도 헷갈릴 수 있는 소수의 경우는 있겠지만, 버튼이 동사를 보여주는지 명사를 보여주는지 불분명한 UI를 상상하려면 꽤 애써야 함
  • 스크롤바를 숨기지 않으려면 이걸 보면 됨
    https://superuser.com/a/1720363
    Firefox를 쓰는가?