Design

디자이너가 쓰는 FRD(기능정의서) - 그래서 FRD가 뭔데?

dokyy 2024. 10. 10. 22:29

FRD는 Functional Requirements Document의 약어로, 다른 말로는 SB (스토리보드), 화면설계서 또는 기획서 등으로 부릅니다. 

기능이 어떻게 구현되어야 하는지, 화면의 구성과 레이아웃, 케이스별 정의, 동작과 플로우 등 구축 시 필요한 모든 정보를 담은 문서입니다.

저는 세 번의 프로젝트에서 기능 정의, 정책 설계부터 화면 기획까지 직접 참여한 경험이 있는데요, 저와 같이 FRD를 작성하는 일이 있는 디자이너들을 위해 준비해봤습니다 :)

 

 

1. FRD의 산출물 형태는 어떻게 될까? 

 

친구가 "FRD의 산출물 형태란 정확히 어떤거야?"하고 질문한 적이 있습니다.

크게 화면의 대략적인 생김새를 보여주는 와이어프레임과 기능을 설명하는 디스크립션이 있다면 그게 바로 FRD입니다. 그 외에는 프로젝트에 따라 페이지 넘버나, 수정 이력등도 포함이 될 수 있습니다.

 

포맷은 피피티나 피그마일수도, 엑셀과 피그마에 나눠서 쓸 수도 있습니다. 기능정의와 화면설계정의를 분리할 수도, 묶어 정의할 수도 있습니다. 예를 들면 정책/로직이나 문구는 엑셀로 기능정의를 하고, 프론트 영역인 UI 화면 설계 (구조와 동작)만 Figma로 작성할 수도 있고, 정책과 유효성 검사로직 설계를 Figma에서 다 정의할수도 있습니다.

 

프로덕트의 볼륨에 따라 RnR과 기획을 관리하는 법과 담당 영역이 달라집니다. 볼륨이 클수록 다수가 쪼개관리하고, 작을수록 하나의 포맷에서 소수가 관리하게 됩니다. 따라서, 산출물 형태는 회사마다 달라지게 됩니다.

 

 

2. FRD의 예시

 

포스팅을 위해 예시로 유튜브 숏츠 메인 화면의 FRD를 작성해 보았습니다. 캡처 대신에 와이어프레임이 들어간다고 보시면 됩니다. 영역이나 기능 별로 넘버링을 해주고, 그 안에 세부 기능이 있다면 또 나눠서 정의를 해줍니다. 넘버링한 기능의 이름/상태/기능/케이스 등을 작성해줍니다.

 

또한 버전/수정 이력 역시 필수적으로 관리해야 하는데요, 이번 글에서는 다루지 않고 다른 글에서 따로 설명드리고자 합니다.

 

3. 어떤 것을 고려하면서 작성해야 할까?

 

 

1. 공통적인 내용은 한 곳에 모아 관리하기

좋아요/싫어요 등 버튼을 클릭했을 때 알고리즘 로직은 숏츠 뿐만 아니라 홈화면의 다른 유튜브 동영상에도 적용되는 로직일테니, 이 화면의 FRD에 몽땅 다 작성하는 것이 아니라 [알고리즘 문서]등 하나의 문서 안에 정리하고 작성해두는 것이 좋겠죠? 

마찬가지로 404에러, 화면 로딩 등 모든 화면에 반복적으로 나오는 내용 역시 공통 문서로 관리하는 것이 좋습니다.

 

2. 다음 프로세스 설명과 호출되는 화면 작성하기

'검색 Icon Button을 누르면 검색 화면으로 이동하고, 더보기 Icon을 누르면 더보기 Modal을 제공한다' 당연한 이야기지만
다음 화면으로 어떻게 이동하는지 설명이 필요합니다. 어디로 어떻게 이동하는 건지 알아야하니까요.

 

3. 기능 상태별 케이스 작성하기

기본 상태 뿐만 아니라, 다른 상태가 나올 수 있다면 상태별 케이스 정의가 필요합니다. 예를 들면 유튜브 댓글 Icon Button의 경우 댓글을 쓸 수 있는 상태 (Enabled) 도 있지만, 사용자가 해당 영상의 댓글을 중지한 Case인 비활성화 (Disabled) 상태 역시 존재합니다.

 

 

 

비슷하게 아래와 같은 케이스들도 꼭 작성해주어야 합니다.

 

Empty State / Default

영상을 업로드하는 화면이라면, 영상이 업로드된 화면(Default)도 있겠지만 영상을 하나도 업로드하지 않은 사용자 (Empty State)의 화면도 있겠죠? 빈 화면은 놓치기 쉬운데, 사용자가 페이지에 첫 진입 시 만나는 꼭 필요한 화면입니다.

 

 

 

Min / Max Case

유튜브 채널 이름은 몇자까지 작성할 수 있을까요? 최소(Min) 1자, 최대(Max) 50자입니다. 이처럼 최소 - 최대의 기준이 필요한 경우를 고려해 정책을 설계해야 합니다. 또한, 이름을 50자까지 설정할 수 있더라도 다른 화면에서 이를 모두 노출할지 고려해야 합니다. UI 구조를 고려해 '최대 1줄까지 노출하고 말줄임처리하며 Tap 시 전체 노출한다.'와 같은 기획 역시 함께 고민해야 기획이 완성됩니다.

 

 

 

필수 / 옵션 Case

유튜브에서는 영상 업로더가 제품 태그를 붙이면 위 화면에서 처럼 간단한 제품 소개와 제품 사이트로 이동할 수 있는 UI를 제공합니다. 이 기능은 사용자의 설정에 따라 화면에 띄워지는 선택적인 (Optional) 기능입니다. 이런 기능은 다른 좋아요/싫어요 같은 필수(Required)인 기능과 다르게 표시하고, 언제 이 기능이 제공되는 지를 디스크립션에 작성해주어야 합니다. 

 

 

마치며

FRD는 기능 정의, 정책 설계, 화면 기획 등 모든 정보를 담고 있는 문서로, 기획을 관리하고 개발자와 원활하게 소통하기 위한 중요한 산출물입니다. 필요한 기능에 대한 명확한 설명, 케이스 정의가 포함된다면, 작성 방식은 조직의 상황과 커뮤니케이션 방식을 고려해 유연하게 작성하는 것이 좋다고 생각합니다.

 

기획은 어려울 수 있지만, 사용자 경험을 중시하는 프로덕트/UX 디자이너에게 필요한 업무라고 생각합니다.

이 글이 더 좋은 사용자 경험을 제공하고자 하는 디자이너 분들께 도움이 되었으면 좋겠습니다.