비동기 검색 필드 UX: 입력한 텍스트와 확정된 선택 구분하기

서버에서 후보를 가져오는 검색 필드에는 비슷해 보여도 구분해야 하는 세 가지 값이 있습니다. 사용자가 입력한 문자열, 목록에서 살펴보는 후보, 실제로 선택한 레코드입니다. 이 상태를 섞으면 청구서에는 한 고객의 이름이 보이는데 다른 고객의 ID가 전송될 수 있습니다.

먼저 폼 필드가 허용하는 값과 동작(영어)을 정합니다. 이 예시의 청구 고객 필드는 임의의 텍스트가 아니라 기존 고객 한 명의 ID를 받습니다. 검색은 그 레코드를 찾는 수단입니다. 그럴듯한 고객 이름을 입력했다고 해서 선택이 완료되는 것은 아닙니다.

문자열 일치보다 레코드 식별을 먼저 설계하기

가상의 청구 관리 앱에 Northstar Studio(ID C-104)와 Northstar Supplies(ID C-219)가 등록되어 있다고 가정해 보겠습니다. 청구서를 작성하는 사람이 “North”를 입력하면 두 고객이 모두 검색됩니다. 드롭다운에는 선택하기 전에 둘을 구분할 수 있는 보조 정보를, 공개가 허용된 범위 안에서 보여 줘야 합니다.

고객 이름을 중심으로 표시하고 옆에 식별에 도움이 되는 정보를 붙입니다. 이 예시에서는 고객 ID로 충분합니다. 실제 제품에서는 공개가 허용된 소재지나 거래처 번호가 더 알아보기 쉬울 수도 있습니다. 검색을 쉽게 만들려고 비공개 정보를 노출하거나, 작은 아바타만으로 비슷한 레코드를 구분하게 해서는 안 됩니다.

Northstar Studio를 선택한 뒤에는 필드가 C-104를 가리킨다는 점이 분명해야 합니다. 표시 이름은 나중에 바뀔 수 있지만, 연결 대상은 선택한 레코드입니다. 제품 담당자와 개발자는 이 식별 정보를 어떻게 저장하고, 해당 레코드를 더 이상 사용할 수 없을 때 어떻게 처리할지 합의해야 합니다.

검색어, 탐색 중인 후보, 확정된 선택 구분하기

마지막 상태는 눈에 잘 띄지 않는 불일치를 막습니다. 사용자가 Studio를 Supplies로 바꿨는데 폼 내부에는 C-104가 남아 있다면 화면과 전송 데이터가 달라집니다. 선택한 레코드를 분명한 항목으로 표시하고 “변경” 동작을 제공하거나, 문자열을 수정할 때 이전 선택이 무효가 되는 시점을 명확히 정하세요. 이 동작을 암묵적으로 두지 않는 것이 중요합니다.

WAI-ARIA 콤보박스 패턴(영어)은 편집 가능한 필드, 허용되는 값, 수동 또는 자동으로 확정하는 자동 완성 동작을 구분합니다. 여기서는 레코드 한 개를 수동으로 확정하는 방식을 선택했습니다. 모든 다중 선택 토큰 필드나 명령 메뉴에 그대로 적용하는 명세는 아닙니다.

후보 목록이 어느 검색어의 결과인지 명확히 하기

원격 검색에는 응답 순서 문제가 있습니다. “North”를 입력해 요청 A가 시작된 다음 “s”를 붙이면 “Norths”에 대한 요청 B가 시작됩니다. B가 먼저 끝나고 A가 나중에 도착하더라도 현재 목록을 오래된 North의 결과로 바꾸면 안 됩니다.

이 순서를 인터랙션 명세에 기록합니다. 화면의 후보와 결과 수는 현재 검색어를 설명해야 합니다. 개발자는 이전 요청 취소, 오래된 응답 무시 등 신뢰할 수 있는 방법을 선택할 수 있습니다. 디자인에서는 로딩 표시만으로 문제가 해결된다고 가정하지 말고, 사용자가 보게 될 결과를 명시해야 합니다.

새 검색어의 결과를 불러오는 동안 이전 결과를 남길지도 정합니다. 이전 결과를 남기면 맥락을 유지할 수 있지만, 새 검색어에 대한 결과처럼 보이거나 실수로 선택되지 않아야 합니다. 짧은 고객 선택 필드에서는 목록을 비우는 편이 단순할 수 있습니다. 어느 쪽이든 요청이 끝나기 전에 완료 상태인 “고객을 찾을 수 없습니다”를 보여 줘서는 안 됩니다.

디바운스는 불필요한 요청을 줄일 수 있지만 모든 데이터 소스, 기기, 작업에 맞는 하나의 지연 시간은 없습니다. 개발자와 응답 동작을 조율하고 실제로 발생할 만한 지연을 넣어 시험하세요. 디자인 파일에서 결과가 즉시 나타나는 깔끔한 상황만 검토해서는 부족합니다.

검색 결과 없음과 서비스 장애에 다른 행동 제공하기

검색을 완료했지만 공개 가능한 일치 항목이 없다면 “‘Norths’와 일치하는 고객이 없습니다”처럼 정확히 말하고 검색어를 수정할 수 있게 합니다. 검색 서비스를 사용할 수 없다면 고객을 불러오지 못했다는 안내와, 지원되는 경우 다시 시도할 경로를 제공합니다. 실패했다고 해서 고객이 존재하지 않는 것은 아닙니다.

결과가 비었다는 이유만으로 “고객 만들기”를 붙이지 마세요. 레코드 생성은 권한, 필수 필드, 중복 확인 규칙을 갖춘 별도 작업입니다. 청구 앱이 생성을 지원한다면 기존 고객 선택과 구분해서 제공하고, 생성 완료를 확인한 뒤 원래 흐름으로 돌아오게 합니다.

결과가 보이지 않는 이유는 접근 제한일 수도 있습니다. 오류 문구로 숨겨진 레코드를 노출하지 마세요. 검색과 응답은 해당 사용자가 받을 권한이 있는 정보로 제한해야 합니다. 후보를 비활성화해 표시하는 것만으로 접근 권한을 통제할 수는 없습니다.

확정과 닫기 동작을 예측할 수 있게 하기

상태와 함께 키보드 동작을 문서화합니다. 이 수동 선택 방식에서는 방향키로 후보를 탐색하고, Enter로 현재 후보를 확정하며, Escape는 다른 레코드를 확정하지 않고 팝업을 닫습니다. Tab은 선택한 구현 패턴에 따라 폼을 이동하며, 모든 후보를 별도의 Tab 정지 지점으로 만들지는 않습니다.

APG 수동 선택 예시(영어)는 인터랙션과 의미 구조를 위한 참고 자료이지, 곧바로 상용 환경의 접근성을 보증하는 인증은 아닙니다. 최종 컴포넌트는 제품이 지원하는 브라우저와 보조 기술로 시험해야 합니다.

일반적인 텍스트 편집도 그대로 가능해야 합니다. 커서 이동, 범위 선택, 붙여넣기, 입력기의 조합 과정을 방해하지 마세요. 특히 조합 중의 키 입력을 매번 완성된 고객 이름으로 처리하거나, 사용자가 아직 글자를 조합하는 동안 단축키가 후보를 확정하게 해서는 안 됩니다.

결과가 바뀔 때 포커스를 갑자기 옮기지 않습니다. 탐색 중인 후보가 사라지면 어떻게 초기화할지 정하고, 같은 화면 위치에 들어온 다른 레코드에 강조 표시가 그대로 남지 않게 합니다. 로딩, 결과, 실패는 적절히 알리되, 잠깐씩 발생하는 요청을 매번 읽어 작업을 중단시키지 않도록 합니다.

Pixso에서 필드를 연속된 상태로 검토하기

Pixso 파일에 청구 고객 필드의 네 상태를 만듭니다. North 입력 중, 현재 후보 목록, Northstar Studio / C-104 선택 완료, 확정된 ID 없이 다시 편집하는 상태입니다. 필드 레이아웃은 재사용하고 상태별 문구와 피드백을 바꿉니다. 후보에는 Northstar Supplies / C-219도 남겨 리뷰어가 실제로 둘을 구분하도록 합니다.

프레임 옆에는 North → Norths 요청 순서를 표시하고 늦게 도착한 North 응답을 오래된 결과로 표시합니다. 이 설명은 설계 중인 청구 앱의 동작이며 Pixso 편집기의 기능을 뜻하지 않습니다. 리뷰어에게 각 시점에서 어떤 ID가 전송되는지, Supplies를 입력하는 것만으로 고객이 바뀌는지 설명해 달라고 요청하세요.

Pixso에서 고객 검색 흐름 설계하기 →

선택이 끝나도 최종 검증은 남아 있습니다

선택과 전송 사이에 고객 레코드가 보관 처리되거나 통합되거나, 현재 사용자의 접근 대상에서 제외될 수 있습니다. 최종 작업에는 여전히 서버 측 검증이 필요합니다. C-104를 해당 청구서에 사용할 수 없다면 복구 가능한 문제를 구체적으로 설명하고, 정책이 허용하는 범위에서 다른 청구서 입력값은 유지합니다.

표시 이름을 새로 가져오면서 다른 ID를 몰래 선택해서는 안 됩니다. 갱신 실패도 제품 규칙상 필요한 경우가 아니라면 유효한 선택을 지우는 이유가 되어서는 안 됩니다. 레코드를 확인하는 동안 마지막으로 확인한 이름을 계속 보여 줄 수 있는지 정하고, 청구서를 확정하기 전에 불확실한 상태를 드러냅니다.

비슷한 두 이름, 느린 응답, 순서가 뒤바뀐 응답, 일치 항목 없음, 서비스 실패, 키보드 선택, 선택 후 편집, 전송 시 사용할 수 없는 레코드를 모두 검토합니다. 이 사례들이 묻는 것은 하나입니다. 화면의 필드가 애플리케이션이 곧 사용할 레코드를 정확히 나타내고 있나요?