태스크 플로우

시안은 오래 화면 단위로 오갔습니다. 디자이너가 화면 12장을 그려 넘기면 개발자는 각 장이 무엇인지는 알아도 그 장들이 어떤 순서로 이어지는지는 알 수 없었습니다. 파일 이름이 공유_01, 공유_02 로 붙어 있으니 순서가 있는 것처럼 보이지만, 실제로 02 가 01 다음인지 01 에서 갈라진 다른 경우인지는 그린 사람 머릿속에만 있었습니다.

그래서 핸드오프 회의는 같은 질문을 반복했습니다. "이 화면 다음에 뭐가 오나요" 하고 물으면 "상황에 따라 다른데요" 라는 답이 돌아오고, 상황이 몇 가지인지를 다시 묻다 보면 한 시간이 지나 있었습니다. 만드는 쪽은 결국 자기 판단으로 순서를 정했고, 검수 단계에서 그 순서가 틀렸다는 사실이 드러나 다시 만들었습니다.

태스크 플로우는 화면 대신 과업을 단위로 삼아 이 문제를 풀었습니다. 사용자가 실제로 하려는 일 하나를 골라 시작부터 끝까지 한 줄로 늘어놓습니다. 갈림길은 일부러 걷어냅니다. 몇 단계로 끝나는지 세는 것이 목적이라서, 예외를 다 그려 넣으면 그 숫자를 세지 못하게 됩니다.

과업 하나를 동사로 적는 것에서 시작합니다. "문서를 다른 팀원에게 공유한다" 처럼 사용자가 하려는 일을 끝나는 형태로 적습니다. "공유 기능" 처럼 명사로 적으면 어디까지가 한 과업인지 정해지지 않습니다.

그다음은 네 단계입니다.

1. 시작점과 끝점을 못 박습니다. 시작은 문서가 열려 있는 상태, 끝은 상대가 링크를 받은 상태로 잡습니다. 양쪽을 정하지 않으면 로그인부터 그려야 할지 아닐지가 매번 논쟁이 됩니다.
2. 그 사이를 사용자 행동 단위로 끊습니다. 화면 단위가 아니라 행동 단위인 점이 중요합니다. 한 화면에서 이름을 적고 권한을 고르고 보내기를 누르면 그건 세 단계입니다.
3. 단계마다 세 가지를 한 줄로 적습니다. 어느 화면인지, 사용자가 무엇을 하는지, 제품이 무엇으로 답하는지입니다. 세 번째를 빼면 눌렀는데 아무 반응이 없는 구간이 설계 단계에서 걸러지지 않습니다.
4. 단계 수를 셉니다. 공유하기 버튼을 눌러 팀원 선택, 권한 선택, 메시지 입력, 보내기까지 다섯 단계라면 이 숫자가 다음 논의의 재료가 됩니다.

줄일 후보를 찾는 방식은 정해져 있습니다. 사용자가 답을 이미 아는 단계와 대부분이 기본값을 그대로 두는 단계를 봅니다. 권한을 고르는 단계에서 열 명 중 아홉이 보기 권한을 그대로 둔다면 그 단계는 기본값으로 접어 두고 바꾸고 싶은 사람만 펼치게 만들 수 있습니다. 다섯 단계가 셋이 되는 판단이 이렇게 나옵니다.

갈림길이 필요해지면 그건 태스크 플로우를 벗어난 신호입니다. 로그인 여부로 길이 갈리고 결제 정보가 없어 막히는 지점까지 담으려면 유저 플로우로 옮겨 그립니다. 태스크 플로우는 한 줄로 유지해야 세는 도구로 남습니다.

네 자리에서 주로 씁니다.

첫째는 온보딩의 첫 과업을 정할 때입니다. 온보딩은 새 사용자가 제품에 자리 잡도록 돕는 과정인데, 처음 만나는 과업이 일곱 단계면 절반이 도중에 나갑니다. 단계를 세어 둔 상태에서만 어디를 접을지 정할 수 있습니다.

둘째는 와이어프레임을 그리기 전 순서를 합의할 때입니다. 와이어프레임은 꾸밈 없이 구조와 배치만 그린 도면인데, 순서를 정하지 않고 도면부터 그리면 화면 여섯 장을 다 그린 뒤에 두 장이 필요 없다는 사실을 알게 됩니다.

셋째는 사용성 테스트의 과업 대본을 쓸 때입니다. 참가자에게 시킬 일을 한 문장으로 주고 어느 단계에서 멈추는지 보는 방식이라서, 단계가 미리 끊겨 있어야 몇 번째에서 막혔는지 기록할 수 있습니다.

넷째는 경쟁 제품과 견줄 때입니다. 같은 과업을 상대 제품에서 몇 단계로 끝내는지 세어 나란히 놓으면 감상 대신 숫자로 이야기할 수 있습니다.

"공유하는 태스크 플로우가 지금 다섯 단계인데 셋으로 줄일 수 있을까요?"

과업 하나에 드는 단계 수를 줄이자는 제안입니다.

"이건 태스크 플로우가 아니라 유저 플로우로 그려야 해요. 갈림길이 세 개예요."

한 줄로 담을 수 없는 범위라서 도구를 바꾸자는 지적입니다.

"태스크 플로우에 제품 반응이 안 적혀 있어서 로딩 화면이 빠졌습니다."

각 단계에 제품이 무엇으로 답하는지 적지 않으면 그 자리가 구현에서 비어 버린다는 문제 제기입니다.

페이지덱에서는 민서가 문서 공유를 다시 설계하면서 이 도구를 먼저 꺼냈습니다. 기존 경로를 적어 보니 공유 버튼, 팀원 검색, 팀원 선택, 권한 선택, 메시지 입력, 보내기로 여섯 단계였습니다. 여섯 줄을 나란히 놓고 보니 메시지 입력은 실제 사용 기록에서 12퍼센트만 쓰고 있었습니다.

지현이 물은 것은 권한 선택이었습니다. 기록을 보니 87퍼센트가 기본값인 보기 권한을 그대로 뒀고, 그래서 권한과 메시지를 접어 두고 필요한 사람만 펼치는 쪽으로 정리해 여섯 단계가 셋이 됐습니다. 태오는 이 세 줄을 그대로 받아 구현 순서를 잡았고, 화면 몇 장이 필요한지를 되묻지 않았습니다.

단계가 적을수록 좋은 설계라고 읽는 경우가 가장 많습니다. 단계 수를 세는 도구이니 그 숫자를 낮추는 것이 목표처럼 보입니다. 그런데 단계를 줄이는 가장 쉬운 방법은 여러 결정을 한 화면에 몰아넣는 것이고, 그렇게 하면 단계 수는 셋으로 줄지만 한 화면에서 결정할 것이 여섯 개가 됩니다. 사람이 한 번에 붙잡는 항목에는 한계가 있어서, 세 단계짜리 화면에서 오히려 멈춰 서서 나가는 비율이 늘어난 사례가 흔합니다. 세어야 할 것은 단계 수와 각 단계에서 내리는 결정의 수 둘입니다.

다 그렸으면 설계가 끝났다고 보는 것도 오해입니다. 태스크 플로우에는 예외가 없어서, 파일이 용량을 넘거나 권한이 없거나 연결이 끊긴 경우가 통째로 빠져 있습니다. 그 자리를 채우지 않고 넘기면 만드는 사람이 자기 판단으로 정하고, 같은 제품 안에서 화면마다 다른 오류 문구가 뜨게 됩니다.