Q01문제 정의
사용자가 원하는 기능을 그대로 만들면 되나요?
핵심요청한 해결책 뒤의 목적·상황·제약을 확인해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
사용자는 불편을 자신이 아는 기능으로 표현할 수 있어요. 먼저 어떤 작업에서 무엇이 막혔는지 확인하겠습니다. 기능 요청을 무시하는 게 아니라 그 요청이 해결하려는 문제를 더 정확히 찾는 과정입니다.
답변할 때 주의할 점
요청 수가 많다는 것만으로 문제와 해결책이 검증됐다고 보기
예상 꼬리질문
- 인터뷰에서 유도 질문을 피하려면요?
- 말한 요구와 실제 행동이 다르면 무엇을 보나요?
Q02정보 구조
메뉴를 줄이면 사용성이 좋아지나요?
핵심선택 수 외에 분류·명칭·사용 빈도와 찾기 경로를 봐요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
메뉴가 적어도 사용자가 원하는 곳을 예측하기 어려우면 불편할 수 있어요. 주요 과제와 정보 구조를 기준으로 정리하겠습니다. 무엇을 숨길지보다 어떤 이름과 경로로 찾게 할지 검증해야 합니다.
답변할 때 주의할 점
화면의 요소 수 감소를 사용성 향상으로 바로 해석하기
예상 꼬리질문
- 카드 소팅과 트리 테스트의 목적은 어떻게 다른가요?
- 초보자와 숙련자의 탐색이 다르면요?
Q03사용성 평가
사용자가 예쁘다고 하면 좋은 UX인가요?
핵심선호와 과제 성공·오류·이해도는 다른 지표예요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
시각적 선호는 참고할 수 있지만 실제로 원하는 일을 완료하는지도 봐야 합니다. 과제 성공과 막힌 지점, 복구 과정을 함께 관찰하겠습니다. 만족도만으로 사용성을 확정하지 않겠습니다.
답변할 때 주의할 점
호감도 조사 결과를 행동상의 개선 효과로 단정하기
예상 꼬리질문
- 테스트 과제를 실제 상황처럼 만들려면요?
- 사용성 테스트의 표본을 어떻게 설명하나요?
Q04시각 체계
타이포그래피 위계는 왜 필요한가요?
핵심정보의 중요도와 읽는 순서를 크기·굵기·간격 등으로 전달해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
모든 문장을 강조하면 무엇부터 볼지 알기 어려워요. 핵심과 보조 정보의 역할을 나누고 크기와 여백을 일관되게 쓰겠습니다. 색을 못 구분해도 의미가 전달되는지도 확인해야 합니다.
답변할 때 주의할 점
장식적 차이를 늘리는 것과 정보 위계를 만드는 일을 혼동하기
예상 꼬리질문
- 강조 색상만으로 상태를 구분하면 어떤 문제가 있나요?
- 작은 화면에서 위계를 어떻게 유지하나요?
Q05접근성
명도 대비만 맞추면 접근성을 충족하나요?
핵심키보드·보조기술·명칭·초점·확대와 인지 부담도 봐야 해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
읽기 쉬운 대비는 한 부분입니다. 마우스 없이 조작할 수 있는지, 버튼 이름이 전달되는지, 초점과 오류 안내가 보이는지도 중요해요. 실제 사용 흐름과 보조기술을 함께 확인하겠습니다.
답변할 때 주의할 점
색상 검사 도구 하나를 통과한 것을 전체 접근성 검증이라고 부르기
예상 꼬리질문
- 탭 순서가 시각적 순서와 다르면요?
- 아이콘 버튼에 접근 가능한 이름이 필요한 이유는요?
Q06디자인 시스템
컴포넌트를 많이 만들면 디자인 시스템인가요?
핵심재사용 요소와 함께 원칙·상태·사용 규칙·관리 방식이 필요해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
버튼 모음만으로는 어떤 상황에 무엇을 써야 하는지 알기 어려워요. 크기와 상태, 접근성, 문구와 변경 규칙까지 연결하겠습니다. 제품에서 일관되게 쓰이고 유지되는지가 중요합니다.
답변할 때 주의할 점
컴포넌트 수를 시스템의 품질 지표로만 사용하기
예상 꼬리질문
- 예외가 생기면 새 컴포넌트를 바로 만들 건가요?
- 디자인 파일과 구현이 어긋나면요?
Q07검증
전환율이 올랐으면 디자인 덕분인가요?
핵심동시 변경·유입 구성·측정 기간과 인과 검증을 확인해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
화면 변경과 동시에 캠페인이나 가격이 바뀌었을 수 있습니다. 비교 조건과 계측을 확인해야 해요. 실험이 어렵다면 인과 효과를 확정하지 않고 관측된 변화와 한계를 구분하겠습니다.
답변할 때 주의할 점
변경 전후의 차이를 다른 조건 확인 없이 디자인의 인과 효과로 주장하기
예상 꼬리질문
- 클릭이 늘었지만 최종 구매가 줄었다면요?
- A/B 테스트에서 어떤 보완 지표를 보나요?
Q08포트폴리오
잘되지 않은 디자인을 설명해 보세요.
핵심실패한 가설·관찰·수정 기준을 결과 화면과 연결해요.
답변 예시와 꼬리질문 보기
말로 풀어 설명하면
실패를 그럴듯한 성공담으로 바꾸기보다 무엇을 잘못 예상했는지 설명하겠습니다. [관찰된 행동] 때문에 [가설]을 수정했고 [대안]을 검토했다는 구조로요. 실제로 한 검증과 아직 못한 검증을 나누겠습니다.
답변할 때 주의할 점
시안을 여러 번 바꿨다는 사실만으로 검증된 문제 해결이라고 부르기
예상 꼬리질문
- 그 수정으로 좋아졌다는 근거는요?
- 다시 한다면 어떤 가설부터 확인하나요?
내 과제·프로젝트와 연결하기
위 개념을 실제로 사용한 적이 있다면 입력·조건·본인 역할·확인한 결과를 적어 보세요. 배운 원리와 직접 수행한 경험은 구분하고, 아직 적용하지 않았다면 일반적인 접근으로 설명하면 됩니다.
전공 면접 준비 방법 읽기 ↗개념 학습과 말하기 연습용 자료입니다. 최신 법규·설계·안전 기준이나 실무 절차를 대신하지 않습니다.