프레임웍 단계에서 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를 진행하기 어려운 상황이라면 디자이너가 스스로 프레임웍이 잘 설계되었는지 판단하기 위한 용도로써 플로우를 한눈에 볼 수 있는 프로토타입을 만들어 보는 것을 추천합니다.

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