모든 케이스가 파악되어야 한다.
이용자들이 IT 기획자의 의도와 같이 사이트를 이용해 주면 참 좋지만, 의도와 다르게 사이트를 이용하는 경우가 많습니다. 공원에 ‘잔디밭에 들어가지 마십시오’ 라는 커다란 안내 문구가 있음에도 들어가는 사람들이 있는 것처럼 말이죠. 따라서 IT 기획자는 이용자에게 바라는 이용 행태와 바라지 않은 이용 행태를 모두 고려해야 하고, 바라지 않은 방향으로 이용할 경우 대비책이 모두 설계되어 있어야 합니다.
바둑에서는 이와 같은 여러 경우의 수를 생각해 보는 것을 ‘수읽기’라고 합니다. 상대가 바둑돌을 어디에 둘지 예상하고 내가 둘 곳을 미리 생각하는 것입니다. 사이트를 기획할 때도 이용자들이 어떻게 이용할지 미리 예상하는 능력이 필요합니다. 이용자의 이용 행태는 보통 아래 세 가지 형태로 구분할 수 있습니다.
정상
IT 기획자가 의도한 대로 이용한 경우
(예) 회원 가입 시 아이디는 8자를 초과할 수 없는데 이용자가 8자 이내로 입력함.
변칙
IT 기획자가 의도한 대로 이용하지 않은 경우
(예) 비밀번호에 특수 문자를 넣어야 하는데 이용자가 넣지 않음.
만회
IT 기획자가 의도한 대로 이용했지만 이용자의 입장에서 결과를 다시 되돌리고 싶은 경우
(예) 정상적으로 결제를 완료했지만 결제를 취소하거나 상품 수량을 바꾸고 싶음.
일반적인 사이트의 회원가입 화면을 설계할 때 단순하게 ‘아이디와 비밀번호를 입력하고 회원 가입 버튼을 클릭하면 되는 것 아닌가?’라고 생각할 수 있습니다. 하지만 기획자는 더 넓고, 깊게 사고해야 합니다. 화면을 설계할 때 이용자의 모든 이용 행태를 예상하지 못한다면 사이트 오류와 연결될 수 있으며, 이런 오류를 사전에 발견하지 못한다면 이용자는 불편을 겪게 되기 때문입니다.
회원가입 화면은 이용자가 직접 입력할 내용이 많아서 각종 변칙 상황이 많이 발생하는 화면입니다. 따라서 아래 예시와 같이 이용자가 변칙 이용 시 경우에 맞는 대응 방안을 함께 설계합니다.
상황: 아이디를 입력하지 않았을 때
대응: ‘아이디를 입력해 주세요.’라는 알림 메시지(Alert)를 보여 줍니다.
상황: 정책에 맞지 않는 아이디를 생성하려고 할 때
대응: ‘아이디는 4~ 15자리 이내의 영문, 숫자로만 생성해 주세요.’라는 알림 메시지(Alert)를 보여 줍니다.
상황: 이메일 형식에 맞지 않는 이메일 주소를 입력할 때
대응: ‘이메일 형식에 맞는 메일 주소를 입력해 주세요’라는 알림 메시지(Alert)를 보여 줍니다.
회원 가입 화면은 비교적 단순하고, 가입 절차도 매우 익숙하지만 온라인 민원 신청, 여행 상품 주문처럼 기능이 많은 화면에서는 사용자의 모든 이용 행태를 예상하기 힘든 경우가 많습니다. 그렇다면, 이용자의 변칙 이용을 최소화하려면 어떻게 해야 할까요? 불필요한 기능은 과감히 삭제하여 경우의 수를 최소화하고, 그 안에서 이용 행태의 모든 경우의 수를 파악하는 수밖에는 없습니다. 이용자가 고민하지 않고 직관적으로 사용할 수 있도록 화면을 단순하게 설계하는 것이 무엇보다 중요합니다.
요즘 제작되는 사이트는 예전과 달리 많이 친절해졌습니다. 이용자의 실수가 사이트 운영에 미치는 영향이 크다는 것을 기획자들이 경험을 통해 배웠기 때문입니다. 따라서 이용자가 사이트를 이용하다가 실수했더라도 이용자가 직접 수정할 수 있도록 설계해야 합니다.
특히, 쇼핑몰에서는 이용자의 실수가 많습니다. 상품을 구매할 때 수량이나 색상을 잘못 선택하거나, 배송 주소를 잘못 입력한 경우가 대표적입니다. 심지어 무통장 입금을 선택한 이용자에게 입금할 금액(26만 원)을 문자 메시지로 안내해도 26만원이 아니라 260만원을 입금하기도 합니다. 비록 이용자의 실수지만 더욱 편리하고 쉬운 사이트 이용을 위해 실수를 수정할 수 있는 정책과 그에 따른 기능을 마련해 놓아야 합니다.
아주 쉬운 예를 들어 볼까요?
메일 작성 시 내용을 작성한 후 ‘보내기’ 버튼 대신 실수로 ‘닫기’ 버튼을 눌러서 1시간 동안 작성한 메일 내용을 모두 날린 경험이 있나요? 예전에는 닫기 버튼을 클릭하면, 작성한 내용이 바로 삭제되었습니다. 하지만 지금은 이용자를 배려하여 확인 메시지를 띄워서 의견을 한 번 더 묻는 방식이 정석처럼 사용됩니다. 이런 작은 차이로 이용자가 실수를 하여도 소중한 1시간을 아껴 줄 수 있게 된 것이죠.
쇼핑몰을 예로 들어 조금 더 구체적으로 살펴보겠습니다.
이용자가 의류 쇼핑몰에서 옷을 5벌 구매했습니다. 그런데 2벌은 사이즈를 잘못 선택했고, 다른 2벌은 배송 주소를 잘못 입력했습니다. 이용자는 상품 주문 수정 화면으로 들어가서 상품 옵션과 배송 주소를 직접 수정했습니다.
이용자 입장에서는 꼭 필요한 기능이고 흐름도 자연스럽습니다. 하지만 기획자의 입장에서는 그리 간단하지 않습니다. 주문 정보를 수정할 때는 수정할 수 있는 상황인지를 점검한 후, 조건을 만족할 경우에만 이용자에게 수정할 수 있는 권한이 부여되어야 하기 때문입니다. 예를 들어, 상품이 배송 중일 때는 주문 정보를 수정할 수 없도록 설계해야 합니다. 상품이 이미 택배로 배송 중이므로 이용자가 아무리 정보를 수정하여도, 운영자가 발송 주소를 수정할 수 없기 때문입니다.
만약 이러한 예외 상황이 모두 고려되지 않으면 이용자와 운영자 사이트 이용에 불편함을 겪게 됩니다. 예상 가능한 이용자의 실수는 정책 정의서를 작성할 때 미리 살펴볼 수 있습니다. 이후 이를 바탕으로 사이트를 설계하면서 세부적인 사항을 검토해 보세요. 예외 상황을 하나씩 나열하다 보면 사이트 화면에서는 알 수 없는 이용자의 특별한 행태를 발견할 수 있습니다. 이용자의 실수를 찾고, 이에 대한 대응 방안을 준비하여 이용자의 불편 사항을 최소화해야 합니다.
사이트의 수읽기는 IT 기획자의 기본 역량입니다.
처음부터 완벽하게 예측하는 것은 어렵습니다.
그리고 완벽하게 예측하는 IT 기획자 역시 없을 것입니다.
최대한 많은 변칙 이용에 대비하여 오류로 연결되는 경우의 수를 줄이는 것이 최선입니다.
오늘부터 사이트를 이용할 때 정상적인 이용 방법 이외에 변칙 이용을 해보며, 다른 기획자들이 기획한 대처 방안을 학습하며 이용해 보는 건 어떨까요?
변칙 이용한 내용과 이에 대한 대처 방안을 하나씩 기록해 보며 학습한다면 더욱 체계적으로 학습될 것입니다.