멀고도 험하고, 알다가도 모르겠다.
팀에 신규 디자이너분이 새로 합류했다.
제품, 도메인, 사용자에 대해 이해하기 위한 온보딩 테스크로
1주차 - 제로베이스 상태에서, 사용자라고 생각하고 제품을 써보기를 드렸다.
1주차가 끝나갈 때 즘, 팀원들과함께 진행하신 테스크(제품을 써보고 느낀점과 피드백)을
공유하는 자리를 가졌다.
새로 합류하신 디자이너분이 피드백해 주신 내용들, 그리고 그 이전에 팀에 합류하셨던 PO님도
처음 오시자마자 제로베이스에서 제품을 써보시고 피드백을 주셨었던 터라
피드백 주셨던 많은 내용들이 어느 정도 예상됐고, 속으로 ‘아 저건 저래서 지금 저 상태인데..’하며
그간의 디자인&개발 히스토리를 속으로 되내이고 있었다.
하지만 그게 뭐가 중요한가, 결국 사용자들은 화면에 보이는 것들로 작동해 보고 제품을 인식하는 걸.
그렇게 피드백을 잘 듣고 있다가
알파업셀의 <상품추천설정> 기능에 관한 피드백을 듣는데,
보자마자 뭘 해야 할지 모르겠고
뭘 해보려 해도 어려웠다.
그러다 보니 더 뭔갈 설정하고 싶은 마음이 들지 않았다.
이탈하게 되었다.
라는 얘기를 해주셨는데, 이 부분은 다른 부분에 비해 좀 신선하고 충격으로 다가오긴 했다.
이유는 해당 피쳐는 비교적 최근에 UX 개선을 한 상태였기 때문이다.
(완벽해!라고 할 만큼 개선하진 못했지만, 나름 이 정도면 이전에 비해서 충분히 쓸 만은 하겠군~ 생각했었다.)
해당 개선 스프린트를 마쳤을 때
나름 잘 개선됐다고 생각(착오)했었고, 팀 내부에서도 긍정적인 분위기와 반응이었기 때문에
더더욱 착오를 했었던걸 지도 모르겠다.
‘개선해 뒀으니, 이 정도면 사용자들이 쓰는데 이전보다 훨씬 더 편해졌겠지’가 정확한 속마음이었던 것 같다.
그 개선 이후 또 급하게 다음 스프린트를 진행하다 보니 실제로 사용자들이 어떻게 쓰는지, 진짜 이제
해당 기능을 쓸 때 불편함은 없는지? 이런 것에 관심 가지지 못했다.
그런 찰나에 완전히 제로베이스의 입장에서 못쓰겠다고 할 정도로 냉철한 피드백을 들으니 ‘아!’ 싶었던 것.
최근 알게 된 개념 중 ‘지식의 저주’라는 게 있다.
이건 어떤 개인이 다른 사람들과 의사소통을 할 때 다른 사람도 이해할 수 있는 배경을 가지고 있다고
자신도 모르게 추측하여 발생하는 인식적 편견이다.
내 상황을 예로 들면 말하면,
“내가 아는 걸, 사용자들도 어느 정도는 알겠지”하는 것들이다.
알파업셀의 <상품 추천 설정>은
상품 추천 위젯에, 직접 원하는 상품을 추천하는 기능이라고 말할 수 있는데
이 기능을 더 쉽게 만들기 위해 내가 뭔갈 막~만들었는데
어쩌면 사용자들은 애초에 '위젯'이라는 게 정확히 뭔지도 모를 수 있다는 것이다.
‘당연히 이 정도는 알겠지’라며 무의식적으로 생각하고 설계에 임했는데
사용자들은 당연히 이 정도도 몰랐던 것.
그런 오류들이 이 <상품 추천 설정> 기능 개선을 했을 때 꽤 많이 있었다.
돌이켜보면, 이런 오류들이 얼마나 제품 여기저기에 덕지덕지 붙어있을까..
생각만 해도 끔찍하다. 시간을 되돌릴 수 있다면 좋겠지만 그럴 순 없으니
PO님도 얘기하시길, 아무리 제로베이스의 사고를 가지고 제품을 설계하려 해도
메이커가 되고, 히스토리를 알고, 레거시들이 내 머릿속에 덕지덕지 붙으면 어쩔 수 없이
인간이라면 제로베이스사고가 완벽히 될 수는 없다.
그래서 우리가 신규 디자이너님이 제품을 써보고 얘기하는 걸 들어보며 정신을 차렸던 것처럼
UT를 진행하고, 사용자들이 어떻게 쓰는지 보고해야 한다는 것이었다.
( = 완전히 제로베이스가 되기 힘드니, 진짜 제로베이스인 사용자를 만나라)
맞는 말이다.
나는 아무리 제로베이스로 사고하려 해도, 마치 카레를 많이 먹어서 카레색이 배어있는 흰 그릇처럼
내 뇌는 알파업셀(제품)에 대한 지식들이 덕지덕지 붙어있다.
새로운 입사자들이 들어왔을 때, 혹은 아무것도 모르는 지인에게
물어보며 제품에 대해서, 제품의 특정 기능에 대해서 얘기해봐야 할 것이고
좀 더 숙련도가 생겼을 때 (어떻게 사용자에게 냉철한 피드백을 이끌고, 어떻게 테스트시켜야 효과적인지)
진짜 UT도 좀 더 적극적으로 진행해보고 싶었다. (제대로 된 UT도 리소스니까, 본격적으로 진행한다고 하기 전에 리소스가 덜 드는 방식으로 약식으로라도 사전연습이 필요할 것이다.)
디자이너는 사용자가 되려고 노력해야 한다.
실무를 경험하다 보면 느끼는 게 UT처럼 테스트하고, 사용자 반응을 보고 한다는 게
말처럼 쉽지 않고 그만큼의 시간이 허락하지 않는다.
그래서 디자이너 (혹은 PM,PO)이 끊임없이 사용자입장이려고 노력해야 한다.
완벽하진 못하더라도 근처엔 갈 수 있으니
디자이너가 사용자의 입장을 고려하지 않고, 사용자에 몰입(빙의)해서 제품을 설계하지 않는 순간,
기술과 레거시에 타협하고 디자이너만의 사고(이 정도면 쓸만하겠지)에 갇히면
그 제품이 개판 나는 건 시간문제다. (그렇다 부끄럽지만 내 얘기였다.)
만드는 사람이 얼마나 힘들었는지
어떤 히스토리가 있었는지
이 기능이 얼마나 구현하기 힘들었는지
.. 등등 뭐 이런 건 사용자입장에선 관심이 전혀 없다.
그저 사용자들은 이 제품에
어떤 기능이 있고
그 기능을 하려면 어떻게 해야 하는지
이것들만 관심 있을 뿐..
유명한 일화처럼
자판기에서는 내가 원하는 음료가 빠르게 나오면 된다.
자판기 안에서는 뭔 일이 일어나든 상관없다.
(심지어 자동이 아니라 직접 사람이 일일이 음료를 주는 것 일지라도!)