비즈니스 앱 개편을 승인하기 전에 무엇을 시험해야 할까요?

새 화면은 좋아 보입니다. 공급업체가 주문을 찾고 수정한 뒤 저장하는 방법을 보여줍니다. 이제 개발을 진행할 수 있도록 개편안을 승인해 달라는 요청을 받았습니다.

승인하기 전에 실제로 앱을 사용할 사람에게 중요한 업무를 해보게 하세요. 어떤 상황인지, 어떤 결과를 얻어야 하는지 알려준 다음 진행 과정을 지켜보세요. 설명을 듣는 사람은 발표자가 길을 안내해 줍니다. 고객 요청을 처리하는 사람은 직접 필요한 방법을 찾아야 합니다.

중요한 업무부터 시작하세요

자주 하는 업무나 실수하면 문제가 생기는 업무를 고르세요. 예외 상황에 따라 해야 할 일이 달라진다면 그 경우도 포함하세요. 적절한 범위는 앱의 특성과 지금 내려야 할 결정에 따라 달라집니다.

가상의 예를 들어보겠습니다. 주문 담당자가 배송 전에 주소를 바꿔 달라는 고객 요청을 받습니다. 담당자는 해당 주문을 찾아 주소를 수정하고, 변경이 반영됐는지 확인해야 합니다.

가상의 고객 정보로 샘플 주문을 준비하세요. 담당자에게 그럴듯한 고객 메시지와 주문을 식별하는 데 필요한 정보를 제공하세요. 실제 정보를 보호할 수 없는 프로토타입에는 실제 고객 정보나 사업 정보를 넣지 마세요.

그런 다음 요청을 처리해 달라고 하세요. “주문을 열고, 편집을 선택한 다음 저장을 누르세요”처럼 지시하지 마세요. 알아보려는 답을 미리 알려주는 셈입니다.

Marieke McCloskey는 2014년 1월 12일 작업 시나리오 가이드에서 이 차이를 설명합니다. 의미 있는 상황과 목표를 제시하되 인터페이스에서 어떤 순서로 진행할지는 알려주지 않는 것입니다.

실제 사용 가능성이 있는 사람이 직접 해보게 하세요

이런 업무를 하는 사람이나 맡을 가능성이 있는 사람에게 시도해 달라고 하세요. 주문 담당자가 주문 수정을 맡는다면 제안된 화면을 이미 알고 있는 관리자가 대신할 수 없습니다. 다른 역할에서 다른 질문이 생긴다면 해당 역할의 사람도 포함하세요.

업무에 중요한 사용 조건을 반영하세요. 하루 종일 책상에서 일하는 담당자는 키보드를 주로 사용할 수 있습니다. 휴대전화로 주문을 확인하는 사람은 화면과 입력 방식이 다릅니다. 보조 기술을 사용하는 사람이 있다면 관련 환경을 마련하고 프로토타입이 이를 지원하는지 확인하세요.

GOV.UK의 진행자 동반 사용성 테스트 가이드는 실제 사용자나 예상 사용자가 그럴듯한 작업을 시도하는 모습을 관찰하는 방법을 설명합니다. 정부의 연구 프로그램 전체를 그대로 가져오지 않아도, 검토하려는 업무에 이 원칙을 적용할 수 있습니다.

담당자가 어디를 보는지, 언제 망설이는지, 잘못된 경로로 가거나 정보를 놓치는지 살펴보세요. 무슨 일이 일어났다고 생각하는지도 들어보세요. 도와줘야 한다면 언제 어떻게 도왔는지 기록하세요. 안내를 받아 끝낸 경우와 도움 없이 끝낸 경우는 서로 다른 정보를 줍니다.

“화면 구성이 마음에 들어요”는 개인의 선호를 알려줍니다. “주소가 저장된 줄 알았는데 아직 편집 모드였어요”는 조사할 만한 구체적인 문제를 알려줍니다.

이제 주문이 이미 출고 담당 부서로 넘어갔다고 해보겠습니다

같은 가상의 예에서 고객은 일반적인 주소 수정이 불가능한 시점에 요청합니다. 담당자가 주문의 현재 상태를 이해하고 다음에 무엇을 해야 할지 판단할 수 있을까요? 관리자 승인을 받거나 배송 부서에 연락해야 할 수도 있습니다.

먼저 회사 업무에 맞게 다음 단계가 무엇인지 정하고, 담당자가 직접 해보게 하세요. 프로토타입이 지원한다면 관련 화면과 선택지도 포함하세요. 결과가 명확한지 살펴보세요. 주소가 바뀌었는지, 다른 사람이 조치해야 하는지, 고객에게 답변할 수 있는지 담당자가 알고 있나요?

경고를 시뮬레이션해 문구가 이해되는지 확인할 수는 있습니다. 하지만 실제 앱이 권한 없는 변경을 막거나 배송 부서에 메시지를 전달한다는 점까지 입증하지는 못합니다. 그런 질문은 실제로 답을 확인할 수 있는 검증 단계에 남겨두세요.

질문에 답할 수 있는 프로토타입을 고르세요

스케치는 화면에 어떤 내용이 있어야 하는지, 제안한 방식이 타당한지 논의하는 데 도움이 됩니다. 클릭 가능한 프로토타입은 필요한 부분이 구현되어 있다면 주문 찾기, 화면 이동, 확인 메시지 이해를 시험할 수 있습니다. 어떤 부분이 실제로 작동하고 어떤 부분이 시뮬레이션인지 모두에게 알려주세요.

담당자가 주소 수정 경로를 찾을 수 있는지 알고 싶다면 그 경로를 직접 시도하게 하세요. 경고가 이해하기 쉬운지 판단하려면 경고가 나타날 상황에서 보여주세요. 화면을 사용할 수 있을 것 같은지 물으면 그 사람의 예측을 듣게 됩니다. 실제 시도를 지켜보면 실제로 무엇을 하는지 알 수 있습니다.

Katherine Alsop은 2014년 8월 27일 GDS의 프로토타입 활용 기록에서 이해관계자에게 보여주는 안정된 시연과 조사 중에 바꾸는 프로토타입의 차이를 설명했습니다. 또한 실제 운영 중인 서비스를 조사하면 프로토타입에서는 드러나지 않는 응답 시간과 오류 처리 문제를 발견할 수 있다고 했습니다.

이 점은 작업을 승인할 때 중요합니다. 클릭 가능한 “저장됨” 메시지로 담당자가 결과를 이해하는지 시험할 수 있습니다. 데이터가 올바르게 저장됐는지, 반복 요청이 안전하게 처리되는지, 연결된 시스템에 변경 사항이 전달됐는지는 적절한 구현 검증이 필요합니다. 보안, 실제로 적용되는 권한, 속도도 앱의 관련 기능을 작동시켜 근거를 확인해야 합니다.

평소 사용하는 보조 기술 환경으로 참여하게 하면 실제 장벽을 발견할 수 있습니다. 사용자를 접근성 평가에 참여시키는 W3C 가이드가 설명하듯, 이 과정은 접근성 표준에 따른 평가와 함께 진행해야 합니다. 이 작업들을 완료했다고 해서 앱이 접근성 표준을 충족한다는 뜻은 아닙니다. 프로토타입이 필요한 환경을 지원하지 못한다면 그 한계를 기록하고, 적절한 후속 검증을 마련하세요.

회의를 마칠 때 설명할 수 있는 결정을 남기세요

기억이 생생할 때 관찰한 내용을 적으세요. 실무에 쓸 수 있도록 정리하세요.

• 누가 무엇을 해봤는지: 참여자의 역할, 작업, 기기와 입력 방식, 프로토타입이 지원한 부분.
• 무슨 일이 있었는지: 의도한 결과에 도달했는지, 어디에서 어려움을 겪었는지, 어떤 도움이 필요했는지. 관찰한 사실과 원인에 대한 추측은 구분하세요.
• 무엇을 고쳐 다시 시도할지: 혼란스러운 이름, 빠진 정보, 불분명한 다음 단계가 무엇인지 적으세요. 수정한 뒤 영향을 받은 업무를 다시 시도하게 하세요.
• 실제 작동하는 앱에서 확인할 점: 남은 질문, 확인할 사람, 확인 시기를 기록하세요. 이 예에서는 출고 단계에서 늦게 요청된 주소 변경을 누가 승인할 수 있는지, 배송 부서에 어떻게 전달할지 등이 해당합니다.

그다음 시도가 뒷받침하는 방향은 승인하고, 어려움을 겪은 부분은 수정을 요청하고, 적절한 근거를 얻을 때까지 특정 결정을 보류할 수 있습니다. 개편의 부분마다 다른 선택을 해도 됩니다. 주문 화면을 승인했다고 해서 시험하지 않은 배송 시스템 연동까지 받아들여야 하는 것은 아닙니다.

비즈니스 앱 개편을 준비 중이라면, 저희의 디자인 서비스를 시작점으로 삼아 앱을 누가 쓰는지, 무엇을 해야 하는지, 어떤 결정을 내리는 데 도움이 필요한지 이야기할 수 있습니다.