이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Figma를 처음 쓴 건 UI/UX 수업에서 팀 프로젝트 앱 프로토타입을 만들 때였습니다. 처음에는 컴포넌트 개념을 몰라서 같은 버튼을 여러 번 그렸는데, Auto Layout 기능을 익힌 뒤부터 디자인 수정 시간이 크게 줄었습니다. 팀원들과 실시간으로 피드백을 주고받는 경험이 가장 유용했는데, 코멘트 기능 덕분에 슬랙을 왔다갔다하지 않아도 됐습니다.
Adobe Illustrator는 포스터 디자인 동아리 활동에서 사용했고, 레이어 구조와 색상 팔레트 관리 방식을 익혔습니다. 두 도구 모두 협업 효율이 도구 숙련도만큼 중요하다는 걸 경험하게 해줬고, 지금도 팀 단위 작업에서 공유 파일 구조를 먼저 잡는 습관이 남아 있습니다. 도구를 쓸 줄 아는 것보다 왜 이렇게 구성하는지를 설명할 수 있는 것이 더 중요하다는 걸 프로젝트를 통해 배웠습니다.
Figma 프로젝트에서 어떤 원칙으로 파일을 구성할지가 나중에 수정 비용을 결정한다는 것을 경험했습니다. 버튼 하나를 고칠 때 20군데를 수동으로 바꾸는 상황이 반복되면서, 컴포넌트 라이브러리를 먼저 정의하고 나머지 화면은 그것을 조합하는 방식으로 바꿨습니다.
배리언트(variant) 시스템 — 같은 버튼의 크기·상태·색상을 한 컴포넌트에 묶어두는 것 — 을 쓰기 시작하면서 디자인 변경이 전체에 자동 반영되는 구조가 됐습니다. 팀 협업에서는 공유 라이브러리의 변경이 다른 팀원 화면에도 반영되기 때문에, 변경 전 팀 전체와 합의하는 것이 원칙이 됐습니다. 디자인 원칙이란 일관성과 재사용성을 유지하면서 변경이 쉬운 구조를 만드는 것이라고 이해하고 있습니다. 좋은 Figma 파일은 구조가 먼저입니다.
Figma와 개발자 사이의 가장 흔한 마찰은 스펙이 애매한 것이었습니다. 간격이 얼마인지, 색상 코드가 정확히 무엇인지를 매번 채팅으로 주고받는 것이 반복됐는데, Figma의 핸드오프 기능을 제대로 쓰기 시작하면서 그것이 줄었습니다. 개발자가 레이어를 클릭하면 스페이싱·색상 토큰·폰트 스타일이 자동으로 보이는 구조로 파일을 만드니, 질문이 오는 횟수가 눈에 띄게 줄었습니다.
설계 파일이 스펙 문서가 되는 것 — 별도 문서 없이 Figma 파일 하나로 개발 협업이 가능한 방향이 가장 효율적이었습니다. 협업 효율은 도구를 잘 쓰는 것보다 도구를 어떻게 구성하는지에서 나온다는 것을 이 경험에서 배웠습니다. 협업은 오해가 생기기 전에 구조로 막을 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.