회의실에서 "이 버튼 좀 더 눈에 띄게 해주세요", "화면이 너무 복잡해 보여요" 같은 말을 한 번쯤 들어본 적 있으실 거예요.그런데 막상 왜 눈에 안 띄는지, 어떻게 덜 복잡하게 만들 수 있는지 설명하기는 쉽지 않습니다. UI 디자인 원칙은 바로 이럴 때 쓰는 공통 언어예요. 이름은 거창해 보여도, 사실 매일 쓰는 앱과 웹사이트에 이미 다 들어 있는 상식에 가깝습니다. 디자이너는 물론이고 기획자, 개발자, 마케터까지 알아두면 시안 피드백이 훨씬 명확해지는 원칙 10가지를 하나씩 살펴볼게요. 사람의 시선은 정해진 길로 움직인다1. F패턴 - 글이 많은 화면을 읽는 방식 채용 사이트에서 공고 목록을 볼 때를 떠올려 보세요.맨 위 공고는 회사명부터 연봉, 근무지까지 꼼꼼히 읽지만, 아래로 갈수록 왼쪽 회사명..

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

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

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

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