정책서가 필요한 이유, 피그마만으론 안 되는 것
예전에 화면 프레임 한쪽에 "이 조건이면 예외 처리"라고 텍스트로 적어둔 적이 있습니다. 급하게 넘긴 화면이라 정식 문서로 뺄 여유가 없었고, 어차피 나만 보면 되는 메모라고 생각했습니다.
몇 주 뒤 화면을 리디자인하면서 그 프레임을 통째로 지웠는데, 예외 조건도 같이 사라졌습니다. 개발자가 "그때 말씀하신 예외 케이스, 어디 적혀 있나요"라고 물었을 때에야 그 메모가 정책서 역할을 하고 있었다는 걸 깨달았습니다.
이번 글에서는 피그마로 정책 내용을 관리하는 게 왜 한계에 부딪히는지, 그리고 화면과 정책 문서를 어떻게 나눠야 오래 버티는지 정리해보겠습니다.
1. 피그마로도 정책서를 만들 수는 있다
먼저 짚고 넘어갈 부분이 있습니다. 피그마 안에서 정책 내용을 정리하는 것 자체는 충분히 가능합니다. 방법도 여러 가지입니다.
① 텍스트 프레임
화면 옆에 별도 프레임을 만들고 조건, 예외 케이스, 분기 로직을 텍스트로 적어두는 방식입니다. 화면과 같은 캔버스에 있어서 참조하기 편하다는 장점이 있습니다.
② FigJam 보드
포스트잇 형태로 정책 항목을 나열하고, 화살표로 조건과 결과를 연결하는 방식입니다. 브레인스토밍 단계에서 정책 초안을 잡을 때는 특히 유용합니다.
③ Dev Mode 주석
개발자에게 전달할 화면에 주석을 달아 특정 컴포넌트의 동작 조건을 설명하는 방식입니다. 화면과 설명이 1:1로 붙어 있어서 전달 누락이 적은 편입니다.
2. 그런데 왜 오래 못 버틸까
문제는 만들 수 있느냐가 아니라, 만든 뒤에 그게 버텨주느냐입니다. 세 가지 지점에서 균열이 생깁니다.
구조의 문제
정책서는 위계와 분기가 핵심입니다. "A 조건이면 B, 아니면 C"를 순서대로 읽을 수 있어야 합니다. 반면 피그마는 캔버스 기반이라 화면 배치 순서를 따라갑니다. 정책이 복잡해질수록 조건을 어느 프레임에 적어놨는지 캔버스를 뒤져야 합니다.
협업 대상의 문제
정책서를 참조하는 사람은 디자이너만이 아닙니다. 개발자, QA, CS까지 봅니다. "피그마 링크 들어가서 프레임 3번 찾아보세요"라고 안내하는 순간 접근성 장벽이 하나 생깁니다.
변경 이력의 문제
"이 정책이 언제부터 왜 이렇게 바뀌었는지"를 추적하려 해도 근거가 남아있지 않습니다.
화면과 정책의 생명주기는 다릅니다. 화면은 트렌드와 사용성에 따라 자주 바뀌지만, 정책은 사업 규칙이 바뀌지 않는 한 유지됩니다. 서로 다른 생명주기를 가진 것들을 한 프레임에 묶어두면, 둘 중 하나가 바뀔 때 다른 하나도 같이 흔들립니다.
3. 화면과 정책, 이렇게 나눠보세요
원칙은 단순합니다. 화면은 화면대로, 정책은 정책대로 각자의 도구에 둡니다. 피그마 화면에는 정책 문서로 연결되는 링크만 남기고, 판단 기준이 되는 조건과 예외는 별도 문서에서 관리하는 방식입니다.
이렇게 나누면 화면을 아무리 갈아엎어도 정책 내용은 그대로 남습니다. 반대로 정책이 바뀌어도 화면 작업과 무관하게 문서만 수정하면 됩니다.
4. 실무 팁 3가지
팁1. 화면엔 링크만, 판단 기준은 문서에 둔다
팁2. 정책이 바뀌면 반드시 이력을 남긴다
팁3. 정책서 목차는 조건별로 구성한다
5. 마무리
- 피그마로 정책 메모를 남기는 건 가능하지만, 화면이 바뀌면 함께 사라지기 쉽습니다.
- 정책서가 오래 버티려면 구조, 협업 대상, 변경 이력이라는 세 가지 조건을 갖춰야 합니다.
- 화면에는 링크만, 판단 기준은 별도 문서에 두는 것이 기본 원칙입니다.
지금 진행 중인 화면에 정책 조건을 텍스트로 적어둔 프레임이 있다면, 그 내용만 따로 문서로 옮겨보세요. 여러분 팀은 정책서를 어떤 도구로 관리하고 계신가요.