기획자의 작업대

피그마 학습, 기획자는 어디까지 배울까 피그마 학습, 기획자는 어디까지 배울까 기획자의 작업대 · 실무 가이드 처음 피그마를 켰을 때, 왼쪽 사이드바에 늘어선 아이콘들을 보고 뭐부터 눌러야 할지 몰라 한참을 멍하니 있었던 기억이 있습니다. 그 주 주말에 유튜브 강의를 몇 개나 정주행했는데, 막상 실무에 들어가 보니 배운 내용을 모두 사용하지는 않았습니다. 반대로 어떤 동료는 딱 필요한 기능 몇 가지만 익히고도 개발자, 디자이너와의 커뮤니케이션에서 전혀 막힘이 없었습니다. 그 차이를 겪고 나서, "얼마나 배워야 충분한가"에 대한 기준이 사람마다 다르다는 걸 알게 됐습니다. 이번 글에서는 기획자 입장에서 피그마를 어디까지 배워야 실무에 지장이 없는지, 단계별로 정리해보겠습니다. 📌 목차 피그마 학습이 끝없이 느껴지는 이유 기획자를 위한 3단계 학습 로드맵 실무 팁 3가지 마무리 FAQ 1. 피그마 학습이 끝없이 느껴지는 이유 피그마 강의나 공식 문서를 펼쳐보면 배울 게 끝이 없어 보입니다. 컴포넌트, 오토레이아웃, Variables, 플러그인, 디자인 시스템 구축까지 목록이 계속 이어지기 때문입니다. 이건 피그마가 하나의 툴이 아니라 성격이 다른 두 가지 역할을 한 앱 안에 담고 있기 때문입니다. 하나는 화면을 그리고 다듬는 "디자인 제작" 기능이고, 다른 하나는 그 결과물을 팀과 주고받는 "협업" 기능입니다. 자동차에 비유하면 운전면허와 레이싱 기술의 차이와 비슷합니다. 도로에서 안전하게 이동하는 데 필요한 건 면허 수준의 지식이지, 트랙에서 최고 속도로 코너를 도는 레이싱 기술이 아닙니다. 둘 다 같은 차를 다루지만, 훈련 목적과 범위가 완전히 다릅니다. 기획자에게 피그마가 끝없이 느껴지는 이유는, 이 둘을 구분하지 않고...

PPT 기획자가 피그마에서 자주 하는 실수 7가지 PPT 기획자가 피그마에서 자주 하는 실수 7가지 기획자의 작업대 · 실무 가이드 📌 목차 슬라이드 감각 그대로 피그마를 켰던 날 PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT 기획자가 자주 하는 실수 7가지 실무 팁 3가지 마무리 FAQ 1. 슬라이드 감각 그대로 피그마를 켰던 날 처음 피그마로 화면 기획서를 만들던 날, 저는 습관대로 화면을 한 장씩 새로 그렸습니다. PPT에서 슬라이드를 복제하고 텍스트만 바꾸던 방식 그대로, 피그마에서도 프레임을 복사해서 문구만 고쳐나갔습니다. 문제는 열 번째 화면쯤에서 터졌습니다. 버튼 색을 하나 바꿔야 하는데, 그 버튼이 들어간 화면이 몇 개인지조차 파악이 안 됐습니다. 결국 화면을 하나하나 열어서 같은 버튼을 스무 번 넘게 고쳐야 했습니다. 디자이너가 그 모습을 보고 "컴포넌트로 만들어두지 그러셨어요"라고 했을 때, 저는 그게 정확히 뭘 의미하는지도 몰랐습니다. 이번 글에서는 저처럼 PPT 감각으로 피그마를 시작한 기획자가 자주 걸리는 실수 7가지를 정리해보겠습니다. 2. PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT는 한 장 한 장이 독립된 결과물입니다. 슬라이드끼리 데이터를 공유하지 않아도 발표라는 목적은 그대로 달성됩니다. 반면 피그마는 화면끼리 서로 연결되고 재사용되는 것을 전제로 설계된 도구입니다. 비유하자면 PPT는 낱장으로 인쇄하는 전단지에 가깝고, 피그마는 부품을 조립해서 완성하는 가구 설계도에 가깝습니다. 전단지는 한 장씩 새로 디자인해도 상관없지만, 가구는 같은 나사와 경첩을 여러 군데서 재사용해야 조립도 수리도 쉬워집니다. 이 차이를 모르고 PPT 하던 방식 그대로 피그마를 쓰면, 화면은 늘어나는데 관리는 점점 힘들어지는 상황을...

피그마·Jira 연동, 기획 협업흐름 잡는 법 피그마·Jira 연동, 기획 협업흐름 잡는 법 📌 목차 화면, 이슈, 근거가 각자 따로 노는 순간 세 도구는 원래 역할이 다르다 실제로 겪은 어긋남 참조 구조로 연결하는 법 실무 팁 3가지 마무리 FAQ 1. 화면, 이슈, 근거가 각자 따로 노는 순간 피그마에 화면을 올리고, Jira에 이슈를 만들고, Confluence에 정책을 적어두면 협업이 저절로 될 거라 생각한 적이 있습니다. 막상 스프린트가 돌아가기 시작하니 세 곳의 내용이 서로 다른 이야기를 하고 있었습니다. 개발자는 Jira 이슈만 보고 작업했는데, 그 이슈에는 이틀 전 수정된 피그마 화면이 링크되어 있지 않았습니다. 결국 QA 단계에서 "이 버튼 위치가 왜 이렇게 됐냐"는 질문이 나왔고, 저는 세 곳을 오가며 어디서부터 어긋났는지 확인해야 했습니다. 이번 글에서는 피그마, Jira, Confluence가 각각 어떤 역할을 맡아야 하는지, 그리고 세 곳을 어떻게 연결해야 이런 어긋남이 줄어드는지 정리해보겠습니다. 2. 세 도구는 원래 역할이 다르다 세 도구를 연동한다고 하면 흔히 자동화 플러그인부터 떠올리지만, 그 전에 각 도구가 무엇을 담당하는지부터 명확히 해야 합니다. 역할이 겹치면 연동을 아무리 걸어도 정보가 어디 있는지 헷갈리는 문제는 그대로 남습니다. 도구 담당 영역 생명주기 Figma 화면의 최신 모습, 인터랙션, 스타일 자주 바뀜 Jira 지금 진행 중인 작업 단위, 담당자, 상태 작업이 끝나면 종료 Confluence 왜 이렇게 결정했는지에 대한 근거와 정책 사업 규칙이 바뀔 때만 갱신 정리하면 Figma는 "지금 화면이 어떻게 생겼는가", Jira는 "지금 무엇을 ...

피그마 Dev Mode란? 기획자가 알아둘 기능 피그마 Dev Mode란? 기획자가 알아둘 기능 📌 목차 피그마 Dev Mode란 무엇인가 기획자 관점에서 적용하는 법 실무 팁 3가지 마무리 FAQ 화면 시안을 캡처해서 슬랙으로 개발자에게 보낸 적이 있습니다. "이 여백 몇 px이에요", "이 회색 색상 코드가 뭐예요" 같은 질문이 하루 종일 따라왔고, 저는 매번 피그마를 열어 자로 재듯 확인해서 답을 보냈습니다. 나중에서야 피그마 안에 이런 질문 자체를 없애주는 모드가 따로 있다는 걸 알게 됐습니다. 바로 Dev Mode입니다. 이번 글에서는 Dev Mode가 정확히 무엇이고, 디자이너나 개발자가 아닌 기획자가 왜 이걸 알아둬야 하는지 정리해보겠습니다. 1. 피그마 Dev Mode란 무엇인가 Dev Mode는 피그마 화면 우측 상단 토글로 켤 수 있는 별도 작업 모드입니다. 평소 쓰는 디자인 모드가 "화면을 그리고 다듬는 용도"라면, Dev Mode는 "그 화면을 구현하는 데 필요한 정보를 뽑아내는 용도"에 가깝습니다. 비유하자면 인테리어 완성 사진과 시공 도면의 차이와 비슷합니다. 완성 사진만 보고는 벽 두께나 배관 위치를 알 수 없듯이, 디자인 모드 화면만 보고는 여백 값이나 색상 코드, 컴포넌트 상태값을 정확히 알기 어렵습니다. Dev Mode는 그 도면 역할을 합니다. Dev Mode의 핵심 구성 요소 기능 설명 Inspect 패널 선택한 요소의 여백, 크기, 색상, 폰트 등 스펙을 자동으로 보여줍니다. 코드 스니펫 CSS, iOS, Android 등 언어별 코드를 자동으로 생성해 보여줍니다. 에셋 추출 아이콘, 이미지 등을 개발에 필요한 해상도와 포맷으로 바로 내려받을 수 있습니다. 주석(...

피그마 개발 전달 기준, 화면 선별하는 법 피그마 개발 전달 기준, 화면 선별하는 법 기획자의 작업대 · 실무 가이드 스프린트 막바지에 화면 30장을 한꺼번에 개발자에게 넘긴 적이 있습니다. 일정이 촉박해서 "일단 다 넘기고 보자"는 생각이었는데, 그중 절반은 빈 값이나 에러 상태가 정의되지 않은 화면이었습니다. 개발자가 화면마다 "이 경우엔 뭘 보여줘야 하나요"를 하나씩 물어오기 시작하면서, 전달이 아니라 문답이 되어버렸습니다. 그날 이후로 화면을 넘기기 전에 반드시 확인하는 기준을 따로 만들어두게 됐습니다. 이번 글에서는 어떤 화면을 먼저 넘기고 어떤 화면은 보류해야 하는지, 그 기준을 어떻게 잡는지 정리해보겠습니다. 📌 목차 개발 전달 기준, 무엇을 봐야 할까 화면 선별 기준 적용해보기 실무 팁 3가지 마무리 FAQ 1. 개발 전달 기준, 무엇을 봐야 할까 화면을 넘길지 말지는 "다 그렸는가"가 아니라 "개발자가 이 화면만 보고 구현할 수 있는가"로 판단해야 합니다. 이 질문에 답하려면 세 가지 축을 확인하면 됩니다. ① 화면 상태가 다 정의됐는가 정상 상태 화면 한 장만으로는 부족합니다. 데이터가 없을 때, 로딩 중일 때, 에러가 났을 때 화면이 각각 어떻게 보이는지까지 있어야 합니다. 이 세 가지가 빠진 화면은 겉으로는 완성돼 보여도 실제로는 절반짜리 화면입니다. ② 인터랙션과 분기 스펙이 명확한가 버튼을 눌렀을 때 어디로 이동하는지, 조건에 따라 다른 화면을 보여줘야 하는지가 화면만 봐서는 알기 어려운 경우가 많습니다. 이 부분이 명확하지 않으면 개발자는 임의로 추측해서 구현하게 되고, 나중에 다시 고쳐야 할 확률이 높아집니다. ③ 예외 케이스까지 화면에 반영됐는가 이 글은 2026.09 기준으로 작성...

정책서가 필요한 이유, 피그마만으론 안 되는 것 정책서가 필요한 이유, 피그마만으론 안 되는 것 예전에 화면 프레임 한쪽에 "이 조건이면 예외 처리"라고 텍스트로 적어둔 적이 있습니다. 급하게 넘긴 화면이라 정식 문서로 뺄 여유가 없었고, 어차피 나만 보면 되는 메모라고 생각했습니다. 몇 주 뒤 화면을 리디자인하면서 그 프레임을 통째로 지웠는데, 예외 조건도 같이 사라졌습니다. 개발자가 "그때 말씀하신 예외 케이스, 어디 적혀 있나요"라고 물었을 때에야 그 메모가 정책서 역할을 하고 있었다는 걸 깨달았습니다. 이번 글에서는 피그마로 정책 내용을 관리하는 게 왜 한계에 부딪히는지, 그리고 화면과 정책 문서를 어떻게 나눠야 오래 버티는지 정리해보겠습니다. 📌 목차 1. 피그마로도 정책서를 만들 수는 있다 2. 그런데 왜 오래 못 버틸까 3. 화면과 정책, 이렇게 나눠보세요 4. 실무 팁 3가지 5. 마무리 6. FAQ 1. 피그마로도 정책서를 만들 수는 있다 먼저 짚고 넘어갈 부분이 있습니다. 피그마 안에서 정책 내용을 정리하는 것 자체는 충분히 가능합니다. 방법도 여러 가지입니다. ① 텍스트 프레임 화면 옆에 별도 프레임을 만들고 조건, 예외 케이스, 분기 로직을 텍스트로 적어두는 방식입니다. 화면과 같은 캔버스에 있어서 참조하기 편하다는 장점이 있습니다. ② FigJam 보드 포스트잇 형태로 정책 항목을 나열하고, 화살표로 조건과 결과를 연결하는 방식입니다. 브레인스토밍 단계에서 정책 초안을 잡을 때는 특히 유용합니다. ③ Dev Mode 주석 개발자에게 전달할 화면에 주석을 달아 특정 컴포넌트의 동작 조건을 설명하는 방식입니다. 화면과 설명이 1:1로 붙어 있어서 전달 누락이 적은 편입니다. 이 글은 2026.08 기준으로 작성되었으며, 피그마 기능은 계속 업...

피그마 모달·팝업 설계, 기획자가 놓치는 7가지 피그마 모달·팝업 설계, 기획자가 놓치는 7가지 모달과 팝업, 디자이너에게 넘기기 전에 기획서에서 반드시 확인해야 할 7가지 체크포인트를 정리했습니다. 오버레이 처리부터 접근성까지, 실무에서 자주 빠뜨리는 항목을 사례 중심으로 다룹니다. 📌 목차 기획서엔 있는데 화면엔 없는 것들 모달, 팝업, 토스트는 다르다 흔한 실수 사례 기획서에 반드시 넣어야 할 7가지 체크리스트 실무 팁 1. 닫힘 규칙은 문장으로 남긴다 실무 팁 2. 포커스 이동, 기획 단계에서 정의한다 실무 팁 3. 모바일 전환 기준은 미리 합의한다 마무리 FAQ 기획서엔 있는데 화면엔 없는 것들 기획서에 "확인 모달 노출"이라고 한 줄 적어두고 디자이너에게 넘긴 적, 다들 한 번쯤 있을 겁니다. 문제는 QA 단계에서 터집니다. 오버레이를 클릭했을 때 닫히는지, 배경 스크롤은 잠기는지, 아무도 정의하지 않았기 때문입니다. 결국 개발자와 디자이너가 각자 판단해서 구현하고, 화면마다 동작이 미묘하게 달라집니다. 재작업은 그때부터 시작됩니다. 모달, 팝업, 토스트는 다르다 세 용어를 섞어 쓰는 팀이 생각보다 많습니다. 하지만 인터랙션 설계 관점에서는 명확히 구분해야 합니다. 모달(Modal) — 화면을 가리고 사용자의 다음 행동을 강제하는 요소. 확인/취소 없이는 뒤 화면으로 못 돌아갑니다. 팝업(Popup) — 정보 전달 목적이 강하고, 모달보다 닫힘 경로가 자유로운 경우가 많습니다. 토스트(Toast) — 사용자 행동을 막지 않고 일정 시간 후 자동으로 사라지는 알림입니다. 이 구분이 애매하면 디자이너와 개발자 모두 "이거 모달이에요, 팝업이에요?"를 매번 물어보게 됩니다. 용어를 기획서 초반에 정의해두는 것만으로도 커...

결제 사용자 플로우(User Flow) 1장 예시: 화면설계서 전 필수 동선 설계 [UX 기획] 화면설계서 전 필수 단계: 1장으로 정리하는 사용자 플로우(User Flow) 전략 기획서 작성, 혹시 '지도 없이 도시부터 그리는 모험'을 하고 계시진 않나요? 제출 기일이 촉박할 때면 저도 모르게 화면 설계부터 시작하곤 했습니다. 하지만 설계도 없이 벽돌부터 쌓은 집은 결국 무너질 수밖에 없더군요. 동선이 꼬인 기획서 앞에서 "이 기능은 왜 여기 있나요?"라는 날카로운 질문을 받을 때의 당혹감은 지금 생각해도 아찔합니다. 그래서 저는 이제 아무리 급해도 반드시 '사용자 플로우'부터 챙깁니다. 화면설계서라는 상세 지도를 그리기 전, 목적지까지의 가장 빠른 길을 찾는 과정이죠. 복잡한 기획을 단 1장으로 압축해 논리의 뼈대를 세우는 법 , 지금부터 하나씩 짚어보겠습니다. 📚 목차 화면부터 그리면 벌어지는 3가지 삽질 사용자 플로우(User Flow) vs 화면설계서(Storyboard) 차이 1장으로 끝내는 사용자 플로우 작성 4단계 복붙용: 1장 사용자 플로우 템플릿(High-level) 성공적인 User Flow 체크리스트(Dead-end 방지) FAQ: 사용자 플로우 실무 질문 모음 참고 자료(공식/권위 출처) 화면부터 그리면 벌어지는 3가지 삽질 많은 UX 기획자가 의욕적으로 화면설계서(Storyboard) 부터 시작합니다. 하지만 논리가 정립되지 않은 상태에서 화면부터 그리면, 다음 문제가 빈번하게 터집니다. 동선 질문 폭탄 : “이 버튼 누르면 어디로 가죠?”라는 개발자 질문에 흐름이 흔들립니다. 예외...

UX 개선 우선순위, 이렇게 정하면 안 흔들린다 — 실무 기준 4단계 공식 할 일이 산더미인데 어디부터 손대야 할지 모르겠다고요? 팀 회의에서 매번 우선순위가 바뀌어 멘탈이 흔들린 적 있다면, 이 글이 여러분의 구원투수가 됩니다. 이번 글에서는  실무에서 바로 쓰는 ‘4단계 우선순위 공식’ 을 공개합니다. 임팩트와 실행 가능성, 데이터 근거까지 한 번에 정리해서 팀 합의까지 빠르게 끌어내는 방법입니다.  📚 목차 왜 우선순위가 중요한가 실무 기준 4단계 공식 요약 우선순위 매트릭스(Impact × Effort) 실전 예시 팀 합의용 실행 프로세스 현장 체크리스트 & 템플릿 FAQ 1. 왜 우선순위가 중요한가 모든 개선안이 다 중요한 건 아닙니다. 잘못된 우선순위는 개발 리소스 낭비, 제품 혼란, KPI 정체로 이어집니다. 따라서 합리적 근거(데이터+비즈니스+사용자 영향)를 기반으로 우선순위를 정해야 팀의 실행력이 살아납니다. 2. 실무 기준 4단계 공식 요약 우선순위는 감이 아니라 공식(숫자 + 텍스트 근거) 으로 정하세요. 간단한 4단계로 요약하면 다음과 같습니다. 문제 정의 (Problem) — 무엇이 문제이고 누구에게 영향을 주나? (정량·정성 근거) 임팩트(Impact) — 개선 시 기대되는 효과를 수치 또는 가변 지표로 산정 (예: 전환율, 이탈률, ARPU) 난이도/비용(Effort) — 개발/디자인/기획 소요(작업량/기간/리스크)를 점수화 우선순위 산정(Priority = Impact ÷ Effort) — 값이 클수록 우선 적용 추가적으로 비즈니스 중요도(정책적 이유, 법적 요건 등) 는 우선순위 보정용 가중치로 반영하세요. 3. 우선순위 매트릭스(Impact × Effort) 실전 예시 표로 정리하면 의사 결정이 쉬워집니다. 아래는 실무 예시입니다. ...