자율 에이전트를 위한 설계는 독특한 좌절감을 안겨줍니다. AI에게 복잡한 작업을 맡기면 30초(또는 30분) 동안 사라진 다음 결과를 가지고 돌아옵니다. 우리는 화면을 응시합니다. 효과가 있었나요? 환각을 느꼈나요? 규정 준수 데이터베이스를 확인했습니까, 아니면 해당 단계를 건너뛰었습니까? 우리는 일반적으로 이러한 불안에 대해 두 가지 극단 중 하나로 반응합니다. 우리는 시스템을 블랙박스로 유지하여 단순성을 유지하기 위해 모든 것을 숨기거나 패닉 상태에서 데이터 덤프를 제공하여 모든 로그 라인과 API 호출을 사용자에게 스트리밍합니다. 두 접근 방식 모두 사용자에게 이상적인 수준의 투명성을 제공하는 데 필요한 미묘한 차이를 직접적으로 다루지 않습니다. 블랙박스는 사용자에게 무력감을 느끼게 합니다. 데이터 덤프는 알림을 무시하게 만들어 에이전트가 제공하겠다고 약속한 효율성을 파괴합니다. 사용자는 문제가 발생할 때까지 지속적인 정보 흐름을 무시합니다. 문제가 발생하면 문제를 해결할 수 있는 컨텍스트가 부족합니다. 균형을 찾기 위해서는 체계적인 방법이 필요합니다. 이전 기사인 "에이전트 AI를 위한 설계"에서는 AI의 의도된 작업을 미리 표시하고(의도 미리보기) AI가 자체적으로 수행하는 작업의 양을 사용자에게 제어할 수 있는 기능(자율 다이얼)을 제공하는 등 신뢰를 구축하는 인터페이스 요소를 살펴보았습니다. 그러나 어떤 요소를 사용해야 하는지 아는 것은 문제의 일부일 뿐입니다. 디자이너에게 가장 어려운 질문은 언제 사용해야 하는지 아는 것입니다. 30초 워크플로에서 의도 미리보기가 필요한 특정 순간과 간단한 로그 입력으로 처리할 수 있는 순간을 어떻게 알 수 있습니까? 이 기사에서는 해당 질문에 답하는 방법을 제공합니다. 결정 노드 감사를 살펴보겠습니다. 이 프로세스를 통해 같은 공간에 있는 디자이너와 엔지니어가 백엔드 로직을 사용자 인터페이스에 매핑할 수 있습니다. AI가 수행하는 작업에 대한 업데이트가 사용자에게 필요한 정확한 순간을 정확히 찾아내는 방법을 배우게 됩니다. 또한 표시할 결정 노드와 해당 결정과 짝을 이루는 관련 디자인 패턴의 우선 순위를 지정하는 데 도움이 되는 영향/위험 매트릭스도 다룰 것입니다. 투명성의 순간: 사례 연구 예 초기 사고 청구를 처리하기 위해 에이전트 AI를 사용하는 보험 회사인 Meridian(실명이 아님)을 생각해 보세요. 사용자가 차량 손상 사진과 경찰 신고서를 업로드합니다. 그런 다음 에이전트는 위험 평가 및 제안된 지불 범위를 가지고 돌아오기 전에 잠시 사라졌습니다. 처음에 Meridian의 인터페이스에는 청구 상태 계산만 표시되었습니다. 사용자들은 좌절감을 느꼈습니다. 그들은 여러 개의 세부 문서를 제출했지만 AI가 완화 정황이 포함된 경찰 보고서를 검토했는지 여부에 대해 확신이 없었습니다. 블랙박스는 불신을 만들어냈습니다. 이 문제를 해결하기 위해 디자인 팀은 결정 노드 감사를 실시했습니다. 그들은 AI가 수많은 작은 단계가 포함된 세 가지 별개의 확률 기반 단계를 수행한다는 것을 발견했습니다.
이미지 분석 상담원은 손상 사진을 일반적인 자동차 충돌 시나리오 데이터베이스와 비교하여 수리 비용을 추정했습니다. 여기에는 신뢰도 점수가 포함되었습니다. 텍스트 검토경찰 보고서에서 책임에 영향을 미치는 키워드(예: 과실, 기상 조건, 절주)를 검색했습니다. 여기에는 법적 지위에 대한 확률 평가가 포함되었습니다. 정책 상호 참조 사용자의 특정 정책 용어와 청구 세부 사항을 비교하여 예외 또는 적용 범위 한도를 검색했습니다. 여기에는 확률적 매칭도 포함되었습니다.
팀은 이러한 단계를 투명성의 순간으로 전환했습니다. 인터페이스 순서가 다음과 같이 업데이트되었습니다.
손상 사진 평가: 500개의 차량 충격 프로파일과 비교. 경찰 보고서 검토: 책임 키워드 및 법적 판례 분석. 정책 적용 범위 확인: 계획에서 특정 제외 사항을 확인합니다.
시스템은 여전히 같은 시간이 걸렸지만 에이전트의 내부 작업에 대한 명시적인 커뮤니케이션은 사용자의 신뢰를 회복했습니다. 사용자는 AI가 설계된 복잡한 작업을 수행하고 있다는 것을 이해했으며 최종 평가가 부정확해 보일 경우 어디에 주의를 집중해야 하는지 정확히 알고 있었습니다. 이 디자인 선택은 불안의 순간을 사용자와의 연결의 순간으로 바꾸었습니다. 영향/위험 매트릭스 적용: 우리가 숨기기로 선택한 것 대부분의 AI 경험에는 처리 중에 잠재적으로 표시될 수 있는 이벤트와 결정 노드가 부족하지 않습니다. 감사의 가장 중요한 결과 중 하나는 무엇을 보이지 않게 할 것인지 결정하는 것이었습니다. Meridian 예에서 백엔드 로그는 클레임당 50개 이상의 이벤트를 생성했습니다. UI의 일부로 처리되는 각 이벤트를 기본적으로 표시하도록 설정할 수도 있습니다. 대신 위험 매트릭스를 적용하여 이를 정리했습니다.
로그 이벤트: Ping 서버중복성 검사를 위한 West-2. 필터 판정: 숨기기. (낮은 지분, 높은 기술성).
로그 이벤트: 수리 견적을 BlueBook 가치와 비교합니다. 필터 평가: 표시. (높은 지분, 사용자의 지불금에 영향을 미침)
불필요한 세부 사항을 제거함으로써 적용 범위 확인과 같은 중요한 정보가 더욱 효과적이었습니다. 우리는 개방형 인터페이스를 만들고 개방형 경험을 디자인했습니다. 이 접근 방식은 사람들이 작업이 완료되는 것을 볼 때 서비스에 대해 기분이 좋아진다는 생각을 사용합니다. 구체적인 단계(평가, 검토, 검증)를 보여줌으로써 30초의 기다림을 걱정의 시간(“고장난 걸까요?”)에서 뭔가 가치 있는 것이 만들어지는 듯한 느낌의 시간(“생각하는 중”)으로 바꿨습니다. 이제 명확한 정보가 필요한 주요 순간을 식별하기 위해 제품의 의사 결정 프로세스를 검토하는 방법을 자세히 살펴보겠습니다. 결정 노드 감사 투명성을 기능적 요구 사항이 아닌 스타일 선택으로 취급하면 투명성이 실패합니다. 우리는 “UI는 어떤 모습이어야 하는가?”라고 묻는 경향이 있습니다. "에이전트가 실제로 무엇을 결정하는가?"라고 묻기 전에 결정 노드 감사는 AI 시스템을 더 쉽게 이해할 수 있도록 하는 간단한 방법입니다. 이는 시스템의 내부 프로세스를 신중하게 매핑하여 작동합니다. 주요 목표는 시스템이 설정된 규칙을 따르지 않고 대신 확률이나 추정에 따라 선택하는 정확한 순간을 찾아 명확하게 정의하는 것입니다. 이 구조를 매핑함으로써 제작자는 시스템을 사용하는 사람들에게 이러한 불확실성 지점을 직접 보여줄 수 있습니다. 이는 시스템 업데이트를 모호한 진술에서 AI가 어떻게 결론에 도달했는지에 대한 구체적이고 신뢰할 수 있는 보고서로 변경합니다. 위의 보험 사례 연구 외에도 최근에는 조달 대리인을 구성하는 팀과 함께 일했습니다. 시스템은 공급업체 계약을 검토하고 위험을 표시했습니다. 원래 화면에는 "계약 검토 중"이라는 간단한 진행 표시줄이 표시되었습니다. 사용자들은 그것을 싫어했습니다. 우리 연구에 따르면 그들은 누락된 조항의 법적 의미에 대해 불안감을 느끼는 것으로 나타났습니다. 우리는 결정 노드 감사를 수행하여 이 문제를 해결했습니다. 이 기사의 마지막 부분에는 이 감사를 수행하기 위한 단계별 체크리스트가 포함되어 있습니다. 우리는 엔지니어들과 세션을 진행하고 시스템 작동 방식을 설명했습니다. 우리는 AI가 두 가지 좋은 옵션 중에서 선택해야 하는 순간인 "결정 지점"을 식별했습니다. 표준 컴퓨터 프로그램에서 프로세스는 명확합니다. A가 발생하면 B는 항상 발생합니다. AI 시스템에서 프로세스는 종종 우연에 기초합니다. AI는 A가 아마도 최선의 선택이라고 생각하지만 확실성은 65%에 불과할 수 있습니다. 계약 시스템에서 AI가 회사 규칙에 따라 책임 조건을 확인하는 순간을 발견했습니다. 완벽하게 일치하는 경우는 거의 없었습니다. AI는 90% 일치가 충분한지 결정해야 했습니다. 이것이 중요한 결정 포인트였습니다.
이 노드를 식별한 후 이를 사용자에게 노출했습니다. 인터페이스는 "계약 검토" 대신 "책임 조항은 표준 템플릿과 다릅니다. 위험 수준 분석 중"이라고 업데이트되었습니다. 이 특정 업데이트는 사용자에게 자신감을 심어주었습니다. 그들은 대리인이 책임 조항을 확인했다는 것을 알고 있었습니다. 그들은 지연 이유를 이해하고 원하는 작업이 백엔드에서 발생하고 있다는 신뢰를 얻었습니다. 또한 에이전트가 계약서를 생성한 후 어디를 더 깊이 파고들어야 하는지도 알고 있었습니다. AI가 의사결정을 내리는 방식을 확인하려면 엔지니어, 제품 관리자, 비즈니스 분석가 및 AI 도구의 작동 방식에 영향을 미치는 선택(종종 숨겨진)을 수행하는 주요 인력과 긴밀히 협력해야 합니다. 도구가 수행하는 단계를 그려보세요. 확률이 충족되어 프로세스 방향이 바뀌는 모든 지점을 표시합니다. 이는 보다 투명해지는 데 집중해야 하는 부분입니다. 아래 그림 2에 표시된 것처럼 결정 노드 감사에는 다음 단계가 포함됩니다.
팀을 하나로 모으십시오: 제품 소유자, 비즈니스 분석가, 디자이너, 주요 의사 결정자 및 AI를 구축한 엔지니어를 참여시키십시오. 예를 들어, 지저분한 법적 계약을 검토하도록 설계된 AI 도구를 구축하는 제품 팀을 생각해 보십시오. 팀에는 UX 디자이너, 제품 관리자, UX 연구원, 해당 분야 전문가 역할을 하는 현직 변호사, 텍스트 분석 코드를 작성한 백엔드 엔지니어가 포함됩니다.
전체 프로세스 그리기: 사용자의 첫 번째 작업부터 최종 결과까지 AI가 수행하는 모든 단계를 문서화합니다. 팀은 화이트보드 앞에 서서 AI가 복잡한 계약에서 책임 조항을 검색하는 것과 관련된 주요 워크플로의 전체 시퀀스를 스케치합니다. 변호사가 업로드합니다.50페이지 PDF → 시스템이 문서를 읽을 수 있는 텍스트로 변환합니다. → AI가 페이지에서 책임 조항을 검색합니다. → 사용자가 기다립니다. → 잠시 또는 몇 분 후에 도구는 발견된 단락을 사용자 인터페이스에서 노란색으로 강조 표시합니다. 도구가 수용하는 다른 많은 작업 흐름에 대해서도 이 작업을 수행합니다.
불분명한 부분 찾기: AI가 완벽하게 일치하지 않는 옵션이나 입력을 비교하는 모든 지점에 대한 프로세스 맵을 살펴보세요. 팀은 화이트보드를 보고 모호한 단계를 찾아냅니다. 이미지를 텍스트로 변환하는 것은 엄격한 규칙을 따릅니다. 특정 책임 조항을 찾는 데는 추측이 필요합니다. 모든 회사는 이러한 조항을 다르게 작성하므로 AI는 정확한 단어 일치를 찾는 대신 여러 옵션을 고려하고 예측해야 합니다.
'최선의 추측' 단계 식별: 명확하지 않은 각 지점에 대해 시스템이 신뢰도 점수를 사용하는지 확인합니다(예: 85% 확실합니까?). AI가 최종 선택을 하는 지점은 바로 이 지점이다. 시스템은 어떤 문단이 표준 책임 조항과 매우 유사한지 추측(확률 제공)해야 합니다. 최선의 추측에 신뢰도 점수를 할당합니다. 그 추측은 결정 노드입니다. 인터페이스는 최종 조항을 찾았다고 말하는 것이 아니라 잠재적인 일치를 강조하고 있다고 변호사에게 알려야 합니다.
선택 사항 검토: 각 선택 지점에 대해 수행 중인 특정 내부 수학 또는 비교를 파악합니다(예: 계약서의 일부를 정책과 일치시키거나 고장난 자동차 사진을 손상된 자동차 사진 라이브러리와 비교). 엔지니어는 시스템이 과거 회사 사례의 표준 책임 조항 데이터베이스와 다양한 문단을 비교한다고 설명합니다. 확률에 따라 일치 여부를 결정하기 위해 텍스트 유사성 점수를 계산합니다.
명확한 설명 작성: AI가 선택을 할 때 발생하는 특정 내부 작업을 명확하게 설명하는 메시지를 사용자에게 만듭니다. 콘텐츠 디자이너는 바로 이 순간을 위한 구체적인 메시지를 작성합니다. 텍스트 내용은 다음과 같습니다. 잠재적 책임 위험을 식별하기 위해 문서 텍스트를 표준 회사 조항과 비교합니다.
화면 업데이트: "계약 검토 중"과 같은 모호한 메시지를 대체하여 사용자 인터페이스에 새롭고 명확한 설명을 추가합니다. 디자인 팀은 일반 PDF 처리 로딩 스피너를 제거했습니다. AI가 생각하는 동안 문서 뷰어 바로 위에 있는 상태 표시줄에 새로운 설명을 삽입합니다.
신뢰도 확인: 새로운 화면 메시지에서 사용자에게 대기 시간이나 결과에 대한 간단한 이유를 제공하여 사용자가 더욱 자신감과 신뢰감을 느낄 수 있도록 하세요.
영향/위험 매트릭스 AI의 프로세스를 자세히 살펴보면 AI가 선택하는 지점을 많이 발견할 수 있습니다. AI는 하나의 복잡한 작업에 대해 수십 개의 작은 선택을 할 수 있습니다. 모두 표시하면 불필요한 정보가 너무 많이 생성됩니다. 이러한 선택 사항을 그룹화해야 합니다. 영향/위험 매트릭스를 사용하여 AI가 수행하는 작업 유형에 따라 이러한 선택 사항을 정렬할 수 있습니다. 영향/위험 매트릭스의 예는 다음과 같습니다. 먼저, 위험도가 낮고 영향력도 낮은 결정을 찾으세요. 낮은 위험 / 낮은 영향
예: 파일 구조 구성 또는 문서 이름 바꾸기. 투명성 요구사항: 최소. 미묘한 토스트 알림이나 로그 항목이면 충분합니다. 사용자는 이러한 작업을 쉽게 취소할 수 있습니다.
그런 다음 위험도가 높고 영향력이 큰 결정을 식별합니다. 높은 위험 / 높은 영향
예: 대출 신청을 거부하거나 주식 거래를 실행하는 경우. 투명성 요구: 높음. 이러한 조치에는 작업 증명이 필요합니다. 시스템은 작동하기 전이나 작동하는 즉시 그 근거를 입증해야 합니다.
모든 매수/매도 주문을 동일하게 처리하는 금융 거래 봇을 생각해 보세요. $50,000 거래와 동일한 불투명도로 $5 거래를 실행합니다. 사용자는 이 도구가 대규모 달러 거래에 대한 투명성의 잠재적 영향을 인식하는지 여부에 대해 의문을 제기할 수 있습니다. 그들은 고위험 거래를 위해 작업을 일시 중지하고 보여주기 위한 시스템이 필요합니다. 해결책은 특정 달러 금액을 초과하는 모든 거래에 대해 검토 논리 상태를 도입하여 사용자가 실행 전에 결정을 내리는 요인을 볼 수 있도록 하는 것입니다. 패턴에 노드 매핑: 디자인 패턴 선택 루브릭 경험의 주요 결정 노드를 식별한 후에는 표시할 각 노드에 어떤 UI 패턴을 적용할지 결정해야 합니다. Agentic AI 설계에서는 의도 미리보기(고위험 제어용) 및 작업 감사(회고적 안전용)와 같은 패턴을 도입했습니다. 둘 중 하나를 선택할 때 결정적인 요소는 가역성입니다. 우리는 매일 필터링합니다올바른 패턴을 할당하기 위해 영향 매트릭스를 통해 결정 노드: 높은 위험 및 되돌릴 수 없음: 이러한 노드에는 의도 미리보기가 필요합니다. 사용자는 작업(예: 데이터베이스를 영구적으로 삭제)을 쉽게 취소할 수 없기 때문에 실행 전에 투명성이 확보되어야 합니다. 시스템은 일시 중지되고 의도를 설명하며 확인이 필요합니다. 높은 위험 및 되돌릴 수 있음: 이 노드는 작업 감사 및 실행 취소 패턴을 사용할 수 있습니다. AI 기반 판매 에이전트가 리드를 다른 파이프라인으로 이동하는 경우 사용자에게 알리고 즉각적인 실행 취소 버튼을 제공하는 한 자율적으로 이동할 수 있습니다. 이러한 방식으로 노드를 엄격하게 분류함으로써 "경고 피로"를 방지합니다. 우리는 진정으로 되돌릴 수 없는 순간에 대해서만 마찰이 높은 의도 미리보기를 예약하고 다른 모든 것의 속도를 유지하기 위해 작업 감사에 의존합니다.
리버시블 되돌릴 수 없음 낮은 영향 유형: Auto-ExecuteUI: 패시브 토스트 / LogEx: 파일 이름 바꾸기 유형: 확인UI: 단순 실행 취소 옵션예: 이메일 보관 높은 영향 유형: ReviewUI: 알림 + 검토 TrailEx: 고객에게 초안 보내기 유형: 의도 미리보기UI: 모달 / 명시적 권한예: 서버 삭제
표 1: 영향 및 가역성 매트릭스를 사용하여 투명성의 순간을 디자인 패턴에 매핑할 수 있습니다. 정성적 검증: "기다려야 하는 이유는 무엇입니까?" 테스트 화이트보드에서 잠재적인 노드를 식별할 수 있지만 인간의 행동으로 이를 검증해야 합니다. 지도가 사용자의 정신 모델과 일치하는지 확인해야 합니다. 나는 “잠깐, 왜?”라는 프로토콜을 사용합니다. 시험. 사용자에게 에이전트가 작업을 완료하는 모습을 지켜보라고 요청하세요. 큰 소리로 말하도록 지시하십시오. 그들이 질문을 할 때마다 “잠깐, 왜 그랬지?” 또는 “고착됐나요?” 또는 "내 말 들었어?" — 타임스탬프를 표시합니다. 이러한 질문은 사용자의 혼란을 나타냅니다. 사용자는 자신의 통제력이 사라지는 것을 느낍니다. 예를 들어, 의료 일정 도우미에 대한 연구에서 사용자는 상담원이 약속을 예약하는 것을 지켜보았습니다. 화면이 4초 동안 정지되어 있었습니다. 참가자들은 “내 달력을 확인하는 건가요, 아니면 의사의 달력을 확인하는 건가요?”라고 일관되게 질문했습니다.
그 질문은 투명성의 순간이 누락되었음을 드러냈습니다. 시스템은 4초의 대기 시간을 "가용성 확인"과 "제공자 일정과 동기화"의 두 단계로 나누어야 했습니다. 이 작은 변화는 사용자가 표현하는 불안 수준을 줄였습니다. 시스템 작업만 설명하는 경우 투명성이 실패합니다. 인터페이스는 기술적 프로세스를 사용자의 특정 목표에 연결해야 합니다. "사용 가능 여부 확인 중"을 표시하는 화면은 맥락이 부족하기 때문에 밋밋합니다. 사용자는 AI가 달력을 보고 있다는 것을 이해하지만 그 이유는 알 수 없습니다. 우리는 행동과 결과를 연결해야 합니다. 시스템은 4초의 대기 시간을 두 개의 개별 단계로 나누어야 합니다. 먼저 인터페이스에는 '개점 시간을 찾기 위해 달력을 확인하는 중'이 표시됩니다. 그런 다음 '예약을 확보하기 위해 제공업체의 일정과 동기화 중'으로 업데이트됩니다. 이는 사용자의 실제 생활에 기술적인 프로세스를 기반으로 합니다. 지역 카페의 재고를 관리하는 AI를 생각해 보세요. 시스템에 공급 부족이 발생했습니다. '공급업체에 문의' 또는 '옵션 검토'라고 읽는 인터페이스는 불안감을 조성합니다. 관리자는 시스템이 주문을 취소하는 것인지 아니면 값비싼 대안을 구매하는 것인지 궁금해합니다. 더 나은 접근 방식은 의도된 결과를 설명하는 것입니다. "금요일 배송 일정을 유지하기 위해 대체 공급업체를 평가합니다." 이는 AI가 달성하려는 목표가 무엇인지 사용자에게 정확하게 알려줍니다. 감사 운영 결정 노드 감사를 완료하고 영향 및 위험 매트릭스를 통해 목록을 필터링했습니다. 이제 투명성을 유지하기 위한 필수 순간의 목록이 생겼습니다. 다음으로 UI에서 이를 생성해야 합니다. 이 단계에는 여러 부서 간의 팀워크가 필요합니다. 디자인 도구를 사용하여 혼자서 투명도를 디자인할 수는 없습니다. 시스템이 뒤에서 어떻게 작동하는지 이해해야 합니다. 논리 검토로 시작하세요. 수석 시스템 디자이너를 만나보세요. 결정 노드 맵을 가져오세요. 시스템이 실제로 이러한 상태를 공유할 수 있는지 확인해야 합니다. 기술적인 시스템이 내가 보여주고 싶은 모습을 정확하게 드러내지 못하는 경우가 종종 있습니다. 엔지니어는 시스템이 단지 일반적인 "작동" 상태를 반환한다고 말할 수 있습니다. 자세한 업데이트를 추진해야 합니다. 특정 통지를 보내려면 시스템이 필요합니다.텍스트 읽기에서 규칙 확인으로 전환할 때. 이러한 기술적 연결 없이는 디자인을 구축할 수 없습니다. 다음으로 콘텐츠 디자인 팀을 참여시키세요. AI의 행동에 대한 기술적 이유가 있지만 명확하고 인간 친화적인 설명이 필요합니다. 엔지니어는 기본 프로세스를 제공하지만 콘텐츠 디자이너는 커뮤니케이션 방식을 제공합니다. 이 메시지를 혼자 쓰지 마십시오. 개발자는 기술적으로는 정확하지만 사용자에게는 의미가 없는 "함수 402 실행"을 작성할 수 있습니다. 디자이너는 친근하지만 너무 모호한 "Thinking"이라고 쓸 수도 있습니다. 콘텐츠 전략가는 올바른 중간 지점을 찾습니다. 그들은 AI가 사용자를 혼란스럽게 하지 않고 작동하고 있음을 보여주는 "책임 위험 검색"과 같은 특정 문구를 만듭니다. 마지막으로 메시지의 투명성을 테스트하세요. 텍스트가 작동하는지 확인하기 위해 최종 제품이 만들어질 때까지 기다리지 마십시오. 나는 상태 메시지만 변경되는 간단한 프로토타입에 대해 비교 테스트를 수행합니다. 예를 들어 한 그룹(그룹 A)에는 "신원 확인 중"이라는 메시지를 표시하고 다른 그룹(그룹 B)에는 "정부 데이터베이스 확인 중"이라는 메시지를 표시합니다(이것들은 꾸며낸 예이지만 요점을 이해하셨습니다). 그런 다음 어느 AI가 더 안전하다고 생각하는지 묻습니다. 어떤 말은 걱정을 불러일으키는 반면 어떤 말은 신뢰를 쌓는다는 사실을 종종 발견하게 될 것입니다. 문구를 테스트하고 효과를 입증하는 데 필요한 것으로 취급해야 합니다. 이것이 디자인 프로세스를 어떻게 변화시키는가 이러한 감사를 수행하면 팀의 협력 방식이 강화될 수 있습니다. 세련된 디자인 파일을 더 이상 전달하지 않습니다. 우리는 지저분한 프로토타입과 공유 스프레드시트를 사용하기 시작합니다. 핵심 도구는 투명도 매트릭스가 됩니다. 엔지니어와 콘텐츠 디자이너가 이 스프레드시트를 함께 편집합니다. 정확한 기술 코드를 사용자가 읽을 단어에 매핑합니다. 팀은 논리 검토 중에 마찰을 경험하게 됩니다. AI가 비용 보고서에 제출된 거래를 거부하기로 결정한 방법을 엔지니어에게 묻는 디자이너를 상상해 보십시오. 엔지니어는 백엔드가 "오류: 데이터 누락"과 같은 일반 상태 코드만 출력한다고 말할 수 있습니다. 디자이너는 이것이 화면에서 실행 가능한 정보가 아니라고 말합니다. 디자이너는 특정 기술적인 후크를 만들기 위해 엔지니어와 협상합니다. 엔지니어는 시스템이 누락된 영수증 이미지 등 누락된 내용을 정확히 보고하도록 새 규칙을 작성합니다. 콘텐츠 디자이너는 이 단계에서 번역가 역할을 합니다. 개발자는 "공급업체 일치에 대한 신뢰 임계값 계산"과 같이 기술적으로 정확한 문자열을 작성할 수 있습니다. 콘텐츠 디자이너는 해당 문자열을 특정 결과에 대한 신뢰를 구축하는 문구로 변환합니다. 전략가는 이를 "금요일 배송을 확보하기 위해 현지 공급업체 가격을 비교합니다."라고 다시 작성합니다. 사용자는 작업과 결과를 이해합니다. 전체 다기능 팀이 사용자 테스트 세션에 참여합니다. 그들은 실제 사람이 다양한 상태 메시지에 반응하는 것을 지켜봅니다. 화면에 "거래 실행 중"이라고 표시되어 사용자가 당황하는 모습을 보면 팀은 접근 방식을 다시 생각하게 됩니다. 엔지니어와 디자이너는 더 나은 표현에 동의합니다. 그들은 주식을 사기 전에 텍스트를 "충분한 자금 확인"으로 변경합니다. 함께 테스트하면 최종 인터페이스가 시스템 로직과 사용자의 마음의 평화를 모두 보장합니다. 이러한 추가 활동을 팀 일정에 포함시키는 데는 시간이 필요합니다. 그러나 최종 결과는 보다 공개적으로 소통하는 팀, 그리고 AI 기반 도구가 자신을 대신하여 수행하는 작업(및 이유)을 더 잘 이해하는 사용자가 되어야 합니다. 이러한 통합 접근 방식은 진정으로 신뢰할 수 있는 AI 경험을 설계하는 초석입니다. 신뢰는 디자인 선택입니다 우리는 종종 신뢰를 좋은 사용자 경험의 정서적 부산물로 간주합니다. 신뢰는 예측 가능한 의사소통의 기계적 결과로 보는 것이 더 쉽습니다. 적시에 올바른 정보를 보여줌으로써 신뢰를 구축합니다. 사용자를 압도하거나 기계를 완전히 숨겨서 파괴합니다. 특히 에이전트 AI 도구 및 제품의 경우 결정 노드 감사부터 시작하세요. 시스템이 판단을 내리는 순간을 찾아보세요. 그러한 순간을 위험 매트릭스에 매핑하십시오. 위험이 높으면 상자를 엽니다. 작품을 보여주세요. 다음 기사에서는 이러한 순간을 디자인하는 방법, 즉 복사본을 작성하는 방법, UI를 구성하는 방법, 에이전트가 잘못되었을 때 피할 수 없는 오류를 처리하는 방법을 살펴보겠습니다. 부록: 결정 노드 감사 체크리스트 1단계: 설정 및 매핑 ✅ 팀을 하나로 모으세요: 제품 소유자, 비즈니스 분석가, 디자이너,주요 의사 결정자와 AI를 구축한 엔지니어. 힌트: 실제 백엔드 로직을 설명하려면 엔지니어가 필요합니다. 이 단계를 단독으로 시도하지 마십시오. ✅ 전체 프로세스 그리기: 사용자의 첫 번째 작업부터 최종 결과까지 AI가 수행하는 모든 단계를 문서화합니다. 힌트: 실제 화이트보드 세션은 이러한 초기 단계를 그리는 데 가장 효과적인 경우가 많습니다. 2단계: 숨겨진 논리 찾기 ✅ 불분명한 부분 찾기: AI가 완벽하게 일치하지 않는 옵션이나 입력을 비교하는 지점을 프로세스 맵에서 살펴보세요. ✅ 최선의 추측 단계 식별: 명확하지 않은 각 지점에 대해 시스템이 신뢰도 점수를 사용하는지 확인하세요. 예를 들어 시스템이 85% 확실한지 물어보세요. AI가 최종 선택을 하는 지점은 바로 이 지점이다. ✅ 선택 사항 검토: 각 선택 항목에 대해 수행 중인 구체적인 내부 수학 또는 비교를 파악합니다. 예를 들어 계약의 일부를 정책과 일치시키는 것입니다. 또 다른 예는 깨진 자동차 사진을 손상된 자동차 사진 라이브러리와 비교하는 것입니다. 3단계: 사용자 경험 만들기 ✅ 명확한 설명 작성: AI가 선택을 할 때 발생하는 특정 내부 작업을 명확하게 설명하는 메시지를 사용자에게 만듭니다. 힌트: 메시지를 구체적인 현실에 기반을 두세요. AI가 지역 카페에서 고객과의 미팅을 예약하면 시스템이 카페 예약 시스템을 확인 중이라고 사용자에게 알립니다. ✅ 화면 업데이트: 새롭고 명확한 설명을 사용자 인터페이스에 추가하세요. 계약 검토와 같은 모호한 메시지를 구체적인 설명으로 바꾸세요. ✅ 신뢰도 확인: 새로운 화면 메시지가 사용자에게 대기 시간이나 결과에 대한 간단한 이유를 제공하는지 확인하세요. 이를 통해 아이들은 자신감과 신뢰감을 느끼게 될 것입니다. 힌트: 실제 사용자와 함께 이러한 메시지를 테스트하여 달성되는 특정 결과를 이해하고 있는지 확인하세요.
