휴먼 인터페이스 가이드라인

스마트폰 앱이 쏟아지기 시작하던 무렵, 앱을 하나 열 때마다 사용법을 새로 배워야 했습니다. 어떤 앱은 뒤로 가기 버튼이 왼쪽 위에 있었고, 어떤 앱은 화면 아래 가운데에 있었으며, 아예 없는 앱도 있었습니다. 삭제 버튼이 빨간 글씨인 앱과 회색 아이콘인 앱이 섞여 있어서, 누르기 전에 한 번씩 멈춰 생각해야 했습니다.

만드는 쪽도 편하지 않았습니다. 화면 하나를 그릴 때마다 탭을 몇 개까지 둘지, 버튼을 얼마나 크게 할지, 경고 창을 어디에 띄울지를 팀 안에서 처음부터 다시 정해야 했습니다. 근거가 취향밖에 없으니 시안 리뷰는 매번 "제 생각에는" 으로 시작해 결론 없이 끝났습니다. 그렇게 한 달을 들여 내놓은 앱이 앱 장터 심사에서 "표준 동작과 다르다" 는 이유로 반려되기도 했습니다.

애플은 이 결정들을 기기 제조사가 미리 답해 두는 쪽을 택했습니다. 기기를 파는 회사가 화면의 기준까지 문서로 못 박아 두면, 앱마다 달라지던 조작법이 한 벌로 모이고 사용자는 처음 여는 앱도 아는 대로 씁니다. 줄여서 HIG 라고 부르는 이 문서가 그 답을 모아 둔 자리입니다.

HIG 가 없애 주는 것은 화면을 그릴 때마다 팀이 처음부터 정해야 했던 결정입니다. 이미 정해진 답이 문장과 수치로 적혀 있어서, 디자이너는 그 답을 찾아 쓰고 남은 시간을 제품 고유의 문제에 씁니다.

문서가 답해 주는 것은 크게 셋입니다.

1. 구체적인 수치. 화면 아래 탭은 다섯 개까지, 누를 수 있는 영역은 한 변이 44포인트 이상, 뒤로 가기는 왼쪽 위처럼 숫자와 위치가 못 박혀 있습니다. 44포인트는 성인 손가락 끝이 화면에 닿는 넓이에서 나온 값이라, 이보다 작게 만들면 옆 버튼이 눌립니다.
2. 기기별 차이. 아이폰·아이패드·맥·워치마다 장이 따로 있습니다. 마우스는 한 점을 정확히 짚으니 작은 버튼도 괜찮지만 손가락으로 만지는 화면은 그렇지 않기 때문입니다.
3. 사용자 설정에 따른 변형. 배경을 어둡게 바꾼 다크 모드 사용자와 글자 크기를 키워 둔 사용자에게 화면이 어떻게 보여야 하는지를 따로 다룹니다. 장애나 상황에 관계없이 쓸 수 있게 만드는 접근성 항목도 같은 자리에 있습니다.

여기에 하나가 더 붙습니다. 앱 장터 심사 기준이 이 문서를 근거로 삼기 때문에, 적힌 것 중 일부는 권고가 아니라 사실상 통과 조건입니다. 표준 부품을 엉뚱한 용도로 쓰거나 결제 흐름을 문서와 다르게 만들면 심사에서 걸립니다.

쓰는 방법은 처음부터 끝까지 읽는 것이 아닙니다. 화면을 그리기 전에 해당하는 장만 찾아 읽고, 디자인 리뷰에서 배치를 두고 의견이 갈릴 때 근거로 인용하고, 운영체제가 새 버전을 낼 때마다 바뀐 항목만 훑습니다. 사전처럼 필요할 때 펴 보는 물건에 가깝습니다.

HIG 를 쓰지 않는 선택지는 셋이고, 어느 플랫폼에 무엇을 내느냐가 갈림길입니다.

1. 머티리얼 디자인. 구글이 내놓은 같은 성격의 문서이고 안드로이드가 이쪽을 따릅니다. 두 플랫폼에 같은 기능을 내려면 기획은 한 벌로 쓰되 화면은 두 벌을 그리게 됩니다. 문서를 삭제하겠냐고 묻는 창이 아이폰에서는 아래에서 밀려 올라오고 안드로이드에서는 화면 가운데에 뜨는 식으로 갈리기 때문입니다.
2. 자체 디자인 시스템. 브랜드 고유의 화면을 만들고 싶을 때 색·간격·부품을 직접 정해 씁니다. 다만 뒤로 가기나 경고 창처럼 사용자가 운영체제에서 이미 배운 동작까지 새로 만들면 학습 비용이 사용자에게 넘어갑니다. 대개는 HIG 를 바닥에 깔고 브랜드 색과 UI 컴포넌트 일부만 자기 것으로 바꾸는 절충을 택합니다.
3. 크로스플랫폼 도구의 기본 부품. 한 벌의 코드로 양쪽 앱을 만드는 도구들은 자체 부품을 제공하고, 그중 일부는 애플 쪽 모양을 흉내 낸 것도 함께 제공합니다. 화면을 두 벌 그리지 않아도 되는 대신, 운영체제가 새 동작을 내놓아도 도구가 따라잡기 전까지는 쓸 수 없습니다.

셋 중 무엇을 택하든 결정은 디자인 토큰까지 내려갑니다. 플랫폼마다 갈리는 값은 두 벌로 두고, 브랜드 색이나 문구처럼 갈리지 않는 값은 한 벌만 두는 식입니다.

"이거 HIG 에 뭐라고 돼 있는지 보고 정합시다."

취향으로 다투지 말고 문서에 적힌 기준을 근거로 삼자는 제안입니다.

"탭을 여섯 개 넣으면 HIG 에서 벗어나서 심사에서 걸릴 수 있어요."

문서에 적힌 다섯 개 상한을 넘겼고, 그게 권고를 넘어 통과 조건에 가깝다는 경고입니다.

"안드로이드는 머티리얼 쪽이 다르니까 이 화면은 두 벌로 그릴게요."

한 기획을 두 플랫폼 규범에 맞춰 각각 그리겠다는 뜻입니다.

페이지덱이 모바일 앱을 처음 내놓던 분기에 민서가 문서 목록 화면을 그렸습니다. 웹에서 쓰던 대로 화면 오른쪽 위에 점 세 개 메뉴를 두고 그 안에 삭제와 이름 변경을 넣었는데, 태오가 아이폰에서는 목록 항목을 왼쪽으로 밀어 삭제하는 동작이 이미 사용자에게 익은 방식이라고 짚었습니다. 둘이 HIG 의 목록 관련 장을 열어 권장 동작을 확인하고, 밀어서 삭제를 기본으로 두되 점 세 개 메뉴도 함께 남기기로 했습니다.

반대 방향의 판단도 나왔습니다. 문서 위에 여러 사람의 커서가 보이는 기능은 HIG 에 해당하는 항목이 없어서, 이 화면만은 웹에서 쓰던 방식을 그대로 가져왔습니다.

HIG 를 따르면 앱이 다 비슷해진다는 말을 자주 듣습니다. 문서가 수치와 배치를 지정하니 결과물도 한 모양이 될 것 같아 보입니다. 하지만 문서가 정하는 것은 탭의 개수나 버튼의 최소 크기처럼 사용자가 조작법으로 익힌 부분이고, 색·서체·사진·말투·정보 구조는 건드리지 않습니다. 같은 규범을 따르는 앱들이 서로 전혀 달라 보이는 이유가 여기 있습니다. 조작법을 제 마음대로 바꾼 앱은 개성 있다는 평가 대신 쓰기 불편하다는 평가를 받습니다.

문서에 적힌 것이 전부 강제라고 읽는 것도 흔합니다. 반려된 경험이 한 번 있으면 모든 문장이 규정처럼 보입니다. 실제로는 대부분이 권고이고, 심사와 직접 엮인 항목은 결제나 개인정보 처리처럼 따로 정해진 몇 가지입니다. 이 구분을 못 하면 제품에 필요한 변형까지 "HIG 에 없어서" 라며 포기하게 됩니다.