UI 디자이너 협업 경험, 포트폴리오에 쓰는 방법

UI 디자이너의 협업 경험은 함께 사용한 도구 목록보다 어떤 문제를 두고 누구와 논의했고, 그 결과 화면과 구현 조건이 어떻게 달라졌는지로 설명하면 구체적입니다. 포트폴리오에는 완성 화면과 함께 본인의 담당 범위, 검토 자료, 선택 이유, 실제 확인한 결과를 남겨 보세요.

이 글에서 다루는 내용

1. 협업 범위와 본인 역할 정리
2. 디자인을 전달할 때 필요한 자료
3. 신청 폼 오류 상태 설계 예시
4. 디자인 시스템과 구현 검수
5. 포트폴리오 사례 구성
6. 채용 공고와 경험 연결
7. 자주 묻는 질문

협업 범위와 본인 역할부터 정리하세요

같은 UI 디자이너라는 직함이라도 제품과 팀에 따라 리서치, 화면 설계, 시각 디자인, 디자인 시스템, 구현 검토 중 맡는 범위가 다릅니다. 프로젝트 이름 아래에 기간, 팀 구성, 담당 화면, 결정 권한, 참여하지 않은 범위를 적으면 이후 설명의 기준이 생깁니다.

영국 정부의 서비스 팀 역할 안내도 디자이너·리서처·개발자 등이 사용자 요구를 바탕으로 함께 서비스를 설계하고 개선하는 구조를 설명합니다. 이는 해당 서비스 조직의 사례이며 국내 모든 회사의 직무 분장을 뜻하지는 않습니다. 지원할 팀의 실제 역할은 공고와 면접에서 확인하세요.

• 기획자·제품 담당자와: 해결할 문제, 사용자가 끝내야 할 일, 우선순위와 이번 작업에서 제외할 범위를 확인합니다.
• 개발자와: 데이터 유무, 서버 응답, 화면 상태, 구현 제약과 변경 비용을 검토합니다. 구현 방식을 디자이너가 일방적으로 확정한 것처럼 쓰지 않습니다.
• 리서처·운영 담당자와: 관찰이나 문의의 출처를 확인하고, 단일 의견과 여러 사용자에게서 반복된 문제를 구분합니다.
• 다른 디자이너와: 공통 컴포넌트 적용 여부, 일관성, 예외가 필요한 이유를 검토합니다.

PM이라는 약어도 Product Manager와 Project Manager 중 무엇을 가리키는지 적어 두면 역할 오해를 줄일 수 있습니다. 혼자 기획과 화면 제작을 모두 한 개인 작업은 여러 직무를 연습한 경험입니다. 실제 상대와 논의하지 않았다면 팀 협업이나 개발 협의 경험으로 표현하지 마세요.

디자인 전달 자료에는 화면의 동작 조건을 담으세요

정상 상태 화면만 전달하면 빈 데이터, 입력 오류, 처리 중, 실패 상태의 해석이 서로 달라질 수 있습니다. 다음 항목은 프로젝트에 맞게 골라 사용할 수 있는 전달 자료의 예시입니다. 모든 작업에 같은 양식이나 문서 분량이 필요한 것은 아닙니다.

화면과 함께 확인할 전달 항목

항목	기록 예	확인할 상대·자료
목적과 범위	사용자가 신청을 제출하고 접수 여부를 알 수 있게 함	제품 담당자의 요구사항, 제외 범위
진입·종료 흐름	신청 화면 → 제출 → 접수 완료 또는 수정 안내	화면 흐름도와 개발 라우팅 검토
상태와 전환	입력 전, 제출 중, 항목 오류, 통신 실패, 성공	상태별 화면과 서버 응답 조건
문구와 데이터	필드 이름, 필수 여부, 오류 문구, 표시할 접수 정보	데이터 명세와 콘텐츠 검토
접근·조작	키보드 순서, 초점 표시, 오류 안내의 연결	구현 화면에서의 조작 확인
버전과 미결정 사항	검토 대상 버전, 변경 항목, 담당자와 후속 확인일	변경 기록과 이슈 목록

각 항목에는 제안·합의·구현·검증 중 현재 상태를 표시하세요. 의견을 보냈다는 사실과 상대가 수용했다는 사실은 다릅니다. 코멘트가 해결 처리되었어도 실제 화면에 반영되었는지는 따로 확인해야 합니다.

예시: 신청 폼의 오류 상태를 함께 정의하기

아래는 설명을 위한 가상의 설계 연습입니다. 실제 사용자 조사, 개발 협의, 배포나 성과 측정을 수행한 사례가 아닙니다. 이름과 이메일을 입력하는 행사 신청 폼을 가정하고, 정상 화면에 빠진 상태를 찾아 전달 자료를 만드는 과정을 보여 줍니다.

처음 시안에 입력창과 제출 버튼만 있다고 가정해 보세요. 협업을 준비할 때는 “오류는 빨간색으로 표시”라는 한 줄 대신 무엇이 잘못되었는지, 어느 위치에 어떤 안내가 필요한지, 입력한 내용은 어떻게 처리할지를 묻습니다.

가상 신청 폼의 상태별 설계안

상태	사용자에게 보여 줄 내용	협의·검증할 내용
입력 전	이름·이메일의 명확한 라벨과 필요한 입력 안내	필수 항목과 허용 형식을 명세와 맞추기
이메일 미입력	이메일 입력창에 연결된 “이메일을 입력하세요” 안내	색상 외 텍스트로 오류를 알리는지, 해당 항목으로 이동할 수 있는지
이메일 형식 오류	입력한 내용을 유지하고 형식 확인 안내 제공	클라이언트와 서버의 검증 규칙이 다른 경우 처리 방식
제출 처리 중	처리 상태를 알 수 있는 안내	중복 제출 방지와 키보드 초점 처리를 어떻게 구현할지
통신 실패	접수 완료를 확인하지 못했다는 안내	이미 접수됐을 가능성, 상태 조회와 재시도 조건을 개발자에게 확인
접수 성공	서버에서 확인된 접수 결과와 다음 단계	버튼 클릭만으로 성공 화면이 뜨지 않는지

W3C WAI의 폼 알림 안내는 성공·오류 결과를 분명히 전달하고, 오류가 난 항목과 수정 방법을 이해할 수 있게 안내하는 방식을 설명합니다. 실제 구현에서는 오류 안내와 해당 입력창의 연결도 검토합니다. 디자인 시안에 문구가 있다고 스크린리더에서 올바르게 전달된다고 단정할 수는 없습니다.

GOV.UK 오류 메시지 컴포넌트 안내는 오류를 표시할 때 입력 내용을 지우지 않도록 설명하고, 사용자가 고칠 수 없는 서비스 문제를 입력 오류와 구분합니다. 위 연습에서도 이메일 누락과 통신 실패를 서로 다른 상태로 다뤘습니다. 해당 지침의 문구나 색상을 그대로 복제하기보다 서비스 맥락에 맞는 동작을 검토하세요.

가상 결정 기록은 “이메일 형식 오류 시 입력을 초기화하는 안과 유지하는 안을 비교하고, 수정할 내용을 사용자가 확인할 수 있도록 유지하는 안을 제안했다”처럼 쓸 수 있습니다. 이 단계의 결과는 검토할 설계안과 확인 질문입니다. 실제 개발자와 합의하거나 구현하지 않았다면 그 단계까지 완료한 것으로 바꾸어 쓰지 않습니다.

디자인 시스템 적용과 구현 검수는 별도로 기록하세요

사용한 공통 요소와 실제로 확인한 구현 범위를 남겨 보세요.

GOV.UK Design System은 스타일, 재사용 컴포넌트, 사용자가 작업을 완료하는 패턴을 구분해 제공합니다. 포트폴리오에서도 공통 색상표를 만든 일, 입력창 컴포넌트를 정리한 일, 폼 흐름을 개선한 일을 각각 설명하면 기여 범위가 명확해집니다.

기존 디자인 시스템을 적용했다면 시스템 전체를 구축한 것으로 쓰기보다 사용한 구성 요소, 수정한 변형, 새로 제안한 예외를 보여 주세요. 예를 들어 입력창의 기본·오류 상태는 공통 요소를 사용하고, 접수 결과 화면은 별도 패턴을 제안했는지 구분하는 방식입니다.

구현 검수 기록은 조건 → 기대 동작 → 실제 동작 → 처리 상태로 남길 수 있습니다. 아래는 앞의 가상 폼에 사용할 검수 항목이며, 실제 테스트 결과가 아닙니다.

• 키보드만으로 입력·제출·오류 수정까지 이동할 수 있는가?
• 오류 안내가 대상 입력창과 연결되고, 색상 구분 없이도 내용을 알 수 있는가?
• 입력 오류 뒤에 기존 내용이 남아 있는가?
• 작은 화면이나 긴 안내 문구에서 내용과 조작 요소가 겹치지 않는가?
• 서버가 실패하거나 응답이 늦을 때 성공으로 잘못 표시하지 않는가?

검수한 브라우저, 화면 크기, 보조기술, 빌드 버전과 날짜를 함께 쓰세요. 확인하지 않은 조합은 미확인으로 남깁니다. 일부 항목을 점검한 기록을 서비스 전체의 접근성 충족이나 전환율 개선 증거로 확대하지 않습니다.

포트폴리오는 결정이 바뀐 장면을 중심으로 구성하세요

프로젝트마다 모든 회의 내용을 나열할 필요는 없습니다. 지원 직무와 관련 있는 결정 하나를 골라 다음 순서로 설명해 보세요.

1. 문제와 출처: 어떤 화면에서 무엇이 문제였는지, 문의 기록·관찰·요구사항 중 어디에서 확인했는지 적습니다. 개인 추정이면 가설이라고 표시합니다.
2. 본인 역할: 직접 만든 화면·문구·상태 정의와 다른 구성원의 작업을 구분합니다.
3. 대안과 의견: 검토한 두 안, 팀원의 이견, 기술·일정 제약을 함께 보여 줍니다.
4. 결정과 변경: 최종 선택 이유를 이전 시안과 수정 시안에 연결합니다. 회의록이나 코멘트는 공개 가능한 부분만 인용합니다.
5. 확인 결과와 남은 일: 설계 완료, 구현 반영, 검수 통과, 사용자 결과 측정 중 실제 끝낸 단계만 적습니다.

예를 들어 “소통 능력으로 협업을 성공시켰다”는 문장만 쓰기보다, 실제 경험이 있다면 “서버 오류를 입력 오류와 같은 문구로 처리하던 안을 검토했고, 개발자와 응답 조건을 확인한 뒤 화면 상태를 나누었다”라고 설명할 수 있습니다. 관련 시안과 기록이 있어야 하며, 이 문장을 실제 경험 없이 복사해서 사용해서는 안 됩니다.

성과 수치를 사용할 때는 측정 기간, 대상, 지표 정의와 비교 조건을 함께 남기세요. 배포 후 문의가 줄어든 사실이 있더라도 다른 변경의 영향까지 분리하지 못했다면 해당 디자인만의 효과로 단정하지 않습니다. 숫자가 없다면 반영된 변경과 확인한 동작을 결과로 쓰면 됩니다.

회사·고객 자료는 공개 가능한 범위를 먼저 확인하고, 공개가 어려우면 허용된 방식으로 구조를 재현하되 재현 자료임을 표시하세요. 원본의 비공개 사용자 정보, 내부 대화나 인증 정보가 포함되지 않도록 검토합니다.

채용 공고에 맞춰 경험과 준비할 일을 연결하세요

공고에서 개발 협업을 요구한다면 상태 정의와 구현 검토 자료를, 디자인 시스템 운영을 요구한다면 공통 요소와 예외의 관리 기록을 우선 보여 주세요. 도구 이름이 같다는 이유만으로 필요한 경험을 모두 갖췄다고 판단하지 않습니다.

프리랜서와 정규직도 이름만으로 협업 수준을 판단하기 어렵습니다. 제안받은 일에서 누구와 검토하는지, 개발 이후 수정에 참여하는지, 작업 인수 기준과 디자인 자료 관리 방식이 무엇인지 확인해 자신의 목표와 비교하세요. 고용 형태에 따른 조건은 실제 제안과 계약 내용을 따로 살펴야 합니다.

협업 경험이 부족하다면 개인 프로젝트를 명확히 표시한 뒤 동료 리뷰를 요청하고, 실제 받은 의견과 반영 내용을 기록하는 것부터 시작할 수 있습니다. 개발자와 함께 구현해 보았다면 서로 맡은 부분과 검수 기록을 추가하세요. 리뷰 요청만 했거나 답변을 받지 못한 경우도 그 상태 그대로 적습니다.

제품 담당자와 역할을 나누는 맥락은 프로덕트 매니저의 역할과 협업 글에서, 수치를 성과로 표현하기 전 점검할 기준은 A/B 테스트 가설과 데이터 검증 글에서 이어서 볼 수 있습니다.

자주 묻는 질문

협업 도구를 많이 사용하면 좋은 협업 사례가 되나요?

사용한 도구와 함께 어떤 의견이 오갔고 무엇이 달라졌는지를 보여 주세요. 파일 공유만 했는지, 상태 정의를 합의했는지, 구현까지 검토했는지에 따라 경험의 범위가 다릅니다.

개발 경험이 없으면 UI 직무에 지원할 수 없나요?

지원 가능 여부는 공고의 필수 요건을 기준으로 판단하세요. 직접 구현한 경험이 없어도 설계 자료와 실제 협업 경험은 구분해 설명할 수 있습니다. 코딩 능력이나 개발 협의 경험을 수행한 범위보다 크게 표현하지 않습니다.

의견 충돌을 포트폴리오에 넣어도 되나요?

상대를 평가하기보다 각 안의 목적과 제약, 논의 근거, 결정 후 확인 결과를 설명하세요. 채택되지 않은 제안이라도 무엇을 배웠는지 보여 줄 수 있습니다.

개인 프로젝트에 가상의 팀원과 대화를 넣어도 되나요?

실제 협업 경험처럼 표현하면 안 됩니다. 가상 연습에서는 예상 질문과 설계안을 제시하고, 실제 리뷰를 받은 경우에만 참여자 역할과 피드백 내용을 별도로 기록하세요.

완성 화면만 있고 측정 수치가 없으면 어떻게 쓰나요?

해결하려던 문제, 본인 작업, 수정 이유와 검토 범위를 적으세요. 사용자 결과를 측정하지 않았음을 밝히고 다음에 확인할 지표를 제안할 수 있습니다. 예상 효과를 이미 달성한 성과로 쓰지는 않습니다.

자료 확인: 2026년 9월 8일. 본문의 신청 폼은 설명용 가상 연습이며 실제 제품의 협업·구현·사용자 성과를 보고한 사례가 아닙니다.