[YAPP 7주차] 기획자의 산출물을 남겨보자 #IA #기능명세서 #정책

이번 프로젝트에서 나의 스킬업을 위해 목표한 것은 기획자의 얼굴인 '산출물을 제대로 남기보자'였다. 앞서 마인드맵을 활용해 전체 기능을 구조화하였고, 디자이너와 와이어프레임을 짜며 화면 기획을 함께 병행했는데, 이때 만든 산출물들을 하나씩 공유해보려 한다. 

---

 IA(정보구조도)
한눈에 서비스의 구조를 파악하는 문서

IA는 흔히 메뉴트리, 메뉴구조도 라고도 많이 섞어 말하는 것 같은데, 내가 공부를 하며 느낀 것은 IA와 메뉴구조도는 엄밀히 말하면 다른 개념이다. 메뉴구조도는 정보구조를 도식화하여 나타낸 것이고, 정보구조도는 표로 표현한 것! 나의 경우 IA의 DEPTH를 페이지로 기준을 잡았고, 그 기준을 잡는 것이 매우 중요했다. 

 

혼돈의 카우스 여정 공유

초기 IA를 작성할때, DEPTH 기준에 대한 개념이 온전치 않아 버튼과 페이지를 섞어 적었다.
그 잘못된 예시를 공유해보면 아래와 같다.

홈화면 와이어프레임

 
 

• 유저의 홈화면 행동

1.  상단에 유저 정보수정(마이페이지이동),
2. 여행 등록하기(버튼),
3. 등록한 여행 목록 → 4)가계부(페이지이동) 

 
조금 더 자세히 보면,
① 의경우
'양송이'클릭시 마이페이지로 진입(DEPTH2)하여
닉네임, 프로필 수정 시 다른 페이지(DEPTH3),
로그아웃과 회원탈퇴도 다른 페이지(DEPTH3), 이고
마이페이지 내 다른 고객지원(문의하기, 리뷰 쓰기)은
외부링크로 연결되어 그대로(DEPTH2)
 
2)의 경우, 
<여행 등록하기> 버튼 클릭 후 국가선택화면 진입(DEPTH2),
국가선택 후 여행 날짜선택 화면 진입(DEPTH3),
날짜선택 후 동행자 선택 화면 진입(DEPTH4),
동행자 선택 후 여행제목 적는 화면 진입(DEPTH5)
 
으로  < 여행 등록하기> 버튼은 DEPTH2가 아님!
국가화면이 DEPTH2가 되어야 하는데,
아래 좌측 IA를 보면, 버튼을 DEPTH에 적었다.
 
      

이후, 계속 IA를 수정하면서 완성한 IA는 아래 우측 표와 같다. 완전히 페이지를 기준으로 DEPTH를 잡을 수 있었고, 특히 NO를 적으면서 같은 DEPTH의 페이지들을 한번 더 매칭시켜 보며 체크하니 더 명확하게 기준을 잡을 수 있었다! (NO는 추후 화면 번호로도 활용됨) 체크하고 수정하기를 반복하다 보니 우리 서비스의 구조를 한눈에 파악할 수 있는 문서가 탄생하게 되었다.

(좌) 에서 (우)로 IA 변화

느낀점&배운 점
초기 IA를 작성할 때 가장 어려웠던 점은 유저의 상태(유저의 행동)에 따라 우리 서비스에서는 가계부의 화면이 다르게 노출되는데, 이런 서비스 플로우를 고려해서 IA를 작성해야하는 건지, 대체 어떻게 적어야 하는건지 감이 오지 않았었다. 그런데 앞서 마인드맵을 통해 발생되는 기능&화면을 전부 나열하면서 플로우에 관계없이 정리가 가능했고, 발생되는 페이지를 구조화하는 것이 IA의 핵심인 것을 알게 되었다.
  
공부에 도움이 많이 되었던 자료
https://seanlion.github.io/ux/23
https://youtu.be/om8RxX_T7vE?si=7IhMY88ZP_TRfXUE 

---

기능정의서
한눈에 서비스의 기능 목록을 파악하는 문서

초기 기능 기획 단계에서는 내가 요구사항정의서(우리 서비스의 굵직한 기능명시)를 적고 개발자들에게 보여주는 방식으로 소통하는 문서로 사용하다가, 화면기획(와이어프레임) 병행과 함께 기능들이 구체화되면서 기능정의서로 문서를 업데이트를 한 경험을 공유해 본다.


아래는 초기에 러프하게 잡았던 요구사항과 기능 목록 들이다.

초기 기능 기획시 작성했던 PRD 일부

 
이후 기능정의서는 화면 기준(대분류)으로 각 화면당 해당하는 기능들을 전부 명시하여 어떤 기능들이 우리 서비스에 있는지 한눈에 파악할 수 있도록 했다. (이렇게 업데이트를 하는데 한 달 정도 소요) 이후, 디자인/개발이 진행될때 생각지 못한 케이스 / 구현이 어려울 거 같은 이야기는 매주 꾸준히 있어서(ㅜㅜ) 회의를 통해 기능을 추가 or변경 or삭제했다. 이렇게 기능이 변경되면 문서의 업데이트는 당연히 진행했다.

현재 기능정의서의 일부

 
느낀점&배운 점
와이어프레임 후에는 디자인을 하는 단계에서도, 개발을 하는 단계에서도 기능정의서는 계속 업데이트가 되어야 한다. 아까도 말했듯 뭔가 새로운 이슈들은 계속 생기기 때문에! 처음부터 완벽한 기획은 없고 아직도 꾸준히 (2024.01 기준) 계속해서 업데이트 중이다. 기능정의서가 없으면 우리 서비스의 모든 기능을 처음에 어떻게 기획했는지 기억이 나지 않고, 흔들리기 때문에 가장 중요한 문서라는 생각이 든다. 
 

---

정책정의서
서비스를 움직이도록 하는 규칙서

 
기능정의서와 함께 병행하며 작성한 문서가 바로 이 정책 정의서였다. 위에서도 언급했듯이 우리가 생각하는 큰 틀의 기능은 바뀌지 않지만, 서비스가 돌아갈 때(유저가 어떻게 행동할지)를 생각하면 정책서는 필수인 문서라는 것을 깨닫게 되었다. 내가 기획하고 있는 여비는 '돈'과 관련된 서비스라 정책을 생각하면 기능이 변경되거나 디자인이 변경되어야 하는 경우가 종종 발생했었다. 
 
예시를 들어보면, [가계부] 기능이라는 큰 틀 안에서 1) 경비 추가, 2) 경비수정, 3) 경비삭제라는 기능이 존재한다. 이때 정책으로 추가(입력)할 때 금액 소수점은 어떻게 해야 하는지, 경비 금액은 가계부 화면에서 어떤 규칙으로 어떻게 노출해야 하는지 등등이 필요했다. 즉, 서비스가 굴러갈 수 있도록(개발을 할 수 있도록?) 이런 것들이 기획에서 결정되어야 했다. 이런 규칙이 없으면 어떻게 구현해야 하는지 개발도 어려워지고, 디자인도 어려워지고! 소통은 더더욱 힘들어지기 때문에 구성원들과 계속 회의를 하고 문서로 계속 관리하는 것이 반드시 필요했다.

 

---

히스토리관리

마지막으로 이러한 문서들을 관리할 때 어떻게 관리했는지 이야기하고 글을 마치려 한다. 처음과 다르게 계속 기획은 바뀌게 되고 그에 따라 문서도 업데이트가 되는데, 그때마다 이전의 내역에서 어떻게 바뀌었는지 관리가 안 되는 것도 문제라 생각했다. 그래서 나는 [버전관리]라는 시트를 따로 운영하면서 언제, 어떤 지점이 바뀌었는지를 전부 적으며 관리했다. 이렇게 관리하니 어떤 이유로 우리가 바꾸었었는지, 처음 기획은 어땠었는지 효과적으로 알 수 있어서 히스토리 관리에 신경을 많이 썼다.

 
 
글을 마치며
내가 쓴 양식은 맞는 건가?  끊임없이 의문을 가졌었다. 처음에는 내 산출물에 내가 자신을 가지지 못했었는데 우리 팀원들이 잘 이해하고 소통에 필요한 문서로 자리매김했다면 그건 성공한 산출물이란 생각이 점점 들어갔다. 그동안 사프를 할 때 산출물을 따로 남기지 않고 피그마에 전부 입력하는 형태로 관리해서 처음부터 기능정의서를 적는 게 어색하고 어려웠지만, 이번 YAPP 활동을 통해 조금은 성장할 수 있는 시간이 된 것 같아 매우 뿌듯하다.✌그리고 이젠 이런 문서가 없이 진행했다면 어떻게 됐을지.. 상상만 해도 무서워지는 거 같다.. ㅎㅎ
문서화! 어렵지만 경험을 쌓다 보면 언젠가 내공이 쌓이라 믿는다

-두려워말고 해 보는 거야!