작업물 소개와 경험 설명을 구분하기
디자이너 경력기술서에 화면 이미지가 많아도 자신의 역할이 자동으로 드러나는 것은 아닙니다. 어떤 요청을 받았고 어디에서 문제를 발견했으며 어떤 범위의 설계를 맡았는지 함께 설명해야 합니다. 브랜드, 편집, 제품 디자인처럼 직무마다 결과물이 다르므로 지원 공고에서 보는 역량과 자신의 작업을 먼저 연결하세요. 시각적인 완성도와 문제 해결의 근거를 서로 대신하는 것으로 취급하지 않습니다.
토스플레이스의 공식 프로덕트 디자이너 공고는 사용자 관점의 문제 해결 과정과 개선 전후 자료를 안내하는 사례입니다. 특정 기업의 사례일 뿐 모든 디자이너에게 같은 제출 방식을 요구하는 것은 아닙니다. 포트폴리오 제출 여부와 형식, 인터뷰 발표 자료의 조건은 지원하는 기업과 전형별로 확인합니다. 오래된 특별 전형을 현재의 일반 채용 규칙으로 읽지 않도록 주의하세요.
문제를 사용자 행동으로 적기
화면이 복잡했다는 표현을 사용자가 어떤 행동에서 막혔는지로 바꾸어봅니다. 주문 상태를 확인하는 직원이 다음 처리 단계를 찾기 어려웠다는 식입니다. 디자인을 바꾸기 전 사용성 검사나 현장 관찰을 했다면 대상과 범위를 적습니다. 조사 없이 내부 요청으로 시작한 프로젝트라면 그 사실을 밝히고 이후 어떤 방식으로 가정을 확인했는지 설명할 수 있습니다.
문제 정의에 디자인 용어를 많이 넣는 것보다 관찰한 장면을 구체적으로 적는 것이 유용합니다. 정보 구조를 개선했다고만 쓰기보다 같은 상태가 두 위치에서 다른 이름으로 표시되었다는 현상을 설명하세요. 사용자가 불편했을 것이라는 추측과 실제 문의나 관찰 기록을 구분하면 검증의 한계를 솔직하게 표현할 수 있습니다. 작은 조사 결과를 전체 사용자에게 그대로 일반화하지 않습니다.
가상 사례: 관리자 화면의 상태 표시 개선
가상 사례의 디자이너는 매장 직원이 주문 상태를 잘못 읽는 문제를 다루었습니다. 역할은 상태 정보의 구조 설계와 화면 시안 작성이었고, 업무 정책은 운영팀이 정했습니다. 먼저 상태별 다음 행동을 정리하고 서로 다른 상태에 같은 색이 사용되는 부분을 확인했습니다. 이후 색뿐 아니라 상태 이름과 설명 위치를 함께 바꾸는 안을 제안했습니다.
개선 후에는 준비한 업무 시나리오로 내부 사용자에게 확인을 요청했습니다. 이 검토에서 설명이 부족한 예외 상황을 발견하고 안내 문구를 추가했습니다. 결과는 변경안이 출시 화면에 반영되고 검토 과정에서 발견된 예외가 문서화되었다는 것입니다. 실제 오류율을 측정하지 않았다면 오류가 몇 퍼센트 감소했다고 쓰지 않습니다. 시안 제작뿐 아니라 확인과 수정의 과정을 보여주는 가상 예시입니다.
산출물에 본인의 판단을 붙이기
개선 전후 이미지를 넣는다면 각 이미지가 무엇을 증명하는지 짧게 설명합니다. 버튼 위치가 달라졌다는 사실만 보이는 자료보다 사용자의 다음 행동을 드러내기 위해 정보의 우선순위를 바꾸었다는 설명이 유용합니다. 여러 안을 만들었다면 모든 시안을 나열하기보다 중요한 대안 두 개와 선택 기준을 보여주세요. 최종안이 왜 선택되었는지 알 수 있어야 과정 자료가 의미를 가집니다.
공동 작업물에는 직접 담당한 범위를 표시합니다. 공통 디자인 시스템을 사용했다면 시스템 전체를 만든 것처럼 적지 않고 어떤 화면과 패턴에 적용했는지 설명하세요. 다른 디자이너가 만든 시안을 이어받았다면 기존 구조와 자신이 바꾼 부분을 구분합니다. 이런 구분은 기여를 작게 만드는 것이 아니라 실제 역량을 검토할 수 있는 경계를 제공합니다.
검증과 제약을 함께 설명하기
디자인 결과의 검증은 매출만으로 표현할 필요가 없습니다. 사용자가 작업을 완료했는지, 어떤 부분에서 다시 설명을 요청했는지, 운영자가 어떤 예외를 발견했는지 확인할 수 있습니다. 다만 참여자가 적은 검토와 넓은 범위의 운영 지표는 서로 다른 근거입니다. 내부 검토에서 확인한 반응을 전체 고객의 선호라고 단정하지 않고 검토의 범위를 적습니다.
일정이나 기술 제약 때문에 적용하지 못한 안이 있다면 그 판단도 짧게 남길 수 있습니다. 애니메이션을 줄이고 상태 설명을 우선한 이유처럼 실제 선택을 설명하세요. 제약을 다른 직군의 잘못으로 표현하기보다 어떤 조건을 함께 맞추었는지 적습니다. 이후 개선할 사항은 완료 성과와 분리하고, 아직 관찰하지 못한 효과는 기대 결과로 표시합니다.
경력기술서와 발표 자료를 연결하기
문서에서는 프로젝트의 문제, 역할, 핵심 결정, 확인한 결과가 빠르게 보이도록 구성합니다. 상세 발표 자료에는 조사 장면과 대안 비교, 수정 과정처럼 말로 풀어야 할 근거를 담을 수 있습니다. 두 자료의 프로젝트명과 기간, 개인 역할이 서로 일치하는지 확인하세요. 발표할 때만 새로운 성과가 나타나거나 문서와 다른 숫자를 말하지 않도록 원본 기록을 기준으로 정리합니다.
경력노트의 행동 칸에 설계 결정을, 결과 칸에 검증에서 실제 확인한 내용을 넣어보세요. 만들어진 초안에서 시각적 표현을 설명하는 문장과 사용자 문제를 설명하는 문장의 비중을 비교합니다. 도구 이름만 많고 판단이 적다면 왜 그 변경이 필요했는지 한 문장을 더 적습니다. 공개 가능한 이미지나 포트폴리오 링크는 이후 문서 편집기에서 추가하고 접근 권한을 확인하세요.
자주 묻는 질문
포트폴리오가 있으면 경력기술서는 필요 없나요?
제출 서류는 공고에 따라 다릅니다. 두 자료를 요구한다면 경력기술서는 경험의 요약과 역할을, 포트폴리오는 작업물과 판단 근거를 보여주도록 연결하세요.
디자인 시안만 만들고 출시하지 못했다면요?
시안과 검토 결과까지를 완료 범위로 적고 미출시 상태를 명확히 하세요. 실제 사용자 성과가 발생한 것처럼 표현하지 않습니다.