일리야 비르만은 블로그에 올린 두 편의 연속 글에서 사람들을 불필요하게 느리게 만드는 인터페이스에 대해 이야기한다.

첫 번째 글에서, “Let me click”이라는 제목으로 비르만은 사용자가 바로 갈 수 있는데도 빙 돌아가게 만드는 사례 몇 가지를 보여준다:

Aegea의 댓글 설정에는 “send by email” 체크박스와 연결된 이메일 주소 입력란이 있다. 체크박스가 해제된 상태라면 입력란을 채울 이유가 없다. 그 주소는 다른 데 쓰이지 않기 때문이다. 체크박스는 체크되어 있는데 주소가 비어 있다면, 시스템은 주소를 모르니 아무것도 보낼 수 없다. 요컨대 이 두 컨트롤은 서로 연결되어 있다.

논리적으로 보면 체크박스가 해제되어 있을 때 입력란 자체를 비활성화할 수도 있다. 어차피 채워 봐야 소용없으니까. 하지만 그건 짜증 나는 일이다. 주소를 먼저 입력하고 나서 체크박스를 켜고 싶을 수도 있지 않은가? 주소가 입력된 상태에서 체크박스를 끄지 못하게 하는 건 더 나쁘다. 끄고 싶은데 — 클릭하게 해달라!

후속 글에서 비르만은 팟캐스트 앱 Overcast의 구체적인 사례를 다룬다. Overcast 제작진은 까다로운 시스템적 난관에 직면했었다:

어느 팟캐스트든 기기에 다운로드해 보관할 에피소드 개수를 설정할 수 있다. 예를 들어 상한을 세 개로 설정한 뒤 그 팟캐스트를 더 이상 꾸준히 듣지 않는다고 하자. 그러면 다음 세 개 에피소드가 다운로드되고 그 이후로는 더 이상 다운로드되지 않는다. 공간을 낭비할 이유가 없으니까. […]

[하지만] 이미 세 개를 다운로드해 둔 상태에서 사용자가 직접 에피소드 다운로드를 요청하면 어떻게 해야 할까? 깔끔하게 유지하겠다고 바로 삭제해 버릴 수는 없다. […]

마침내 마르코의 아내 티프가 모든 문제를 해결할 방법을 제안한다. 그냥 사용자가 에피소드를 더 다운로드하지 못하게 하고, 대략 “에피소드 상한은 세 개인데, 이건 네 번째라서 안 됩니다”라는 메시지를 보여주자는 것이었다.

마르코는 그 해결책이 마음에 들었다. 나는 아니었다. 물론 그건 마르코의 문제는 해결하지만, 사용자의 문제는 해결하지 못한다.

나는 Overcast의 차단 동작을 직접 보지는 못했지만, 두 글에 나온 비르만의 모든 예시는 내게도 정확하게 와닿았다. 몸이 기억한 움직임은 원하는 대로 하려 하고, 누구도 그걸 막지 못한다.

여기에 내 쪽에서 두 가지를 덧붙이고 싶다.

1.

비르만은 이를 “Let me click”이라고 제시하지만, 예전에 내게 도움이 됐던 두 가지 대안적/보완적 원칙을 소개하고 싶다:

• Let me do things in any order. Google Home 앱을 보자. 온도와 유지 시간을 바꿀 수 있는데, 시간을 먼저 바꾸고 나서 온도를 바꾸면 짜증나게도 시간이 초기화된다. 어떤 순서로 해도 될 것처럼 보이는 인터페이스에서 특정 순서 하나를 강요하는 셈이다:

• The current action has the most momentum. 사용자는 지금 바로 여기에서 무언가를 탭하며 적극적으로 뭔가를 해내려 하고 있다. Overcast가 정말로 “에피소드 상한은 세 개입니다”라는 메시지를 띄운다면, 사용자는 설정으로 가는 방법을 기억해 내서 값을 바꿔야 한다. 흐름이 끊기는 것이다. 과거의 내가 내린 결정이 지금의 내가 내리는 결정만큼 중요해서는 안 된다.

2.

비르만이 든 모든 예시에 동의하지만, 상황은 더 복잡할 수 있고, 때로는 클릭하게 하거나 어떤 순서로든 할 수 있게 하는 것이 오히려 인터페이스를 이해하기 어렵게 만들기도 한다.

Figma에서는 각 텍스트 상자의 크기를 완전 자동으로(너비와 높이 모두 자동 – 짧은 레이블에 사용), 너비만 지정하고 높이는 자동으로(문단 텍스트에 사용), 혹은 너비와 높이를 모두 수동으로(그래픽 요소에 사용) 설정할 수 있다:

너비나 높이가 자동인 텍스트 상자에서는 해당 값의 입력 필드가 회색으로 비활성화되어 바꿀 수 없다는 것도 볼 수 있다. 값을 바꾸려면 먼저 특정 모드로 전환해야 해당 필드가 활성화된다. 이는 꽤 까다로운 영역에서 요소들이 서로 어떻게 연결되는지 이해하도록 돕기 위한 것이지만, 결과적으로 때로는 Figma가 클릭을 허용하지 않고 특정 순서대로 하도록 강제한다는 뜻이기도 하다.

하지만 이는 저 필드에서만 그렇다. 캔버스 위의 오브젝트는 언제나 직접 잡아 크기를 조절할 수 있고, 그러면 드래그의 흐름을 존중해 자동으로 수동 모드로 전환된다:

여기서 보이는 불일치는 의도된 것이다. 이 선택들이 옳다고 말하는 것은 아니며, 실제로 시스템을 이미 이해한 상태에서 쉽게 클릭할 수 없어 답답하다는 사용자 의견도 들었다(안타깝게도 현대 GUI에서 비활성화된 필드를 “뚫고” 들어가는 molly guard 같은 좋은 어포던스는 아직 보지 못했다). 나는 그저 이런 문제들이 어려울 수 있으며, “클릭하게 해달라”와 “클릭하지 못하게 하는 것이 시스템을 이해하는 데 도움이 될 수 있다” 사이의 균형을 맞추기가 까다롭다는 점을 공유하고 싶었을 뿐이다.

10년 전 뉴욕 필하모닉 공연 맨 앞줄에서 누군가의 휴대폰이 울렸던 이야기가 계속 생각난다. 그 일로 공연이 실제로 중단됐고 지휘자와 관객 모두의 분노를 샀다. 부끄러워하던 관객이 나중에 내놓은 해명은 이러했다. “휴대폰을 무음으로 해뒀는데, 알람도 설정해 둔 상태였습니다.”

이 해명이 실제로 사실이라고 가정해 보자(당시 목격담에 따르면 울린 소리는 마림바 벨소리였는데, 이는 기본 알람음은 아니다. 하지만 사람들의 기억은 원래 자주 흐릿하기도 하다). 내 생각에 이는 “let me click”이 실제로 작동하는 완벽한 예다. 특정 시간에 알람을 설정할 수 있고, 그 다음에 휴대폰을 무음으로 전환할 수 있다. 반대 순서로도 할 수 있다. 결국 휴대폰에 서로 모순되는 두 가지 지시를 내린 셈이고, 휴대폰 로직은 어느 경우든 알람이 우선하도록 결정한 것이다.

여기서는 쉬운 인터페이스 해법이 떠오르지 않는다. 여기서는 순서가 중요하지 않은 것이 맞게 느껴진다. 무음 모드는 통화에도 영향을 미치므로, 알람이 켜져 있다는 이유로 무음 모드 전환을 막는 것은 상상하기 어렵다. 과정 중 어느 시점에서든 효과적인 UI 경고를 띄우는 것도 상상하기 어렵다.(게다가 예전 iPhone은 상단 바에 작은 알람 아이콘을 표시해 은근히 알려주곤 했다.)

무음 모드와 알람은 비르만의 표현을 빌리자면 서로 연결되어 있지만 — 그 연결을 사용자에게 설명하는 일은 결국 까다롭다.