이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
디자인 의도를 문서화할 때 왜 이 방향을 선택했는지, 어떤 대안을 고려했는지를 남기는 것에 가장 중점을 둡니다. 결과물만 남기면 나중에 수정이 필요할 때 맥락이 사라져서 다음 사람이 같은 고민을 반복하게 됩니다. 디자인 결정 배경과 트레이드오프를 함께 기록하면 새 팀원이 빠르게 맥락을 파악할 수 있습니다.
비디자이너도 읽을 수 있는 언어로 작성하는 것도 중요한데, 협업 팀이 이해해야 실제로 적용될 수 있기 때문입니다. 리뷰 과정에서 나온 피드백과 그에 대한 반응도 기록에 포함하면 설계 과정이 투명해지고 신뢰가 쌓입니다. 문서화는 시간을 쓰는 일처럼 보이지만, 결국 불필요한 재논의를 줄이는 자산이 됩니다.
디자인 의도 문서화에서 형식을 갖추는 것이 생각보다 중요하다는 걸, 나중에 인수인계를 받는 쪽에서 경험하고 나서 실감했습니다. 피그마 코멘트에만 의도를 남기면 파일 버전이 바뀔 때 맥락이 사라지기 때문에, 결정 사항과 대안 검토 내용을 별도 문서로 연결해 두는 방식이 더 오래 살아남습니다.
채택하지 않은 방향과 그 이유를 같이 기록하면 같은 논의가 반복되는 일이 줄어들고, 후속 디자이너가 실수를 반복할 확률도 낮아집니다. 문서는 작성하는 것보다 최신 상태로 유지하는 것이 더 어렵기 때문에, 디자인 파일과 연동된 도구로 Document Drift를 줄이려 노력합니다.
디자인이 바뀔 때 문서도 함께 업데이트되는 루틴을 팀에 제안한 이후로, 오래된 의도를 잘못 참조하는 경우가 줄었습니다. 문서가 결과만 담는 스냅샷이 아니라 과정을 담는 기록이 될 때 실제 가치가 생깁니다.
문서가 실제로 기능하는지 확인하는 방법은 맥락을 모르는 사람이 읽었을 때 의도대로 실행할 수 있는가를 보는 것입니다. 디자인을 처음 보는 개발자나 팀원에게 문서만 주고 질문을 받아보면, 어디서 막히는지가 바로 보입니다. 비디자이너도 읽을 수 있는 언어로 작성하는 것이 중요한 이유도 여기에 있는데, 내부 전문 용어가 많으면 협업 팀이 임의로 해석하게 됩니다.
제약 조건을 명시해두면 개발 단계에서 불필요한 질문이 줄어들고, 재현 가능한 산출물로 이어집니다. 문서를 읽은 후 같은 결과물을 만들어낼 수 있다면, 그 문서는 의도를 충분히 담은 것이라고 판단합니다. 이해·실행·재현이 가능한 수준까지 다듬는 게 좋은 디자인 문서의 기준이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 PTKOREA UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.