프로젝트를 하다 보면 이런 장면을 자주 만나게 됩니다. 디자이너는 시안에 "메인 파란색"이라고 적어 두었는데, 개발자는 코드에서 #3366FF를 쓰고, 다른 화면에서는 누군가 #3465FE를 넣어 둡니다. 눈으로 보면 거의 같은 색이지만, 이런 작은 차이가 쌓이면 QA 기간마다 "이 버튼 색이 왜 달라요?"라는 이슈가 수십 개씩 올라오게 되죠. 이 문제를 근본적으로 줄여 주는 도구가 바로 변수(Variables)입니다. 피그마에서는 "변수", 개발 쪽에서는 보통 "토큰(Token)"이라고 부르지만 가리키는 대상은 같습니다. 색상, 간격, 글자 크기처럼 반복해서 쓰이는 값에 이름을 붙여 한곳에서 관리하는 방식입니다. 디자이너와 개발자가 같은 이름을 쓰기 시작하면 소통이 빨라지고, 구현이 쉬워지고, 화면 전..

"이 아이콘 원본 파일 어디 있어요?", "버튼 그림자 값이 화면마다 달라요." 디자이너와 개발자가 함께 일하는 팀이라면 한 번쯤 이런 메시지를 주고받아 봤을 거예요. 이런 질문이 반복된다면 대부분 에셋(Asset)과 스타일(Style)이 체계적으로 정리되지 않았다는 신호입니다. 디자인 시스템이라고 하면 버튼이나 입력창 같은 컴포넌트를 먼저 떠올리기 쉽지만, 그 컴포넌트를 이루는 재료가 바로 에셋과 스타일이에요. 재료가 정리되어 있어야 핸드오프가 매끄럽고, 개발자가 "디자이너님, 이거 확인 한 번만…"이라고 묻는 횟수도 줄어듭니다. 이번 글에서는 피그마를 기준으로 에셋과 스타일을 어떻게 준비하면 좋은지 차근차근 살펴볼게요. 에셋: 개발자가 '내려받아야 하는' 모든 것에셋은 쉽게 말해 개발자가 코드로 직..

신규 입사 디자이너가 Figma 라이브러리를 열었을 때 가장 먼저 마주치는 감정은 대부분 "이 버튼은 언제 써야 하지?"라는 막막함이다.컴포넌트는 잘 만들어져 있는데, 그 컴포넌트가 왜 존재하고 어떤 상황에 써야 하는지 알려주는 문서가 없는 경우가 특히 국내 스타트업에서는 흔하다. 디자인 시스템이 진짜로 힘을 발휘하는 순간은 컴포넌트와 문서가 한 몸처럼 움직일 때다. 컴포넌트를 만들 때 자주 놓치는 세 가지컴포넌트 하나를 만드는 일은 생각보다 손이 많이 가는 작업이다. 버튼 하나만 봐도 색상, 크기, 아이콘 유무에 따라 조합이 수십 가지로 늘어난다. 이 과정에서 자주 놓치는 부분들이 있다. 1) 상태(State)를 끝까지 정의하지 않는다많은 팀이 기본 상태와 눌렀을 때 상태 정도만 만들어두고 개발 단계로..

많은 프로덕트 팀이 리서치 자체에는 진심이다. 몇 주씩 사용자 인터뷰를 하고, 페르소나를 정리하고, 여정 지도를 그린다. 보고서만 보면 흠잡을 데가 없다. 그런데 막상 "이 인사이트를 화면에 어떻게 옮기죠?"라는 질문 앞에 서면 회의실 분위기가 달라진다. 방금까지 근거로 가득했던 논의가 갑자기 "이게 더 낫지 않을까요"라는 취향 싸움으로 바뀐다. 이건 리서치가 부실해서 생기는 일이 아니다. 리서치 결과와 화면 설계 사이를 이어주는 층이 팀 안에 존재하지 않아서 생기는 일이다. 페르소나는 "누구"를 알려줄 뿐, "어떻게"는 알려주지 않는다페르소나 문서에는 나이, 직업, 목표, 불편함이 자세히 적혀 있다. 하지만 그 문서 어디에도 "버튼은 얼마나 커야 하는가", "이 화면은 정보 밀도를 얼마나 낮춰야 하는가..

많은 조직에서 디자인 시스템 프로젝트는 비슷한 순서로 흘러간다.컴포넌트를 정리하고, 토큰을 만들고, 문서를 쓰고, 마침내 배포한다. 그런데 정작 진짜 위기는 그 다음부터 시작된다. 잘 만들어 놓은 시스템이 조직 개편, 예산 삭감, 새로운 팀장의 취향 같은 이유로 슬그머니 외면받는 순간이 반드시 온다. 기술적으로 완성도가 높다고 해서 살아남는 게 아니라, 사람들이 계속 써야 할 이유를 느껴야 살아남는다는 뜻이다. 즉, 디자인 시스템에는 "만드는 기술"만큼이나 "설득하는 기술"이 필요하다. 이 글에서는 그 설득을 어떻게 이해관계자별로 다르게 풀어가야 하는지, 그리고 아무리 잘 만든 시스템도 무너지는 흔한 패턴들은 무엇인지 살펴본다. 같은 시스템, 부서마다 다른 언어로 설명해야 한다디자인 시스템을 설명할 때..