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

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

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

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

다크모드는 색만 뒤집는다고 완성되지 않는다언젠가부터 새로운 앱이나 사이트를 들어가보면 다크모드도 같이 완성하는 곳이 많아졌다. 그런데 막상 들어가보면 라이트모드 화면의 흰색을 검정으로, 검정 글자를 흰색으로 바꾸는 것으로 끝내는 경우가 많다. 그렇게 완성된 다크모드는 눈이 편안해지기는커녕 오히려 화면을 오래 보기 힘들어지거나, 버튼과 배경이 구분이 안 되거나, 중요한 안내 문구가 흐릿하게 묻혀버리는 문제를 만든다. 다크모드는 색상표를 반전시키는 작업이 아니라, 별도의 디자인 시스템을 다시 설계하는 작업에 가깝다. 완전한 검정(#000000)이 항상 정답은 아니다다크모드를 처음 만들 때 가장 많이 빠지는 함정이 배경을 순수한 검정으로 칠하는 것이다.OLED 화면에서는 순수 검정이 배터리를 아껴준다는 장점..