STEP 1. 필요한 기능과 데이터를 정의한다.
1. 서비스의 재료가 되는 기능과 데이터를 생각해보자
2. 데이터를 활용하는 정책을 같은 마인드맵에 써보자
서비스 목표와 이에 필요한 기능과 데이터를 차례로 정리했으면, 이제 '정책'을 정리할 차례다. 정책은 '데이터 활용 기준'이라고 생각하면 된다. 개발을 하는 사람이 알고리즘을 짤 때 핵심적으로 고려할 기준을 정리해주는 것이다.
STEP 2. 내부와 외부 사용자별 플로우를 정리한다.
보통 자료에서 보는 플로우 차트는 고객이 보는 프론트 화면의 순서를 나타낸다. 하지만 그런 화면만으로는 디자인도 개발도 진행하기 어렵다. 다양한 정책이 가져오는 여러 가지 케이스에 대해 모두 확인해볼 수 있는 플로우 차트가 필요하다. 현업 실무자에게는 '비즈니스에 맞는 플로우 차트'가 필요하다. 그러므로 내부와 외부의 모든 사용자를 정의하고 서비스가 굴러갈 수 있는 업무 프로세스를 설계해야 한다.
STEP 3. 정보구조(IA) 작성하기
마지막으로 필요한 것은 프로젝트에 포함될 화면 목록을 정리하는 것이다. 시각적으로 보이는 화면 목록을 정의한 것을 보통 IA(Information Architecture)라고 부르는데, 트리 방식으로 정리되는 '정보 구조 체계'를 의미한다.
모바일 환경에서는 IA 문서보다 유저플로우나 아트보드처럼 UI 조작에 따른 환경 변화에 주목하여 설계한 문서들이 주목받는다.
IA는 어드민을 포함하여 고객이 이용하는 화면까지 업무 프로세스 설계를 큼직하게 정리하기에 적합하다. 유저플로우만큼 화면 UI를 세세하게 정리하기 전에 프로세스 단위로 화면을 몇 개로 작업할지 확인해서 작업량을 산출하는 기준을 마련할 수 있다.
*플로우차트 : 사용자별 입출력 데이터, 로직의 흐름, 눈에 보이지 않는 데이터 저장 방식이나 연동 방식의 개념도 포함한다.
*유저플로우 : 같은 페이지 내에서도 이용 순서에 따라 화면이 어떻게 바뀌는지 정의한다. 프로세스 설계보다는 화면 UI를 작업하는 과정에서 좀 더 편리하고 자연스러운 사용성을 개선하는 시점에서 더 필요로 한다.
*API (Application Programming Interface) : 응용 프로그램 개발자들이 앱을 만들 때 운영체제에서 동작하는 프로그램을 쉽게 만들 수 있도록 화면 구성이나 프로그램 동작에 필요한 각종 함수를 모아놓은 것을 말한다. 즉 다른 개발자들이 이 프로그램을 응용해서 다른 프로그램을 만들려면 '최소한 이런 기능들은 필수로 들어가겠지'라는 생각으로 미리 필요한 함수들을 만들어서 모아놓은 도서관과 같다.
