작은 요청이 불러오는 서비스기획자의 역할과 사이클
화면하나 추가하면 발생하는 나비효과
오늘은 한 가지 요청이 들어오면 어떤 일이 일어나는지 서비스기획자 중심으로 생각해 볼 수 있는 간단한 사례를 통해 알아보겠습니다.
우리 회사 홈페이지에 서비스 신청하기 페이지를 추가해 주세요.
영업팀에서 이렇게 단순한 요청을 받으면, 대개 “한 페이지만 추가하는 거니까 간단하겠지?”라는 생각이 듭니다. 이미 홈페이지의 디자인과 구조도 있으니, 기존 틀을 조금만 수정해서 추가할 수 있을 것 같고, 다음 주까지 완료하자는 계획이 세워지기도 합니다. 그러나 실제로 기획에 들어가면 이 단순한 요청 하나가 얼마나 많은 과정과 변수들로 확장될 수 있는지 이 요청이 만들어내는 과정과 복잡성을 예시로 살펴보겠습니다.
1. 플로우 설계
: 접근 경로와 완료 후 흐름 설정
첫 번째 단계는 사용자가 새로운 서비스 신청 페이지에 접근하는 흐름을 설계하는 것입니다. 여기서 다음과 같은 세부 사항을 고려합니다:
진입 경로: 이 화면이 어떤 메뉴나 버튼을 통해 접근될지 설정하고, 기존 사이트의 내비게이션과 일관성을 유지할지 검토합니다.
완료 피드백: 신청 완료 시 팝업으로 안내할지, 스낵바 형태로 알림을 줄지 정합니다.
이동 경로와 이벤트: 완료 후 사용자가 이동할 화면과 함께, 신청 내용이 필요한 담당자에게 실시간으로 메일이 발송되도록 설정할 수 있습니다.
작은 화면 하나를 추가하는 데에도 사용자 경험과 편의성을 고려해 플로우 전체를 계획해야 하며, 이는 사용자 흐름과 사이트 일관성을 좌우합니다.
2. 약관 및 정책 점검
: 개인정보와 법적 요구사항 검토
서비스 신청 시 개인정보가 포함되므로, 개인정보 처리 방침을 철저히 검토하고 필요한 문서를 준비합니다.
개인정보 수집 및 이용 동의서 작성: 개인정보 항목을 정하고, 필수 정보와 선택 정보를 구분하여 동의서를 작성합니다.
제3자 제공 동의서와 위수탁 계약: 만약 외부와 정보 공유가 필요하다면 제3자 제공 동의서를 마련하고, 외주 업체가 개인정보 처리를 맡는 경우 위수탁 계약서를 체결합니다.
이 과정은 단순한 신청 페이지가 법적 요구사항에 맞게 운영될 수 있도록 하는 중요한 절차입니다. 법무검토가 필요하다면 이 과정이 길어질 수도 있겠지요... 하지만 예시니까 그런 슬프고 복잡한 이야기는 생략하겠습니다.
3. 화면 기획
: UI/UX, UX Writing과 입력 필드 기획
다음으로 본격적인 화면 기획 단계로 넘어갑니다. 사용자에게 필요한 정보를 명확히 전달하고 오류 없이 입력하도록 하는 것이 목표입니다.
UI 구성: 서비스 목적과 기존 홈페이지에 맞게 화면을 구성하고 어떤 순서로 입력하는 게 목적에 맞을지 전체적인 구조를 그립니다.
입력 항목 구성: 필수와 선택 항목을 구분하고, input 또는 dropdown으로 할지 다양한 UI구조를 고민하며 설정합니다. 예를 들어, ‘주소’ 입력은 API를 사용할지, input박스를 사용할지, API를 사용한다면 어떤 API로 구성하고 팝업이나 모달로 구현할지 등도 함께 고민합니다.
에러 처리와 UX Writing: 각 필드의 최대 길이와 형식 조건을 설정하고, 오류 메시지를 언제 어떻게 표시할지 계획합니다. 예를 들어 전화번호는 형식을 고정하고, 이메일은 형식을 실시간으로 검토하는 방식으로 UX를 고려합니다.
완료 후 피드백: 신청 완료 후 사용자에게 적절한 피드백을 주고, 알림 메일을 발송할 때도 이해관계자별로 알맞은 메일 포맷으로 전송할 수 있도록 설계합니다. 이때 필요한 메일 포맷 UI도 함께 기획합니다.
이렇게 세부적으로 설계된 화면과 UI는 사용자 경험을 결정짓는 중요한 요소입니다.
4. 디자인 요청
: 일관성과 반응형 디자인 확보
디자인 요청 시 기존 사이트의 톤 앤 매너와 일관되게 유지하면서 반응형 기준을 포함하여 요구 사항을 전달합니다.
UI 요소 설정: 폰트 크기, 버튼 크기, 그리고 각 필드의 max Length를 설정해 모바일에서도 일관된 사용자 경험을 제공합니다.
반응형 디자인 고려: 모바일에서도 자연스럽게 보이도록 박스 크기, 글자 크기 등을 요청하고, 메일 발송 시 텍스트와 이미지의 배치까지 가이드라인에 따라 디자인 요청을 정리합니다.
모든 페이지가 하나의 사이트로 자연스럽게 이어질 수 있도록 작은 요소까지 일관성을 고려해야 합니다.
5. 백엔드 개발 요청
: 기획과 동시에 빠르게 개발을 준비하다
기획서가 나오자마자 개발팀과의 협업을 시작해 원활한 개발이 가능하도록 지원합니다. 이 부분은 디자인요청과 동시에 진행합니다.
개발에 필요한 자료 제공: 개인정보 동의서, 수집 항목, 저장 기간, 메일 발송처 등 필요한 정보를 빠르게 제공하여 DB 구조를 짜고, API 명세를 준비할 수 있도록 합니다.
도메인 요청: 서비스 신청 페이지에 별도의 도메인이 필요할 경우 미리 요청하여 준비를 완료합니다.
6. 프론트엔드 개발
: 디자인, API명세서 전달
디자인이과 백앤드 API명세서 작업이 완료되면 API명세서와 함께 모든 디자인 가이드를 프론트 개발팀에 전달합니다. 물론 미리 플로우와 기획서를 전달해 흐름이 정확히 전달되도록 하며, 리뷰를 통해 의도한 경험이 잘 구현될 수 있도록 합니다. 기획자 입장에서도 세심한 배려가 필요한 부분입니다.
7. 테스트
: 최종 결과 검증과 오류 확인
모든 개발이 끝나면 빠르게 퀵 테스트를 진행합니다.
기능별 테스트 케이스(TC) 기반으로 필드 입력, 오류 처리, 메일 발송, 데이터 저장 여부를 확인하고, 알림이 제대로 도착하는지, 메일 양식이 문제없는지 검토합니다. 초기 단계에서 설정했던 에러 조건을 바탕으로 기능별 테스트를 꼼꼼히 진행하여 최종 점검을 완료합니다.
에러 건별로 티켓을 등록해 개발자들이 빠르게 처리할 수 있도록 합니다.
뒤에서 기다리는 동료와 스노우볼을 생각하는 기획자의 역할
지금까지 한 화면 추가라는 작은 요청이 기획자에게 어떤 과정과 준비를 요구하는지 살펴보았습니다. 물론 글에서는 모든 과정이 순조롭게 진행된 예시로 설명했지만, 실제 현장에서는 다양한 변수들이 함께 얽힙니다.
특히 기획자는 초기에 요구사항이 바뀌지 않도록 철저히 조율하는 역할을 합니다. 단순해 보이는 화면 하나라도 계획 중간에 수정이 발생하거나 기능이 추가되면, 뒤에서 발생하는 공수와 비용이 기하급수적으로 늘어나기 때문입니다. 급하게 진행되는 건을 조율하고, 작은 기능 하나라도 신중하게 검토하는 이유도 바로 여기에 있습니다. 요구사항이 자주 바뀌면 디자이너와 개발자가 추가 부담을 겪게 되고, 이는 프로젝트의 전반적인 속도와 완성도에 영향을 미칩니다. 따라서 기획자는 작은 요구사항 변경이 뒤로 갈수록 팀 전체의 고충이 될 수 있다는 점을 항상 염두에 두어야 합니다.
개인적으로는 프론트엔드 개발자에게 특히 미안한 마음을 느낍니다. 디자인 확정이 늦어지거나, API 준비가 완료되지 않아 대기하는 일이 많기 때문이죠. 심지어는 완료해야 하는 일정이 정해져 있는 경우가 많아 앞에서는 안 주지, QA테스트 일정은 고정되어 있지... 프론트 개발자의 한숨소리가 참 안타까울 때가 많았습니다. 프론트엔드 개발자는 화면을 실제로 구현하는 마지막 단계에 위치해 있어, 디자인과 API가 지연되면 작업 속도에도 영향을 받습니다. 이를 최소화하기 위해 기획서와 플로우를 함께 전달하고, 간단한 리뷰라도 진행해 기획자가 의도한 경험이 전달될 수 있도록 합니다.
결국, 기획자의 역할은 초기 단계부터 요구사항을 명확히 조율하고, 기획서는 빠뜨림 없이 디테일까지 잘 작성하고, 꼭 필요하지 않다면 변화가 생기지 않도록 하여 디자이너와 개발자가 겪을 고충까지 고려해 관리하는 일입니다. 이를 통해 협업이 원활히 이루어지고, 작은 요청도 더 이상 스노우볼 효과로 이어지지 않도록 최선을 다해야 함을 느낍니다.
동료들이 프로젝트에 회의감과 스트레스가 느껴지지 않고 기대감과 몰입도를 가지고 프로젝트에 임할 수 있도록 깊이 고민하고 조율하는 부분이 제게도 늘 숙제입니다. 결국 프로젝트가 잘 흘러가도록 돕고, 동료들이 제자리를 지킬 수 있게 만드는 것은 기획자의 세심한 손길에서 시작되니까요.
