brunch

You can make anything
by writing

C.S.Lewis

by Poem Kim Mar 13. 2022

휴리스틱 평가, NASA-TLX, USE

HMI/UX 검증과 개선에 필요한 평가 방법 맛보기

오늘의 이야기는 지난해 실무에서 UT(사용성 평가, Usability Test)를 해보면서 쓰기 시작했다(글을 쓰기 시작한 지 장장 네 달.....^^). 보통 대학생 수준에서 하나의 프로젝트를 기획하고 UX/UI 프로토타입을 설계하면 설계 단계에서 마무리되는 경우가 많다. 되게 열심히 만들었는데 이에 대한 검증이 없으니 사실상 다음 단계도 없이 거기서 끝나버린다는 게 개인적으로도 아쉬웠다. 학부 졸업 논문을 쓸 때도 음성 오류 발생시 가이드라인을 설계했는데 이후에 어떻게 평가를 하는 게 좋겠냐고 교수님께 넌지시 여쭤봤던 적이 있다. 그런 거는 대학원 가서 하면 된다고 하셔서 대학원에 갔는데... 진짜 가보니까 이번에는 앞단의 설계나 기획도 중요하지만 그보다도 평가를 통해 나온 결론을 정리하는 것이 꽤나 큰 일이었다.


부제에 HMI를 끼워넣은 이유는 모바일 앱보다 모빌리티 기반의 프로젝트 및 연구를 더 많이 경험한 탓에 자연스럽게 모바일 앱과는 사뭇 다른 지점들에 대한 고민이 필요했기 때문이다. 이 글에서는 '아 맞아, 이런 평가지표들도 활용할 수 있었지' 하고 정리해보려 한다.



개선하기 VS. 검증하기

검증과 개선은 함께하기도 하지만 평가 시점에 따라 개선점을 얻는 게 중요할 때가 있고, 수치로 검증 결과를 증명해내는 것이 중요할 때가 있다. 예를 들어 초기에 Low-Fidelity 프로토타입으로 빠르게 평가한다면 개선점 위주로 뽑아내는 게 더 적절한 평가 방식일 수 있다. 설계에 있어 잘못 생각했던 부분을 빠르게 짚어내면 설사 설계에 오류가 있더라도 충분히 개선해나갈 수 있다. 이때는 인터뷰와 같은 정성적 평가가 정량적 평가보다 더 큰 힘을 발휘하기도 한다. Low-Fidelity 프로토타입 평가 후 개선을 마치고 High-Fidelity 프로토타입이 완성되었다면 이제는 개선점보다 High-Fidelity 프로토타입의 사용성이 충분하다는 것을 입증하는 게 목표가 될 것이다.


Low-Fi vs. Hi-Fi


이 글에서는 사용자경험을 평가하는 3가지 방법을 소개하려 한다.

5가지를 소개하려 했으나 도무지 글이 끝나지 않아...UEQ와 SUS는 기회가 되면 소개하도록 하겠다.



1. 휴리스틱 평가

휴리스틱은 시간과 정보가 불충분할 때, 사람들이 자신의 감이나 경험에 의존하여 결정하는 심리적 현상을 말한다. 쉽게 말하면 휴리스틱은 어림짐작 내지는 직관적 판단이라는 의미다. 휴리스틱 평가는 전문가 평가에서 주로 사용되며, 전문가 3~5명 정도가 적절하다고 한다. 전문가의 자질만 보장된다면 시간과 비용을 아끼면서도 사용성 문제를 발견할 수 있다는 장점이 있다. 실제로 업무를 할 때 휴리스틱 평가를 한 후에 일반 사용자 평가를 따로 진행한 적이 있었다. 딱 맞는 전문가를 섭외하는 일은 어려웠지만 굵직한 문제를 빠르게 발견하기에는 효율적이었다.


휴리스틱 평가도 여러 가지가 존재하지만 가장 잘 알려진 것은 닐슨의 휴리스틱 평가다. 제이콥 닐슨(Jacob Nielson)의 휴리스틱 평가(Heuristic Evaluation)는 웹/앱의 사용성을 평가할 때 활용되어왔다.

https://www.nngroup.com/articles/ten-usability-heuristics/#poster

아마도 아래에 나열되는 10가지 평가 척도는 익숙한 분이 많을 거다. 사용자 인터페이스를 디자인할 때 자주 언급되는 내용으로 닐슨이 제안한 원칙이다. 프로덕트의 형태가 웹에서 앱으로, 그리고 우리가 앱이나 서비스를 사용하는 환경도 웨어러블 기기나 메타버스로 확장되기 때문에 반드시 이 10가지 항목이 맞아떨어지지 않을 때도 있다. 그럼에도 이 원칙들을 살펴보면 프로덕트의 도메인에 상관없이 꼭 한 번 생각해봐야 하는 항목들이다.


1. Visibility of System Status: 시스템의 현재 상태를 적절한 때에 피드백으로 제공해야 한다. 예를 들어 로딩바가 제대로 보인다면 사용자는 기다릴 수 있지만 로딩되고 있다는 상황을 확인할 수 없다면 계속 새로고침을 누르거나 이탈하게 된다.

2. Match Between System and the Real World: 현실세계와 부합하는 시스템을 제공해야 사용자가 이해할 수 있다. UI나 색상, 언어(UX writing) 등 곳곳의 요소가 사용자가 곧바로 이해하고 추측할 수 있는 익숙한 것이어야 한다. 한때 아이폰의 앱 아이콘을 떠올려보면, 스큐어모피즘(skeuomorphism)을 통해 카메라 아이콘이나 휴지통을 현실의 카메라와 휴지통과 매우 유사하게 표현한 바 있다. 지금은 그렇게 리얼하게 표현하지 않아도 사용자가 앱이나 웹에 굉장히 친숙하지만 아이콘이나 일러스트 등을 활용할 때도 이 원칙은 고려할 필요가 있다.

3. User Control and Freedom: 사용자에게 적절한 통제권을 부여해야 한다. 만약 실수로 버튼을 잘못 눌렀을 때 뒤로 가기 버튼이나 실행 취소 버튼 등을 통해 실수를 쉽게 되돌릴 수 있어야 한다.

4. Consistency and Standards: 시스템의 일관성과 표준성을 높이는 것은 매우 중요한 일이다. 그렇기 때문에 애플이나 구글 등 회사에서 디자인 시스템에 대한 가이드라인을 연구하기도 한다. 어떤 시스템을 사용하더라도 일관성이 있으면 사용자가 그 시스템을 잘 몰라도 어렵지 않게 사용할 수 있다.

5. Error Prevention: 오류를 방지하도록 설계한다. 3번은 이미 발생한 실수를 되돌린다면 5번은 오류가 발생하지 않도록 미연에 방지하는 것이다. 오류는 행위를 수행하다 부주의로 인해 발생하는 slip과 시스템 작동 방식을 잘못 이해했을 때 나타나는 mistake 2가지로 나뉜다. 사용자가 수행할 수 있는 영역을 제한하거나 경고 메시지 등을 통해 미리 오류를 차단하는 노력이 필요하다.

6. Recognition Rather than Recall: 사용자가 적은 인지적 노력으로도 시스템을 사용할 수 있어야 한다. 사용자가 별도의 학습이나 기억을 하지 않아도 '아, 이 빈칸에 주소를 적으면 되는구나'하고 기능을 바로 이해할 수 있도록 시스템을 설계해야 한다.

7. Flexibility and Efficiency of Use: 시스템의 사용자 수준은 다를 수 있다. 초보와 전문가는 시스템을 사용할 때 원하는 것이 다르다. 전문가는 단축키로도 금방 금방 기능을 찾아쓸 수 있지만 초보는 어디에 어떤 기능이 있는지 모를 것이다. 사용자 모두를 포괄할 수 있도록 커스텀 기능 등을 통해 시스템의 유연함을 갖춰야 한다.

8. Aesthetic and Minimalist Design: 불필요한 요소는 가급적 제외하고 간결한 디자인을 제공해야 한다.  

9. Recognize, Diagonise, and Recover from Errors: 사용자가 스스로 오류를 인식하고 회복할 수 있도록 해야 한다. 오류 메시지를 제공할 때도 오류의 원인이 무엇인지, 오류를 해결하려면 사용자가 무엇을 해야하는지까지 명확하게 제공할 때 유의미한 오류 메시지가 될 수 있다.

10. Help and Documentation: 도움말은 언제든 접근 가능해야 하고 내용 면에서도 사용자의 학습을 도울 수 있어야 한다. 앱을 처음 다운받았을 때 종종 까만 화면 위에 화살표로 가이드를 제공받은 경험이 있을 것이다. 이런 방식이라면 사용자가 따로 도움말을 찾아보지 않아도 시스템을 학습하는 데 큰 도움이 되기도 한다.


2. NASA-TLX

NASA-TLX? 모바일이나 웹 기반의 프로덕트를 평가할 때는 들어본 적이 없을 것이다. 그러나 주행이라는 맥락에서 전방 주시와 주의 집중이 필요한 차량 내 인터페이스와 관련된 연구에서는 심심찮게 등장하는 평가 방법이다. 예를 들어 AR 기반의 HUD(Head-up Display)에서 정보를 확인하며 주행할 때 인지 부하가 없는지, 또는 인포테인먼트를 즐기다가도 TOR(Take Over Request, 제어권 전환) 상황을 맞닥뜨렸을 때 인지 부하 없이 태스크를 수행할 수 있는지 알아보는 실험/연구를 할 때 사용된다.


NASA-TLX와 같은 평가가 필요한 복잡한 환경(조종석)

더 자세하게 설명해보자면,  NASA-TLX다양한 상황에서 시스템 또는 작업의 성능과 효율성을 평가하기 위한 지표개인이나 조직에 걸리는 인지 부하를 정량적으로 평가한다. 여기서 NASA는 흔히 떠올리는 그 NASA가 맞고, NASA의 아메스 연구센터의 인간공학 연구그룹에서 개발한 작업부하 평가 방법이기 때문에 앞에 NASA가 붙은 것이다. TLX는 Task Load Index로 작업부하 척도를 의미한다.


NASA-TLX는 여러 작업부하 평가 도구 중에 정신적 작업부하를 주관적으로 평가하는 도구다. 뇌파(EEG), 심전도(ECG), 호흡수 등 객관적으로 정신적 작업부하를 평가하는 방식과 비교하면 이해하기 쉽다. NASA-TLX의 평가 방법은 시뮬레이션을 수행한 후 1분 이내에 정량적인 평가를 진행하는 것이다. 평가 차원은 총 6가지로 구성되어있으며, 각 차원의 점수가 높을수록 부정적인 결과를 나타낸다. (필요에 따라 가중치를 사용하기도 하지만 평가 차원별 가중치는 배제한 Raw-TLX 버전도 많이 사용되고 있고, 평가 차원 역시 연구 목적에 따라 일부만 쓰니 가중치에 대한 설명은 생략하겠다.)


NASA-TLX의 6가지 차원은 다음과 같다.

1. 정신적 요구(Mental Demand): 얼마나 정신적 부담(탐색, 기억, 사고, 연산 등)을 느꼈습니까?

2. 신체적 요구(Physical Demand): 얼마나 신체적 부담(조작, 힘, 사용, 기동 등)을 느꼈습니까?

3. 시간적 요구(Temporal Demand): 얼마나 서둘러서 작업을 해야했습니까? 얼마나 시간적 압박을 느꼈습니까?

4. 수행도(Performance): 얼마나 성공적으로 과제를 수행할 수 있었습니까?

5. 노력(Effort): 자신의 수준을 성취하기 위해 얼마나 열심히 과제를 수행했습니까?

6. 좌절(Frustration): 작업 중에 얼마나 성가시거나 짜증이 났고 스트레스를 받았습니까?


NASA-TLX 평가 설문지 | Evaluation of Electronic Formats of the NASA Task Load Index(2011)



3. USE

USE는 'Measuring Usability with the USE Questionnaire'라는 글에서 연구자가 제시한 것으로 4가지 항목(Usefulness, Ease of Use, Ease of Learning, Satisfaction)으로 구성되어있다. 약 1360회 이상 인용되었으며, UX 관련 논문에서 평가 방식으로 심심찮게 사용된 것을 발견할 수 있다.


연구자는 4가지 항목 아래 7점 리커트 척도로 측정할 수 있는 세부문항들을 설계하였다. 원문에는 다음의 이미지와 같이 4가지 항목이 정리되어있으며, 이탈릭체로 표시된 세부문항은 상대적으로 덜 영향을 미치는 항목으로 나타났다.

Measuring usability with the use questionnaire12

따라서 이탈릭체를 제외하고 Usefulness, Ease of Use, Ease of Learning, Satisfaction에 맞는 문항을 정리해보면 다음과 같다.


Usefulness(유용성)

It helps me be more effective.

It helps me be more productive.

It is useful.

It gives me more control over the activities in my life.

It makes the things I want to accomplish easier to get done.

Ease of Use(사용 용이성)

It is easy to use.

It is simple to use.

It is user friendly.

It requires the fewest steps possible to accomplish what I want to do it.

Ease of Learning(학습 용이성)

I learned to use it quickly.

I easily remember how to use it.

It is easy to learn to use it.

Satisfaction(만족도)

I am satisfied with it.

I would recommend it to a friend.

It is fun to use.

It works the way I want it to work.




학문의 영역과 실무에서 제품/서비스/실험을 위해 여러 테스트를 해보니 매번 평가의 목적과 범위에 따라 방법이 달랐고, 어찌 보면 다른 게 당연하다는 것을 깨달았다. 평가 지표들을 통해 나온 수치만을 100% 맹신해서는 안된다. 오히려 왜 그렇게 평가되었는지 함께 파악하는 것이 중요하다.


앞으로도 UX를 평가하고 검증할 수 있는 다양한 방법을 살펴보려 한다.




출처

10 Usability Heuristics for User Interface Design (https://www.nngroup.com/articles/ten-usability-heuristics/#poster)

Trujillo, A. C. (2011). Evaluation of electronic formats of the NASA task load index. National Aeronautics and Space Administration, Langley Research Center. (https://core.ac.uk/download/pdf/10561741.pdf)

Lund, A. M. (2001). Measuring usability with the use questionnaire12. Usability interface, 8(2), 3-6.(https://www.researchgate.net/profile/Arnold-Lund/publication/230786746_Measuring_Usability_with_the_USE_Questionnaire/links/56e5a90e08ae98445c21561c/Measuring-Usability-with-the-USE-Questionnaire.pdf)



이미지 출처

The Differences Between Low Fidelity vs. High Fidelity Prototyping (https://www.protopie.io/blog/low-fidelity-vs-high-fidelity-prototyping)

Study of NASA-TLX and Eye Blink Rates Both in Flight Simulator and Flight Test (https://link.springer.com/chapter/10.1007/978-3-030-22507-0_28)


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari