사용자의 행동을 관찰하라 (당신은 사용자가 아니다)

프로그래머가 알아야 할 97가지 - 세 번째 이야기

by - Giles Colborne
영국 항공, 물리학회 출판국(IOP : Institute of Physics Publishing), 유로 RSCG 등 20여 년에 걸쳐 사용성 문제와 관련된 일을 해왔다. 그동안 수백 명의 컴퓨터 사용자를 관찰해왔다. 관찰 실험뿐만 아니라, 직장과 집에서 일상적으로 컴퓨터를 사용하는 모습을 관찰하기도 했다. 2004년에는 사용자 중심의 디자인 회사(UCO : User Centered Design) cxpartners를 공동 설립했다. cxparterners에서 Nokia, Marriott, eBay를 통해 고객을 위한 디자인과 사용자의 행동, 사용자의 체험과의 관계성을 연구하고 있다. 2003년부터 2007년 사이에는 영국 UPA(Usability Professionals’ Association) 회장을 역임했고, BSI(British Standards Institute: 영국 규격 협회)와 함께 접근성 관련 규격을 제정하고, 안내를 위해 노력하고 있다.

사람들은 타인이 자신과 비슷한 생각과 의견을 갖고 있다고 믿곤 하지만 생각과 의견은 사람마다 다르다. 이러한 잘못된 편견을 심리학에서는 허위 합의 효과라고 한다. 본인과 생각, 행동이 다른 사람을 봤을 때, (대체로 무의식적으로) 그 사람이 뭔가 문제 있는 사람이라고 평가하기도 한다. 사용자의 입장이 되어 생각하는 것이 어려운 이유가 바로 이 선입견 때문이다.

사용자는 프로그래머처럼 생각하지 않는다. 일반 사용자를 프로그래머와 비교해보면 일단 컴퓨터를 다루는 시간이 압도적으로 짧다. 그리고 컴퓨터가 내부적으로 어떻게 작동되는지 모를 뿐만 아니라 깊이 알고 싶어 하지도 않는다. 프로그래머는 매일 당연하게 처리해 온 문제 해결 테크닉이 몸에 베어 있지만, 일반 사용자는 그렇지 않다. 프로그래머라면 처음 보는 사용자 인터페이스라도 한번 만져보면 정해진 패턴이나 동작을 보고 많은 힌트를 알아채 금방 익숙해지지만, 일반 사용자는 그렇지 못하다.

사용자가 무엇을 어떻게 생각하는지를 알려면 사용자 그 자체를 관찰하는 것이 중요하다. 자신이 지금 개발 중인 소프트웨어와 비슷한 소프트웨어를 준비해서 사용자에게 작업하게 하고 그 모습을 관찰하는 것이다. 작업은 가능한 한 실제 업무처럼 진행하도록 유도해야 한다. 예를 들어 스프레드시트 소프트웨어라면 '일련의 숫자를 더해보세요.'라는 작업이나 '지난달, 자신의 지출을 계산해보세요'라는 작업을 부탁한다. '특정 셀을 선택해서 SUM 함수를 입력해 주세요'와 같이 너무 구체적인 지시는 피하는 게 좋다. 작업이 어디까지 진행되었는지 지금 어떤 상황인지를 사용자에게 직접 듣도록 한다.
당신이 직접 작업에 끼어들거나 도움을 줘서는 안 된다. 끊임없이 '왜 이 사람은 이렇게 하지?', '왜 이렇게 하지 않지?' 라는 생각을 하며 관찰해야 한다.

아마도 관찰을 해보면 사용자들은 대체로 핵심작업을 비슷하게 한다는 걸 알게 될 것이다. 작업 진행 순서나 실수하는 부분이 거의 비슷하다는 뜻이다. 즉 소프트웨어는 이러한 사용자의 기본적인 행동을 고려한 설계가 필요하다. 회의실에 모여 '사용자가 아마도 이렇게 할 거니까…'라는 상상으로 이야기하는 것과는 차원이 다르다. 단순히 상상을 기반으로 만들어본들 사용자가 무엇을 원하는지 명확히 모른 채 결국 복잡하고 사용하기 어려운 시스템이 만들어질 뿐이다. 사용자를 직접 관찰함으로써 그걸 해결할 수 있게 된다.

사용자가 조작법을 몰라서 고민하는 모습도 여러 번 보게 될 것이다. 프로그래머라면 시점을 바꿔 다른 방법을 찾아보고, 화면 이곳저곳을 테스트해보겠지만, 일반인은 그렇지 않다. 사용자가 고민이 깊어지면 시야가 좁아져 버리기 때문에 화면 다른 곳에 있는 해결책을 찾는 것이 더 어려워진다. 그러므로 도움말 버튼을 화면 어딘가에 배치하는 건 근본적인 해결책이 될 수 없다. 그러한 디자인은 오히려 사용자 인터페이스가 불친절하다는 뜻이 된다. 문제 해결을 위한 지시, 도움말 문구는 문제가 일어난 그곳, 그 지점에 표시돼야 한다. 사용자의 시야가 좁아져 있으므로 다른 곳에 배치한 도움말 메뉴보다 문제가 일어난 지점에 표시된 툴팁이 훨씬 유용한 것이다.

사용자들은 어떻게든 문제를 해결하면 그걸로 만족한다. 그 과정이 효율적인지 어떤지는 크게 개의치 않는다. 어떻게든 문제 해결 방법을 한 가지 찾게 되면 계속 그 방법을 고집한다. 그게 비효율적인 방법이더라도 고치려 생각하지 않는다. 간편한 단축키가 두, 세 가지 준비된 것보다, 보고 금방 알아차릴 방법 한 가지를 오히려 고맙게 느낀다.

사용자가 하고자 하는 일이 있을 때, 그것에 관해 설명을 시켜보면, 말과 행동이 다르다는 걸 금방 눈치 챌 수 있다. 이것도 상당히 성가신 문제다. 사용자가 뭘 원하는지 알려면 그들이 하는 말에 귀를 기울일 수밖에 없기 때문이다. 사실 사용자가 원하는 것을 제대로 알려면 말을 듣기보다 그들의 행동을 관찰하는 편이 낫다. 그들이 뭘 원하는지 고민하며 하루를 보내기보다 한 시간 정도 옆에서 관찰하는 편이 얻는 것이 훨씬 많다.