태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'user test'에 해당되는 글 3건

  1. 2017.05.12 프레임웍 단계에서 Task 평가를 하면 좋은 이유 by KAHYUN.
  2. 2016.08.18 중급 UX 디자이너로 성장하기 9편 - 성공적인 사용성 평가 Usability Test by 이 재용
  3. 2012.03.26 Windows 8 Real User Test 파문 (1) by 이 재용
2017.05.12 07:50

프레임웍 단계에서 Task 평가를 하면 좋은 이유

이미 출시된 서비스의 문제점을 파악하여 새로운 시안을 고민할 때 UT(Usability Test)를 진행하곤 합니다. As-is 서비스의 사용성을 평가한 적은 많지만 To-be 서비스의 사용성 평가는 일정에 쫓기다 보면 진행하기 어려운 경우가 많습니다. 최근 참여했던 프로젝트에서 운 좋게도 기획한 To-be 시안 평가를 진행할 기회가 있었습니다. 보통 프레임웍 선호도를 조사할 때 프린트된 시안을 가지고 A,B안의 선호도 조사를 진행하지만 이번에는 간단한 메인 Task도 평가해보기로 했습니다. 프레임웍 단계에서 Task 평가를 진행하니 프린트된 화면을 통해 듣는 이야기와 다른 사용자의 이야기를 들을 수 있었습니다. 이번 포스팅에서는 프레임웍 단계에서 Task를 평가를 진행하며 깨달은 몇 가지를 공유하고자 합니다.



직접 사용할 사용자의 적극적인 의견을 들을 수 있는 기회

테스트는 먼저 프린트된 프레임웍 시안 화면을 통해 As-is 화면에서 To-be 화면이 어떻게 바뀌었는지 파악한 다음 프로토타입으로 각 시안 별 Task를 수행하는 방식으로 진행되었습니다. 사용자가 프린트된 시안을 볼 때에는 '이 영역이 커서 좋아요.' '메뉴가 잘 보여서 좋아요.' 등 화면에서 어떤 영역이 잘 보이는지, 메뉴가 잘 보이는지 등 화면에서 보이는 기능과 정보 위주로 답변을 해주었습니다. 그런데 Task 평가를 수행 후, '알림 영역에서 문제를 바로 해결할 수 있었으면 좋겠어요.' '이 Task에서는 이 영역은 필요 없을 것 같아요.' 등 화면에서 더 개선되었으면 하는 기능과 불필요한 기능에 대해 이야기를 해주었습니다. 프린트된 화면으로만 인터뷰할 때보다 풍부한 의견을 많이 수집할 수 있었습니다. 사용자는 전문가가 아니기 때문에 프린트된 화면을 볼 때는 화면에 보이는 부분에 대해 평가를 할 수밖에 없습니다. 이때 Task 평가를 같이 진행하면 To-be 화면에서 더 개선되면 좋을 화면에 사용자의 생생한 의견을 수집하기 좋은 환경을 제공합니다.

정지된 화면을 볼 때는 메뉴 위치 등 화면 내의 기능에 대한 평가가 이루어지지만, Task 수행 시 Task와 화면을 연관 지어 평가하게 됩니다.



서비스가 운영되는 맥락을 고려해 시안을 낼 수 있는 기회

As-is의 화면은 한 화면 내에 필요한 기능과 정보가 모두 표시되어 초보자가 사용하기에는 복잡한 느낌이 있었습니다. To-be 화면은 복잡해 보이는 부분을 개선하고자 하여, 2가지의 프레임웍 시안을 냈습니다. A안은 정보가 간략하게 변화하는 시안이었고, B안은 안정적인 레이아웃을 유지하는 시안이었습니다. 정보량을 봤을 때 A안이 더 간략한 정보로 구성되어 A,B안 중 A안이 B안보다 낫다고 생각했습니다. 하지만 막상 UT를 진행하니 B안을 선호하는 사용자가 많았습니다. 사용자가 B안을 선택한 가장 큰 이유는 A안은 변화가 일어나기 때문에 '안정성'이 가장 중요한 해당 서비스에서 사용하기 불안하다는 것이었습니다.

프레임웍을 설계하다 보면 화면에서의 사용성, 정보의 간결성을 중심으로 생각하게 됩니다. 하지만 서비스가 운영되는 환경에 따라 사용성보다는 안정성이 우선시 될 수 있는 것입니다. 프레임웍을 디자인할 때 '작은 변화'라고 생각했던 부분이 사용자에게는 시안을 선택하지 않은 1순위의 이유가 될 수 있었습니다. UT를 통해 서비스가 사용되는 환경을 고려해 서비스가 어느 부분에 중점을 두어야 하는지 확인할 수 있었습니다.

작은 변화라고 생각했던 인터랙션이 불안정한 시스템 운영 환경에서는 크리티컬한 요소가 될 수 있습니다.



고민했던 아이디어를 사용자의 시선에서 검증할 수 있는 기회

사용자에게 아무리 몰입해도 실제 사용자일 수는 없는 것 같습니다. 인터뷰에서 언급되지는 않았지만, 사용자가 더 편리하게 사용할 수 있도록 필요한 기능들을 추가했습니다. 특정 직업군이 사용하는 서비스이기 때문에, 인터뷰에서 언급되지 않은 기능을 추가하거나 As-is 서비스 용어를 바꾸면서 실제 사용자도 정말 쉽다고 생각하는지, 이 정도의 용어는 써도 괜찮은지 확신이 서지 않았습니다. Task 평가를 진행하니, 실제 서비스 사용에 몰입한 사용자를 통해 새로운 기능, 용어를 검증할 수 있었습니다.


디테일한 부분까지 설계할 수 있는 기회

프레임웍을 프로토타입으로 만드는 것은 사용자를 위한 디자인을 하는 것뿐 아니라 디자이너에게도 설계한 화면들을 돌아보는 기회를 제공합니다. 메인 화면 중심으로 화면을 설계한 후 설계서 작업에 들어가면 화면 이동이 어색하거나 다른 화면들과 이질적인 화면이 생기는 경우가 종종 있습니다. Task 평가를 위해 설계한 프레임웍을 연결 지어서 보고, 필요한 화면을 이미 설계한 화면과 비교하면서 작업하니 분절된 화면들이 하나의 서비스로 느껴지며 실제 구현시 어색한 부분은 없는지 확인할 수 있었습니다.

스케치에서 Task 별로 화면을 설계해보면 메인 프로세스에서 필요한 화면 중 빠진 것이 없는지 파악하기 쉽습니다.



마치며...

프레임웍이지만 실제 서비스를 사용하듯 테스트에 몰입하는 사용자를 보며 그동안 서비스가 사용자를 만나려면 화면의 완성도가 높아야 한다는 편견(적어도 색은 입혀야 되지 않을까?)을 깨게 되었습니다. 물론 최소한의 완성도는 필요합니다. Low-fidelity 툴을 사용하다 보니 제한된 인터랙션으로 프로토타입을 제작할 수밖에 없었습니다. 그러다 보니 화면 선택 시 매끄럽게 진행되지 않은 부분이 있었습니다. 사용자가 화면 평가 시 인터랙션 요소가 bias가 된 것 같아 만약 인터랙션이 원만했다면.. 하는 아쉬움이 남습니다.

또, 사용자는 To-be 화면을 처음 마주하기 때문에 Task와 관련 없는 기능들도 어떻게 바뀌었는지 궁금해합니다. 제작기간이 충분해서 2depth 메뉴 화면들까지 설계했다면 보다 실제 서비스를 사용하는 몰입감을 제공했을 것입니다. 일정이 빠듯한 양산 프로젝트에서 프레임웍을 가지고 UT를 진행하기는 쉽지 않습니다. UT를 진행하기 어려운 상황이라면 디자이너가 스스로 프레임웍이 잘 설계되었는지 판단하기 위한 용도로써 플로우를 한눈에 볼 수 있는 프로토타입을 만들어 보는 것을 추천합니다.

[참고##사용성 평가##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2016.08.18 07:45

중급 UX 디자이너로 성장하기 9편 - 성공적인 사용성 평가 Usability Test

사용성 평가를 성공적으로 하려면 어떻게 해야할까?


정답: 그냥 하면 된다. 왜냐하면 모든 사용성 평가는 성공하기 때문이다.


좀 극단적으로 이야기했지만 (이 시리즈는 언제나 자극적인 문구로 시선을 끄는 것을 목표로 한다는 점은 이제 독자들도 알 듯) 중급 디자이너라면 이런 질문을 해 보아야 한다.



왜 모든 사용성 평가는 성공할까?


물론 회사에서 돈 들여 만들었는데, 평가에서 성공하지 않는다면 매우 곤란하다. 만든 사람이 평가하는 구조, 혹은 만든 사람에게 고용된 사람이 평가를 하는 구조에서 난데없이 실패 평가를 내리기란 어렵다. 하지만 이런 정치적인 이유를 지적하려는 건 아니다. 그렇다면 왜 많은 사용성 평가가 성공적일까?


그 이유는, 대개의 사용성 평가에서 사람들은, 자신이 보려는 것을 보기 때문이다.


예를 들어 특정 화면에서 메뉴의 활용성을 높이기 위해 특정 메뉴를 더 잘 보이게 만들었고, 그것을 가지고 사용성 평가를 하면 당연히 메뉴가 잘 보이니까 활용성이 높아질 것이다. 바보가 아닌 다음에야, 특정 A 목적으로 개선을 하고, 그 A 를 가지고 테스트를 했다면 적든 많든 무언가 개선된 것 결과가 나올 확률이 99%인 것이고, 그렇게 나오지 않았다면 이상한 일이다.


그렇다면 이렇게 계속 A 목적에 이어, B를 위해, C를 위해 개선하고 평가하고 개선하고 평가한다면 마침내 우리 제품은 우주 극강의 편리한 제품이 되겠네? 왜냐하면 A 목적으로 개선했을 떄, 평가해 보면 성공적, 그 뒤 B 목적 개선 후 평가 결과도 성공적, C 목적 개선 결과도 성공적, 이렇게 계속 성공적이기만 할테니까 말이다. 


하지만 현실은 그렇지 않다. 왜냐하면 대개 B를 개선한 결과는 성공적이지만, 이렇게 할 경우 앞의 A를 훼손할 수가 있기 때문이다. 또 C를 개선해서 평가하면 분명 C는 개선된 걸로 나오지만 그렇게 함으로서 B나 A 가 훼손될 수 있기 때문이다. 이것이 늘 성공적인 사용성 평가 결과를 가지고도 전체적으로 제품의 사용성은 개선되지 않는 것에 대한 현실의 함정이다.


예를 들어 '햄버거 메뉴 논란'을 다시 생각해 보자. 햄버거 메뉴의 가장 치명적인 문제는 메뉴가 무엇이 있는지 보여주지 않기 때문에 메뉴를 찾고 메뉴를 네비게이션 하기 어렵다는 점이다. 


닐슨노만 그룹의 햄버거 메뉴에 대한 사용성 평가에서도, 데스크탑이나 모바일에서나 햄버거 스타일의 숨겨진 메뉴는 치명적인 사용성 문제를 갖고 있었다.

Hamburger Menus and Hidden Navigation Hurt UX Metrics


그렇다면 우리 모두 햄버거 메뉴를 버려야 하나?


사이트의 목적에 따라 다를 수는 있지만 어떤 사이트, 어떤 앱에서는 사람들이 다소 메뉴를 찾기 쉽지 않더라도 포기할 수 없는 시각적 아이덴터티가 있을 수 있다. 그런 이유로 햄버거를 도입한 사이트에서 '쉬운 메뉴 네비게이션'이란 목적으로 햄버거 메뉴를 없애고 모든 메뉴를 다 꺼내 놓은 개선을 한 뒤, 사용성 평가를 한다면, 그 평가 결과는 '매우 우수'하게 나올 것이다. 그러나, 그와 동시에 그 사이트의 개성 강한 시각적 아이덴터티를 잃게 될 수 있고, 이는 쉬운 메뉴 네비게이션에서 얻는 경영적 이익보다 훨씬 더 큰 손실로 이어질 수도 있다.

그러나 이러한 '손실'은 '쉬운 메뉴 네비게이션'을 측정하는 사용성 평가에서는 측정되지 않는다. 무엇을 얻었는지에 주목하고, 무엇을 잃었는지는 부각되지 않기 때문에, 모든 사용성 평가는 성공적인 결과로 끝난다.



그럼 어떻게 사용성 평가를 해야 하나?

UserFocus의 David Travis는 그의 글에서, 다음과 같은 네 가지 사용성 평가의 원칙을 이야기하고 있다.


4 forgotten principles of usability testing


- 테스트 사용자를 선택할 때, 데모그래픽이 아닌 행동 패턴에 따라 선택하라

- 사업에서, 또 사용자에게 가장 중요한 업무를 중심으로 테스트하라

- 사람들이 무어라 말하는지 듣지말고, 어떤 행동을 하는지에 집중하라

- 사용자에게 인터페이스를 다시 디자인해 보라고 요청하지 마라


특히 이 중에서, 두 번째와 세 번째가 지금 이 글에서 하고 싶은 이야기와 연결이 된다. 


중급 UX 디자이너는 사용성 평가에서 항상 우리 사업의 가장 중요한 부분, 또 우리 사용자에게 가장 중요한 부분을 테스트해야하고, 또 다른 목적의 사용성 평가를 하더라도, 위의 부분이 훼손되지 않았는지, 즉 C를 이루면서 A나 B가 훼손되지 않았는지 살펴 보아야 한다.

모든 것이 다 좋은 UX란 없고, 대개 무언가를 개선하면 무언가는 나빠지는 법이다. 특정한 비즈니스 목적, 사용자의 목표에 맞도록 최적화하는 것은 이러한 무언가를 서로 조절하는 일인데, 하나의 평가 결과를 보고, 그것만 생각해서는 중급 디자이너가 될 수 없다.


특히 특정 기능을 고쳤을 때 사람들이 '좋아요'라고 말하는 건 당연하기 때문에, 그들이 일상생활 속에서 이것을 썼더라면, 어떤 반응을 보였을 지를 아는 것이 중요한데, 그들의 행동을 유심히 관찰하는 것 만이 이것을 아는 방법이다. 얼마전에도 대대적인 개편을 한 UX가 사람들이 싫어하는 바람에 욕을 먹고 있다는 뉴스를 보면서, '왜 그 사람들은 사용자 평가를 안 했을까?'라고 궁금해한다면, 그건 초급 디자이너의 질문이다.


중급 디자이너라면 이렇게 물어야 한다. "분명 사용자 평가에서는 성공적으로 나왔을텐데 왜 실제 상황에서 사용자들은 최악의 평가를 내렸을까?" 


그리고 그에 대한 답은 이미 위에 썼다.


모든 사용성 평가는 성공하기 때문이다.

[참고##사용성 평가##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2012.03.26 20:24

Windows 8 Real User Test 파문

2012년 3월 7일에 Chris Pirillo라는 블로거는 새로 나온 Windows 8을 자기 아버지에게 써 보라고 하고, 비디오로 그 모습을 촬영했다. 마이크로소프트(MS)의 차세대 운영체제 ‘윈도우8′의 일반사용자용 미리보기 버전인 ‘컨슈머 프리뷰’가 스페인 현지시각으로 2월29일, ‘모바일 월드 콩그레스(MWC) 2012′ 현장에서 공개된지 8일 만이었다.




그 동영상은 많은 사람들에게 공감을 불러 일으켰고, 3월26일 현재, 63만 뷰 이상을 기록하고 있다.

[동영상] How Real People Will Use Windows 8

물론 70대 정도로 보이는 노인이 사용하는 것이라, 일반 사람들의 이야기가 아닐 것이라고 치부할 수는 있지만, 10년 이상 윈도즈를 사용해온 분이라는 주장으로 문제의 심각성을 부각시키려 했다. 많은 사람들이 새로운 시스템에 적응하는데 시간이 걸리는 것은 당연하다고 반박하자, Chris는 자기의 아버지에게 맥 OS X를 사용해 보라고 하고, 역시 촬영했다. (그동안 맥 OS는 전혀 사용한 경험이 없다고 한다) 맥을 큰 무리없이 사용하자, 좀 더 많은 사람들이 공감을 했고, 그래서 여기 저기서 따라 하는 비디오가 우후 죽순처럼 나왔다. 아버지, 할아버지, 할머니 등등... 기술 전문가라는 사람들까지도 공감을 했는지, '시작'버튼을 되살리기 위한 팁들이 블로그로 올라왔다. ('윈도우8'에서 '시작' 버튼 되살려보자) 물론 디바이스별 OS가 통합되어 가는 상황에서 마이크로소프트가 선택한 이유는 분명하다. 파괴적 혁신을 단행할만큼 절박한 것도 이해가 된다('시작' 없는 혁신의 시작, '윈도우8'). 그렇더라도 이렇게까지 일반 사용자들이 괴로워할 거라는 것을 알면서 출시를 해야할까?

일반 사용자라면, 편리하면 쓰면되고, 불편하면 안 쓰면 된다.
하지만 당신이 UI/UX 전문가라면, 어떻든 입장을 내 놓아야 한다. 비디오의 제작자들과 함께 마이크로소프트를 조롱하는 편에 설 것인가? 아니면 마이크로소프트의 정책적 결단을 지지하는 편에 설 것인가?

만약 아이폰 출시 전에, 아무 사용자에게 폰을 던져주고, 사진을 확대해 보라고 한다면, 그 사용자는 핀칭을 해 낼 수 있었을까? 지금은 너무나 당연해 보이지만, 쉽지 않았을 거라고 추측한다. 왜냐하면 현실 세계에서 우리는 한 번도 사진을 확대하기 위해 핀칭을 사용하지 않았다. (홈버튼) 더블탭 같은 것이 보통 사람들에게 거의 사용하지 말라는 것과 같은 UI인 것은 그 이전의 많은 user research 자료에서 반복하여 들어난 진실이다. 다만 애플 같은 경우, 자신들이 만든 것을 일반 사용자들이 마구잡이로 난도질하기 전에, 멋지게 사용하는 법을 비디오로 보여주고, 열성적인 지지자들이 그걸 퍼 나르고, 전체 대중이 따라하도록 하는 매우 효율적인 지식 전파 수단을 갖고 있기 때문에 웬만한 인터페이스들이 모두 처음부터 알았던 것처럼 느껴지는 것일 뿐이다.

애플의 교훈을 살펴보면, 마이크로소프트가 지금 해야할 일은 분명하다. 많은 사람들이 적응할 수 있는 방법을 주되, 가장 핵심적인 어려움에 대해서는, 그것이 정말 혁신에 필수적이라면(-이 부분은 Windows 8을 직접 써보지 않아서 확실하지 않다) 멋진 사람들이 멋지게 알리는 것이다. 정식 제품이 출시되고 많은 사람들이 구입을 시작할 때 쯤엔 '상식'이 되도록. 아울러 첫 눈에 모르더라도, 지속적으로 사용하면서 계속 문제가 되지는 않는지 점검하는 일이다.

놀라운 것은, 현재 몇몇 (미국의) UI 전문가들도 단지 이 비디오들만을 근거로, 마이크로소프트가 사용자를 무시하고 있다는 입장에 서고 있다는 점이다. 아마 한국의 많은 '전문가'들도 그럴 것이다. 가장 무서운 것은 얼치기 UI 전문가의 User Test일텐데도 말이다.

이 글의 요지는 Windows 8이 잘했다, 못했다는 평가가 아니라, 단순히 처음 사용자들이 어려워하는 것만으로 판단을 끝내서는 안된다는 것이다.

[참고##Windows##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 1
Ad Test...