직무별 자소서 가이드
디자이너 자소서 쓰는 법 — 포트폴리오가 못 보여주는 것을 쓰는 방법
디자이너 자소서는 포트폴리오와 역할이 다릅니다. 포트폴리오가 결과라면 자소서는 판단 과정입니다. 무엇을 왜 버렸는지를 쓰는 법.
읽는 사람이 실제로 보는 것
- 디자인 결정의 이유 — 왜 이 구조, 왜 이 위계인지 (예쁨이 아니라 판단)
- 사용자 문제를 어떻게 정의했는지, 검증은 했는지
- 개발자·기획자와 충돌했을 때 어떻게 조율했는지
- 버린 안이 있는지, 왜 버렸는지
- 그 회사 제품의 디자인을 실제로 뜯어봤는지
디자이너 자소서에서 유독 자주 나오는 실패
"'사용자 중심 디자인을 지향합니다'"
왜 문제인가 — 모든 디자이너가 같은 말을 합니다. 실제로 사용자를 만났는지, 무엇을 알아냈는지가 없으면 슬로건입니다.
이렇게 바꾼다 — 사용자 인터뷰나 테스트에서 예상과 달랐던 것 하나를 씁니다. 예상이 틀렸던 경험이 사용자 중심의 가장 강한 증거입니다.
"포트폴리오 설명을 자소서에 반복한다"
왜 문제인가 — 읽는 사람은 포트폴리오를 따로 봅니다. 같은 내용이면 자소서가 자리를 낭비하는 것입니다.
이렇게 바꾼다 — 포트폴리오에 없는 것을 씁니다. 버린 안, 팀과의 충돌, 제약 조건 안에서의 타협. 결과물 뒤의 과정입니다.
"제약이 없었던 것처럼 쓴다"
왜 문제인가 — 실무 디자인은 일정·개발 비용·기존 시스템이라는 제약 안에서 합니다. 제약이 안 보이면 학교 과제처럼 읽힙니다.
이렇게 바꾼다 — 어떤 제약이 있었고 그 안에서 무엇을 포기하고 무엇을 지켰는지를 씁니다. 타협의 기준이 디자이너의 판단력입니다.
근거로 쓸 수 있는 경험의 모양
형용사 대신 이런 형태의 사실이 있어야 합니다. 규모가 작아도 구조가 같으면 근거가 됩니다.
- 온보딩 화면을 5단계에서 2단계로 줄이자고 제안했다가 사용자 테스트에서 이탈이 늘어 3단계로 되돌렸다
- 개발 일정 때문에 커스텀 컴포넌트를 포기하고 기본 컴포넌트로 같은 위계를 만드는 방법을 찾았다
- 디자인 시스템 문서를 만들면서 실제로 쓰이지 않는 컴포넌트 12개를 찾아 정리했다
- 기획자가 요구한 배너 3개를 하나로 합치자고 설득했고, 근거는 히트맵이었다
지원동기에서 언급하면 좋은 것
회사 칭찬이 아니라 조사한 흔적입니다. 아래 중 하나만 구체적으로 써도 "회사 이름만 바꾸면 어디에나 낼 수 있는 글"에서 벗어납니다.
- 그 회사 앱·웹을 실제로 쓰면서 발견한 사용성 문제와 내가 생각한 해결
- 그 회사 디자인 시스템이 공개돼 있다면 그것을 뜯어본 소감
- 채용 공고의 역할 설명(프로덕트/브랜드/그래픽)과 내 경험의 정확한 연결
쓴 자소서를 바로 점검하기
위 기준으로 자소서를 읽고 점수와 함께 "지금 바로 걸리는 것 3가지"를 짚어 줍니다. 그다음 같은 글로 면접 예상 질문을 뽑아 방어가 약한 문장을 미리 찾을 수 있습니다. 전부 무료, 가입 없음.
자주 묻는 질문
- 포트폴리오가 있는데 자소서는 뭘 써야 하나요?
- 포트폴리오에 없는 것을 씁니다. 버린 안과 그 이유, 팀과의 충돌과 조율, 제약 조건 안에서의 타협. 포트폴리오가 결과라면 자소서는 판단 과정입니다. 같은 프로젝트를 다루더라도 관점이 달라야 합니다.
- 실무 경험 없이 학교 과제만 있으면요?
- 과제에도 제약과 판단은 있습니다. 시간 제약, 교수의 피드백, 팀원과의 의견 차이. 그 안에서 무엇을 포기하고 무엇을 지켰는지를 쓰면 실무와 같은 구조가 됩니다. 제약이 없었던 것처럼 쓰는 것이 문제이지 과제 자체는 문제가 아닙니다.