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

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

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

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

거창한 도구나 조직이 없어도, 규칙 몇 가지만 정해두면 개발 속도와 화면 일관성이 눈에 띄게 달라진다. 왜 작은 프로젝트에도 디자인 시스템이 필요할까혼자, 혹은 두세 명이서 서비스를 만들다 보면 흔히 겪는 상황이 있다.로그인 폼을 만들 때 썼던 파란색과, 며칠 뒤 상품 상세 페이지 버튼에 쓴 파란색이 미묘하게 다르다. 어떤 카드 컴포넌트는 모서리가 둥글고, 어떤 카드는 각져 있다. 급하게 필요한 대로 값을 그때그때 정하다 보니 벌어지는 일이다. 문제는 이게 단순히 미관의 문제가 아니라는 점이다. 매번 "이번엔 패딩을 몇 픽셀로 할까", "이 버튼은 어떤 회색을 쓸까"를 다시 고민해야 하니 작업 속도 자체가 느려진다. 디자인 시스템은 이런 반복되는 결정을 미리 한 번만 내려두고, 그 다음부터는 그냥 가져다..