문제
지역 상점 토큰을 사고파는 거래소의 베타 화면이었습니다. 마켓, 상점, 거래, 런치패드, 포트폴리오가 한 제품이고 열두 라우트로 시작했습니다.
디자인 파일에는 정상 화면이 있었습니다. 마켓에 상점이 없을 때, 검색 결과가 없을 때, 네트워크가 끊겼을 때, 지갑이 아직 없을 때의 화면은 「콘텐츠 미정」 프레임으로 비어 있었습니다. 그 상태로 넘기면 나머지는 구현하는 사람이 그 자리에서 정합니다. 정한 것이 화면마다 달라지고, 나중에 어느 것이 의도였는지 알 수 없게 됩니다.
판단: 상태를 코드로 먼저 세웠습니다
빈 화면을 디자인 파일에서 채우는 대신 코드로 먼저 세웠습니다. 라우트 하나에 한 화면의 상태를 전부 나열합니다. 거래 화면이라면 닫힘, 구매 방법 선택, 구매 확인, 구매 완료, 판매 방법 선택이 라벨과 설명을 달고 한 줄로 섭니다.
빈 상태는 하나가 아니었습니다. 데이터가 없는 원인이 다르면 화면이 말해야 하는 것도 다릅니다. 아직 상장된 상점이 없는 것과, 필터가 너무 좁은 것과, 검색어가 틀린 것과, 불러오기에 실패한 것은 같은 빈 화면이 아닙니다. 마켓의 빈 상태를 원인별로 넷으로 갈랐습니다.
모바일은 따로 세웠습니다. 데스크탑의 슬라이드아웃이 모바일에서는 바텀시트가 되고, 폭 384 에서 시나리오가 달라집니다. 같은 상태 이름을 쓰되 화면은 따로 두었습니다.
디자인 파일로 되돌려 보냈습니다
코드로 세운 상태 화면을 1차 안으로 삼아 디자인 파일에 역반영했습니다. 디자인이 코드를 따르는 방향입니다. 정상 화면은 디자인 파일이 먼저였고 상태 화면은 코드가 먼저였는데, 어느 쪽이 먼저든 마지막에는 둘이 같아야 합니다. 결정론적 스크린샷과 픽셀 차이로 그 같음을 검사하는 게이트를 따로 두었습니다.
결과
상태 묶음이 스물셋이 됐습니다. 마켓, 런치패드, 거래, 상점, 포트폴리오, 헤더, 모바일 메뉴, 지갑까지 화면마다 정상 외의 상태가 한 화면에 서 있습니다. 베타 스캐폴딩에서 GA 첫 화면까지 스물여드레였고, 화면 본체는 공용 패키지로 올라가 제품 레포가 그것을 받아 씁니다. 그 경위는 「디자인 도구를 기준 자리에서 내리다」 케이스에 있습니다.