Question 1

포트폴리오 중에서 가장 자신 있는 작업 하나를 골라서, 어떤 문제를 풀었는지 설명해 주세요.

Accepted Answer

예쁜 화면보다 문제 정의와 근거를 말할 수 있는지 봐. 답변 순서: 결론: 어떤 문제를 풀었는지 한 문장 → 문제를 발견한 근거 (데이터, 인터뷰, 관찰) → 디자인 결정과 버린 시안 → 결과와 검증 방법. 피할 것: 툴, 컬러, 폰트 이야기부터 하는 것.

Question 2

대표님이 디자인을 보고 "그냥 좀 더 고급스럽게 해주세요"라고 하면 어떻게 하시겠어요?

Accepted Answer

모호한 피드백을 구체적인 요구사항으로 바꿀 줄 아는지 봐. 답변 순서: 결론: "고급스러움"의 기준부터 맞추겠다 → 레퍼런스로 질문해서 범위 좁히기 → 두세 가지 방향 시안으로 빠르게 확인 → 결정 기준을 문서로 남기기. 피할 것: "말씀하신 대로 수정합니다"로 끝나는 것.

Question 3

개발자와 디자인 구현을 두고 의견이 갈렸던 경험이 있나요?

Accepted Answer

디자인을 지키는 것과 현실을 받아들이는 것 사이의 균형을 봐. 답변 순서: 상황: 무엇이 구현 어려움으로 걸렸는지 → 개발자의 제약을 확인한 방법 → 함께 찾은 대안 → 결과와 이후 협업 방식의 변화. 피할 것: "개발자가 구현을 못 해서"처럼 상대 탓으로 끝나는 것.

Question 4

디자인 결정을 데이터로 검증해 본 적이 있나요?

Accepted Answer

취향이 아니라 결과로 디자인을 설명할 수 있는지 봐. 답변 순서: 결론: 무엇을 어떻게 검증했는지 → 세운 가설과 지표 → 결과 수치 → 그 뒤 바꾼 디자인. 피할 것: "사용자 반응이 좋았습니다"처럼 수치 없는 결과.

Question 5

디자인 시스템을 만들거나 운영해 본 경험이 있으시면 말씀해 주세요. 가장 어려웠던 건 뭐였나요?

Accepted Answer

혼자 만드는 것보다 팀이 실제로 쓰게 만드는 과정을 아는지 봐. 답변 순서: 범위: 무엇을 시스템으로 만들었는지 → 도입 과정의 저항과 설득 → 운영 방식 (버전, 문서, 리뷰) → 도입 전후 달라진 것 (속도, 일관성). 피할 것: 컴포넌트 개수만 자랑하는 것.

Question 6

최근에 써본 서비스 중에서 불편했던 화면 하나를 골라서, 본인이라면 어떻게 바꾸시겠어요?

Accepted Answer

관찰력과 문제 정의. 신입 디자이너의 시선을 보는 단골 질문이야. 답변 순서: 어떤 서비스, 어떤 화면인지 → 불편한 지점과 이유 (사용자 목표 기준) → 개선안 → 개선이 맞는지 확인할 방법. 피할 것: "색이 촌스러워서"처럼 취향으로만 말하는 것.

Question 7

출시가 이틀 남았는데, 사용성 테스트에서 큰 문제가 발견됐습니다. 어떻게 하시겠어요?

Accepted Answer

완벽함과 출시 사이에서 현실적인 판단을 하는지 봐. 답변 순서: 결론: 문제의 심각도부터 판단 → 당장 가능한 최소 수정안 → 팀과 출시 여부 협의 → 출시 후 개선 계획과 모니터링 지표. 피할 것: "출시를 미뤄야 합니다"만 고집하는 것.

Question 8

디자인 트렌드를 어떻게 따라가세요? 트렌드를 일부러 안 따른 적도 있나요?

Accepted Answer

레퍼런스를 소비만 하는지, 맥락에 맞게 걸러 쓰는지 봐. 답변 순서: 결론: 트렌드를 보는 내 기준 → 정보를 얻는 구체적인 방법 → 트렌드를 적용한 사례 또는 걸러낸 사례 → 이유와 결과. 피할 것: 사이트 이름만 줄줄이 나열하는 것.