Protopie로 간단한 UT 하기
Prototype은 UT에 활용되어야 그 가치가 있다.
프로토타이핑에 관심을 갖게 된 지 약 2년이 되었다. 처음 시작한 툴은 Invisionapp이었고 엄청나게 쉬운 사용법에 Flow 중간에도 URL을 이용해서 공유도 쉽게 할 수 있었기에 User Story 단위로 개발하는 Agile 팀에서 굉장히 유용했다. 하지만 사람의 욕심은 끝이 없고 같은 실수를 반복하지 않기 위해 우리는 매주 회고를 합니다..(?)가 아니라. 디자인 작업을 하다 보면 더욱 상세한 인터랙션을 구현해보고 싶은 욕심이 생기기 마련인데 그러다 보니 더 풍부한 표현력을 가진 툴을 찾게 되고 Origami, Flinto for MAC, Protopie를 거쳐 지금은 주로 Framer를 쓰고 있다. (빈도로 따지면 Protopie는 업무에서 주로 쓰고 Framer는 공부를 위해 쓰는 듯.. 속도가 안나...)
디자이너가 왜 프로토타입을 만드는지에 대해서는 많은 글들이 있다. 몇 가지 예를 들면 개발에 들어가기 전에 실제 디자인 Flow를 검증한다든지, 어떤 디자인이 더 나은지에 대해 의사결정을 받든지, 사용자에게 보여주고 빠른 피드백을 받는다든지... 결국, 프로토타입은 '누구에게 보여주기 위해' 만드는 것이다. 의사결정자든 사용자든 개발자든..
하지만 '보여주기'만을 위해서라면 파워포인트나 조금 더 복잡한 애니메이션이라면 애프터이펙트로도 충분하다. 이런 단순한 목적이라면 왜 디자이너들은 1년에도 몇 번씩 새롭게 업데이트되는 툴들을 학습하기 위해 머리를 싸매야 할까?
프로토타입은 사용자 검증에 활용되어야 한다.
사실 실제로 동작하는 소프트웨어를 만들어 사용자 테스트를 하려면 개발자에게 맡기는 것이 훨씬 빠르고 안정적으로 잘 만들어진다. 그러나 개발자와 디자이너가 함께 일하는 환경(특히나 상호 협조적인;;)에 있지 않은 디자이너라면 프로토타입을 통한 사용자 검증은 개발단계로 넘어가기 위해 반드시 거쳐야 할 과정이다. 반복적인 사용자 테스트를 통해 검증된 가설과 컨셉은 이해관계자들을 설득시키기 위한 기획서에 힘을 실어주고 개발 자원을 아낄 수 있는(지극히 교과서적인 표현이긴 하지만) 장점이 있기 때문이다.
그래서 Framer는 Hotjar나 Firebase를 연결하여 사용성 테스트를 하려는 시도가 있어왔다. 특히 Hotjar와 연결할 경우 Heatmap까지 볼 수 있다는 장점이 있다.(.. 지만 시선 추적 연구를 해본 입장에서 Heatmap은 그다지 쓸모가...)
그러나 이 정도의 기능이 필요 없고 단계별로 시간이 얼마 정도 걸렸는지 확인하기 위한 용도로는 Protopie를 활용할 수 있겠다고 판단이 되고, 회사에서 쓰는 툴도 그것이라 이번에 한 번 간단하게 시도해보았다. (절대 코드에 약해서 Framer를 안 쓴 것이 아니다;;;)
Protopie로 간단한 UT 하기
Protopie로 시간 체크를 하기 위해 다음과 같이 준비했다.
1) 먼저 테스트할 프로토타입(이하 A)과 시간을 체크할 파일(이하 B) 두 개를 준비한다.
2) 각각 인터랙션의 트리거 컴포넌트에서 메시지를 send 하게 만든다.
3) Afftereffect에서 Timecode를 만들어(넉넉하게 한 5~10분 정도) B에 인터랙션 트리거만큼 삽입한다.
4) B에서 신호를 Receive 하여 각 비디오 파일이 플레이 되게 만든다.
시간 체크를 위해 Timecode 비디오파일을 인터랙션 만큼 삽입하였다. 오른쪽은 시간이 찍힌 결과시간 체크의 장단점
이렇게 시간 체크를 하니 다음과 같은 부분이 장점이라 생각했다.
1. 비디오 분석 시간이 줄어든다.
이전까지는 UT 후 시간 체크를 위해 Quicktime 같은 툴을 이용하여 UT 과정을 녹화, 그 비디오를 다시 돌려 보면서 시간을 체크해야 했지만 Time stamp를 통해 시간 체크하는 것이 정확하고 수월하게 되었다. (다시 엑셀에 옮겨 적어야 하는 불편은 있지만)
2. 각각 단계별로 시간이 유별나게 많이 걸린 부분을 사용성 개선 포인트로 추론할 수 있다.
실제로 테스트한 프로토타입에서 Step 4가 다른 단계에 비해 시간이 많이 걸렸다. 사후 인터뷰를 통해 그 이유에 대해 파악하고 개선할 포인트를 찾을 수 있는 계기가 되었다.
3. 일단 숫자를 드리면 윗 분(?)들은 행복해하신다.
이전까지는 프로토타입으로 사용 시나리오에 대해 설명하는 것으로 그쳤다면, 사용자 검증 계획과 그 테스트 결과, 그리고 개선된 디자인에 대한 줄어든 시간을 '숫자'로 제공하니 훨씬 설득이 잘 되었다. 팀원들에게 우리 디자인이 올바르게 가고 있다는 객관적인 데이터를 기반으로 확신을 주는 것도 매우 중요한 효과 중의 하나였다.
단점은, 프로토타입의 복잡성이 높아지면 모든 트리거에 메시지를 받고 주는 것이 노가다로 느껴질 만큼 불가능에 가까우며(시간이 매우 많이 걸리고, 수정하기도 어려워진다.) 사용 시나리오가 일방향일때만 이런 Time check가 가능하다는 것이었다.
결론
처음 이직을 준비할 때 한 회사에서는 이렇게 말했다. '우리 회사는 한 화면에서 컴포넌트를 쪼개고 쪼갠 인터랙션의 끝까지 고민한다.'고. 접근 방법 자체는 존중받아야 하지만, 그 일은 인터랙션 디자이너보다 모션 디자이너에 가깝다고 생각한다고 말했다. (그래서 결국 떨어졌다;;) 또한 디자이너는 다소 포괄적인 의미로 '문제를 해결하는 사람'이다. 결국 문제는 비즈니스와 사용자의 Pain Point와 맞닿아있어야 한다고 생각한다. 그 목적에 부합하지 않는 프로토타입은 결국 디자이너의 욕심을 투영한 결과물밖에 되지 않는다고 생각한다.
그렇기에 더욱 프로토타입은 반드시 사용자 검증에 활용되어야 한다. 김수 대표님이 이 글을 보시면 나중 업데이트 때 이런 Time check나 관찰자가 프로토타입을 기준으로 간단한 체크와 메모를 할 수 있는 기능을 넣어주시면 우리 같은 UX 디자이너들이 프로토타입을 더욱 풍부하게 활용할 수 있을 것이란 제언을 드리고 싶다. (저번에 인터뷰할 때도 말씀드린 것 같긴 하다.)
P.S 내가 하고 있는 프로젝트를 전부 공개할 수 있었다면 더 쉽게 설명할 수 있었을 텐데 그러지 못함이 아쉽다.
