기획자의 작업대

글은 다 썼는데 안 예쁜 노션 정리법 글은 다 썼는데 안 예쁜 노션 정리법 📌 목차 왜 다 쓴 문서가 안 예뻐 보일까 레이아웃을 이루는 3요소 — 다단·여백·구분선 적용 방법 — 실제로 손보는 순서 실무 팁 3가지 마무리 FAQ 기획서를 다 쓰고 나서 노션 페이지를 쭉 훑어봤는데, 이상하게 눈에 잘 안 들어오는 경우가 있습니다. 내용은 빠진 게 없는데도 문서가 답답해 보이고, 스크롤을 몇 번 내려야 원하는 부분을 찾을 수 있습니다. 저도 기획 문서를 노션으로 옮기고 나서 이런 경험을 했습니다. 텍스트만 위에서 아래로 쭉 나열하다 보니, 분명 다 쓴 문서인데 팀원들이 "이거 어디 있는 내용이었죠"라고 되묻는 일이 잦았습니다. 문제는 내용이 아니라 레이아웃이었습니다. 이번 글에서는 다단, 여백, 구분선 세 가지만 정리해도 문서가 눈에 띄게 정돈되는 방법을 다룹니다. 1. 왜 다 쓴 문서가 안 예뻐 보일까 노션은 기본적으로 블록을 위에서 아래로 쌓는 구조입니다. 제목, 문단, 리스트를 순서대로 넣기만 해도 문서 형태는 갖춰지지만, 정보량이 많아질수록 세로로만 길게 늘어진 문서가 됩니다. 세로로 긴 문서는 읽는 사람이 지금 어느 구간을 보고 있는지 스스로 계속 확인해야 합니다. 구간을 나누는 시각적 장치가 없으면, 내용이 정확해도 훑어보기 어려운 문서가 됩니다. 반대로 성격이 다른 정보를 나란히 배치하거나, 구간이 바뀌는 지점을 표시하거나, 답답한 구간에 숨 쉴 공간을 주는 것만으로도 같은 내용이 훨씬 정리되어 보입니다. 이 세 가지 장치가 바로 다단, 여백, 구분선입니다. 2. 레이아웃을 이루는 3요소 — 다단·여백·구분선 세 요소는 각각 다른 역할을 합니다. 다단은 성격이 다른 정보를 좌우로 배치해서 비교하거나 병렬로 보여줄 때 쓰는 장치이고, 여백...

노션 단축키 정리, 문서 작성 시간 줄이는 법 노션 단축키 정리, 문서 작성 시간 줄이는 법 📌 목차 회의록 쓰다가 슬래시 메뉴만 몇십 번 열었던 날 노션 단축키의 두 축 — 마크다운 단축키와 커맨드 단축키 단축키 있을 때와 없을 때, 같은 문서를 써봤습니다 카테고리별 단축키 정리 실무 팁 3가지 마무리 FAQ 1. 회의록 쓰다가 슬래시 메뉴만 몇십 번 열었던 날 주간 회의록을 노션으로 정리하던 날이었습니다. 안건마다 제목을 달고, 액션 아이템은 체크박스로, 참고 자료는 토글로 접어 넣다 보니 슬래시( / ) 메뉴를 여닫는 손이 쉴 틈이 없었습니다. 회의가 끝나고 문서를 다시 보니 내용은 다 들어있는데, 정작 회의 시간보다 회의록 정리에 들인 시간이 더 길게 느껴졌습니다. 손이 마우스와 메뉴 사이를 계속 오갔기 때문입니다. 그날 옆자리 동료가 # 하나로 제목 블록을 만들고, > 하나로 토글을 여는 걸 보고서야 단축키를 거의 안 쓰고 있었다는 걸 깨달았습니다. 이번 글에서는 실무에서 바로 써먹을 수 있는 노션 단축키를 카테고리별로 정리했습니다. 2. 노션 단축키의 두 축 — 마크다운 단축키와 커맨드 단축키 노션 단축키는 크게 두 종류로 나뉩니다. 하나는 마크다운 단축키 로, 문장을 입력하면서 특정 기호를 치면 그 자리에서 블록이 바뀌는 방식입니다. # 을 치고 스페이스를 누르면 제목 블록이 되는 식입니다. 다른 하나는 커맨드 단축키 로, cmd/ctrl 같은 조합키를 눌러 실행하는 방식입니다. 텍스트 서식을 바꾸거나 페이지를 이동할 때, 이미 써놓은 글자를 선택한 상태에서 쓰는 경우가 많습니다. 두 방식은 쓰이는 시점이 다릅니다. 마크다운 단축키는 "새 블록을 만들 때", 커맨드 단축키는 "이미 있는 내용을 다룰 때" 쓴다고...

노션 표·이미지·파일·링크 삽입법 노션 표·이미지·파일·링크 삽입법 📌 목차 표 삽입하기 — 항목과 값을 짝지어 보여줄 때 이미지 삽입하기 — 설명보다 한 장이 빠를 때 파일 첨부하기 — 원본 문서를 그대로 남겨야 할 때 링크 삽입하기 — 페이지를 연결하는 법 실무 팁 3가지 마무리 FAQ 기획서 하나에 요구사항 표, 화면 캡처, 참고 PDF, 관련 페이지 링크를 한꺼번에 넣어야 했던 적이 있습니다. 표는 일단 텍스트로 나열하고, 이미지는 캡처해서 대충 붙이고, PDF는 링크만 남겨뒀습니다. 결과물을 리뷰받는 자리에서 팀장이 "이 파일 원본은 어디 있냐"고 물었는데, 정작 저도 어느 메신저로 공유했는지 기억이 안 났습니다. 표·이미지·파일·링크를 각각 다르게 다뤄야 한다는 걸 그때 처음 실감했습니다. 이번 글에서는 노션에서 이 네 가지 요소를 어떻게 삽입하고, 언제 어떤 방식을 골라야 하는지 정리했습니다. 1. 표 삽입하기 — 항목과 값을 짝지어 보여줄 때 슬래시( / )를 입력하고 "표"를 선택하거나, | 세 개를 입력하면 표 블록이 만들어집니다. 요구사항, 일정, 담당자처럼 항목과 값이 짝을 이루는 정보는 줄글보다 표로 정리할 때 훨씬 빠르게 읽힙니다. 항목 내용 담당 화면 설계 결제 플로우 와이어프레임 기획팀 API 명세 결제 승인/취소 엔드포인트 정의 개발팀 표 블록은 열 너비 조정, 셀 색상 지정, 정렬까지 가볍게 지원합니다. 다만 항목이 계속 늘어나거나 상태별 필터링이 필요해지는 시점부터는 표 블록으로는 한계가 있습니다. 이때는 표를 데이터베이스로 전환하는 편이 관리가 훨씬 수월합니다. 2. 이미지 삽입하기 — 설명보다 한 장이 빠를 때 이미지를 넣는 방법은 세 가지입니다. 파일을 드래그해서 바로 끌어다 ...

노션 하위 페이지로 문서 계층 잡는 법 노션 하위 페이지로 문서 계층 잡는 법 📌 목차 노션 페이지 계층의 개념 — 상위 페이지와 하위 페이지 계층이 꼬였던 사례와 정리 기준 적용 방법 — 하위 페이지 만들기와 구조 설계 실무 팁 3가지 마무리 FAQ 신규 프로젝트 하나를 노션으로 관리하기 시작했을 때, 처음에는 페이지 하나로 충분했습니다. 그런데 기획서, 회의록, 레퍼런스가 쌓이면서 어느새 페이지가 스무 개를 넘어갔고, 필요한 문서를 찾는 데만 한참씩 걸리는 상황이 됐습니다. 사이드바를 열어도 어떤 페이지가 어디에 속해 있는지 한눈에 안 보였습니다. 하위 페이지를 그때그때 손에 잡히는 대로 만들어 넣은 게 문제였습니다. 이번 글에서는 노션 페이지가 늘어날 때 계층을 어떻게 잡아야 문서를 오래 써도 헤매지 않는지 정리했습니다. 1. 노션 페이지 계층의 개념 — 상위 페이지와 하위 페이지 노션 문서는 기본적으로 페이지 하나에 하위 페이지가 딸려 있는 트리 구조입니다. 상위 페이지 안에서 하위 페이지를 만들면, 그 하위 페이지는 다시 자기 하위 페이지를 가질 수 있습니다. 이 구조를 어떻게 쓰느냐에 따라 문서가 폴더처럼 정돈되기도 하고, 뒤죽박죽 쌓인 창고처럼 되기도 합니다. 사이드바 계층과 인라인 하위 페이지 하위 페이지를 만드는 방법은 크게 두 가지입니다. 하나는 사이드바에서 상위 페이지 아래에 바로 추가하는 방식이고, 다른 하나는 본문 중간에 페이지 블록을 삽입해서 인라인으로 넣는 방식입니다. 두 방식 모두 결과적으로는 "하위 페이지"지만 역할이 다릅니다. 사이드바 쪽 하위 페이지는 독립적으로 찾아 들어가는 문서에 가깝고, 인라인 하위 페이지는 상위 페이지 본문 흐름 속에서만 의미가 있는 문서에 가깝습니다. 이 차이를 모르고 아무 데나 넣으면, 나중에 필요한 문서를 사이드바에서도 본...

피그마 학습, 기획자는 어디까지 배울까 피그마 학습, 기획자는 어디까지 배울까 기획자의 작업대 · 실무 가이드 처음 피그마를 켰을 때, 왼쪽 사이드바에 늘어선 아이콘들을 보고 뭐부터 눌러야 할지 몰라 한참을 멍하니 있었던 기억이 있습니다. 그 주 주말에 유튜브 강의를 몇 개나 정주행했는데, 막상 실무에 들어가 보니 배운 내용을 모두 사용하지는 않았습니다. 반대로 어떤 동료는 딱 필요한 기능 몇 가지만 익히고도 개발자, 디자이너와의 커뮤니케이션에서 전혀 막힘이 없었습니다. 그 차이를 겪고 나서, "얼마나 배워야 충분한가"에 대한 기준이 사람마다 다르다는 걸 알게 됐습니다. 이번 글에서는 기획자 입장에서 피그마를 어디까지 배워야 실무에 지장이 없는지, 단계별로 정리해보겠습니다. 📌 목차 피그마 학습이 끝없이 느껴지는 이유 기획자를 위한 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는 "지금 무엇을 ...