brunch

You can make anything
by writing

C.S.Lewis

by Jyoji Jul 10. 2024

사용자를 '진짜' 위한 제품을 만드는 과정

멀고도 험하고, 알다가도 모르겠다.

팀에 신규 디자이너분이 새로 합류했다.

제품, 도메인, 사용자에 대해 이해하기 위한 온보딩 테스크로

1주차 - 제로베이스 상태에서, 사용자라고 생각하고 제품을 써보기드렸다.


1주차가 끝나갈 때 즘, 팀원들과함께 진행하신 테스크(제품을 써보고 느낀점과 피드백)을

공유하는 자리를 가졌다.




제품 피드백? 웬만한 건 예상했었었다


새로 합류하신 디자이너분이 피드백해 주신 내용들, 그리고 그 이전에 팀에 합류하셨던 PO님도 

처음 오시자마자 제로베이스에서 제품을 써보시고 피드백을 주셨었던 터라

피드백 주셨던 많은 내용들이 어느 정도 예상됐고, 속으로 ‘아 저건 저래서 지금 저 상태인데..’하며

그간의 디자인&개발 히스토리를 속으로 되내이고 있었다.

하지만 그게 뭐가 중요한가, 결국 사용자들은 화면에 보이는 것들로 작동해 보고 제품을 인식하는 걸.

그렇게 피드백을 잘 듣고 있다가

알파업셀의 <상품추천설정> 기능에 관한 피드백을 듣는데,   


보자마자 뭘 해야 할지 모르겠고

뭘 해보려 해도 어려웠다.

그러다 보니 더 뭔갈 설정하고 싶은 마음이 들지 않았다.

이탈하게 되었다.


라는 얘기를 해주셨는데, 이 부분은 다른 부분에 비해 좀 신선하고 충격으로 다가오긴 했다.

이유는 해당 피쳐는 비교적 최근에 UX 개선을 한 상태였기 때문이다.

(완벽해!라고 할 만큼 개선하진 못했지만, 나름 이 정도면 이전에 비해서 충분히 쓸 만은 하겠군~ 생각했었다.)

해당 개선 스프린트를 마쳤을 때

나름 잘 개선됐다고 생각(착오)했었고, 팀 내부에서도 긍정적인 분위기와 반응이었기 때문에

더더욱 착오를 했었던걸 지도 모르겠다.

‘개선해 뒀으니, 이 정도면 사용자들이 쓰는데 이전보다 훨씬 더 편해졌겠지’가 정확한 속마음이었던 것 같다.

그 개선 이후 또 급하게 다음 스프린트를 진행하다 보니 실제로 사용자들이 어떻게 쓰는지, 진짜 이제

해당 기능을 쓸 때 불편함은 없는지? 이런 것에 관심 가지지 못했다.

그런 찰나에 완전히 제로베이스의 입장에서 못쓰겠다고 할 정도로 냉철한 피드백을 들으니 ‘아!’ 싶었던 것.




우리는 사용자가 될 수 없다.


최근 알게 된 개념 중 ‘지식의 저주’라는 게 있다.

이건 어떤 개인이 다른 사람들과 의사소통을 할 때 다른 사람도 이해할 수 있는 배경을 가지고 있다고

자신도 모르게 추측하여 발생하는 인식적 편견이다.

내 상황을 예로 들면 말하면,

“내가 아는 걸, 사용자들도 어느 정도는 알겠지”하는 것들이다.


알파업셀의 <상품 추천 설정>은

상품 추천 위젯에, 직접 원하는 상품을 추천하는 기능이라고 말할 수 있는데

이 기능을 더 쉽게 만들기 위해 내가 뭔갈 막~만들었는데

어쩌면 사용자들은 애초에 '위젯'이라는 게 정확히 뭔지도 모를 수 있다는 것이다.

‘당연히 이 정도는 알겠지’라며 무의식적으로 생각하고 설계에 임했는데

사용자들은 당연히 이 정도도 몰랐던 것.

그런 오류들이 이 <상품 추천 설정> 기능 개선을 했을 때 꽤 많이 있었다.

돌이켜보면, 이런 오류들이 얼마나 제품 여기저기에 덕지덕지 붙어있을까..

생각만 해도 끔찍하다. 시간을 되돌릴 수 있다면 좋겠지만 그럴 순 없으니




그럼 어떻게?


PO님도 얘기하시길, 아무리 제로베이스의 사고를 가지고 제품을 설계하려 해도

메이커가 되고, 히스토리를 알고, 레거시들이 내 머릿속에 덕지덕지 붙으면 어쩔 수 없이

인간이라면 제로베이스사고가 완벽히 될 수는 없다.

그래서 우리가 신규 디자이너님이 제품을 써보고 얘기하는 걸 들어보며 정신을 차렸던 것처럼

UT를 진행하고, 사용자들이 어떻게 쓰는지 보고해야 한다는 것이었다.

( = 완전히 제로베이스가 되기 힘드니, 진짜 제로베이스인 사용자를 만나라)


맞는 말이다.

나는 아무리 제로베이스로 사고하려 해도, 마치 카레를 많이 먹어서 카레색이 배어있는 흰 그릇처럼

내 뇌는 알파업셀(제품)에 대한 지식들이 덕지덕지 붙어있다.

새로운 입사자들이 들어왔을 때, 혹은 아무것도 모르는 지인에게

물어보며 제품에 대해서, 제품의 특정 기능에 대해서 얘기해봐야 할 것이고

좀 더 숙련도가 생겼을 때 (어떻게 사용자에게 냉철한 피드백을 이끌고, 어떻게 테스트시켜야 효과적인지)

진짜 UT도 좀 더 적극적으로 진행해보고 싶었다. (제대로 된 UT도 리소스니까, 본격적으로 진행한다고 하기 전에 리소스가 덜 드는 방식으로 약식으로라도 사전연습이 필요할 것이다.)




그럼에도 불구하고


디자이너는 사용자가 되려고 노력해야 한다.

실무를 경험하다 보면 느끼는 게 UT처럼 테스트하고, 사용자 반응을 보고 한다는 게

말처럼 쉽지 않고 그만큼의 시간이 허락하지 않는다.

그래서 디자이너 (혹은 PM,PO)이 끊임없이 사용자입장이려고 노력해야 한다. 

완벽하진 못하더라도 근처엔 갈 수 있으니

디자이너가 사용자의 입장을 고려하지 않고, 사용자에 몰입(빙의)해서 제품을 설계하지 않는 순간,

기술과 레거시에 타협하고 디자이너만의 사고(이 정도면 쓸만하겠지)에 갇히면

그 제품이 개판 나는 건 시간문제다. (그렇다 부끄럽지만 내 얘기였다.)   


만드는 사람이 얼마나 힘들었는지

어떤 히스토리가 있었는지

이 기능이 얼마나 구현하기 힘들었는지

.. 등등 뭐 이런 건 사용자입장에선 관심이 전혀 없다.


그저 사용자들은 이 제품에   

어떤 기능이 있고

그 기능을 하려면 어떻게 해야 하는지

이것들만 관심 있을 뿐..



유명한 일화처럼

자판기에서는 내가 원하는 음료가 빠르게 나오면 된다.

자판기 안에서는 뭔 일이 일어나든 상관없다. 

(심지어 자동이 아니라 직접 사람이 일일이 음료를 주는 것 일지라도!)


작가의 이전글 효과적으로 서비스의 문제와 개선점을 파악하는 방법
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari