어떤 일을 하던지 익숙해지면 문제가 발생하기 쉽다.
고로, 기획자가 업무나 맡은 제품에 대해 익숙해지면서 문제가 발생할 확률이 높아진다.
내가 본 기획자들이 가장 많이 놓치는 부분이 기획(작업) 하는 부분에 대한 순서도 작성을 하지 않는다였다.
이유는 "다 아는 거 아니야?"
잘 안다고 생각할 때 사람의 뇌는 망각이라는 것을 실행하여 중간에 빼먹을 것을 당연히 했다고 여길 수 있다.
그래서 순서도 작성을 강하게 강조한다.
- Biseuness flowchart : 서비스나 상위 수준(시나리오) 업무 플로우
- Function flowchart : 기능 및 사용자 액션 대한 플로우
비즈니스 플로우
최초의 시작은 요구 사항 기반으로 상세 기능이 정의 된 이후 시작할 수 있다.
사용자 요구 사항, 시스템 요구 사항, 유즈케이스, 기능 명세서 등...
그다음 바로 화면 설계서를 작성하는 것이 아니라,
비즈니스 플로우를 작성하기를 권한다.
그 이유는
- 전체 프로세스를 이해하고 시작할 수 있다.
- 화면과 UI 요소, 기능의 누락을 방지한다.
- 방향을 잃고 헤매거나 삼천포로 빠지는 것을 방지한다.
- 결과적으로 문서 작업의 시간이 절약된다.
비즈니스 플로우란 사이트맵 + 유즈케이스 + 와이어프레임의 심플한 혼합 형태라고 볼 수 있다.
필자는 작업 영역이 많거나 신규 제품에 대한 업무를 시작할 때는 PPT 문서 사이즈를 최대 100cm 설정하고 시작한다.
Sample 1. 회원가입 프로세스
범례
- 비지니스 플로우를 구성하는 요소에 대해 정의를 해 두었다.
- 팀이나 TF에서 상호 협의하여 이해할 수 있는 범위로 정해두고 사용하면 좋다.
- 그리고 최대한 개수를 줄여서 범례 없이도 문서를 볼 수 있도록 하는 것이 좋다.
- 범례는 화면, 기능, 분기 등의 요소가 포함될 수 있다.
화면
- 하나의 화면을 구성하는 요소에 대해 명시되어 있다. (UI 컴포넌트, 역할 or 기능)
- 화면설계서를 작성할 때, 명시된 구성요소와 기능이 모두 담겨 있는지 체크하는데 도움을 준다.
- 명사로 작성하기를 권한다.
프로세스(기능)
- 화면에서 다음 화면으로 넘어갈 때 수행하는 기능에 대하여 명시한다.
- 사용자가 행할 수 있는 액션이 될 수 있다.
- 동사로 작성하기를 권한다.
프로세스 분기
- 이전 프로세스에 대한 도착 화면이나 메시지, 결과를 분기한다.
- 2개의 선택지로 "Yes(true)" or "No(false)" 로 결정되어야 한다.
- 3개의 선택지가 필요한 경우 다음 단계를 추가하여 2개의 분기로 처리되도록 한다.
프로세스 이동(업무) 흐름
- 프로세스(데이터) 흐름은 화살표로 표시한다.
- 조금 더 신경을 쓴다면, Critical Path 를 지정하여 선을 볼드로 표현하던가
- 분기의 Yes 와 No 의 점선과 실선 또는 파란색과 빨간색 형태를 구분하던가
필자의 데이터 흐름 작성 방법 (개인취향)
간단하게 작성한 문서로 내용을 살펴보았다.
단, 너무 다양한(복잡한) 조합은 의미 전달이 어려울 수 있으니 주의해야 한다.
예제처럼 로그인 부분만 분리하여 범주별로 작성하는 것도 방법이다.
만약 비즈니스 플로우 문서가 없었다고 한다면
화면설계서를 작성하는 기획자는 더 많은 문어발식 확장을 했을 수도 있다.
필자도 기획을 처음 시작할 때 경험했던 내용이고.. 다시 처음부터 새롭게 다시 작성했었다.
마무리
- 전체 플로우를 담아라
- 연결 관계를 명확히 해라
- 간결하게 작성해라
예시
기능 플로우
화면 내에서 존재하는 기능의 동작에 대하여 데이터 흐름으로 정의하는 방법이다.
데이터 흐름은 순서를 가진다는 의미로 무엇을 먼저 체크하고 수행할지도 정의된다.
기능 플로우를 작성하는 부분은 크게 2가지라고 보면 된다.
1. 화면(페이지)에서 버튼이나 사용자 액션에 따라 동작해야 하는 기능
2. 화면(페이지) 로딩 시 체크되어야 하는 기능
1. 화면에서의 동작
아래 예제는 웹에서 로그인하는 기능에 대한 순서도이다.
사용자 행위가 발생하는 부분을 명시하였다.
마우스 클릭 시, 플로우가 시작된다.
기능 동작 시 체크되어야 할 항목에 대하여 표시한다.
- 입력 필드 및 데이터에 대한 유효성 검증을 한다.
- 검증 결과에 따라 다음 체크 항목으로 이동한다.
- 개발 시, 체크 순서로 정의된다.
오류로 체크된 항목에 대하여 사용자에게 피드백을 제공한다.
- 입력 필드의 경우 빈 공란에 대한 예외처리를 안내할 수 있다.
- 입력 필드의 데이터에 대한 유효성에 대해 가이드할 수 있다.
- 세부 항목은 옆에 Description으로 추가 설명을 한다.
- 사용자에게 다음 액션을 가이드하는 것을 추천한다.
유효성 체크는 크게 2가지로 구분할 수 있다.
- 클라이언트에서 체크하는 유효성 (위의 입력 폼 유효성)
- 서버에서 체크하는 유효성 (아래의 서버 오류 메시지)
기능 동작 체크는 순서에 따라 진행된다고 말했다.
클라이언트에서 입력 데이터에 대한 유효성 체크가 완료되면 서버에서의 유효성 체크가 이루어지는 게 좋다.
따라서 순서도에서도 마지막 부분에 다루어지는 내용이다.
사용자가 알아야 할 중요도에 따라 다이얼로그 형태의 컨펌 창으로 안내할 수 있다.
참고. 보통 화면설계서는 화면에 대한 설명과 기능에 대한 설명을 구분해서 작성한다.
2. 로딩 시점의 동작
화면이 전환되거나 페이지를 로딩, 로그인 후 전환 등의 프로세스에서
서버는 여러 가지 일을 처리하여 고객에게 보여줄 정보를 가공하게 된다.
이 부분도 기획자가 정의한 내용과 순서에 따라 처리가 되어야 사용자 관점에서 원하는 정보가 출력될 수 있다.
가장 쉽게 안내할 수 있는 것이 모바일 앱에서 앱을 실행할 때 체크되는 조건들 일 것이다.
아래 예제는 앱을 실행할 때 체크하는 항목에 대한 순서도이다.
스플래시 화면은 앱의 아이덴티티를 보여주는 역할도 하지만,
사용자가 알지 못하는 백그라운드 작업을 하기 좋은 영역이다.
그래서 위와 같이 체크하는 내용을 별도 화면이 아닌 스플래시 화면에서 처리하는 것을 추천한다.
만약 위에 언급한 순서를 사용자 입장에서 정의하지 않는다면
사용자 입장에서는 앱이 실행되어 홈에 도착한 상태에서 업데이트하라고 다시 앱을 종료하는 경우나
네트워크가 동작하지 않는 상태인데 지속적으로 서버 연결을 시도하여 오랜 로딩이 되는 불편함을 겪을 수도 있다.
두 번째 소개할 예제는 특정 상황에서 웹 페이지를 새 탭으로 실행하는 경우이다.
위 케이스는 회원 가입이나 비밀번호 찾기를 했을 때 이메일로 수신한 링크를 선택할 때 유용하게 쓸 수 있다.
페이지를 로딩하면서 링크의 유효성을 체크하여 잘못된 접근의 경우
사용자에게 불필요하게 정보 입력이나 추가 액션을 하지 않게 바로 다음 가이드를 할 수 있다.
(미미하지만 사용자 불만을 줄일 수 있습니다.)
Flowchart 를 작성함으로써 아래의 효과를 볼 수 있다.
- 개발팀의 코딩/로직 오류의 방지
- 사용자에게 사용성 높여주는 효과
- 오류 발생 시 오류 발생 지점 추적의 용이성
댓글