인터랙션 디자이너

화면은 오랫동안 정지된 그림으로 넘어갔습니다. 디자이너가 버튼과 목록이 놓인 한 장을 그려 주면 개발자가 그것을 코드로 옮기는 식이었습니다. 그림에는 화면이 완성된 순간만 담깁니다. 버튼을 누른 직후의 0.5초, 목록이 아직 비어 있는 상태, 인터넷이 끊겼을 때 뜨는 것은 어느 장에도 없습니다.

그 빈자리는 누군가 채워야 했으므로 대개 개발자가 그때그때 정했습니다. 저장 버튼은 누르면 곧바로 원래 색으로 돌아오고, 삭제 버튼은 확인 창을 띄우고, 다른 화면의 삭제 버튼은 바로 지워 버립니다. 같은 제품 안에서 같은 동작이 화면마다 다르게 반응하는 상태가 이렇게 만들어집니다.

가장 흔한 사고는 저장 버튼이었습니다. 눌렀는데 아무 표시가 없으면 사람은 3초 안에 한 번 더 누릅니다. 그러면 같은 문서가 두 번 저장되고, 목록에 똑같은 항목이 두 줄 생깁니다. 디자이너는 버튼을 그렸고 개발자는 그린 대로 만들었는데도 고장이 납니다. 누른 다음에 무엇이 보여야 하는지를 아무도 결정하지 않았기 때문입니다.

인터랙션 디자이너는 그 결정을 맡는 자리입니다. 화면이 몇 장인지가 아니라 조작과 반응을 쌍으로 세는 사람이고, 이 자리가 다루는 영역 전체를 인터랙션 디자인이라고 부릅니다.

한 화면을 받으면 먼저 그 화면에서 일어날 수 있는 일을 전부 적어 내려갑니다. 그림 한 장이 실제로는 여러 모습으로 갈라지기 때문입니다.

1. 상태를 늘어놓습니다. 같은 요소가 상황에 따라 달라지는 모습을 UI 상태라고 하는데, 목록 하나만 해도 불러오는 중, 비어 있음, 정상, 오류, 권한 없음으로 다섯 갈래가 나옵니다. 여기서 빠진 상태가 나중에 버그로 돌아옵니다.
2. 조작마다 반응을 정합니다. 누른 순간 버튼이 회색으로 바뀌고 저장 중이라는 글자가 뜬다, 끝나면 3초짜리 알림이 뜬다 같은 식으로 한 줄씩 적습니다. 이 짧은 반응 하나하나를 마이크로 인터랙션이라고 합니다.
3. 움직임의 규칙을 정합니다. 무엇이 어디서 어디로 몇 밀리초 동안 움직이는지를 정하는 일이라 모션 디자인과 겹칩니다. 창이 화면 아래에서 올라오면 사용자는 닫을 때 아래로 내리면 된다고 짐작합니다.
4. 눌러 볼 수 있는 시안을 만듭니다. 말로 설명하는 대신 실제로 눌러 반응을 확인할 수 있게 연결해 둡니다. 0.2초와 0.4초의 차이는 글로 읽어서는 판단이 되지 않습니다.
5. 개발에 넘길 문서를 씁니다. 시안을 구현 쪽으로 넘기는 과정을 핸드오프라고 하는데, 여기에는 시간, 곡선, 사용자가 연달아 눌렀을 때의 처리까지 값으로 적혀 있어야 합니다.

구현된 뒤에는 직접 써 보며 시안과 다른 곳을 찾아 돌려보냅니다. 이 확인을 건너뛰면 4번에서 맞춘 0.2초가 실제 제품에서는 0.6초로 나가 있는 일이 생깁니다.

화면의 시각 요소와 배치를 맡는 UI 디자이너와 가장 자주 붙습니다. 한쪽이 버튼의 크기와 색을 정하면 다른 쪽이 눌린 뒤의 0.3초를 정하는 식이라, 같은 화면을 다른 축으로 나눠 갖습니다. 흐름 전체를 설계하는 UX 디자이너와는 경계가 이어집니다. 가입에서 첫 문서 작성까지 몇 단계를 밟을지가 그쪽 결정이고, 각 단계에서 버튼을 눌렀을 때 무엇이 벌어지는지가 이쪽 결정입니다.

개발자와는 값으로 이야기합니다. "부드럽게" 는 구현할 수 없지만 "250밀리초 동안 아래에서 위로" 는 구현할 수 있습니다. 그래서 이 역할은 만들 수 있는 것과 없는 것을 아는 상태에서 설계해야 하고, 그 경계를 더 깊이 다루는 자리가 디자인 엔지니어입니다.

반복을 줄이려면 디자인 시스템에 결정을 남깁니다. 로딩 표시와 알림 시간을 부품마다 한 번씩 정해 두면 다음 화면에서 다시 논의하지 않습니다. 이 기록이 없으면 3년 뒤 알림이 사라지는 시간만 다섯 가지인 제품이 됩니다.

"이 화면 상태 다섯 개 중에 오류만 안 잡혀 있어요. 인터랙션 쪽에서 정해 주실 수 있나요?"

화면이 가질 수 있는 모습 하나가 설계에서 빠졌으니 그 자리를 채워 달라는 요청입니다.

"인터랙션 디자이너가 따로 없어서 프로덕트 디자이너가 겸하고 있습니다."

역할이 아직 갈라지지 않은 조직 구조를 설명하는 말입니다.

"연타 방지는 인터랙션 스펙에 적혀 있어야 할 것 같은데요."

같은 버튼을 연달아 눌렀을 때의 처리를 구현 쪽이 임의로 정하지 않도록 문서에 적어 달라는 뜻입니다.

페이지덱에는 이 직함을 가진 사람이 따로 없어서 민서가 겸합니다. 문서 공유 화면을 새로 만들 때 민서가 먼저 한 일은 화면을 그리는 것이 아니라 권한 목록이 가질 수 있는 상태를 여섯 개로 적어 둔 것이었습니다. 불러오는 중, 아무도 초대되지 않음, 정상, 초대 실패, 권한 부족, 링크 만료입니다.

여섯 개 중 두 개는 기획서에 없던 것이라 그대로 지현에게 넘어가 결정이 필요했습니다. 링크가 만료되면 다시 만들게 할지 요청을 보내게 할지는 디자인이 아니라 제품 결정이기 때문입니다. 설계가 화면을 그리기 전에 결정을 먼저 끌어냈다는 점이 이 역할이 하는 일을 잘 보여 줍니다.

애니메이션을 만드는 사람이라는 오해가 가장 많습니다. 결과물 중 눈에 띄는 것이 움직임이라 그렇게 보입니다. 하지만 이 역할이 정하는 것의 대부분은 움직이지 않습니다. 무엇을 눌렀을 때 무엇이 잠기는지, 실패하면 이전 상태로 되돌릴지 그대로 둘지, 같은 버튼을 두 번 누르면 어떻게 할지가 그렇습니다. 움직임만 맡기면 화면은 근사해지는데 두 번 눌러 두 번 저장되는 고장은 그대로 남습니다.

큰 회사에만 있는 직함이라는 생각도 자주 봅니다. 실제로 구성원 100명 아래에서는 프로덕트 디자이너가 이 일을 함께 하는 경우가 대부분입니다. 하지만 직함이 없는 것과 일이 없는 것은 다릅니다. 담당을 정해 두지 않으면 조작과 반응에 대한 결정은 사라지는 것이 아니라 구현하는 사람에게 한 명씩 나뉘어 넘어가고, 제품은 화면마다 다르게 반응하는 상태로 자랍니다.