버튼

종이 서식에는 누를 것이 없습니다. 칸을 채워 창구에 내면 사람이 받아서 처리합니다. 같은 일을 화면으로 옮기자 없던 문제가 생겼습니다. 다 채운 다음 무엇을 해야 제출이 되는지를 화면이 스스로 알려 줘야 합니다.

초기 화면에서는 이게 잘 안 됐습니다. 글자는 다 같은 글자라 어느 것을 누를 수 있는지 보이지 않았습니다. 그래서 이런 전화가 왔습니다. "다 적었는데 그다음은 어떻게 하나요." 화면 아래에 파란 글자로 "다음" 이 있었지만 그게 누를 수 있는 것이라고 아무도 알려 주지 않았습니다.

버튼은 여기에 답하려고 만든 약속입니다. 배경을 채우고 테두리를 두르고 그림자를 얹어 주변 글자와 다르게 보이게 하면, 사용자는 배우지 않고도 저기를 누르면 된다는 것을 압니다. 현실의 물리 버튼이 튀어나와 있어서 누르라고 말하지 않아도 누르게 되는 것과 같은 원리를 화면에 옮긴 것입니다.

누를 수 있다는 것을 보여 주고, 눌린 것을 알려 주고, 결과가 나올 때까지 다시 눌리지 않게 막습니다. 그래서 하나를 만들 때 실제로는 다섯 가지 모습을 함께 만듭니다.

1. 기본 — 평소 모습입니다. 주변 글자와 구별되는 배경이나 테두리가 여기서 정해집니다.
2. 마우스를 얹었을 때 — 색이 살짝 진해지거나 그림자가 붙습니다. 지금 가리키는 것이 이것이라는 신호입니다.
3. 누르고 있을 때 — 색이 더 진해지거나 살짝 눌린 모양이 됩니다. 손가락이나 마우스가 닿았다는 것을 즉시 확인해 줍니다.
4. 눌러도 안 되는 상태 — 색을 흐리게 해서 지금은 쓸 수 없다고 알립니다. 필수 칸이 비어 있을 때 제출을 막는 자리에 씁니다.
5. 결과를 기다리는 상태 — 누른 뒤 응답이 올 때까지 돌아가는 표시를 띄우고 다시 눌리지 않게 잠급니다. 로딩 상태를 부품 안쪽에 넣은 형태입니다.

여기에 키보드로 옮겨 왔을 때의 테두리 표시가 하나 더 붙습니다. 마우스를 못 쓰는 사용자는 탭 키로 화면을 옮겨 다니는데, 지금 어디에 와 있는지 보이지 않으면 결제까지 갈 수 없습니다. 접근성이 화면이 아니라 부품 단위에서 먼저 정해지는 이유입니다.

모습 말고 두 가지를 더 정합니다. 하나는 한 화면에 눈에 띄는 것을 몇 개 둘지입니다. 색을 꽉 채운 것은 하나만 두고 나머지는 테두리만 있거나 글자만 있는 형태로 낮춥니다. 셋을 나란히 채우면 강조가 셋이라 강조가 없는 것과 같습니다. 다른 하나는 라벨입니다. "확인" 은 무엇을 확인하는지 말해 주지 않으니, "결제하기" 나 "초대 보내기" 처럼 누르면 일어날 일을 동사로 적습니다.

같은 부품이지만 놓이는 자리에 따라 맡는 역할이 다릅니다.

1. 입력 화면의 제출 자리 — 가입이나 결제처럼 사용자가 값을 다 채운 뒤 마지막에 누르는 자리입니다. 인풋과 짝으로 다닙니다. 인풋은 글자를 직접 받는 칸이고, 받은 값을 보내는 일은 버튼이 합니다.
2. 창의 확인과 취소 — 모달처럼 답하기 전에는 다른 일을 못 하게 막는 창에서는 나가는 길이 버튼뿐입니다. 되돌릴 수 없는 동작이면 여기서 확인 쪽을 위험한 색으로 칠합니다.
3. 목록 안의 동작 — 문서 목록에서 행마다 붙는 공유나 삭제 같은 것입니다. 행이 스무 개면 같은 버튼이 스무 개 깔리므로, 크기를 줄이고 아이콘만 남기는 형태를 씁니다.
4. 랜딩 페이지의 권유 자리 — 방문자에게 다음 행동을 권하는 자리이고 행동 유도 문구라고 부릅니다. 여기서는 라벨 한 마디가 실제 가입 수를 바꿉니다.

놓이는 자리가 다르면 크기와 세기도 달라져야 하는데, 화면마다 그때그때 정하면 같은 제품 안에서 버튼이 열 종류로 늘어납니다. 그래서 종류와 크기를 미리 몇 가지로 못 박아 디자인 시스템에 넣어 둡니다. 디자인 시스템은 재사용할 규칙과 부품을 한 벌로 묶어 둔 기준입니다.

손가락으로 누르는 화면에서는 크기에 하한이 하나 더 걸립니다. 글자 높이에 맞춰 얇게 만들면 눌리는 영역이 손가락보다 작아져 누른 것 같은데 아무 일도 안 일어나는 일이 반복됩니다. 보이는 크기와 별개로 눌리는 영역을 한 변 44픽셀쯤 확보합니다.

"이 화면에 꽉 찬 버튼이 세 개예요. 하나만 남기고 나머지는 낮추죠."

무엇을 권하는 화면인지 정하자는 제안입니다.

"로딩 상태가 빠져서 두 번 눌렸어요. 결제가 두 건 들어왔습니다."

5번 모습을 안 만들어서 생긴 사고를 보고하는 말입니다.

"라벨을 '확인' 말고 '삭제하기' 로 바꿔 주세요."

누르면 무슨 일이 일어나는지 라벨만 보고 알게 하자는 요청입니다.

페이지덱에서 이 이야기가 길어진 적이 있습니다. 문서를 지우는 창의 라벨이 "확인" 이었고, 지원팀에 "실수로 눌렀는데 되살릴 수 있느냐" 는 문의가 한 달에 열 건 넘게 들어왔습니다. 민서가 라벨을 "영구 삭제" 로 바꾸고 색을 빨간색으로 올리고, 취소를 왼쪽에 두되 테두리만 있는 형태로 낮췄습니다. 다음 달 문의는 두 건이었습니다.

같은 창에서 태오가 하나를 더 잡았습니다. 삭제 후 서버 응답까지 0.8초가 걸리는데 그동안 모습이 그대로여서 급한 사용자는 한 번 더 눌렀고, 두 번째 요청은 이미 지워진 문서를 다시 지우려다 오류 화면을 띄웠습니다. 누른 즉시 잠그고 표시를 돌리는 것으로 끝났습니다.

링크와 버튼의 차이를 생김새 차이로 보는 경우가 많습니다. 실제로 둘 다 누르는 것이고 링크를 버튼처럼 칠하는 일도 흔하니 그렇게 보이기 쉽습니다. 하지만 갈리는 기준은 모양이 아니라 하는 일입니다. 다른 곳으로 데려가면 링크이고, 그 자리에서 무언가를 실행하면 버튼입니다. 이 구분을 어기면 화면을 소리로 읽어 주는 프로그램이 "링크" 라고 읽은 것이 사실은 결제 실행이 되고, 새 탭으로 열릴 줄 알았던 것이 아무 일도 하지 않습니다.

눌러도 안 되는 상태를 친절한 처리라고 여기는 것도 흔합니다. 잘못 누르는 것을 막아 주니 그렇게 보입니다. 그런데 흐려진 버튼은 왜 안 되는지를 말해 주지 않습니다. 약관에 동의하지 않아서인지, 필수 칸이 비어서인지, 카드가 등록되지 않아서인지 알 수 없는 채로 사용자가 화면을 뒤지게 됩니다. 누를 수 있게 두고 누르면 무엇이 막고 있는지 알려 주는 편이 대개 빠릅니다.