이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 생활에서 선배 디자이너에게 매주 디자인 리뷰를 받았던 경험이 있습니다.
처음에는 리뷰 시간이 무서웠습니다. 제가 공을 들인 부분에서 '왜 이렇게 결정했는지 설명이 없다'는 피드백이 자주 나왔습니다. 그때부터 시안마다 '왜 이 색상인지, 왜 이 배치인지'를 한 줄씩 써서 가져갔습니다. 3주 후에 선배가 '이제 리뷰가 훨씬 빠르다'고 했고, 저도 결정을 더 명확하게 설명할 수 있게 되었습니다.
이 경험에서 디자인 크리틱은 결과물 평가가 아니라 결정 과정을 설명하는 연습이라는 것을 배웠습니다. 피드백을 제대로 받으려면 먼저 결정 이유를 미리 정리해서 가야 한다는 것도 알게 되었습니다.
팀 프로젝트에서 팀원 디자인에 피드백을 줘야 했는데, 처음엔 '좋아 보인다'는 말만 했어요.
구체적으로 뭐가 좋고 뭐가 어색한지 설명하기가 어려웠거든요. 그래서 '사용자가 이 화면에서 뭘 먼저 보는가?'라는 질문을 기준으로 피드백을 바꿨어요. '색상이 예쁘다'가 아니라 '이 버튼이 텍스트와 대비가 낮아서 처음 보는 사람은 못 찾을 수 있다' 식으로 바꾸니 팀원이 바로 이해했습니다. 저도 어떤 부분이 실제로 문제인지 더 명확하게 보이게 됐어요.
이 경험에서 피드백은 느낌이 아니라 사용자 관점에서 구체적 행동을 기준으로 해야 전달이 된다는 걸 배웠어요. 막연한 '좋다/나쁘다'보다 근거 있는 질문이 더 낫다는 것도요.
팀 프로젝트에서 디자인 리뷰 시간이 매번 1시간 넘게 걸리면서 방향도 안 잡히는 문제가 생겼어요.
여러 의견이 동시에 나오다 보니 어디에 집중해야 할지 몰랐습니다. 저는 '먼저 사용자 동선 기준으로 화면 순서대로 보자'는 제안을 했어요. 모든 화면을 한꺼번에 보는 대신 메인 플로우 3단계만 먼저 보고 나머지는 다음으로 미뤘습니다. 그 다음 리뷰는 40분으로 줄었고 결정도 빨리 났어요.
이 경험에서 리뷰 시간이 길어지는 건 범위를 안 정해서인 경우가 많다는 걸 배웠어요. 어디서 시작할지 순서를 먼저 정하면 리뷰가 훨씬 빠르게 끝난다는 것도요. 그 다음 프로젝트부터는 리뷰 시작 때 항상 화면 순서를 먼저 정했어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.