[HCI] Evaluation techniques

유저가 그룹단위일때 어떻게 할것인가?

지금까지 우리는 single-user system에서의 실험을 어떻게 하는가에 대해서 알아보았다. group system의 단위에서 실험을 evaluation 하기 위한 실험은 추가적인 문제를 야기시킨다. 인간 끼리의 의사소통과 group working의 복잡성이 주어졌을 때, single-user system보다 어렵고 복잡한 것은 놀라운 일이 아니다. 토론의 목적으로 실험 참가자들 사이에서 video connection을하는 application을 evaluate한다고 해보자. 그리고 몇몇 가지 문제들에 직면할 것이다.

The participant groups 

10번의 실험을 하는 single-user system은 10명의 실험 참가자가 필요하다. 3개의 그룹이 포함되는 실험에서는 30명의 참가자가 필요할 것이다. 게다가 group working 내에 실험은 single-user 실험보다 길다. 그 이유 중하나가 될 수 있는게 바로 settle-down이라는 것이 있는데, 이것의 실험의 결과가 안정되는것을 이야기 한다. 이 시간이 소요 되므로 길 수 있고  실험 참가자들에게 지장을 주고 이것이 비용이 더 많이 들게 하는 요소가 된다. 

참가자와 시스템간의 일정을 맞추는데에도 어려움이 생기게 된다. 실험에 사용 되는 워크스테이션이 동료의 개인적인 시스템이어서 우리는 적어도 6명의 사람을 포함 시킬려고 시도 했다. 실험자들에게 언급하지 않았다. 

많은 group working에 대한 report들이 3개 또는 4개의 그룹만을 포함한것은 놀라운일이 아니다 이것은 명백히 통계적인 측면으로 봤을때는 문제가 있지만 주된 장애가 되지는 않는다. 

The experimental task

알맞는 task을 선택하는것 역시 어렵다. 우리는 여러 종류의 task을 테스트하기를 원했다 : creative, structuredm information passing등등. 물론 task은 협력을 장려해야한다. 상호 합의가 필요한 task이거나 정보나 control이 실험 참가자들 사이에 분배가 되기 때문이다. 또한 명백하게 tassk는 groupware system의 속성에 의존한다 : 가능한 채널이 여러가지라면, 우리는 넓게(될 수 있으면 다 쓸 수 있게)장려받는다. 예를 들어서 가정한 video application의 경우에는 application을 사용하지 않고는 task의 수행이 불가능할 수 밖에 없다. 사용한다면 video conferencing에 대한 조사가 한결 수월 해 진다.

 

creative task는 '~에 대해짧은 레포트를 쓴다' 혹은 '~에 관한 연구 제안서를 작성한다'와 같을 수 있다. 때때로 이것이 매우 효과적인데, 예에서 실험 참가자들이 합의에 도달해야만하는 경우 공유 application을 이용한 final report를 쓰라고 요청할 수 있다.

Design task들 역시 사용된다. 어떤 디자인에 대해서 변경 요청같은것에 이용이 될 수 있다.

Decision game은 협동적인 활동을 테스트하고 훈련하기 위해서 만들어진것이다. Decision game은 개인의 활동이 아닌 그룹 협동에 성공이 좌지우지가 된다. 예를 들어서 사막 서바이벌 task에서, 참가자들이 사막에서 곤경에 처했다고 하자. 그들은 그들이 가진 아이템을 그들의 생존에 도움이 되는 순서대로 순위를 매길것이다: 칼, 플라스틱 시트 등등.. 참가자들은 이 아이템들 중에서 하나의 리스트를 만들어야한다, 참가자들이 혼자서 그일을 진행 할 순 없다. 

time-critical simulated process control task는 실험 참가자들이 모델의 다른 파트들을 제어함으로 더 높은 페이스의 상호작용을 가능하게 하는것이다. 

Data gathering 

single-user 실험에서도 우리는 여러대의 비디오 카메라에 application의 직접적인 로깅까지 이용을 할 수 있다. 그룹의 세팅의 경우에는 single-user의 경우를 각각의 실험 참가자들에게 그대로 적용하면 된다. 우리는 6개이상의 비디오 소스와 3개의 keystroke log를 동기화를 시킬려고 해봤다. 합성하는데에 문제는 각각 어떤 실험이나 장소에 따라 달라질 것이다. 기술적인 문제가 큰것은 당연하다. -> 4-into-1 비디오 레코딩은 가능하고 화면의 각 4분면에서 다른 이미지를 저장을 하지만 우리가 바라는 채널 수에서 부족했다. 

실험 참가자들의 개인적인것에 집중했을 때 녹화 각 참가자마다 이루어 지고 비디오 이미지나 사운드는 각 시스템의 부분으로 중계가되었다.(video connection이 있다고 가정을 했다.) 이들은 특별한 실험참가자들의 keystroke과 추가적인 video 탐색과 함께 동기화가 되었다. 그러므로 우리는 이런 상황을 재창조를 할수 있다. 

충분한 레코딩 장비가 주어졌으면 이것은 각 참가들에게 반복이 될수있다.  행복하게도 각 참가자들의 동기화의 레벨은 중요하지 않다. 중요한것은 각 개인의 동리화 레벨이 될것이다. 

=> 보니까 각각의 실험 참가자들 사이의 동기화는 걱정할 것이 안되고 각 개인의 동기화(비디오, 소리, log->keystroke등)이 매우 중요한 요소가 된다는것이 핵심이다.

Analysis 

실제 실험을 따라 우리는 실험 조건사이에서의 차이를 통계적으로 분석해보려고 한다. 우리는 이전에 single-user experimental에서는 개인적인 차이가 문제를 발생시킬 수 있다고 했는데 그룹 에서는 variation이 더욱 극단적이다. 무작위로 혼합된 그룹에서, 어떤 그룹은 민주적 성향이 나타나고; 다른 곳에서는 틀별한 pair가 토론을 지배할 수 있다; 세번째로 참가자들중 한명이 진행자가 되어서 다른 사람들의 의견을 정리할 수도 있다. variation의 정도는 어떤 컨디션 하에서는 매우 비극적일 정도로 실패고 다른 조건하에서는 기가 막히게 성공을 할수 있다. 그러므로 variation의 정도는 항상 통계적으로 중요한 의미를 이끌어내진 못한다. 

이것의 예로  우리가 output의 quality의 몇몇 양적인 measure가 있다고 하자. 우리는 거의 확실하게 non-parametric test들 하게 될 것이고 그러므로 우리가 어느 한 조건에서의 모든 그룹이 다른 조건의 그룹보다 점수가 높다고 가정해보자. 5%의 의미를 얻기 위해서는 적어도 각 조건에 4개는 필요하다.(아마도 measure가)

이제 하나의 조건만 고려하는 예제가 있고 여기서 최고의 결과를 가능해보자. 일반적으로 우리는 컨디션내에서 그룹사이의 spread(다양성)가 더 좋아지길 기대한다, 그리고 우리는 한먼에 더많은 조건을 테스트 하기를 원할것이다. 우리의 10 그룹은 어떤 통계적으로 의미가 있는 결과를 세우기 위해서 빠르게 증가를 할 것이다. 하지만 우리는 10개의 실험 그룹을 얻는것이 상당한 문제가 있다는것을 알아냈다.

이 문제를 해결하기 위해서는 세가지 가능한 솔루션이 있다. 먼저 하나는 within-group experiment를 이용하는것이다. 이것은 은 각 그룹이 여러컨디션 하게에서 실험이 진행이 된다. 두번째로 우리는 micro analysis같은 것을 통해서 발언(의견) 사이의 차이와 같은 특징을 볼 수도 있다. 이와 같은 measure들은 standard distribution에 좀더 적합하게 들어 맞을 수 있고 그러므로강력한 parametric test들을 해볼 수 있다. 게다가 그들은 그룹 사이에 큰스케일의 social difference(사회적 차이)에 더욱 확실하다.

세번째 솔루션은 좀 더 입증되지 않은 분석을 할 때 택할 수 있다. 뭔가 데이터 내에 critical한 사건을 찾는다- 예를 들어서, 흥미로운 이벤트나 고장같은 경우;;; 그룹 차이를 문제로서 간주하는데신에 그들이 분석에 포함 될 수 있다. 즉, 우리는 그들이 사용하는 통신 미디어와 어플리케이션과 상호작용하는 다른 그룹 구조를 찾는 체계적인 방법을 찾기를 시작할 수 있다.

물론 실험은 양적이고 질적인 방법을 둘다 이용해서 분석이 가능하다. 정말 구체화된 입증되지 않은 로그의 분석은 통계적인 분석을 하는데 있어서 생산적인 measure로 나타낼수 있다. 하지만 실험 그룹의 수가 제한 되면 제한된 실험을 시도하는것은 생산적이지 않을 수 있다. 그리고 낭비가 될 수가 있다. group-working 실험의 높은 비용이 주어졌다면, 흥미로운 결과를 낼 수 있는 조건을 선택해야할 것이다. 통계적이 분석이 불가능할 지라도 말이다.

Field studies with group

물론 그룹 실험을 할때 그들을 실험 환경에 집어넣기가 문제가 발생할 수 있다. group이 임의적으로 섞이면 우리는 그룹 편성의 프로세스를 일반적인 워킹그룹보다 효율적으로 조사한다. 심지어 먼저 존재했던 그룹이 이용되어도 그들의 일반적인 작업 환경으로부터 사람들을 제외하는것은 그들의 일하는 패턴을 바꿀 수 있다. 새로운 시스템을 위해서 일반적인(정상적이) workplace는 없을 수 있고 우리가 하는 모든것은 인공적인 환경을 조성하는 것이다. 하지만 이런 새로운 시스템이라도 우리는 좋은 실험이나 자연스러운 세팅을 선택할 수 있다. 전통적인 실험적 심리학은 이들 더 질적인 사회적 분석과 함께 이용될 수 있다. 

그룹실험 같은 경우에는 오직 컨텍스트 안에서만 연구될 수 있다고 주장할 수 있다. 실제 상황에서 벗어나는것은 실제 작업의 

본질을 바꾸는 것이 될것이다. enthnography라는 것은 사람들, 그들의 환경 그리고 서로서로 사이에 매우 상세한 상호작용의 기록을 하는것이다. 

Observational technique

시스템의 실제 사용에 대한 정보를 얻기 위해 사용하는 인기있는 방법은 유저가 시스템과 상호작용하는 것을 탐색을 하는것이다. 

Protocol analysis 

유저의 행동을 기록하는 여러가지 방법이 있다.

- 종이, 연필

- 오디오 레코딩

- 비디오 레코딩

- 컴퓨터 로깅

Automatic protocol analysis tools

프로토콜을 분석하면서 비디오, 오디오나 시스템 로그 둘중하나는 시간을 소비를 하거나 손으로 하게 되어서 지루해질 수 있다. 이것은 동기화해야하는 데잉터가 한개 이상일 때 매우 어려워 지게 되는데 이럴때는 automatic analysis tool을 이용하면 해결할 수가 있다. 이런 툴들은 상세한 분석을 위해서 수정과 비디오, 오디오 주석다는 작업이나 이것들을 동기화하는 그런 수단을 제공한다. 

EVA라고 그런 예가 하나 있는데 이것의 특징은 평가자가 tag버튼을 이용해서 흥미있는 일이 일어나면 그것에 대해서 따로 주석을 달아놓을 수 있다는것이다. 세션이 끝나고 리뷰를 하면서 태그를 달아놓으면 그것으로 검색 역시 가능하다. 

이와 같은 시스템은 비디오 분석에서의 부담은 완화를 시켜주지만 문제가 그것만은 아니다. 태깅하고 주석은 다는 행위는 그들 자신에게 일어나는 이벤트들에 대해서 집중하는것을 방지할 수 있다. 한마디로 이벤트를 놓치거나 나중에 대그가 될 수 있다는 이야기이다. 

Post-task walkthrough

때때로 데이터는 직접적인 탐색을 통해 해석이 결여된채로 획들되었다. 우리는 어떤 수행된 basic action을 가지고 있다. (왜 그런지에 관해 약간의 지식을 가지고) 참가자가 작을을 통해서 think aloud를 장려 을지라도  정보가 잘못될 수가 있다. 예를 들어서 참가자들은 "그리고 지금 내가 undo 메뉴를 선택하고 있어요" 라고 이야기할 수 있다. 하지만 우리에게 어떤 잘못이 undo메뉴를 필요한가는 이야기를 하지 않는다. 게다가 think aloud는  대안같은 정보를 가지고 있지 않다.

walkthrough의 시도는 이러한 문제들을 완화 시키기위한 시도이다, 이벤트 후에 참여자들의 액션을 다시 생각하게 하는것이다.  써졌거나 레코딩된 transcrip은 커멘트를 하러온 실험 참가자들에게 리플레이가 된다. 혹은 질문자들은 바로 질문을 받게 된다. 이것은 참가자가 행동을 하게 된 이유를 알게 된다면  매우 간단하게 해결이 되거나 간격 후에 사용자들의 일정 시간이 지난후의 해석까지 덭붙여서 대답을 받을 수 있다. 지연된 walkthrough의 장점이라고 한다면 분석가가 적합한 질문을 구성하고 어떤 명확한 사건에 초점을 맞춘다는데 있다. 단점이라면 freshness가 떨어지게된다. 시간이 좀 지나서 하는것이기 때문이다.  

실제 observation을 하는 동안 참가자들이 이야기하는것을 기대할 수 없을때는 몇몇 환경이 있다. 예를 들어서 critical task동안에 또는 task가 집중적(많이 모여)일 때 post-task walkthrough가 유저의 행동을 주관적인 관점에서 얻을 수 있는 유일한 방법이 될 수 있다. 가능한한 좋은 퍼포먼스를 얻기 위해서  direct observation동안에 task와 관련없는 이야기를 최소한으로 하는것이 더 선호되는 주장도 있다. 이것이 walkthrough를 필수로 여기게 한다.