이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대학 캡스톤 프로젝트에서 UX 팀과 개발 팀이 서로 다른 화면 흐름을 주장해 일주일째 결론이 안 났던 적이 있습니다. 저는 당시 아직 학생이라 결정권이 없었는데, 그래도 의견이 갈리는 지점을 정리해 두 안의 사용자 흐름 단계 수를 표로 만들어 공유했습니다. 어느 쪽이 더 낫다고 말하기보다, 각 안에서 사용자가 막힐 수 있는 지점이 몇 개인지만 객관적으로 보여줬습니다. 그러자 개발 팀도 "아, 이 단계가 한 번 더 있구나"라며 입장을 조금씩 좁혔고, 결국 두 안의 절충안으로 피그마 시안을 새로 만들었습니다. 저는 결론을 이끈 게 아니라 대화가 막힌 자리에 공통 언어를 놓은 것에 가까웠습니다. 그 경험 이후, 팀 내 의견 충돌이 보이면 어느 쪽이 맞냐보다 두 의견이 엇갈리는 지점이 어디냐를 먼저 찾으려 합니다.
UX 팀과 개발 팀이 화면 흐름을 두고 의견이 갈렸을 때, 각자 말로 설명하면 같은 것을 다르게 이해하는 문제가 있었습니다. 제가 제안한 것은 두 안을 피그마 프로토타입으로 각각 만들어서 옆에 놓고 비교하는 방식이었습니다. 텍스트나 표로 정리했을 때보다 화면으로 보여주자 양쪽 팀이 같은 기준으로 이야기할 수 있게 됐습니다. UX 팀도 자신들 안의 어떤 단계가 불필요한지를 직접 보게 됐고, 개발 팀도 구현 복잡도가 어디에서 늘어나는지를 시각적으로 확인했습니다.
협업 도구는 의사소통 도구이고, 공통 화면을 만드는 것이 가장 빠르게 같은 언어를 만드는 방법이라는 것을 그때 배웠습니다. 결론을 이끈 것이 아니라 결론이 나올 수 있는 자리를 만든 것이라는 것을 그 경험에서 이해했습니다.
팀 내 의견 충돌이 생겼을 때 어느 쪽이 더 맞는지를 판단하는 것보다 두 의견이 어디서 엇갈리는지를 먼저 찾는 것이 더 효과적이라는 것을 경험했습니다. UX 팀이 말하는 사용자 흐름 단순화와 개발 팀이 말하는 구현 복잡도 감소는 사실 같은 방향을 말하고 있었는데, 각자 다른 언어로 말하고 있어서 충돌처럼 보였습니다.
두 팀이 공통으로 피하고 싶어 하는 것이 무엇인지를 먼저 정리하자 이견이 빠르게 좁혀졌습니다. 저는 결정을 내린 것이 아니라 대화가 막힌 자리에서 공통 언어를 먼저 만든 것에 가까웠습니다. 협업에서 가장 시간을 줄이는 방법은 이견의 내용보다 이견이 생긴 이유를 먼저 찾는 것이라는 것을 그 경험에서 배웠습니다.
충돌은 의견 차이가 아니라 기준 차이에서 생기는 경우가 많다는 것을 그때 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.