디자인 시스템 & 협업

작은 프로젝트에 디자인 시스템을 먼저 만들면 배보다 배꼽이 큽니다. 화면이 20개 미만이면 스타일 가이드 정도로 충분합니다. 반대로 화면이 100개를 넘거나 여러 명이 함께 작업한다면 없으면 지옥이 됩니다.

외주에서 "스타일 가이드 포함인가요?"는 별도 산출물 질문입니다. 시안만 넘기는 것과, 재사용 가능한 규칙 문서까지 만드는 것은 작업량이 다릅니다.

디자이너의 "컴포넌트"(Figma)와 개발자의 "컴포넌트"(React 등)는 같은 개념이지만 다른 도구에 있습니다. 이름을 맞춰두면(예: 둘 다 Button/Primary) 소통 비용이 크게 줄어듭니다.

베리언트를 정의하지 않고 시안마다 버튼을 새로 그리면 개발자는 그게 새 컴포넌트인지 기존 것의 변형인지 알 수 없습니다. 결국 비슷한 버튼이 열 종류 생깁니다.

이 구조 덕분에 버튼 색을 한 번만 바꿔도 전체 화면에 반영됩니다. 반대로 인스턴스를 "떼어내서(detach)" 마음대로 고치면 그 연결이 끊어져서, 나중에 원본을 바꿔도 그것만 안 바뀝니다 — 실무 사고의 단골 원인입니다.

디자이너와 개발자가 같은 단어를 쓰게 만드는 장치입니다. "이 파란색"이 아니라 "primary"라고 말하면 오해가 없고, 나중에 브랜드 색이 바뀌어도 토큰 값 하나만 고치면 됩니다.

개념은 훌륭하지만 실무에서 5단계를 엄격히 지키는 팀은 드뭅니다. "이게 분자인가 유기체인가"로 회의 시간을 쓰느니, 기본 요소 / 조합 / 화면 3단계 정도로 단순화해서 쓰는 편이 실용적입니다.

개발의 Flexbox와 거의 1:1로 대응됩니다. 오토 레이아웃으로 만든 시안은 개발자가 훨씬 쉽게 구현합니다. 반대로 요소를 눈대중으로 배치한 시안은 반응형 대응이 어렵습니다 — 실무 채용에서도 확인하는 항목입니다.

13px, 17px, 23px 같은 값이 섞이는 걸 막는 장치입니다. 개발자가 "이건 왜 15px이죠?"라고 묻지 않게 됩니다. 대부분의 화면 해상도가 8로 나누어떨어지는 것도 이유입니다.

"피그마 링크 드렸어요"는 핸드오프가 아닙니다. 최소한 ①상태별 화면 ②에러·빈 화면 ③이미지 리소스 ④폰트 파일 ⑤반응형 기준 이 5가지가 함께 가야 합니다. 체크리스트로 만들어두면 왕복이 줄어듭니다.

일정에 반드시 별도로 잡아야 합니다. 개발이 끝난 날이 프로젝트 끝나는 날이 아닙니다. 디자인 QA를 안 잡으면 "왜 시안이랑 다르죠?"가 오픈 직전에 터집니다. 보통 전체 일정의 5~10%를 배정합니다.