디지털 콘텐츠 디지털 미디어

트랙백TEST(유저인터페이스 관련 글)

* <게임인터페이스 분석과 유저빌러티 테스팅> 교재 개발을 하면서 쓴 글입니다. 
아직 더 다듬어야 하니, 강호독자들의 코멘트 부탁드립니다.

 

유저빌러티 테스팅 설계

1) 분석 방법의 종류와 특성

일반적 시스템의 경우 유저빌러티 테스팅은 다음 다섯 가지의 분석방법으로 설계한다.

(1). 직무분석 task analysis: 누가 무슨 작업을 하는지 분석한다. 직위와 역할에 따라 시스템 사용의 범위와 기능이 정해진다.

(2). 과제 분석: 하나의 직무에 다수의 수행해야 하는 과제가 있으므로, 그 직무가 포함하는 과제의 목록을 작성한다. 

(3). 포커스 그룹: 소수(5-?명)의 사용자 그룹을 모아 연구자가 진행자 역할을 하되 참여자들이 자유롭게 시스템에 대해 의견과 태도를 표현하게 함으로써 심층적인 문제점을 파악한다. 광고회사에서 소비자 니즈와 태도를 파악할 때 많이 쓴다. 다만, 대표성이 떨어지므로 실제 문제 해결을 위한 자료로는 직접 쓸 수 없다.

(4). 맥락적 연구: 문화기술지(ethnography *인종지학이라는 옛날 용어는 쓰지 말자). 질적 연구방법의 하나이다. 심층 인터뷰와 비슷한데, 실제 사용자가 실제 그 시스템을 사용하는 현장(집, 사무실)에서 관찰하고 심층 인터뷰를 통해 맥락에서의 해석을 이끌어내는 방법.

실증주의가 주류를 형성할 무렵에는 ““체계적이지 않고 이론적 바탕도 없으며 특정 경험으로부터 모종의 원리를 추출해 낼 수가 없는 방법” - Caroll & Kellogg, 1989“ 이라는 편견. 무식한 발언. 일반화는 어렵지만, 의미 파악에 가장 효과적인 방법.

(5). 휴리스틱(자기 발견적) 평가 .

전문가가 직접 사용해보고 문제를 진단해보는 방법.   

유저빌러티 테스팅의 핵심적인 방법은 유저를 대상으로 한 실험연구(experimental research) 방법이다.

실험연구란 유저를 대상으로 하는 조사연구이기 때문에 유저(사용자)에 대한 분석이 우선 이루어져야 한다. HCI 원칙을 기반으로 한 인터페이스 설계의 핵심 명제는 “사용자 중심으로 시스템을 설계하는 것”(김진우,    )이다. 게임에서는 ‘플레이어를 중심으로 게임 인터페이스를 설계하는 것’이 되겠다. 쉬운 말 같지만 현실에서는 잘 지켜져 오지 않았다. 그 이유로는 크게  개발자들의 잘못된 인식과 현실적 제약이 있기 때문이다.

2) 현실적 제약

게임 테스팅은 스쿠바 다이빙과 유사한 점이 네가지가 있다고 한다 (Schultz, Bryant, & Langdell, 2005).

첫째, 제한된 자원. 스쿠바 다이버에겐 바다속으로 가지고 들어갈 수 있는 장비가 제한되어 있다. 어깨에 부력조절기와 공기통을 매고 다리에 오리발을 끼는 것까지는 필수이지만, 플래쉬, 작살, 게이지, 수중 추진기 등 필요한 장비를 모두 가져가기엔 손이 모자란다. 거기에 수중메모판, 야간용 스트로브 등 특정 상황에 필요한 장비가 있을 경우, 이용가능한 자원의 제약은 절실하게 느껴질 것이다. 게임 테스팅과 이와 마찬가지로 이용가능한 자원에 제약이 있을 수 밖에 없다. 실험장비, 실험공간, 사용자조사에는 개발비 이외의 추가 경비가 들기 때문에 항상 제한된 자원으로 테스팅을 진행하게 된다.

둘째, 시간의 제약. 스쿠바 다이버가 바다속에 있을 수 있는 시간은 제한되어 있다. 공기통의 공기가 떨어지기 전까지 수면으로 올라오지 못하면 큰일이다. 게임 테스팅도 빡빡한 개발과 출시 일정 속에서 한정된 시간 조건에서 이루어지게 된다.

셋째, 규칙 준수. 스쿠버 다이버는 안전을 위해 꼭 지켜야할 규칙이 있다. 미리 잠수 계획을 세워야하며, 잠수전 건강상태를 확인해야 하며(음주 잠수는 절대 안됨), 잠수지점에 표시기를 띄워야 하며, 잠수중엔 수시로 공기량을 확인하고, 30미터 이하로는 내려가지 말고, 항상 짝과 함께 다녀야 하고 만약 놓쳤을 경우 수면으로 올라와 만난 후 다시 잠수해도록 약속을 지켜야한다. 잠수 후에는 짝과 서로 장비 벗는 것을 도우며, 공기통은 정기적으로 검사를 해야한다. 게임 테스터도  조사연구의 신뢰성과 타당성을 위해 지켜야할 규칙이 있다. (뒤에 이 규칙을 자세히 설명한다)

넷째, 가끔 놀랄 일이 생긴다. 스쿠버 다이버는 잠수중에 상어를 만날 수도 있다. 게임 테스터에게도 가끔 상어가 출현하는 상황과 같은 비상 사태가 닥칠 수 있다. 발매 발표일은 코앞인데, 수정하는데 시간이 많이 드는 엄청난 오류가 발견될 수도 있으니까. 스쿠버다이버에게 필요한 대처법은 우선 “절대로 당황하지 말 것 (Don't panic!)”이라고 한다. 게임 테스터의 대처법도 이와 같다. 그렇다고 꼭 무사히 수면으로 올라갈 수 있는 것은 아니지만.

 다음엔 일반적 시스템 개발에서 HCI 전문가들이 지적하는 개발자들의 잘못된 인식(김진우, 278-9)을 기반으로 게임 유저빌러티 테스팅에 대한 개발자의 오해에 대해 알아보자.

 

3) 개발자들의 오해

활을 쏠 때 과녁을 제대로 보지 않으면 적중률이 떨어질 수 밖에 없다. 즉, 어떤 사용자를 위해 게임을 개발하는 것인지 명확하게 파악하지 않으면, 플레이어에게 최적의 경험을 제공할 수 있는 게임 인터페이스를 설계할 수 없다. 그럼에도 불구하고, 실제 게임 인터페이스 개발에서는 플레이어에 대한 분석은 무시되는 경향이 있다. 그 이유는 개발자들이 가지고 있는 오해와 인식에서 비롯한다. 

(1). “내가 직접 플레이어로서 역할을 하면 된다.”

게임 개발자는 자신이 직접 게임을 만들었기 때문에 그 게임에 대해 가장 잘 알고 있다. 그리고 제작과정에서 직접 셀수없이 많이 플레이해보았기 때문에, 굳이 일반 플레이어의 경험을 관찰하고 그들의 반응을 반영할 필요가 없다고 생각한다. 그래서 본인이 직접 사용자로서 역할을 할 수 있다고 인식한다. 실제 플레이어에게 평가를 받으려면 절차도 복잡할뿐더러, 시간도 들고 금전적 비용도 든다. 굳이 여러 사람의 평가가 필요하면 회사내에 있는 직원들에게 부탁하면 된다고 생각한다. 그러나, 원래 자기 자신의 문제점을 스스로 찾아내기 어려운 것은 모든 분야의 공통된 경험이자 상식이다. 자기가 쓴 글을 자신이 여러번 교정해보아도 보이지 않던 틀린 철자가 남이 보면 나온다. 실례로, 세계적으로 명성있는 한 백과사전을 출간하면서 편집진은 자체의 교정이 완전하다고 자부하고, 틀린 철자를 찾아내는 사람에게 현상금을 주겠다고 큰소리를 쳤다가 오류가 쏟아져 나오는 바람에 큰 낭패를 보았다는 일화도 있다. 10대를 위한 온라인 게임을 만들면서, 게임 경험도 다르고 세대차가 나는 20-30대의 게임 개발자나 직원이 실제 플레이어의 동기와 만족도를 평가하고 사용성 분석을 한다는 것은 큰 오해일 뿐이다. 특히, 일부 특정 취향의 플레이어가 아닌, 대중시장(mass market)을 겨냥하는 게임의 경우 그 오해가 게임 마케팅에서 큰 손실을 불러올 수도 있다.       

(2). “사용자 분석은 게임 개발 출시전에 베타테스트만 하면 된다.”

영화 <봄날은 간다>에서 이영애가 말하듯 사랑은 변하는 것이고, 시간과 경험의 변화에 따라에 사람들의 필요와 만족의 기준도 변한다. 실제 HCI 연구결과의 예를 들면(HCI Lab, 2004?), 모바일 인터넷을 사용해본 적이 없는 사람들이 필요하다고 생각하는 인터페이스와 사용해본 사람들이 필요로 하는 인터페이스는 큰 차이가 있다. 즉, 경험의 유무에 따라 사용자의 필요와 취향이 달라지며, 사용자들이 표현하는 내용도 달라진다. 처음에는 사용하기 편했지만 나중에 불편을 느낄 수도 있고, 처음에는 불편을 감지하지 못했지만 나중에 문제점을 인식할 수도 있다. 특히, 사전에 사용 경험이 없는 사람들은 불편을 느껴도 설명하는데 어려움을 느낀다.

많은 게임개발사들이 출시 직전 비공개(closed) 그리고 공개(open) 베타테스팅을 시행한다. 대부분의 경우, 유사한 장르의 게임을 많이 해본 플레이어들이 참여한다. 이미 다른 게임의 인터페이스에 익숙해진 플레이어들은 ‘학습의 용이성’을 평가하기엔 적절한 대상이 아니다. 베타 테스트에선 버그를 잡아내는 것을 주 목적으로 하고 있기 때문에, 경험이 없는 사람들이 참여한다고 해도 그들이 평가가  이미 거의 완성한 게임의 인터페이스에 반영되기엔 너무 늦다.  

(3). “사용자 욕구와 필요가 게임 인터페이스 설계에 반영이 잘 안되어도 큰 문제는 없다.”

게임 제작은 항상 빠듯한 예산과 시간 속에서 진행된다. 예산이 넉넉하고 시간도 충분하다면 사용자 분석을 당연히 수행하겠지만, 당장 플레이가 가능한 게임을 제작하는 게 우선 과제라는 것이다. 버그가 있어서 게임이 제대로 작동하지 않는 것은 큰 문제이지만, 사용자의 욕구나 필요가 게임에 덜 반영되는건 별 문제가 아니라는게 개발자 관점의 시각이다. 이미, 사용자에 대한 분석이 제대로 이루어지지 못해 발생한 문제는 나중에 문제점을 파악했더라도 수정하는 데 많은 비용과 시간이 들어간다. 출시후 플레이어들의 반응이 냉담하여 수익이 저조하더라도 반드시 사용자의 요구사항이 제대로 반영되지 못해서라고 증명하기도 어렵다.