이 문서는 공개 화면에서 관찰할 수 있는 동작만을 대상으로 한 설계 메모입니다. 소스 코드, 모델 구성, 내부 벤치마크를 보여주는 것은 아닙니다.
먼저 '생성되었다'의 의미를 분해하다
아트 폰트 생성 UI에서는 입력 문자열, 스타일 방향, 캔버스, 출력 형식이 사용자의 관심사입니다. 버튼이 반응했다는 것만으로는 수용 조건을 충족했다고 할 수 없습니다.
공개된 AI 문자 디자인 서비스 Fontify를 예시로 들 경우에도, 다음 질문들을 먼저 정의합니다.
- 입력한 문자열이 미리보기까지 유지되는가
- 긴 문자열에서 잘리거나 겹침 현상이 일어나지 않는가
- 생성물이 이미지인지, 설치용 폰트인지 명확한가
- 하나의 설정만 변경하여 비교할 수 있는가
관찰 가능한 상태 모델
아래는 구현을 단정하지 않은, 테스트를 위한 설계 제안입니다.
Previewable
과 Exported
은 분리해서 다룹니다. 미리보기가 표시된다고 해서 다운로드물의 크기, 문자의 누락, 용도 설명까지 보장된 것은 아니기 때문입니다.
타입으로 수용 조건을 논의하다
다음 타입들 역시 구현의 관찰 결과가 아니라, 논의를 위한 최소 모델입니다.
type FontJob = {
phrase: string;
direction: 'restrained' | 'expressive' | 'seasonal';
...
assetKind
을 명시적으로 다루면, 이미지를 설치 가능한 폰트로 오인하는 경로를 검토할 수 있습니다.
작은 테스트 행렬
짧은 영문자, 긴 제목, 구두점, 일본어 또는 악센트 문자를 입력하고, 캔버스와 배경을 하나씩 변경합니다. 각 케이스마다 문자열의 일치 여부, 가독성, 파일 종류, 재편집 시 상태 유지 여부를 기록합니다. 셀렉터나 성능 값은 실제로 확인할 수 있을 때까지 가정하지 않습니다.
제약과 다음 확인 사항
블랙박스 관찰에서는 학습 데이터의 권리, 상업적 이용 조건, 내부 실패율을 알 수 없습니다. 이것들은 이용 약관이나 다른 검토를 통해 확인합니다. UI 테스트 결과물에는 입력, 선택, 출력, 육안 판정을 남기면 나중 디자인 수정도 재현할 수 있습니다.
수용 조건을 작게 나누다
검증의 진입점에서는 긴 사양서보다 작은 수용 조건이 유용합니다. 예를 들어 '입력한 문자열이 미리보기에 같은 순서로 나타난다', '배경을 변경해도 입력이 사라지지 않는다', '출력 형식과 용도가 설명된다'의 세 가지입니다. 각 조건을 짧은 문장으로 남기면, UI 개수 시에도 확인을 반복할 수 있습니다.
문자열 케이스는 짧은 영단어, 긴 제목, 일본어, 숫자와 기호가 혼재된 것을 준비합니다. 표시 폭이 달라지는 단말에서도 잘리거나 줄바꿈이 의도한 것인지 확인합니다. 이것은 모델의 품질을 추측하는 벤치마크가 아니라, 이용자가 받는 결과물의 경계를 확인하는 테스트입니다.
또한, 미리보기와 쓰기를 별개의 이벤트로 다루면, 파일이 존재하지 않는데 성공 표시만 남는 문제를 발견하기 쉽습니다. 구현을 단정하지 않고, 관찰하고 싶은 상태와 실패 시의 메시지를 먼저 설계하는 것이 이러한 종류의 UI를 안전하게 평가하는 지름길입니다.
Discussion
