앱/웹 기획 시 프로세스 설계를 하지 않는 이유

보통 앱/웹 기획은 요구사항에 따라 스토리보드를 작성하는 흐름으로 진행됩니다. 좀 더 꼼꼼한 기획자의 경우 고객 미팅을 통해 요구사항의 세부 내역을 확인할 것입니다. 그리고 좀 더 역량이 있는 기획자라면 기능/화면 명세서를 작성할 것입니다. 여기서 프로세스 설계가 빠지게 되는 이유는 다른 작업보다 어렵기 때문입니다.

 

 

앱/웹 프로세스 설계 부작용 

 

제대로 하지 못한다면 프로세스 설계는 득 보다 실이 더 많은 작업이 됩니다. 쓸데없이 시간을 많이 소비하게 될 뿐 아니라 스토리보드 작업에 혼동을 일으킵니다. 프로세스 작업 시간만 버리는 것이 아니라 스토리보드 작업 시간도 더 걸리게 만들게 됩니다.

 

물론 제대로 작성된 앱/웹 프로세스 설계는 스토리보드 작업 시간을 단축시킬 뿐 아니라 코딩 진행 시 문제 지점을 찾고 수정하기도 편리해집니다. 

 

문제는 제대로 작업하기가 다른 기획 업무에 비해 어렵다는 점에 있습니다.

 

앱/웹 프로세스 설계는 앱/웹 서비스 디자인이라 할 수 있습니다. 이는 아이폰 개발 시 디자인(Design by)은 애플이, 제조(Made in)는 폭스콘 중 애플 영역과 같다고 비유할 수 있습니다.

 

한마디로 어렵기에 부작용이 많다는 것입니다.

 

이는 폭스콘이 아이폰을 만들지만 애플이 될 수 없는 것과 같은 어려움입니다. 부작용은 폭스콘이 직접 아이폰을 디자인(설계) 할 때 나타나는 결과와 같다고 생각하면 쉬울 것입니다.     

 

 

앱/웹 프로세스 설계 방식

 

앱/웹의 프로세스 설계는 사용자 이용 흐름을 단계적으로 표현하는 이용 로직 방식이 있고, 사용자의 기능의 처리가 이루어지는 로직을 설계하는 방식이 있습니다.

 

제대로 된 프로세스 설계를 위해서는 이 두 관점을 함께 적용하는 것이 맞기는 합니다. 그러나 상대적으로 각각의 프로세스만 정리하는 것보다 어렵기는 합니다.

 

그래서 보통 앱/웹 사용자 이용 흐름을 따라 프로세스를 정리하는 연습을 한 후, 사용자 이용 흐름 단계에 따라 서버에서 처리해야 하는 작용을 정리하는 단계를 연습하는 방식으로 전체 프로세스 설계 연습을 하는 것이 효과적입니다.

 

 

앱/웹 이용 프로세스

  

이용 프로세스는 말 그대로 앱이나 웹 사이트를 사용자가 이용할 때 일어난 이벤트를 따라 설계하는 것을 의미합니다.

 

회원 가입을 예로 든다면,

1. 앱/웹 첫 번째 화면에서 미가입자 회원 가입 클릭
2. 가입 방식 선택 (직접 가입, SNS 가입)
3. 직접 가입 선택 시, 사용할 아이디, 비번 등록 / SNS 가입 시 가입 SNS 선택
4. 아이디, 비번 중복 체크 / SNS API
5. 가입 정보 입력 / SNS API 피드백
6. 가입 완료

등의 프로세스 진행이 있을 것입니다.

 

이를 기반으로 프로세스 별 각 화면의 내용과 다음 이동하는 화면의 내용을 명확하게, 빠짐없이 정리합니다.

 

여기서 주의할 것은 화면 이미지가 아니라 내용이라는 점입니다. 보이는 화면 이미지(프레임)는 화면 설계 스토리보드 때 작업 하게 될 것입니다.

 

사용자의 앱/웹 이용 단계별 프로세스 설계는 뼈대이고 화면 설계 스토리보드는 이 뼈대를 토대로 살을 붙이는 작업이라 할 수 있습니다.

 

프로젝트에서 개발자가 어려움을 겪는 것 중 하나가 스토리보드의 스토리 구성이 부실하고 빠진 부분이 있을 때입니다. 이 경우 화면 설계 스토리보드는 설계로의 역할을 하지 못하게 됩니다. 단지 화면이 이렇다는 것을 보여주는 단편적인 화면 디자인 가이드에 그치게 됩니다.

 

이 조차 앱/웹 전체 화면이 아니라 일부 화면의 디자인이 됩니다. 

 

프로세스 설계는 서버 처리가 필요한 화면의 기능 작동에 대한 설명을 빠지지 않게 해 줍니다. 프로세스, 스토리보드 작업 때에 두 번에 걸친 로직 검토를 하기 때문입니다.

 

 

기능 처리 프로세스

  

앱/웹 사용자 이용 화면 프로세스에서는 앱 또는 웹 사이트에서 확인되는 흐름은 존재하나 화면과 화면의 이동 사이 처리되는 해당 기능의 서버 처리에 대한 부분은 빠져 있습니다.

 

어떤 데이터가 처리되어 피드백되어야 하고, 화면 요구 처리 시 어떤 시스템과 연동해서 무엇을 가져와서 체크해야 하는지에 대한 과정 프로세스는 나와 있지 않습니다.

 

그러나 대부분 앱/웹 개발 요구 사항에는 개발 조건, 보안, 데이터 등에 대한 내용이 포함되기도 합니다. 그러므로 이에 대해 어떻게 할 지에 대한 정리가 필요합니다.    

 

그러나 대부분의 기획자 또는 사용자는 앱/웹 화면의 내용은 익숙하지만 서버에서 처리되는 내용은 익숙하지 않습니다. 또한 개발 방식이나 프로그램 버전, 이용 솔루션 등에 따라 처리 프로세스는 달라지기도 합니다.

 

결국 기획자가 다양한 개발 경험이 있어야 하고, 기본적인 개발에 대한 이해 또한 필요합니다. 프로젝트 경험이 많더라도 개발자와 협업하는 케이스가 많지 않다면 서버 단에서 처리되는 프로세스를 설계하는 것은 어렵게 됩니다.

 

안타깝게도 많은 앱/웹 개발 프로젝트의 기획자는 단기로 투입됩니다. 전체 프로젝트 기간 중 기획자는 개발자와 함께 일하는 기간이 거의 없는 경우도 있습니다. 기획자는 요구 사항을 기반으로 스토리보드 그리고 프로젝트에서 철수하면 개발자가 스토리보드를 보고 작업하는 프로젝트도 꽤 있습니다.

 

그러다 문제가 생기면 문제를 처리할 기획자를 단기 계약으로 투입하기도 합니다. 프로세스를 설계할 시간도 없고, 그 정도 역량의 기획자를 단기로 활용한다면 단가도 비싸서 그냥 스토리보드만 그리는 경우도 꽤 있습니다.

 

그러다 보니 점점 기능 프로세스 설계를 할 수 있는 기획자는 줄어들고 있기도 합니다.