UI.UX / 화면 설계서 이야기.4

PART.5 태스크 플로우(Task Flow)의 중요성

기획자라면 한 번쯤 들어봤을 것이다.

“태스크 플로우가 중요합니다.”

하지만 정작 왜 중요한지,

왜 화면보다 먼저 만들어져야 하는지,

어떤 사고 기준으로 설계해야 하는지

명확하게 이해 못한 채로 “그냥 하니까 한다”는 경우를 많이 본다.

오늘은 바로 그 본질을 이야기해보려고 한다.

태스크 플로우가 뭐냐고?

UI/UX 기획은 결국

사용자의 목표 달성을 설계하는 일이다.

예를 들어,

유저는 콘텐츠를 저장하고 싶다.

굿즈를 구매하고 싶다.

포인트를 적립하고 싶다.

로그인하고 싶다.

이렇게 “목표”부터 존재한다.

그리고 목표에 도달하기 위한

사용자의 행동 여정을 구조화한 것이 바로

태스크 플로우

(사용자의 목표를 이루기 위한 행동 흐름도)

즉,

사용자가 걸어가야 할 길을

먼저 그려주는 작업이다.

그런데… 용어에 집착할 필요 없다

회사마다 부르는 이름이 제각각이다.

유저 플로우

플로우 차트

스크린 플로우

그 화살표 도식(?)

심지어 “이 선 따라가는 거”라고 부르기도 한다.

네이밍 전쟁은 끝이 없다.

그러니까 중요한 건 용어가 아니라

“목적이 명확한 흐름인가?”

“모두가 같은 길을 보고 있는가?”

지금 무엇을 부르느냐보다

그게 무엇을 해결하려는 산출물인가가 훨씬 더 중요하다.

화면부터 만들면 생기는 진짜 문제

많은 주니어 기획자들이

“일단 화면을 그리고 플로우는 나중에 넣어볼게요!”

라고 당당히 말한다.

내 경험상…

그건 매우 멋지게 망하는 방법이다.

실제로 아래와 같은 비극이 발생한다.

1) 목적이 사라진다

화면을 만들다 보면

언제부턴가 아래 질문이 사라진다.

“아 이 화면은 왜 필요한 거죠?”

누구도 대답 못 한다.

그냥 있으니까 존재하는 것이다.

그걸 우리는 좀비 화면이라 부른다.

(정말 무섭다)

2) 분기가 뒤늦게 튀어나온다

로그인 X?

데이터 없음?

권한 제한?

“어… 그건 나중에 고려하면 안 될까요?”

라고 말하는 순간,

내일 이 프로젝트는 지옥 난이도가 된다.

3) 개발은 분노하고, PM은 탈모가 진행된다

흐름이 없으니 요구사항이 맵핑되지 않는다.

정책이 안 맞는다.

QA에서 줄줄이 폭탄이 터진다.

달력을 보며 한숨이 깊어진다.

태스크 플로우는 결국

사고의 순서를 바로잡는 장치이다.

목적 → 흐름 → 화면

이 순서가 정답이다.

하지만 기획 경험이 부족하면

모두 이렇게 해버린다.

화면 → 화면 → 화면 → … → 갑자기 정책

이건 망한다. 100%.

숲을 먼저 보고, 나무를 심어야 한다

태스크 플로우 없이 화면부터 만들면

방향이 없다.

목적지가 없다.

길이 없다.

그리고 모두가 각자 다른 숲을 바라보고 있다.

디자인은 북쪽 숲

개발은 서쪽 숲

기획은 남쪽 숲

그러다 결국

동쪽에 있던 PM이 죽는다…

(메타포입니다… 하지만 가끔 진짜 같음)

다시 말한다.

나무(화면)를 보지 말고, 숲(흐름)을 먼저 봐라.

숲이 있어야 나무도 제자리를 찾는다.

기획이란

사용자가 가는 방향성을 설계하는 것이다.

화면은 그 방향성을 보조하는 수단일 뿐이다.

예시로 확인하는 태스크 플로우

콘텐츠 저장하기를 예로 들어보자.

사용자가 저장 버튼을 눌렀다.

그다음은 어떻게 흘러가야 할까?

로그인 상태라면 → 바로 저장 성공 → 피드백 노출 → 끝

로그인 안 되어 있다면 → 로그인 화면 → 다시 원래 화면 복귀 → 성공 여부 피드백 → 끝

실제로 이렇게 짧고 간결하게

흐름이 떨어져야 한다.

흐름이 단순해야

협업이 단순해진다.

흐름이 명확해야

실행이 명확해진다.

태스크 플로우는 기획자의 안전장치다

초기에 제대로 그려놓으면

요구사항이 흐름 기준으로 정리된다

개발 API/정책 논의가 빨라진다

디자인이 불필요한 화면 그리지 않는다

모든 협업자가 같은 그림을 본다

기획의 전체 안정성이 확보된다.

정말 중요해서 다시 말한다.

태스크 플로우는

기획자의 모든 실수를 미리 방지하는 보험이다.

보험료는 꽤 싸다.

하지만 보상은 매우 크다.

마무리

기획자는 화면을 만드는 사람이 아니다.

사용자의 목적을

가장 빠르고 정확하게 달성하게 만드는 사람이다.

따라서 처음 질문은

“화면을 어떻게 만들까?”가 아니다.

“사용자가 어디로 가야 하는가?”

“이 일을 왜 하는가?”

“어떤 상태에서 시작하고 어떤 상태로 끝나는가?”

를 먼저 물어야 한다.

태스크 플로우는

그 질문의 답을 시각화한 산출물이다.

오늘 핵심 정리

화면은 나무

흐름은 숲

우리는 숲을 먼저 설계해야 한다

흐름이 명확하면

화면은 뒤따라온다.

다음 글에서는

키스크린(Key Screen) 선정 방법과

왜 그것이 화면 설계의 출발점인지

재미있게 소개해보겠다.

끝.