brunch

매거진 서비스 기획

라이킷 21 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 기획하는 족제비 May 13. 2024

6. 서비스 기획자를 위한 도식화 기초

플로우 차트

지식 공유를 위해 경험과 자료를 정리하며 작성한 글이다.
이번 글에선 아래 내용을 확인할 수 있다.

1. 플로우 차트의 개념
2. 종류
3. 작성 규칙
4. 툴

플로우 차트? 도식화?

도식화란 사물의 구조, 개념, 관계를 그림이나 양식으로 표현한 걸 의미한다. 예를 들어 차트, 플로우 차트, 와이어 프레임을 말할 수 있다.

사실 대부분의 내용은 글만으로도 표현할 수 있다. (기획자라면 마땅히 할 수 있어야 한다.) 하지만 기획서를 보는 이해관계자들의 작문과 독해 수준이 모두 다르다. 여러 명이 힘을 합쳐 하나의 산출물이 나오기 위해선 동일한 수준의 이해가 필요하다. 그래서 우린 ‘시각 자료’를 활용한다. ‘백문이불여일견’을 생각하자.

플로우 차트란?

플로우 차트란 서비스를 사용하기 위한 ‘일련의 단계와 결정’을 미리 정의한 기호와 선을 사용해 시각적으로 표현한 자료를 의미한다. 순서도, 흐름도라고도 부르기도 한다. 서비스 기획자 내지 *PM의 주요 산출물을 검색하면 I.A, 스토리보드와 함께 빠지지 않고 나오는 개념이다.

*여기서 PM은 Product Manager를 의미한다.

이를 그리면서 경험한 장점을 크게 아래와 같다.

기획서를 보는 개발자나 이해관계자가 기획의 전체 구조를 빠르게 파악할 수 있다.

프로세스상 발생할 수 있는 문제나 누락된 프로세스를 사전에 파악할 수 있다.

사용자 경험을 미리 점검할 수 있다.

잘 그려진 플로우 차트는 서비스 로직의 흐름과 유사하다. 즉, 플로우 차트를 잘 그리면 개발자의 설계 초입을 도울 수 있다.

작성 규칙

도식이 가지는 개념은 사진과 같다. 하지만 개인의 성격과 조직 문화(관습)에 따라 생략하거나 대체하기도 한다.

플로우 차트 종류 ⓒ 위키피디아

플로우 차트의 종류

일반적으로 플로우 차트의 종류까지 세세하게 구분해서 작성하지 않는다. 조직과 본인의 성격에 맞춰 작성하는 게 더 보편적이다. 그래도 종류를 알아두면 작성할 때 도식의 목적을 분명하게 보여줄 수 있으니, 개념 정도는 알아두는 걸 추천한다.

유저 플로우 차트

사용자 행동을 기준으로 흐름을 도식화하여 표현한 것을 의미한다. 단일 사용자의 행동을 표현하기도 하지만, 여러 명의 사용자가 서로 다른 태스크를 수행하는 것도 표현할 수 있다.

유저 플로우 차트 샘플 ⓒ 327roy

태스크 플로우 차트

주요 태스크의 프로세스를 표현한다. 주로 복잡한 플로우를 설계하기 전 뼈대를 설계하기 위해 작성한다. 유저 플로우 차트가 사용자 여정에 초점을 맞춘다면, 태스크 플로우 차트는 단일 작업에 초점을 맞춘다.

태스크 플로우 차트 샘플 ⓒ 327roy

시스템 플로우 차트

흐름에 따라 데이터를 어떻게 처리하는지 확인할 수 있는 플로우 차트다. 데이터의 입출력 흐름을 중심으로 작성하는 게 좋다. 가장 보편적이고 익숙할 것이다.

시스템 플로우 차트 샘플 ⓒ 연디자인

어떤 플로우 차트든 글을 쓰는 것과 마찬가지로 목적과 맥락이 중요하다. 사용자 여정을 이해하기 위한 플로우를 그리고 싶은지, 시스템 설계를 돕기 위한 플로우를 그리고 싶은지 잘 생각하고 작성하자.

실습: 회원가입 플로우 차트 그리기

아래 조건을 참고해서 플로우 차트를 그려보자. 아래 조건을 보면 머릿속에 떠오르는 화면(프로세스)이 있을 것이다. 머릿속에서 이 화면을 먼저 정리하고, 이를 바탕으로 플로우 차트를 그리는 연습이다.

[조건]

회원가입 시 필수로 입력받는 정보: 아이디, 비밀번호, 이메일, 휴대폰 번호, 주소, 개인정보 수집 및 이용 약관

중복 아이디가 없어야 한다.

휴대폰 번호로 본인 인증을 완료해야 한다.

14세 이상만 회원가입할 수 있다.

1인 1계정을 원칙으로 한다.

이 실습은 강의하며 진행한 실습이기도 하다. 인상 깊었던 것은 실습은 진행하기 위해 각자 생각한 프로세스(예시 화면)가 있다는 것이었다. 누군가는 공공기관처럼 14세 미만 회원, 이상 회원(일반 회원), 기업 회원을 생각한 플로우 차트를 그렸고, 누구는 네이버처럼 약관 동의를 먼저 받는 플로우를 그렸다. 플로우 차트를 그릴 때 주안점은 '본인의 의사(생각)를 명확하게 전달하는 것'에 두고 그려달라 요청한 만큼 실습에 참여한 기획자의 생각이 잘 드러나는 실습이었다.

이모저모

기획서를 만들 때 꼭 넣어야 하나요?

놉. 그럴 필요 없다. 도식이 없어도 이해 관계자(특히 실무자)가 내용을 명확하게 이해할 수 있으면 굳이 도식화할 필요 없다. 플로우 차트 같은 '도식' 또한 기획서처럼 이해를 돕기 위한 장치일 뿐이다. 그래도 나는 여유가 있으면 그리는 편이다. 미리 그려놓으면 유용할 때가 많다.

개발자는 플로우 차트를 언제 보나요?

경험상 공통적으로 기획 리뷰할 때 보고, 제품을 설계하는 과정 초입에 많이들 확인한다. 다만 프론트엔드, 백엔드 둘 모두 특징이 다소 다르다.

보통 프론트엔드 개발자는 *마크업 작업을 함께 진행한다. 그래서 이들은 기획 리뷰를 할 때 흐름을 이해하기 위한 정도로만 플로우 차트를 가볍게 보고, 베리에이션을 포함해 디자인된 화면을 개발하며 흐름을 더 파악한다.

*마크업 작업이란 HTML, CSS 등의 언어를 사용해서 페이지의 레이아웃, 구조, 디자인을 정의하는 작업을 말한다. 보통 프론트엔드 개발자는 마크업 작업 → 로직 설계 → (백엔드에서 API 작업을 완료 시) API 연결 후 테스트한다.

백엔드 개발자는 DB 구조를 설계하고 만들어야 하는 API를 판단하기 위해 프론트엔드 개발자보다 플로우 차트를 자주 확인한다. 우리가 플로우 차트에 그리는 절차별 ‘처리’ 과정 하나하나가 백엔드 개발자에겐 개발해야 하는 API기 때문이다.

초입의 설계가 완료되면 프론트, 백 구분 없이 플로우 차트를 잘 보지 않는다. 훗날 ‘히스토리 파악’이란 용도를 제외하면 프로젝트가 진행되는 동안 사용되는 주기가 그렇게 긴 편이 아니다.

짧은 경험상 함께 일해본 개발자가 100명 채 안되며, 경험을 기반으로 작성한 것일 뿐 조직과 개발자마다 다를 수 있다.

어느 정도로 상세하게 작성해야 하나요?

플로우 차트 종류와 조직의 특성마다 다르다. 예를 들어 아이디, 비밀번호, 이름, 주민번호, 전화번호가 모두 필수값인 회원가입 화면을 태스크 플로우 차트로 그린다고 가정해 보자.

누군가는 ‘아이디 입력 → 유효성 체크 → 통과 시, 이름 입력 → 유효성 체크’와 같이 모두 풀어서 적고, 누군가는 ‘정보 입력 → 유효성 체크’라고 퉁쳐서 적을 수 있다. 이처럼 작성자의 성격과 조직 문화에 따라 같은 조건이 주어져도 다르게 작성할 수 있다.

기준이 필요하다면 ‘보는 사람이 이해하기 쉬운가’에 집중하자. 글도 비슷한 말이 반복되면 가독성을 떨어뜨리듯이, 플로우 차트도 반복되는 절차가 많아지면 가독성을 떨어뜨린다. 반복되는 내용은 덜어내고 플로우 차트를 보는 대상에게 지속적으로 피드백을 받아 개선하는 걸 추천한다.

레퍼런스

기획자가 알아두면 좋은 Flow Chart (링크)

플로우 차트의 의미와 종류 (링크)

시스템 플로우 차트의 개념 (링크)

순서도 기호와 작성하기 좋은 툴 (링크)

앱 서비스 설계 - 플로우 차트 (링크)

ⓒ 327roy

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari

brunch

6. 서비스 기획자를 위한 도식화 기초

목차

플로우 차트? 도식화?

플로우 차트란?

작성 규칙

플로우 차트의 종류

관련 툴

실습: 회원가입 플로우 차트 그리기

이모저모

레퍼런스

플로우 차트? 도식화?

도식화란 사물의 구조, 개념, 관계를 그림이나 양식으로 표현한 걸 의미한다. 예를 들어 차트, 플로우 차트, 와이어 프레임을 말할 수 있다.

플로우 차트란?

*여기서 PM은 Product Manager를 의미한다.

이를 그리면서 경험한 장점을 크게 아래와 같다.

잘 그려진 플로우 차트는 서비스 로직의 흐름과 유사하다. 즉, 플로우 차트를 잘 그리면 개발자의 설계 초입을 도울 수 있다.

작성 규칙

도식이 가지는 개념은 사진과 같다. 하지만 개인의 성격과 조직 문화(관습)에 따라 생략하거나 대체하기도 한다.

플로우 차트의 종류

유저 플로우 차트

사용자 행동을 기준으로 흐름을 도식화하여 표현한 것을 의미한다. 단일 사용자의 행동을 표현하기도 하지만, 여러 명의 사용자가 서로 다른 태스크를 수행하는 것도 표현할 수 있다.

태스크 플로우 차트

주요 태스크의 프로세스를 표현한다. 주로 복잡한 플로우를 설계하기 전 뼈대를 설계하기 위해 작성한다. 유저 플로우 차트가 사용자 여정에 초점을 맞춘다면, 태스크 플로우 차트는 단일 작업에 초점을 맞춘다.

시스템 플로우 차트

흐름에 따라 데이터를 어떻게 처리하는지 확인할 수 있는 플로우 차트다. 데이터의 입출력 흐름을 중심으로 작성하는 게 좋다. 가장 보편적이고 익숙할 것이다.

어떤 플로우 차트든 글을 쓰는 것과 마찬가지로 목적과 맥락이 중요하다. 사용자 여정을 이해하기 위한 플로우를 그리고 싶은지, 시스템 설계를 돕기 위한 플로우를 그리고 싶은지 잘 생각하고 작성하자.

관련 툴

플로우 차트 등 도식화를 도와주는 다양한 툴이 존재한다. *화이트보드 툴에서 대부분 도식화를 지원하고 있으며, 플로우 차트, **UML을 그리는데 특화된 툴도 존재한다.

*화이트보드 툴: 피그잼, 미로, 윔지컬, 보드믹스, 드로우 등 화이트보드를 웹 기반으로 구현한 툴을 의미한다.

**UML: Unified Modeling Language(통합 모델링 언어)를 의미하며 시스템과 소프트웨어를 시각화하는 언어(방법)를 의미한다.

피그잼

https://www.figma.com/figjam/

미로

팬데믹 때 몇 번 사용했던 화이트보드 툴이다. 제공하는 기능은 피그잼과 거의 동일하다. 마우스 휠 기능이 기본적으로 축소/확대로 지정돼 있어서 나한테는 불편한 편.

https://miro.com/ko

drawio

다이어그램을 그리는데 특화된 툴이다. 무료로 사용할 수 있고 플로우 차트를 포함해 다양한 UML 다이어그램을 그리는데 특화돼 있다.

https://www.drawio.com/

실습: 회원가입 플로우 차트 그리기

아래 조건을 참고해서 플로우 차트를 그려보자. 아래 조건을 보면 머릿속에 떠오르는 화면(프로세스)이 있을 것이다. 머릿속에서 이 화면을 먼저 정리하고, 이를 바탕으로 플로우 차트를 그리는 연습이다.

[조건]

이모저모

기획서를 만들 때 꼭 넣어야 하나요?

개발자는 플로우 차트를 언제 보나요?

경험상 공통적으로 기획 리뷰할 때 보고, 제품을 설계하는 과정 초입에 많이들 확인한다. 다만 프론트엔드, 백엔드 둘 모두 특징이 다소 다르다.

보통 프론트엔드 개발자는 *마크업 작업을 함께 진행한다. 그래서 이들은 기획 리뷰를 할 때 흐름을 이해하기 위한 정도로만 플로우 차트를 가볍게 보고, 베리에이션을 포함해 디자인된 화면을 개발하며 흐름을 더 파악한다.

*마크업 작업이란 HTML, CSS 등의 언어를 사용해서 페이지의 레이아웃, 구조, 디자인을 정의하는 작업을 말한다. 보통 프론트엔드 개발자는 마크업 작업 → 로직 설계 → (백엔드에서 API 작업을 완료 시) API 연결 후 테스트한다.

초입의 설계가 완료되면 프론트, 백 구분 없이 플로우 차트를 잘 보지 않는다. 훗날 ‘히스토리 파악’이란 용도를 제외하면 프로젝트가 진행되는 동안 사용되는 주기가 그렇게 긴 편이 아니다.

짧은 경험상 함께 일해본 개발자가 100명 채 안되며, 경험을 기반으로 작성한 것일 뿐 조직과 개발자마다 다를 수 있다.

어느 정도로 상세하게 작성해야 하나요?

플로우 차트 종류와 조직의 특성마다 다르다. 예를 들어 아이디, 비밀번호, 이름, 주민번호, 전화번호가 모두 필수값인 회원가입 화면을 태스크 플로우 차트로 그린다고 가정해 보자.

레퍼런스

기획자가 알아두면 좋은 Flow Chart (링크)

플로우 차트의 의미와 종류 (링크)

시스템 플로우 차트의 개념 (링크)

순서도 기호와 작성하기 좋은 툴 (링크)

앱 서비스 설계 - 플로우 차트 (링크)

ⓒ 327roy