디자인 프로세스

디자인이 화면을 보기 좋게 만드는 일로만 통하던 시절이 있었습니다. 기획이 문서에 기능을 적어 넘기면 디자이너가 그 문서대로 화면을 그리고, 개발이 그 화면을 코드로 옮기는 순서였습니다. 디자이너가 받는 것은 이미 정해진 답이었고, 할 일은 그 답을 보기 좋게 배치하는 것이었습니다.

이 순서에서는 시안 회의가 늘 같은 자리에서 막혔습니다. 디자이너가 화면 세 장을 띄우면 참석자들이 한 마디씩 보탭니다. 대표는 파란색이 답답하다고 하고, 개발자는 두 번째 안이 만들기 쉽다고 하고, 영업은 고객이 이런 걸 좋아한다고 합니다. 누구 말이 맞는지 가릴 근거가 없으니 결국 직급이 가장 높은 사람의 취향으로 정해지고, 두 주 뒤에 그 사람 마음이 바뀌면 처음부터 다시 그립니다.

더 큰 손실은 다른 데서 났습니다. 틀린 문제를 정성껏 푸는 일이 자주 일어났습니다. 어느 팀이 두 달을 들여 초대 화면을 새로 만들었는데, 정작 사람들이 팀원을 초대하지 않던 이유는 화면이 불편해서가 아니라 초대할 사람의 회사 메일 주소를 몰라서였습니다. 화면을 아무리 다듬어도 그 이유는 해결되지 않습니다. 무엇이 문제인지 확인하는 단계가 순서 안에 없었기 때문에 두 달을 다 쓰고 나서야 알게 된 것입니다.

디자인 프로세스는 그리기 전에 밟을 칸을 명시적으로 두자는 생각에서 나왔습니다. 조사해서 무엇이 문제인지 확인하고, 그중 어느 문제를 풀지 좁히고, 여러 안을 만들어 보고, 사용자에게 시험해 보고, 그 결과에 따라 고쳐서 내보냅니다. 조사 단계에서 쓰는 도구는 UX 리서치 기법이 따로 모아 두고 있습니다. 사용자를 만나 묻는 인터뷰, 만든 화면을 실제로 써 보게 하고 막히는 지점을 지켜보는 사용성 테스트 같은 것들입니다.

칸을 나눠 두면 회의에서 오가는 말이 달라집니다. 파란색이 답답하다는 감상 대신 사용자 다섯 명 중 넷이 결제 버튼을 3초 안에 찾지 못했다는 관찰이 근거가 됩니다. 취향으로는 이길 수 없지만 관찰로는 이길 수 있고, 무엇보다 다음에 무엇을 고쳐야 하는지가 그 문장 안에 들어 있습니다.

디자인 프로세스 아래 묶인 용어는 두 갈래입니다. 순서를 어떤 모양으로 짤 것인가(방법론)와 그 순서 안에서 남의 눈을 어떻게 빌릴 것인가(협업)입니다. 앞쪽은 혼자서도 돌릴 수 있는 틀이고, 뒤쪽은 사람이 둘 이상 모여야 성립하는 자리입니다.

방법론은 셋입니다. 셋 다 같은 흐름을 다루지만 무엇을 강조하는지와 몇 주를 쓰는지가 다릅니다. 셋 중 하나를 골라야 하는 것도 아닙니다. 태도는 디자인 씽킹에서 빌리고, 어느 칸에 있는지는 더블 다이아몬드로 확인하고, 급한 주제 하나는 디자인 스프린트로 밀어붙이는 식으로 겹쳐 쓰는 팀이 많습니다.

1. 디자인 씽킹 — 사용자에게 공감하는 데서 출발하자는 접근입니다. 공감하고, 문제를 정의하고, 아이디어를 내고, 만들어 보고, 시험한다는 다섯 단계로 흔히 소개됩니다. 네 번째 단계에서 만드는 것은 완성품이 아니라 프로토타입입니다. 반응을 보려고 임시로 구현한 것을 뜻하고, 종이에 손으로 그린 화면도 여기 들어갑니다. 앞의 두 단계에 시간을 많이 쓰는 것이 이 접근의 성격입니다. 무엇을 만들지 정하기 전에 누가 무엇 때문에 불편한지를 먼저 붙잡습니다.
2. 더블 다이아몬드 — 같은 흐름을 넓혔다 좁히기를 두 번 되풀이하는 모양으로 그린 모형입니다. 첫 번째 다이아몬드에서 문제를 넓게 조사했다가 하나로 좁히고, 두 번째에서 해법을 여럿 펼쳤다가 하나로 좁힙니다. 그림으로 그려 두는 쓸모는 팀이 어느 칸을 건너뛰는지 눈에 보인다는 데 있습니다. 대개 첫 번째 다이아몬드를 통째로 건너뛰고 해법부터 펼치는데, 그러면 모두가 열심히 안을 내는 동안 아무도 그 안들이 무슨 문제를 푸는지 말하지 못하는 상태가 됩니다.
3. 디자인 스프린트 — 같은 흐름을 닷새 안에 몰아서 끝내는 워크숍 형식입니다. 월요일에 문제를 정하고, 화요일에 각자 안을 그리고, 수요일에 하나를 고르고, 목요일에 만들고, 금요일에 사용자 다섯 명에게 보여 줍니다. 몇 달을 끄는 논쟁을 한 주에 끝내려고 만든 장치라, 넉 달째 결론이 나지 않는 주제에 쓰면 값이 큽니다. 다만 닷새 동안 대여섯 명의 일정을 통째로 비워야 해서 아무 주제에나 꺼낼 수는 없습니다.

협업은 셋입니다. 셋 다 만든 것을 남에게 보이는 자리인데, 무엇을 얻으려고 보이는지에 따라 이름이 갈립니다.

1. 디자인 크리틱 — 의도와 근거를 놓고 함께 뜯어보는 자리입니다. 여기서는 승인이 나오지 않습니다. 잘했는지 못했는지를 가리는 대신 어떤 사용자가 어디서 막힐지를 찾습니다. 그래서 말하는 방식이 정해져 있습니다. "이 버튼 안 보여요" 가 아니라 "결제 화면에서 다음 단계 버튼을 3초 안에 찾지 못했습니다" 처럼, 자기가 무엇을 하려다 어디서 막혔는지를 말합니다.
2. 디자인 리뷰 — 결정 전에 관계자가 함께 확인하는 절차입니다. 크리틱과 달리 끝에 결론이 붙습니다. 이대로 개발에 넘길지, 무엇을 고쳐서 다시 볼지가 그 자리에서 정해집니다. 그래서 참석자도 다릅니다. 크리틱에는 같은 일을 하는 동료가 모이고, 리뷰에는 개발과 기획처럼 그 결정으로 일이 바뀌는 사람이 모입니다.
3. 코디자인 — 사용자나 이해관계자를 설계하는 자리에 직접 앉히는 방식입니다. 의견을 듣고 돌아와 디자이너가 반영하는 것과는 다릅니다. 그 사람이 종이 위에 화면을 같이 그립니다. 고객사 담당자 셋을 불러 권한 설정 화면을 함께 그려 보면, 디자이너가 두 주 동안 고민하던 배치 문제가 30분 만에 정리되는 일이 생깁니다. 그 사람들은 자기 회사에서 누가 누구에게 권한을 주는지 이미 알고 있기 때문입니다.

두 갈래는 따로 돌지 않습니다. 방법론이 언제 무엇을 할지 칸을 정하면, 협업은 그 칸마다 누구의 눈을 빌릴지를 정합니다. 더블 다이아몬드에서 해법을 펼치는 동안에는 크리틱이 맞고, 하나로 좁힌 직후에는 리뷰가 맞습니다. 순서를 바꿔 펼치는 단계에 리뷰를 열면 아직 고르지도 않은 안을 두고 승인 여부를 묻게 되고, 좁힌 뒤에 크리틱을 열면 이미 정해진 것을 두고 의견만 쌓입니다. 코디자인은 첫 번째 다이아몬드, 그러니까 무엇이 문제인지 좁히는 자리에서 가장 값이 큽니다.

"이번 건은 프로세스 한 바퀴 제대로 돌립시다. 화면은 리서치 끝나고 그려요."

시안부터 그리지 말고 무엇이 문제인지 확인하는 칸을 건너뛰지 말자는 말입니다.

"오늘은 크리틱이지 리뷰가 아닙니다. 결론 내는 자리 아니에요."

안을 넓히려고 연 자리이니 승인 여부를 묻지 말라는 뜻입니다.

"앞쪽 다이아몬드는 건너뛰죠. 문제는 이미 알고 있으니까요."

조사 단계를 생략하자는 제안인데, 안다는 근거가 무엇인지가 바로 뒤따라 나와야 하는 말입니다.

페이지덱에서 무료 사용자를 유료 플랜으로 넘어오게 하는 과제를 맡았을 때 이 말이 자주 나왔습니다. 규원이 결제 화면을 새로 그려 보자고 했고, 민서는 화면을 그리기 전에 한 주만 달라고 했습니다. 그 한 주 동안 유료 전환을 하다 만 팀 여섯 곳에 전화를 걸어 물었더니, 여섯 중 넷이 결제 정보를 넣을 사람이 자기가 아니라고 답했습니다. 화면이 불편한 것이 아니라 결제 담당자를 따로 지정할 수 없는 것이 문제였습니다. 이 한 문장이 문제 정의가 됐고, 그 뒤로 그린 화면 세 장은 전부 담당자를 지정하는 흐름을 다뤘습니다.

그 세 장을 두고 먼저 연 자리는 크리틱이었습니다. 민서와 다른 디자이너 둘이 모여 각 안에서 사용자가 어디서 막힐지를 찾았고, 결론은 내지 않았습니다. 사흘 뒤에 지현과 태오가 들어온 리뷰에서 하나를 골랐습니다. 태오가 두 번째 안은 권한 구조를 바꿔야 해서 2주가 더 든다고 말했고, 그 자리에서 첫 번째 안으로 정해졌습니다. 크리틱에서 이 말이 나왔다면 아직 다듬지도 않은 안이 구현 비용 때문에 먼저 잘려 나갔을 것입니다. 두 자리를 굳이 나눠 연 이유가 여기 있습니다. 안을 넓히는 자리와 하나로 줄이는 자리를 한 회의에 합치면, 대개 줄이는 쪽이 이깁니다.

프로세스를 한 번 훑고 끝나는 직선으로 읽는 경우가 가장 많습니다. 어느 그림에서든 단계가 왼쪽에서 오른쪽으로 흐르는 화살표로 그려져 있으니 그렇게 읽힙니다. 실제로는 뒤 칸에서 앞 칸으로 되돌아가는 일이 정상 동작입니다. 시험 단계에서 사용자 다섯 명이 전부 다른 것을 기대했다면 그것은 화면이 틀렸다는 신호가 아니라 문제 정의가 틀렸다는 신호이고, 두 칸 앞으로 돌아가야 합니다. 이 오해를 그대로 두면 되돌아가는 일이 실패로 취급되어 아무도 되돌아가자고 말하지 않게 됩니다. 그러면 틀린 정의 위에 그린 화면이 그대로 출시되고, 같은 사실이 반년 뒤에 고객 문의로 들어옵니다.

프로세스를 전부 밟아야 제대로 한 것이라는 오해도 흔합니다. 단계가 이름까지 붙어 적혀 있으니 체크리스트처럼 보이는 탓입니다. 그러나 밟을 칸의 수는 결정의 무게를 따라갑니다. 버튼 문구 하나를 바꾸는 데 닷새짜리 워크숍을 열 이유는 없고, 그 결정은 크리틱 20분이면 충분합니다. 반대로 가입 흐름 전체를 다시 짜는 일에 리뷰 한 번만 붙이면 두 달 뒤에 되돌릴 수 없는 상태로 굳습니다. 이 오해를 그대로 두면 절차 비용이 실제 결정의 무게보다 커지고, 팀은 일정에 쫓길 때마다 프로세스를 몰래 건너뜁니다. 문서에 적힌 순서와 실제로 굴러가는 순서가 따로 노는 상태가 이렇게 만들어집니다. 이렇게 되면 정작 크게 틀릴 수 있는 결정에서도 절차를 건너뛰는 습관이 그대로 나옵니다. 판단 기준을 하나 두면 덜 흔들립니다. 되돌리는 데 드는 비용이 큰 결정일수록 앞 칸을 길게 쓰고, 한 주 안에 되돌릴 수 있는 결정은 짧게 지나갑니다.