프로덕트 디자이너

큰 회사에서 나눠 둔 디자인 직무를 작은 회사가 그대로 가져오면 자리가 비었습니다. 흐름 전체를 설계하는 사람과 그 흐름을 화면으로 옮기는 사람을 따로 두는 구조는 구성원이 수백 명일 때 성립합니다. 45명인 회사에서 디자이너를 세 명 뽑을 수는 없고, 한 명만 뽑으면 그 한 명의 직함을 무엇으로 적을지부터 막혔습니다.

나눠 둔 채로 두 명을 뽑아 봐도 다른 문제가 생겼습니다. 화면을 그리는 쪽에 "이 단계가 왜 필요한가" 를 물으면 앞에서 정해진 것이라 답하지 못하고, 흐름을 설계한 쪽에 물으면 그 화면을 본 적이 없어 답하지 못합니다. 결정을 내린 사람과 그 결정을 화면으로 옮긴 사람이 다르니, 개발이 구현 중에 던지는 질문마다 두 사람을 거쳐야 했습니다. 일 자체보다 주고받는 비용이 커졌습니다.

그래서 문제 정의부터 화면까지를 한 사람이 들고 가는 자리가 생겼습니다. 구성원 100명 아래 회사에서 가장 흔한 디자인 직함이고, UX 디자이너와 UI 디자이너가 아직 갈라지지 않은 상태로 보면 맞습니다. 사람이 늘면 조사와 문구가 먼저 떨어져 나갑니다. 오전에 인터뷰 세 건을 하고 오후에 화면을 그리라고 하면 대개 마감이 급한 화면만 남기 때문입니다.

화면을 그리는 시간이 하루의 절반을 넘지 않습니다. 나머지는 왜 이렇게 만드는지를 합의하고, 만든 것이 제대로 붙는지 확인하는 데 들어갑니다. 하루에 오가는 일은 대개 여섯 종류입니다.

1. 문제를 확인합니다. 지표에서 어느 단계가 빠지는지 보고, 지난주 문의에서 같은 말이 몇 번 나왔는지 셉니다. 첫 문서를 만드는 비율이 34퍼센트라는 숫자가 있으면 어디서 멈추는지부터 찾습니다.
2. 흐름을 설계합니다. 화면 몇 장을 어떤 순서로 둘지, 중간에 어디서 갈라질지를 정합니다. 여기서 프로토타입을 쓰는데, 종이에 손으로 그려 다섯 명에게 보여 주는 정도로 순서 문제는 대개 드러납니다.
3. 화면을 그립니다. 처음부터 그리는 것이 아니라 디자인 시스템에 있는 부품을 조립합니다. 버튼과 입력칸을 매번 새로 정하면 3년 뒤에 회색 열일곱 가지를 쓰는 제품이 됩니다.
4. 문구를 씁니다. 전담하는 사람이 없으면 이 일도 여기로 옵니다. "오류가 발생했습니다" 대신 "파일이 20MB를 넘어 올릴 수 없습니다" 라고 쓰는 일이 화면을 고치는 일보다 문의를 크게 줄이는 경우가 많습니다.
5. 넘기고 답합니다. 시안을 넘긴 뒤가 오히려 질문이 많습니다. 목록이 0건일 때는 무엇을 보여 주는지, 이름이 40자를 넘으면 어디서 자르는지 같은 것들입니다.
6. 나간 뒤를 봅니다. 고친 화면의 숫자가 움직였는지 2주쯤 뒤에 확인합니다.

여섯 가운데 3번만 디자이너의 일로 보는 조직에서는 1번과 5번이 아무에게도 배정되지 않습니다. 그러면 화면은 예정대로 나오는데 그 화면이 무엇을 풀려던 것이었는지가 남지 않습니다.

하루에 말을 섞는 상대가 넷입니다. 페이지덱에서 민서를 보면 이렇게 갈립니다.

1. 프로덕트 매니저. 지현과는 무엇을 왜 만드는지를 맞춥니다. 이 단계에서 문제를 좁히는 대화가 가장 오래 걸리고, 여기서 합의가 덜 되면 뒤의 모든 작업이 한 번씩 되돌아옵니다.
2. 개발자. 태오와는 어디까지 가능한지와 언제까지인지를 맞춥니다. 시안을 넘기기 전에 한 번 보여 주는 편이 낫습니다. 지금 구조로 안 되는 화면을 다 그린 뒤에 알게 되면 그리는 시간이 통째로 날아갑니다.
3. 그로스 마케터. 현우와는 실험할 화면을 나눕니다. 두 안을 만들어 나눠 보여 주는 실험에서는 디자이너가 한 안을 더 그립니다.
4. 세일즈와 고객 성공. 수아가 들고 오는 고객 요청은 화면 요청 형태로 도착합니다. 요청받은 화면을 그대로 그리기 전에 그 고객이 무엇을 못 하고 있었는지를 되묻는 일이 이 자리의 몫입니다.

결정 경계가 자주 흐려집니다. 무엇을 만들지는 프로덕트 매니저가 정하고, 그것이 어떻게 보이고 어떤 순서로 흘러갈지는 디자이너가 정합니다. 겹치는 자리는 범위를 줄일 때입니다. 화면 셋 가운데 하나를 빼는 결정이 흐름을 끊는지는 그린 사람이 가장 잘 알아서, 무엇을 뺄지는 두 사람이 함께 정합니다.

"이번 건은 프로덕트 디자이너가 문제 정의부터 같이 들어갑니다."

시안을 받아 그리는 자리가 아니라 무엇을 풀지 정하는 자리부터 참여한다는 뜻입니다.

"화면은 다 나왔는데 빈 상태랑 오류 문구가 안 정해졌어요."

정상 경로만 그려져 있고 나머지 상태가 빠졌다는 지적입니다.

"이건 예쁘게 만드는 문제가 아니라 단계를 하나 빼는 문제입니다."

시각적 개선으로 풀 문제가 아니라는 판단입니다.

페이지덱이 문서 공유 흐름을 고칠 때가 그랬습니다. 지현이 공유 성공률이 낮다는 문제를 들고 왔고, 민서가 종이에 여섯 장을 그려 옆 팀 세 사람에게 보여 줬습니다. 세 사람 모두 권한 고르는 화면에서 멈췄고, 그 자리에서 순서를 뒤집었습니다. 다듬는 작업은 그다음 주에 시작했습니다.

넘긴 뒤에도 일이 이어졌습니다. 태오가 구현 중에 초대받은 사람이 로그인하지 않은 상태로 링크를 열면 어디로 보낼지를 물었고, 시안에 없던 화면 한 장이 그날 추가됐습니다.

화면을 예쁘게 만드는 사람으로 읽는 경우가 가장 많습니다. 결과물이 눈에 보이는 화면이니 자연스러운 오해입니다. 하지만 이 자리에서 내리는 결정의 대부분은 무엇을 넣을지가 아니라 무엇을 빼고 무엇을 접어 둘지입니다. 예쁘게 만드는 사람으로 대하면 문제를 정의하는 자리에 부르지 않게 되고, 그러면 잘 그려진 불필요한 화면이 나옵니다.

시안을 넘기면 일이 끝난다고 보는 것도 흔합니다. 넘기는 시점이 눈에 보이는 마감이라 그렇게 잡힙니다. 하지만 빈 목록, 글자가 너무 긴 경우, 권한이 없는 사용자가 열었을 때처럼 정상 경로가 아닌 상태가 구현 단계에서 줄줄이 나옵니다. 이 질문에 답할 사람이 다음 일로 넘어가 있으면 개발자가 임의로 정하게 되고, 두 달 뒤에 같은 제품 안에서 빈 화면이 세 가지 모양으로 나옵니다.