화면을 요청하면 가장 좋은 날의 화면을 받게 됩니다. 콘텐츠로 가득 차 있고, 로딩되는 것도 없고, 실패한 것도 없으며, 권한은 이미 부여되었고, 네트워크도 정상입니다. 케이스 스터디에 나오는 제품처럼 보이고, 화요일에 실제로 보이는 모습과는 다릅니다.

이것은 모델의 한계로 설명됩니다. 하지만 저는 이것이 그보다 더 구체적인 문제이며, 이 구체성이 유용하다고 생각합니다.

포트폴리오를 통해 학습했습니다

공개적으로 존재하는 인터페이스 이미지 대부분은 마케팅 이미지입니다. 랜딩 페이지의 화면, 케이스 스터디의 화면, 디자인 갤러리의 화면—이 모든 것은 선별되었고, 모두 가득 차 있으며, 최고로 보정된 상태입니다.

아무도 빈 상태(empty state)를 게시하지 않습니다. 아무도 에러 화면을 포트폴리오에 넣지 않습니다. 따라서 '예약 화면'을 요청한 모델은 자신이 만 번 본 버전을 생성하는데, 이는 모든 것이 잘 되었을 때의 버전입니다.

모델이 실패하는 것이 아닙니다. 보여준 것을 정확히 반환하고 있는 것입니다. 격차는 모델의 역량에 있는 것이 아니라, 세상이 사진으로 찍어주지 않은 부분에 있습니다.

화면 개수라는 숫자가 모두를 오도합니다

예약 제품을 예로 들어보겠습니다: 68개의 기능, MVP에서 44개, 7개의 플로우(flow), 28개의 메인 화면입니다.

28개는 작은 프로젝트처럼 들립니다. 하지만 실제 아트보드 개수는 훨씬 더 높게 나왔는데, 그 이유는 화면이 로딩(loading), 빈 상태(empty), 에러(error), 권한(permission), 오프라인(offline) 등 이 특정 제품이 사용자에게 실제로 할 수 있는 모든 '상태'를 갖추기 전까지는 완성되지 않기 때문입니다.

바로 이 배수(multiplier) 때문에 추정치가 무너집니다. 팀은 28개의 화면을 견적 내고, 28개의 화면을 생성하며, 일정이 앞서 나간다고 느끼지만, 프로젝트 후반부에 이르러 각 화면마다 아무도 세지 않은 세네 개의 형제(sibling)가 있다는 것을 발견하고 시간을 보냅니다. 같은 작업이지만, 가장 최악의 순간에 뒤늦게 발견되는 것입니다.

상태는 시각적 옷을 입은 제품 결정입니다

이 부분이 제가 가장 강하게 주장하고 싶은 부분입니다.

빈 상태 (empty state)는 콘텐츠가 제거된 화면이 아닙니다. 그것은 다음과 같은 질문에 대한 답변입니다: 이 사용자에게는 아직 아무것도 없는가 — 그 이유가 신규 사용자이기 때문인가, 모든 항목을 필터링했기 때문인가, 아니면 무언가 실패했기 때문인가? 세 가지 서로 다른 상황에는 세 가지 서로 다른 메시지, 세 가지 서로 다른 액션 (action)이 필요하며, 그중 단 하나만이 "첫 번째 항목을 추가하세요"입니다.

에러 상태 (error state)는 빨간색 박스가 아닙니다. 그것은 사용자가 복구할 수 있는지, 입력한 내용을 잃게 되는지, 사용자의 잘못인지, 그리고 기술적인 이유를 알려주는 것이 도움이 될지 아니면 겁을 줄지에 대한 결정입니다.

모델은 이 중 어떤 것이든 설득력 있게 생성할 수 있습니다. 하지만 모델은 당신이 실제로 어떤 상황에 처해 있는지 결정할 수 없습니다. 왜냐하면 그 정보는 브리프 (brief)에 포함된 적이 없으며, 모델은 이를 멈춰서 물어보지 않을 것이기 때문입니다. 모델은 가장 흔한 상황을 선택하여 아름답게 렌더링 (render)할 것입니다.

따라서 상태는 생성된 후가 아니라, 생성 전에 명명되어야 합니다

모든 화면은 화면 목록의 일부로서 필요한 상태들을 포함해야 하며, 이는 해당 화면이 왜 존재하는지 기억하고 있을 때 결정되어야 합니다.

사후에 이를 처리하면 제가 여러 번 목격한 특정한 실패 모드 (failure mode)가 나타납니다. 상태들이 완성된 화면의 시각적 변형 (visual variant)으로 추가되면서 화면의 레이아웃 (layout)을 상속받게 되고, 결국 아무것도 제어하지 못하는 필터 바 (filter bar)와 행 (row)이 없는 테이블 헤더 (table header)가 있는 빈 상태를 만들게 됩니다. 기술적으로는 빈 상태가 맞을지 몰라도, 제품 (product)의 관점에서는 말이 되지 않는 결과물입니다.

먼저 결정하는 과정은 브리프에서 물었어야 할 질문들을 수면 위로 끌어올리기도 합니다. 아무도 기록하지 않은 상태의 절반은 답변이 진정으로 불확실한 것들이며, 바로 그 지점이 초기에 논의할 가치가 있는 대화 주제입니다.

컴포넌트 (component)에도 동일하게 적용됩니다

한 화면에서 한 번 나타난 컴포넌트는 단 하나의 상태로 모델링될 것입니다. 왜냐하면 그것이 가용한 유일한 증거이기 때문입니다.

하지만 입력창(input)에는 포커스(focus), 채워짐(filled), 비활성화(disabled), 에러(error), 읽기 전용(read-only) 상태가 있습니다. 버튼에는 눌림(pressed), 비활성화(disabled), 로딩(loading) 상태가 있습니다. 체크박스에는 누군가 일괄 선택(bulk-select) 기능을 만드는 순간 반드시 나타나게 될 미결정(indeterminate) 상태가 있습니다. 만약 라이브러리가 화면에 나타난 것들만 담고 있다면, 누락된 상태들은 그것을 처음 접하는 사람—대개 개발자이며, 대개 시간 압박을 받는 상황이고, 대개 세 곳에서 서로 다르게—에 의해 나중에 즉흥적으로 만들어지게 됩니다.

그래서 제가 사용하는 규칙은 이렇습니다: 모든 컴포넌트의 원형(archetype)을 다 만들 필요는 없지만, 일단 만드는 컴포넌트들은 화면에서 요구되었는지 여부와 상관없이 그들의 전체 상태 매트릭스(state matrix)를 포함해야 합니다.

이것이 노력할 가치가 있는 이유

상태(state)야말로 제품이 실제로 사용자와 만나는 지점이기 때문입니다. 제품에 대한 그 누구의 경험도 마케팅용 스크린샷이 아닙니다. 검색 결과가 아무것도 나오지 않았던 날, 결제가 실패했던 날, 혹은 기차 안에서 앱을 열었던 날이 진짜 경험입니다.

다듬어진 화면(polished screens)은 보여주기 위한 것이지만, 상태(states)는 사용되는 것입니다.

이것이 해결하지 못하는 것

이 작업을 과하게 할 수도 있습니다. 저는 결국 제품에서 삭제된 화면들을 위해 전체 상태 커버리지(full state coverage)를 구축한 적이 있는데, 이는 비용만 들고 버려진 작업이었습니다. 더 나쁜 것은, 그 과정을 지켜본 모든 이들에게 상태 목록이 마치 관료주의적인 절차처럼 느껴지게 만든다는 점입니다.

또한 어디까지 진행해야 하는지에 대한 깔끔한 규칙도 없습니다. 현장용 도구(field tool)에게 오프라인 동작은 엄청나게 중요하지만, 내부 대시보드(internal dashboard)에게는 거의 중요하지 않습니다. 제가 아는 유일한 차이점은 누가 어디에서 사용하는지에 대해 제대로 고민하는 것뿐입니다. 이는 다시 프로세스의 시작점으로 돌아가게 만드는데, 보통 그곳에 진짜 답이 있습니다.

실제 프로젝트 하나에 기록된 전체 과정

저는 하나의 프로젝트에서 브리프(brief), 구조 및 흐름(structure and flows), 생성된 화면들, 고정된 토큰 시스템(locked token system), 실제 컴포넌트와 변수(variables)가 포함된 Figma, 클릭 가능한 프로토타입(clickable prototype), 개발자 핸드오프(developer handoff)에 이르기까지의 전체 경로를—오류가 발생한 부분까지 포함하여—끝에서 끝까지 기록했습니다:

Claude AI UI/UX: 브리프부터 Figma까지 완전한 워크플로우 — 하나의 실제 프로젝트에서 브리프를 거쳐 Figma로 전달하는 동일한 경로입니다.

만약 대부분의 목록에서 빠지는 상태(state)가 있어 여러분을 괴롭힌 것이 있다면, 어떤 것인지 알려주세요. 저에게는 권한(permission)이었습니다.