더블 다이아몬드

디자인 작업이 어디까지 왔는지 밖에서는 보이지 않던 시절이 있었습니다. 기획이 요구사항을 넘기면 디자이너가 며칠 뒤 화면을 들고 나타났고, 그사이에 무슨 일이 있었는지는 본인 말고 아무도 몰랐습니다.

그래서 회의는 늘 같은 모양이 됐습니다. 화면이 나온 뒤에야 "이게 정말 우리가 풀려던 문제였나" 하는 질문이 나오고, 그 질문이 나오면 이미 3주가 지나 있었습니다. 되돌아가자니 아까워 대개는 그냥 밀고 갔습니다.

영국 디자인 카운슬이 2005년에 이 과정을 다이아몬드 두 개로 그려 내놓으면서 그 중간이 눈에 보이게 됐습니다. 벌리는 구간과 좁히는 구간을 번갈아 배치하고, 앞쪽 한 쌍은 문제에, 뒤쪽 한 쌍은 해법에 배정한 그림입니다.

그림이 하는 일은 팀이 지금 어느 칸에 있는지, 어느 칸을 건너뛰었는지를 보여 주는 것입니다. 대부분의 팀이 건너뛰는 칸은 정해져 있습니다. 앞의 다이아몬드를 통째로 넘기고 해법부터 펼치는 것인데, 그러면 모두가 열심히 안을 내는 동안 그 안들이 무슨 문제를 푸는지는 아무도 말하지 못하는 상태가 됩니다.

네 칸을 순서대로 지납니다. 칸마다 무엇을 만들어 내야 다음으로 넘어가는지가 정해져 있습니다.

1. 발견 — 문제를 넓힙니다. 사용자 리서치로 사용자를 관찰하고 물어 근거를 모읍니다. 고객 인터뷰 여덟 건, 문의 게시판 300건 읽기, 데이터에서 이탈 지점 찾기 같은 일이 여기 들어갑니다. 판단을 멈추고 재료만 모으는 구간입니다.
2. 정의 — 문제를 하나로 좁힙니다. 모은 재료를 묶어 비슷한 것끼리 붙이고, 그중 지금 풀 가치가 가장 큰 하나를 고릅니다. 산출물은 한 문장짜리 문제 정의입니다. 페이지덱이라면 "처음 들어온 사람이 남의 문서에 댓글을 달 수 있다는 걸 모른 채 나간다" 처럼 씁니다. 여기서 문장이 두 개 이상 남으면 아직 좁혀지지 않은 것입니다.
3. 개발 — 해법을 넓힙니다. 고른 문제를 두고 서로 다른 안을 여러 개 만듭니다. 스케치 열두 장, 그중 셋을 프로토타입으로 만들어 손으로 눌러 보게 하는 식입니다. 프로토타입은 반응을 보려고 임시로 구현한 것을 뜻하고, 종이에 그린 화면도 여기 들어갑니다. 안이 하나뿐이면 고른 게 아니라 떠오른 것을 그대로 쓴 셈입니다.
4. 전달 — 해법을 하나로 좁혀 내보냅니다. 사용성 테스트로 실제 과업을 시켜 보고 막히는 지점을 고친 뒤 개발로 넘깁니다. 내보낸 뒤 숫자를 보는 일까지가 이 칸입니다.

벌리는 칸과 좁히는 칸은 회의 방식이 다릅니다. 벌릴 때는 평가를 미루고 수만 늘리고, 좁힐 때는 기준을 먼저 정해 그 기준으로 자릅니다. 두 방식을 한 회의에 섞으면 안이 나오는 족족 반박당해 처음 나온 안 하나만 남습니다.

칸마다 걸리는 시간은 고정돼 있지 않지만, 두 다이아몬드에 비슷한 시간을 배정하는 것이 원래 의도입니다. 6주짜리 과제라면 3주를 문제에 쓰는 셈인데, 실제로는 문제에 나흘, 해법에 5주를 쓰는 경우가 훨씬 흔합니다.

무엇을 만들지가 아직 정해지지 않은 과제에 맞습니다. "이탈률이 높은데 왜 그런지 모르겠다" 처럼 문제의 모양부터 찾아야 하는 자리입니다. 불만이 여러 갈래로 쏟아지는데 원인이 하나로 모이지 않을 때도 같습니다.

반대로 문제가 이미 좁혀진 과제에는 과합니다. 결제 화면에서 카드 번호 입력 칸이 좁아 오타가 난다는 것을 이미 알고 있다면, 발견과 정의에 2주를 쓰는 대신 바로 고치는 편이 낫습니다.

한계는 세 가지입니다.

그림이 한 방향으로 흐르게 생겼다는 점이 첫째입니다. 실제 작업은 세 번째 칸에서 만든 프로토타입을 보고 두 번째 칸의 문제 정의를 고쳐 쓰는 식으로 왕복합니다. 그림대로 한 번에 통과하려 들면 뒤늦게 드러난 사실을 못 본 척하게 됩니다.

둘째는 칸의 경계가 실무만큼 선명하지 않다는 점입니다. 리서치를 하다 보면 해법이 떠오르고, 프로토타입을 만들다 보면 새 문제가 보입니다. 이 모형은 지금 무엇을 주로 하는지를 가리키지 다른 일을 금지하지 않습니다.

셋째는 그림이 시간 배분을 지켜 주지 않는다는 점입니다. 첫 다이아몬드를 건너뛴 팀도 그림은 그대로 쓰기 때문에, 네 칸을 다 지났다는 보고와 문제를 나흘 만에 정했다는 사실이 나란히 존재합니다.

"지금 두 번째 다이아몬드로 넘어가도 될까요? 문제 정의가 아직 세 문장인데요."

해법을 펼치기 전에 문제부터 하나로 좁히자는 제안입니다.

"이번 주는 발산 구간이라 안을 자르지 말고 수만 늘려 주세요."

평가를 뒤로 미루고 선택지를 확보하자는 요청입니다.

"첫 다이아몬드 없이 시작한 과제라 지금 근거를 다시 모으고 있어요."

문제 조사를 건너뛴 대가를 뒤늦게 치른다는 뜻입니다.

민서가 페이지덱에서 이 말을 가장 자주 꺼내는 자리는 과제 시작 회의입니다. 지현이 "검색 기능을 개선하자" 고 주제를 던지면 민서가 그게 어느 칸에서 시작하는 일인지를 묻습니다. 검색이 안 쓰이는 이유를 아직 모른다면 첫 번째 다이아몬드부터, 검색 결과 정렬이 문제라는 데 이미 합의가 돼 있다면 세 번째 칸부터 시작합니다.

칸을 정해 두면 그 주의 회의 종류도 따라 정해집니다. 벌리는 구간에는 의도와 근거를 함께 뜯어보는 디자인 크리틱을 잡고, 좁힌 직후에는 개발과 기획이 결론을 내는 자리를 잡습니다.

네 칸을 순서대로 한 번 지나면 끝나는 절차로 읽는 경우가 가장 많습니다. 그림이 왼쪽에서 오른쪽으로 흐르게 그려져 있으니 그렇게 보입니다. 실제로는 뒤 칸에서 알게 된 것이 앞 칸의 결론을 바꾸는 일이 흔하고, 그때 돌아가는 것이 정상입니다. 한 번에 통과해야 한다고 믿으면 세 번째 칸에서 문제 정의가 틀렸다는 걸 알고도 일정 때문에 그대로 갑니다. 그 상태로 내보낸 기능은 대개 쓰이지 않고, 반년 뒤에 같은 문제를 처음부터 다시 다루게 됩니다.

발산 구간을 아이디어 회의로 읽는 것도 자주 보입니다. 넓히는 칸이라는 말이 다 같이 모여 떠오르는 대로 말하는 자리처럼 들리기 때문입니다. 첫 번째 다이아몬드에서 넓혀야 하는 것은 아이디어가 아니라 사실입니다. 사용자가 실제로 어디서 막히는지, 문의가 어떤 말로 들어오는지 같은 재료를 늘리는 구간입니다. 이 칸을 회의실 안에서만 채우면 한 시간 뒤에 남는 것은 팀이 원래 갖고 있던 생각 여덟 개뿐입니다.