이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
PM 및 엔지니어와 협업할 때 저는 각자가 다른 언어로 생각한다는 것을 먼저 인식하는 것에서 시작합니다. 디자이너는 사용자 흐름과 시각적 구조로 생각하고, PM은 기능 범위와 일정으로, 엔지니어는 구현 가능성과 제약으로 이야기합니다. 팀 프로젝트에서 디자인 시안을 공유할 때 "왜 이 구조인가"를 먼저 설명하는 것이 엔지니어와의 논의를 훨씬 부드럽게 만들었습니다. PM과는 기능 우선순위를 함께 정의하는 세션을 가져서, 디자인 방향이 요구사항과 일치하는지 사전에 확인했습니다.
시각 자료로 공통 기준을 만드는 것이 협업 속도를 높이는 가장 효과적인 방법이었습니다.
PM, 엔지니어와 소통할 때 제가 가장 먼저 하는 건 초기에 용어와 기준을 맞추는 자리를 만드는 것입니다. 같은 화면을 두고 셋이 다른 단어를 쓰면 회의가 겉돌았고, 그래서 주요 UI 용어와 기능 명칭을 공유 문서에 정리해두는 습관을 들였습니다. 실시간 회의보다 비동기로 디자인 의도를 먼저 적어두는 방식을 더 선호합니다. 피그마 댓글에 '왜 이 컴포넌트를 선택했는지' 한 줄씩 남겨두면 엔지니어가 구현 전에 의문을 미리 해소할 수 있었고, 수정 요청 횟수가 줄었습니다. 피드백은 '이 부분이 구현하기 어렵다'는 말이 나오면 제약 조건을 먼저 이해한 뒤 대안 시안을 가져가는 방향으로 대응했습니다. 이 방식을 반복하면서 느낀 건 소통의 질은 회의 횟수가 아니라 사전에 공유된 정보의 밀도로 결정된다는 것입니다.
PM이 기능 추가를 원하고 엔지니어가 일정을 이유로 반대하는 상황에서, 저는 두 입장을 번갈아 들은 뒤 요약해 공유 문서에 적어두는 역할을 맡았습니다. 각자 상대가 무엇을 원하는지 눈에 보이는 형태로 확인하게 되면 '우리가 같은 목표를 보고 있다'는 인식이 생기면서 갈등이 가라앉는 경우가 많았습니다. 디자인 측면에서는 기능을 온전히 구현한 버전과 빠르게 낼 수 있는 축소 버전을 같이 그려서 PM과 엔지니어에게 선택지를 제시했습니다. 둘이 직접 타협하기 전에 선택지를 보면 대화의 시작점이 생기고 논의가 훨씬 빠르게 정리됐습니다. 이 경험에서 얻은 것은 디자이너가 조율자 역할을 할 때 의견을 모으는 것보다 선택지를 가져오는 것이 팀 속도를 높인다는 감각입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.