UX 디자이너

화면을 잘 만드는 일과 사용자가 원하는 것을 끝내게 만드는 일은 오래 한 사람 몫이었습니다. 문제가 드러나는 자리는 늘 같았습니다. 시안 검수는 통과했는데 실제 사용자가 중간에 멈추는 것입니다.

페이지덱의 첫 가입 흐름이 그랬습니다. 화면 다섯 장을 따로 놓고 보면 어디에도 흠이 없었습니다. 글자 크기도 여백도 버튼 색도 기준을 지켰습니다. 그런데 가입을 시작한 사람 중 끝까지 간 사람은 셋에 하나였습니다. 세 번째 화면에서 팀 이름과 초대할 동료의 메일 주소를 함께 물었는데, 혼자 써 보려고 들어온 사람에게는 답할 것이 없는 질문이었습니다. 화면 한 장씩 보는 검수에서는 이 자리가 보이지 않고, 앞뒤를 이어 놓고 봐야 보입니다.

그래서 화면이 아니라 흐름을 자기 결정으로 삼는 자리가 생겼습니다. 사용자 경험과 화면 설계를 다루는 디자인 축에는 역할이 아홉 있는데, 나뉘는 기준은 그림 솜씨가 아니라 어디까지를 자기 결정으로 삼느냐입니다. UX 디자이너가 맡는 구간은 사용자가 처음 들어온 순간부터 원하던 결과를 손에 넣는 순간까지입니다.

하루 중 화면을 그리는 시간은 절반이 안 됩니다. 나머지는 읽고 묻고 확인하는 데 들어갑니다. 실제로 손이 가는 일은 다섯 가지입니다.

1. 흐름을 그립니다. 화면 목록이 아니라 분기와 막히는 자리를 적습니다. 가입 흐름이라면 혼자 들어온 사람과 초대를 받아 들어온 사람이 갈리는 지점, 메일 인증을 나중으로 미룰 수 있는지, 중간에 창을 닫은 사람이 돌아오면 어디서 시작하는지가 여기 적힙니다.
2. 조사 결과를 읽습니다. 사용자를 만나는 조사를 UX 리서처가 맡는 회사에서는 그 결과를 읽고, 없는 회사에서는 직접 합니다. 어느 쪽이든 고객센터에 쌓인 문의 글을 읽는 일은 대개 본인 몫입니다. 같은 질문이 스무 건 들어온 화면이 다음에 고칠 자리입니다.
3. 눌러 볼 수 있게 만듭니다. 그림만 있는 시안으로는 흐름을 확인할 수 없어서, 화면을 이어 붙여 눌러 보게 만들고 다섯 명 정도에게 과업을 시켜 봅니다. 세 명이 같은 자리에서 멈추면 그 자리는 고칩니다.
4. 정상이 아닌 상태를 정의합니다. 아직 문서가 하나도 없을 때 보이는 화면, 파일이 너무 커서 올라가지 않을 때 뜨는 문구, 네트워크가 끊겼을 때의 처리입니다. 이걸 넘기지 않으면 개발이 추측해서 채우고, 그 결과는 대개 오류가 발생했습니다 한 줄입니다.
5. 구현된 뒤에 다시 봅니다. 시안대로 나왔는지가 아니라 흐름이 그대로인지를 봅니다. 개발 과정에서 화면 하나가 둘로 쪼개지거나 순서가 바뀌는 일이 흔하고, 그 변경이 원래 막혀 있던 자리를 되살리기도 합니다.

산출물은 그림이지만 결정은 순서와 분기입니다. 어떤 화면을 빼자는 판단, 두 질문을 한 화면에 합치자는 판단, 인증을 뒤로 미루자는 판단이 이 역할이 내놓는 것입니다.

혼자 완결되는 자리가 아니어서 하루에 오가는 대화 상대가 넷에서 다섯쯤 됩니다.

1. 프로덕트 매니저 — 무엇을 왜 만들지를 가져옵니다. 경계가 가장 자주 부딪히는 상대이기도 합니다. 무엇을 만들지는 프로덕트 매니저가, 그것에 어떻게 닿게 할지는 UX 디자이너가 정하는 것이 보통이지만 둘은 깔끔하게 갈리지 않습니다. 화면을 하나 빼자는 제안은 기능을 빼자는 제안과 자주 같은 말입니다.
2. 개발자 — 지금 구조에서 그 흐름이 되는지, 되더라도 얼마가 드는지를 알려 줍니다. 여기서 받은 답이 흐름을 바꾸는 일이 잦습니다.
3. UI 디자이너 — 흐름을 실제 화면으로 옮깁니다. 두 자리가 갈려 있지 않은 회사에서는 프로덕트 디자이너 한 사람이 둘을 겸하고, 누르고 끌고 놓는 동작의 반응까지 따로 떼어 둔 회사에서는 인터랙션 디자이너가 그 구간을 맡습니다.
4. UX 라이터 — 화면 안에 들어갈 문구를 씁니다. 사람이 없으면 4번 항목의 문구를 본인이 씁니다.
5. 데이터를 보는 사람 — 고친 흐름이 실제로 나아졌는지를 숫자로 확인해 줍니다.

페이지덱에서는 민서가 이 자리를 겸합니다. 지현이 이번 분기에 무엇을 만들지 가져오면 민서가 흐름을 그려 오고, 태오가 구현 비용을 붙입니다. 가입 흐름을 세 화면으로 줄인 결정도 그 셋이 한 자리에서 내렸습니다.

"이건 화면 문제가 아니라 순서 문제예요. 팀 이름을 처음에 묻지 말고 뒤로 미루죠."

고칠 대상이 화면 안이 아니라 화면 사이라는 지적입니다.

"흐름 먼저 보고 시안은 다음에 볼게요. 화면부터 보면 순서를 못 봐요."

검토 순서를 정하는 말입니다.

"이 상태는 시안에 없는데요. 문서가 0개일 때는 뭐가 보이나요?"

정상 흐름만 그려 놓고 나머지를 비워 뒀다는 지적입니다.

세 번째 대화가 가장 자주 오갑니다. 페이지덱에서 태오가 새 화면을 받을 때마다 먼저 묻는 것이 비어 있을 때와 실패했을 때입니다. 민서가 시안에 정상·빈 상태·오류 세 장을 한 벌로 붙여 넘기기 시작한 뒤로 되돌아오는 항목이 크게 줄었습니다.

그림을 잘 그리는 사람으로 아는 경우가 가장 많습니다. 손에서 나오는 것이 실제로 그림이라서 그렇게 보입니다. 하지만 이 역할이 내놓는 결정은 화면을 몇 장으로 둘지, 무엇을 먼저 묻고 무엇을 미룰지, 어떤 상태를 정의할지입니다. 채용에서 포트폴리오의 완성된 화면만 보면 이 판단력이 전혀 보이지 않습니다. 그래서 면접에서는 예쁜 결과보다 왜 그 순서로 두었는지, 무엇을 빼기로 했는지를 묻습니다.

사용자에게 물어보면 답이 나온다고 여기는 것도 흔합니다. 조사를 강조하는 말을 자주 들어서 그렇게 이해됩니다. 그런데 사용자가 말해 주는 것은 어디서 막혔는지이고, 해법은 말해 주지 않습니다. 초대 화면이 불편하다는 말에서 초대를 없애자는 결론이 바로 나오지 않습니다. 물은 것을 그대로 만들면 요청한 사람에게만 맞는 화면이 쌓이고, 반년 뒤에는 설정 항목이 마흔 개인 제품이 됩니다. 조사는 문제를 좁히는 자료이고 그다음 판단은 이 역할의 몫으로 남습니다.