그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법
그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법
기획서에 화면 수십 장을 나열했는데 개발자에게 이런 질문을 받나요?
- “그래서 이 버튼 누르면 정확히 어떤 조건에서 어디로 가나요?”
- “로그인 안 되어 있으면요? 네트워크 실패면요?”
단순히 화면을 선으로 잇는 건 ‘그림’입니다. 진짜 기획서는 사용자 행동과 시스템 판단이 얽힌 로직(Logic)이 보여야 합니다.
오늘은 피그마 생태계(특히 FigJam)를 활용해 개발자가 질문할 틈이 없는 살아있는 유저 플로우를 만드는 방법을 정리합니다. 🗺️
1) ‘화면 나열’과 ‘유저 플로우’의 결정적 차이
주니어 기획에서 흔한 실수는 해피 패스(Happy Path)만 따라 화면을 줄 세우는 것입니다. 하지만 서비스는 대부분 갈림길(Condition)로 만들어집니다.
화면 나열(그림)
A 화면 → B 화면 → C 화면
유저 플로우(로직)
A 화면 → [로그인 여부?]
├─ YES → B 화면
└─ NO → 로그인 → [성공?]
├─ YES → B 화면
└─ NO → A 화면(에러 토스트)
개발자가 코드를 짜는 데 필요한 건 “다음 화면”이 아니라 조건, 판단, 예외입니다.
2) 피그마에서 로직을 시각화하는 3가지 도구(Section, Connector, Label)
로직 플로우는 “정리 도구 + 연결 도구 + 라벨” 3개가 세트입니다.
2-1. Section(섹션): 기능 단위로 묶어 ‘지도’ 만들기
- 용도: 기능/페이지 단위로 화면 묶기(예: 결제, 로그인, 마이)
- 효과: 개발자가 전체 구조를 한눈에 파악
- 추천: 섹션 이름을 “기능명 + 목표”로 쓰기 (예: [결제] 주문 완료까지)
섹션은 피그마에서 캔버스를 정리하는 공식 기능으로 제공됩니다.
2-2. Connector(커넥터): 위치를 옮겨도 흐름이 깨지지 않게
로직 플로우는 FigJam에서 그리는 편이 특히 안정적입니다. FigJam 커넥터는 도형에 “착” 붙어서, 도형을 옮겨도 선이 따라옵니다.
- 도형과 도형을 연결하는 선(굽은/직선/곡선)을 지원
- 선 위에 텍스트 라벨을 넣고, 끝점/스타일을 조정 가능
FigJam 단축키 힌트: 직선 커넥터는 L, 굽은 커넥터는 X 또는 Shift + L로 빠르게 시작할 수 있습니다.
2-3. Label(라벨): 선만 있으면 미로, 라벨이 있으면 지도
라벨은 필수입니다. 라벨 없는 화살표는 “그냥 간다”만 말하고, 개발자는 “언제 가는데요?”를 다시 묻게 됩니다.
- 라벨 예시: [Tap] 결제하기, [조건] 로그인=NO, [결과] 결제=성공
- 분기 라벨: YES/NO, 성공/실패, 유효/무효처럼 2지선다를 명확히
3) 개발자가 감동하는 유저 플로우 표기 규칙(라벨 문법)
플로우의 품질은 “선의 개수”가 아니라 “라벨의 문법”에서 결정됩니다. 아래 문법으로 통일하면 질문이 줄어듭니다.
3-1. 화살표 라벨은 ‘행동 + 조건 + 결과’ 중 최소 1개를 포함
- 행동(Action): 사용자가 무엇을 했는가? 예: [Tap] 저장
- 조건(Condition): 어떤 상태에서? 예: [조건] 로그인=NO
- 결과(Result): 무엇이 발생했는가? 예: [결과] API 성공
3-2. 텍스트 규칙(추천)
[Tap] 버튼명
[조건] 변수=값
[결과] 성공/실패(또는 status=200/timeout)
이렇게 쓰면 플로우가 “그림”이 아니라 “명세”가 됩니다.
4) 의사결정 다이아몬드(Decision)로 “시스템 판단”을 그리는 법
모든 흐름이 “화면”으로만 이어지지 않습니다. 서버 판단, 데이터 검증, 권한 체크가 진짜 갈림길을 만듭니다.
4-1. 다이아몬드에는 ‘질문’만 넣기
- 좋은 예: 로그인 상태인가?
- 좋은 예: 잔액이 충분한가?
- 나쁜 예: “로그인이 필요합니다”(결론 문장이라 분기 조건이 흐려짐)
4-2. 분기선에는 답만 넣기(YES/NO를 짧게)
[로그인 상태인가?]
├─ YES → 다음 단계
└─ NO → 로그인 화면
표준 흐름도 기호(결정 다이아몬드, 프로세스, 입력/출력 등)를 사용하면 팀 해석이 더 일치합니다.
5) 예외 케이스(Empty/Error)를 플로우에 포함하는 방법
“예외는 나중에”는 보통 “재작업은 곧”으로 번역됩니다. 유저 플로우에 예외를 넣는 순간, 개발자는 구현 범위를 정확히 잡습니다.
5-1. 꼭 넣어야 하는 예외 3종
- Empty: 데이터 0건(첫 진입, 목록 없음, 검색 결과 없음)
- Error: 네트워크 실패, 서버 오류, 타임아웃
- Permission: 권한 없음, 유료/성인/관리자 접근 제한
5-2. 표기 팁(선 스타일로 ‘눈에 띄게’)
- 정상 흐름: 실선
- 예외 흐름: 점선(또는 다른 스타일) + 라벨에 [Error] 또는 [Empty] 접두사
- 예외 흐름은 반드시 “복구 버튼”까지 이어지게: Retry, Back, Home
예외는 “끝”이 아니라 “복구 동선”까지가 한 덩어리입니다.
6) 10분 루틴: 살아있는 유저 플로우 작성 순서
- 목표 1개 고정: 이 플로우가 설명하는 작업 목표는 하나만(예: 결제 완료)
- Entry/Exit 정의: 시작점(진입)과 종료점(성공/실패)을 먼저 박아두기
- 섹션으로 레인 만들기: (User / System / External) 또는 (앱 / 서버 / 결제사)처럼 구역 분리
- 화면 노드 배치: 핵심 화면만, 나머지는 링크로 참조
- 결정 다이아몬드 추가: “판단이 필요한 지점”을 화면 사이에 끼워 넣기
- 커넥터 연결: 도형에 붙는 커넥터로 연결(FigJam 추천)
- 라벨 붙이기: 모든 분기선에 YES/NO, 성공/실패를 필수로
- 예외 흐름 추가: Empty/Error/Permission 최소 1개씩
- 복구 동선 확인: 예외의 끝에 Retry/Home/Back이 있는지 확인
- 개발 질문 시뮬레이션: “이 버튼은 어떤 조건에서 어디로?”를 스스로 5번 물어보기
이 루틴을 돌리면, 플로우가 “선이 많은 그림”이 아니라 “답이 있는 지도”가 됩니다.
7) 예시: 결제 플로우(로그인·잔액·성공/실패) 텍스트 모델
아래는 FigJam/피그마에서 그대로 옮겨 그리기 좋은 “로직 중심” 플로우 예시입니다.
[상품상세]
↓ [Tap] 구매하기
[결제 진입]
↓
◇ 로그인 상태인가?
├─ YES → 다음
└─ NO → [로그인]
↓ ◇ 로그인 성공?
├─ YES → 결제 진입으로 복귀
└─ NO → [결제 진입] (토스트: 로그인 필요)
↓
◇ 잔액(또는 결제수단) 유효한가?
├─ YES → [결제 요청(API)]
└─ NO → [충전/수단등록 팝업]
↓ [Tap] 수단 등록 완료
→ 위 조건 재검사
[결제 요청(API)]
↓ ◇ 응답 성공?
├─ YES → [결제 완료 화면]
└─ NO → ◇ 실패 유형?
├─ [Error] 네트워크/타임아웃 → [에러 화면] (Primary: Retry, Secondary: Home)
├─ [Error] 잔액부족/검증실패 → [결제 진입] (필드 에러 메시지)
└─ [Error] 서버(5xx) → [시스템 오류 화면] (Home/문의하기)
포인트는 “화면을 더 그리는 것”이 아니라, 다이아몬드(판단)와 라벨(조건/결과)로 코드를 짤 수 있게 만드는 것입니다.
8) 개발 전달 체크리스트
- 플로우 목표가 1개로 고정되어 있는가?
- Entry(진입)와 Exit(성공/실패)가 명확한가?
- 결정 지점은 다이아몬드로 분리되어 있는가?
- 모든 분기선에 YES/NO(또는 성공/실패) 라벨이 있는가?
- 예외(Empty/Error/Permission)가 최소 1개 이상 포함되어 있는가?
- 예외는 복구 동선(Retry/Home/Back)까지 이어지는가?
- 화살표 라벨이 ‘행동/조건/결과’ 중 최소 1개를 포함하는가?
- 서버 판단(API 결과, 검증)은 “화면”이 아니라 “판단 노드”로 표현했는가?
- 섹션(기능 단위)로 맥락이 나뉘어 있는가?
- 개발자가 이 플로우만 보고 “상태 전이”를 코드로 옮길 수 있는가?
이 체크리스트에서 8개 이상이 YES면, 개발자 질문은 확실히 줄어듭니다.
FAQ
Q 유저 플로우를 화면 단위로 다 그려야 하나요?
A아닙니다. 유저 플로우는 “의미 있는 순간(결정 지점, 핵심 행동, 실패/복구)” 중심으로 그리는 편이 효율적입니다. 화면 전체는 별도의 스토리보드로 두고, 플로우에서는 노드로 요약하는 방식이 유지보수에 좋습니다.
Q Figma 디자인 파일에서 선으로 그리면 안 되나요?
A가능은 하지만, 로직 플로우처럼 “옮기고 정리하는” 작업이 많을수록 FigJam의 커넥터가 더 안정적입니다. FigJam 커넥터는 도형에 붙어서 이동 시 흐름이 덜 깨집니다.
Q 다이아몬드는 얼마나 써야 하나요?
A“개발자가 조건을 묻는 지점”마다 1개가 적당합니다. 로그인 여부, 권한, 결제 가능 여부, 데이터 유무처럼 분기가 생기는 곳을 먼저 다이아몬드로 잡으면 대부분 커버됩니다.
Q 예외 흐름(Empty/Error)은 어디까지 그려야 하나요?
A최소한 “어떤 화면이 뜨는지”와 “사용자가 어떻게 복구하는지(Retry/Home/Back/문의)”까지는 그려야 합니다. 예외에서 복구가 없으면, 플로우는 막다른 골목이 됩니다.
Q 라벨을 길게 쓰면 오히려 복잡해지지 않나요?
A라벨은 짧게, 대신 문법을 통일하는 게 핵심입니다. [Tap], [조건], [결과] 같은 접두사를 쓰면 길이가 짧아도 의미가 선명해집니다.