피그마(figma)로 화면/기능 정의서를 만들어보자
기능 정의서와 화면 정의서를 한 곳에서 관리하기
이번에 소개하고 싶은 방법은 피그마든 스케치든 xd든 어떤 ui툴로도 활용 가능합니다. 프로젝트마다, 혹은 팀마다 각자만의 방식으로 효율과 최선을 찾고 있을 거예요. 저도 여러 시행착오 끝에 정착한 하나의 방법론을 공유하는 차원에서 글을 씁니다.
업무에도 순서가 있다
회사에 입사해 처음으로 UI 디자인 업무를 할당받았다고 가정해 봅시다.
여기서 디자이너가 받는 업무 요청 문서는 회사마다 조금씩 달라질 수 있지만 대체로 '기획서'로 통칭합니다. (초기 스타트업이라면 기획서 다운 기획서는 없을 가능성이 높습니다. 기획서를 요청하는 경우 '잠시만요!' 하며 종이에 슥슥 그려주는 경우 생각보다 정말 많습니다. 그래도 그거라도 없는 것보다는 있는 것이 훨씬 좋아요.) 이런 경우를 제외하고 기획서는 크게 아래 세가지 타입으로 나뉘게 됩니다.
세 가지 타입의
기획서
1. 기능 정의서
기본적으로는 개발 공수를 측정하는 데 사용합니다. 기능 정의서를 기반으로 프로젝트 단가 측정/인력 측정/일정 관리(m/m=man/month)를 합니다. 요구 사항이 담긴 기획 문서를 토대로 주로 프로젝트 매니저=개발자가 작성해요. 스펙과 기간이 고정되어 있는 워터폴 방식에서 유용하며 유연한 애자일 방식에서는 확정된 기능을 먼저 정의하기가 어렵다는 한계가 있습니다.
기능 정의서는 정해진 양식은 없습니다만 기본적으로 IA (Information Architecture:메뉴-정보 구조도)를 기반으로 해당 화면에 반드시 들어가야 하는 기능 위주의 요구 사항을 포함해야 합니다. 이 기능들을 기반으로 화면 디자인이 요청되며 디자이너는 제한된 범위 내에서만 디자인을 할 수 있습니다. 3개욀 내외의 단기 외주 프로젝트에서 자주 볼 수 있는 형식입니다.
형태는 기능을 따른다 ㅎㅎ
https://www.itlab.co.kr/v7/?m=bbs&bid=project&p=5&uid=7292. 스토리보드
국내 대기업 프로젝트는 백이면 백 외주사(=에이전시)를 이용합니다. 에이전시에서 행해지는 전통적인 워터폴 형식의 문서를 총칭하여 스토리보드라고 하며 이 문서 안에는 매우 다양한 콘텐츠가 정의됩니다. DB 저장 형식, 화면 설계서, IA, 메뉴 구조도, 일정 관리, 운영 정책 같은 큰 꼭지부터 화면명(id), 인터렉션 정의, 기능 정의 같은 디테일까지 방대한 분량이 몇 백장의 ppt 문서로 쪼개져 있어 초보자는 문서를 찾는 것조차 힘이 들어요.
아무래도 협업 주체가 다양하고 한 프로젝트에서 일하는 인력이 적게는 30명 많게는 100명에 이르게 되니 교통 정리해 주는 문서는 반드시 필요합니다. 그러나 작은 규모의 스타트업에서 일하는 디자이너, 개발자에게 스토리보드는 "투머치 인포메이션"이라는 인상이 듭니다.
빠르고 - 유연한 - 실험하고 - 개선하는
애자일 방법론과는 도무지 어울리지 않는 방식이죠.
이 경우에도 1과 마찬가지로 디자이너의 창의력은 제한되며 화면 설계서에 의존하여 그대로, 똑같이, 예쁘게만 디자인하는 경우가 많습니다. 그래서 저는 스토리보드나 기능정의서를 받아서 일 하는 것을 썩 좋아하지 않습니다. ㅎㅎ 커뮤니케이션 로스도 많구요.
일반적인 스토리보드의 형식, 긴 화면은 다음 장에서...3. 화면 정의서
디자이너가 화면의 기획 의도를 설명하는 데 사용합니다. 위의 스토리보드를 실제 디자인 화면으로 옮기는 과정에서 주니어라면 거의 똑같이 - 시니어라면 내용은 보전하되 좀 더 창의적이거나 다르게 표현할 수 있는 거죠. (여기서 말하는 주니어, 시니어는 레벨 차이를 의미함)
어찌 되었거나 디자이너도 디자인 시안만 만들고 끝! 이 아니라 시안의 내용을 설명하는 또 다른 문서가 필요해집니다. 디자이너의 의도 또한 글로써 정의되어야 하기 때문입니다. 화면 정의서는 누구에게 설명해야 하는 내용인가를 기준으로 개발자가 보는 용도, 클라이언트(발주 부서/팀원)가 보는 용도로 나뉘게 됩니다. 합의된 요구 사항을 화면에 녹여낸 후 해당 내용을 양측에게 전달하기 위해 사용되죠.
ㅇㅇ 기능은 ㅇㅇ 화면 어디에 ㅇㅇ처럼 들어간다
ㅇㅇ 기능은 최대 ㅇㅇ, 최소 ㅇㅇ까지 가능하다
장바구니는 최대 한 달까지 보관
ㅇㅇ 데이터는 ㅇㅇ이다
비밀번호 영문 숫자 조합 8자리
-합의된 요구 사항 정의
ㅇㅇ은 최대 10개, 넘치면 캐로셀 스크롤
bg fixed, focus + 넘버 키보드 활성화, 숫자 input
A 클릭 후 토스트 팝업 3초
A부터 B까지는 고정 영역
-디자인 의도 표현
처럼 구체적인 내용과 제한 사항 등을 담고 있습니다.
그렇다면 여기서 의문이 듭니다. 기능 정의서나 스토리보드는 필요 없는 것 아닌가요? 위에도 썼지만 프로젝트의 성격에 따라 필요한 문서가 다릅니다. 디자이너가 쓴 기획서가 빛을 보는 때는 아래의 두 케이스입니다.
0번 기획서가 전무한 경우
1번 기능 정의서만 있는 경우
디자인을 하다 보면 처음의 기획 내용과 달라질 필요가 있는 사항들도 반드시 있으므로 중간중간 협의 후 초기의 기획 내용을 지속적으로 업데이트해야 합니다. 따라서 1번의 기능 정의서가 프로세스의 선에 있든 후에 있든, 디자이너의 화면 정의서는 무조건 필요합니다. 서론이 길었지만 이 글을 쓰게 된 이유는 기능 정의서와 화면 정의서를 따로 관리하지 않고 통합해보니 이런 게 좋더라라는 글입니다.
시행착오들
저 또한 사용하는 툴들이 해마다 바뀌면서 시행착오를 겪었는데요. 그중 최악은 xd의 프레젠테이션 모드에서는 클라이언트용으로, 제플린에서는 개발자용으로 따로따로 적었던 일이었습니다.
그래서 같은 내용을 두 번 적기도 하고, 그 내용을 어디에 적었는지 화면 단위로 찾아야 하는 핵 귀찮음을 겪기도 했죠. (제플린이나 xd, 스케치의 프레젠테이션 모드는 따로 애플리케이션을 쓰지 않는 이상 전체 화면을 한눈에 볼 수 없습니다) 무엇보다 보는 사람이 불편하니 내용을 제대로 보지 않고 디자인 화면만 보고 컨펌을 한 후 나중에 딴 소리 하는 경우도 왕왕 있었습니다.
추억의 제플린개발자가 보는 용으로 적고
xd 프레젠테이션 모드클라이언트가 보는 용으로 또 적는다.
다른 방법으로 노션이나 엑셀 표로 화면을 관리하고 스크린 링크를 일일이 따서 넣는 방법도 잠깐 시도해 봤습니다만 디자인을 하다 보면 화면이 계획과 다르게 늘어날 때도, 줄어들 때도 있기 때문에 화면이 수정될 때마다 링크를 수정해야 하는 번거로움 때문에 포기했습니다.
그러다가 찾은 저만의 방법.
그냥 아예 화면 옆에 기능 정의서를 같이 쓰는 건 어떨까?
방법 : 아트보드를 충분한 간격으로 동일하게 떨어뜨린다 - 그 사이에 기능 정의서를 화면 컨텐츠의 세로축과 최대한 똑같이 맞춰서 쓴다.
이런 점들이
좋았습니다
1. 시각적으로 인지하기 좋다.
어떤 문서이건 아무리 체계적으로 정리를 잘한다고 해도 해당 체계 내에서의 질서이기 때문에 결국 가장 직관적이고 빠른 인지는 시각적 인지인 것 같습니다. 화면 옆에 기능 정의서를 같이 쓰면 일일이 스크린을 캡처해서 ppt 문서로 옮기지 않아도 되고 긴 화면도 자르지 않고 설명할 수 있어 편합니다.
2. 효율적이다.
별도의 화면 아이디, 스크린 네임을 '재정의'할 필요가 없습니다. 화면이 수정/삭제/이동되는 경우 번호 네이밍 (ex 01 스크린_01 스크린)을 다시 해야 하는 경우가 종종 있는데, 스크린 번호를 매기지 않고 flow별로 스크린 a / 스크린 b 정도로만 쪼개서 네이밍을 합니다.
그냥 안드로이드 87번 화면3. 정책/기능/화면 정의를 한 번에 볼수 있다.
지금까지 제플린/액슈어/ppt/노션/엑셀/기타 프로토타이핑에 분산해서 적은 내용을 한눈에, 한 곳에서 관리할 수 있습니다. 이를 위해서 피그마 기능 정의서에는 협의된 내용을 항상 최신 상태로 업데이트합니다. (예: 댓글/회의로 소통한 내용의 결론을 우측 기능 정의서에 바로 업데이트한다)
4. 댓글을 클릭하지 않아도 바로 볼 수 있다.
ppt를 제외한 앱에서는 댓글 기능으로 소통합니다. 이 경우 화면의 포인트를 정확히 찍어주는 장점은 있지만 내용을 보기 위해서는 일일이 클릭해야 하는 수고로움이 따릅니다. 화면 옆에 바로 적는 경우 클릭의 수고를 덜어주며 최종 버전과 논의된 히스토리를 나눠서 관리할 수 있다는 장점이 있어요.
5. 최종 버전과 화면을 항상 align 할 수 있다.
특히 기억력 향상에 도움이 돼요. 서비스 개발 특성상 기획 - 디자인 - 개발의 flow가 일반적인데, 화면 디자인을 마무리하고 다른 일을 하고 있다 보면 꼭 질문이 들어옵니다. 그런데 한두 달 전에 했던 일이라 기억이 안 날 때가 있어요. 당황잼 어디서 봤는데 그게 어디 있더라 하지 않아도 되고, 화면과 화면 정의서의 최종 내용만 보면서 소통하다 보면 신기하게 기억이 돌아옵니다!
6. 내용이 많아지면 아웃링크를 활용
특히 정책에 관련된 내용은 노션이나 엑셀로 아웃 링크합니다. 모든 내용을 다 쓸 수는 없으니까요.
화면과 화면 정의서를 기준으로 정책/기능 정의서를 링크하는 방법이 (현재로서) 제가 찾은 가장 직관적이고 효율적인 방법이네요.
물론 이런 방법, 저런 방법 다 동원해도 일하는 본인이 가장 편안한 방식으로 또 다른 형식의 문서 정리를 하게 될지도 모릅니다. 예를 들어 피그마 화면 링크를 엑셀이나 노션 표로 정리해서 보고 싶은 사람도 있겠죠. (feat. 표가 더 편한 사람)
어떤 방식이든 다 좋습니다. 다만 한 사람이 정리하는 문서는 한 곳에서만 볼 수 있게 하자 - *
이 원칙을 지키는 것이 미래의 나에게 더 도움이 되는 효율적인 방식일 거라 생각합니다. 이 방법에는 피그마만 한 툴이 없네요. 무엇보다 제플린 같은 타 애플리케이션에 의존하지 않아도 되니까요.
여기까지 저의 시행착오였어요 :) 더 좋은 방법이 나타난다면 바로 폐기될 방법론 중 하나입니다. 여러분도 자신만의 노하우를 공유해주세요~!
피그마 커뮤니티에 템플릿을 공유하였습니다 :)
필요하신 분들은 자유롭게 사용해 주세요~
[하기로의 피그마 강의 보기]
성장하는 디자이너, 개발자, 마케터, 기획자, ceo가 세상이 필요로 하는 프로덕트를 만드는 세상을 꿈꿉니다.
프로덕트 기획과 디자인을 한 번에 끝내고 연봉 2배 올리세요!!!
-
copyright@하기로
