UI 완성도는 실제 내용과 상태 변화 속에서 확인한다
주장
UI의 완성도는 실제 구현에 도달할 수 있는 내용과 상태 변화 속에서 확인한다. 코드에서 예상한 문제, 화면에서 관찰한 실패, 표현에 대한 선호를 구분해 판단한다.
한 장면만으로 알 수 없는 동작
보기 좋은 한 장면만으로 긴 문구·비어 있음·실패·재입력 상황의 동작을 알 수 없다. 반대로 실제로 들어오지 않는 값을 넣은 실패나 다른 스타일로 재구현한 예시는 원래 컴포넌트의 문제를 입증하지 못한다.
실제 컴포넌트에서 관찰할 조건
- 먼저 실제 컴포넌트의 입력과 상태를 읽고 적용되는 경우를 고른다. 긴 문구, 항목 없음, 로딩·오류, 좁은 폭, 키보드·포커스 중 해당되는 축만 확인한다.
- 검증용 화면을 만들면 실제 컴포넌트와 프로젝트의 글꼴·토큰·환경을 사용한다. 대역 구현이나 재꾸민 복제본으로 결과를 대신하지 않는다.
- 관찰한 조건과 결과를 구체적으로 남긴다. 「긴 이름이 카드 밖으로 넘친다」와 「간격이 더 넓으면 좋겠다」는 다른 판단이다.
- 렌더링하지 못했으면 코드 검토와 미확인 범위를 밝힌다. 원문을 읽은 것만으로 프로젝트의 실제 동작을 확인했다고 보고하지 않는다.
근거
- 인터페이스 판단과 검토 기준 - Jakub Krehel: break의 가능한 입력·실제 컴포넌트·관찰 범위, better-layout의 내용 증가와 폭 변화 검토.
- 자기용 기록과 단편 자기소개 - cho.sh 대화: 좁은 홈 화면의 문구 잘림·기존 노트의 Markdown 노출과 검색·도구의 실제 상태 변화를 각각 관찰한 사례. 상세 조건과 미검증 범위는 연결된 프로젝트 원천에 둔다.
원문의 고정된 실행 횟수·보고 형식은 이 주장에 포함하지 않았다. 확인 범위는 현재 변경과 사용자 영향에 맞춘다.