공급자 관점에서 탈피하기
평범한 스타트업 일상
우리는 공급자의 관점에서 제품을 만들고 있어요.
사용자가 원하는 제품을 만들어야 한다.
사용자가 사용하지 않는 제품은 시장에서 외면 받기 쉽다.
창업 전선에 뛰어들어 고군분투하고 있거나 제품을 만드는 사람들이라면 한 번쯤 이런 이야기를 들어보았을 거예요. 하지만 실행해보려고 해도 쉽지 않아요. 일단은 우리가 할 수 있는 것을 토대로 제품을 구현하는 것이 보다 적은 리소스임에도 빠르고 쉽게 무언가를 만들 수 있고, 이렇게 무언가를 만들고 있다는 심리적 안정감을 주고 있기 때문이지 않을까 하는 생각을 해요. 그래서 우리는 우리도 모르게 점점 사용자의 관점보다는 공급자의 관점에서 제품을 만들고 있어요.
이번 글은 어려운 상황임에도 공급자 관점에서 벗어나 사용자 관점에서 제품을 만들어야 하는 이유를 소개해요. 현재 조직에서 실제로 경험하고 느낀 점을 위주로 작성하다 보니 개인적인 관점이 다소 많이 들어가 있을 수 있어요.
공급자 관점과 사용자 관점
공급자 관점의 제품 만들기는 우리가 만들 수 있거나, 우리가 전달하고 싶은 가치를 중심으로 제품을 구성하는 것을 말해요. 가령 우리가 만든 제품의 기능의 얼마나 좋은 것인지 설명하거나, 높은 수준으로 구현한 제품이면 당연히 사용자에게 좋을 것으로 생각하고 그런 기능을 우선적으로 사용자가 써 볼 수 있게 만드는 것이에요.
사용자 관점의 제품 만들기는 사용자가 쉽게 인지하고, 쉽게 사용할 수 있도록 만들며 또는 높은 수준이 아닐지라도 사용자가 직관적이고 적은 비용으로도 문제를 해결할 수 있도록 만드는 것을 말해요. 이러한 예시로는 “A를 하기 위해서 B를 입력해 주세요”라는 표현으로 사용자가 무엇을 위해 어떤 행동을 해야 할지 알려준다거나, 사용자가 헷갈리지 않도록 CTA명을 다듬는 것들을 말해요. 또한 다크패턴을 사용하지 않도록 세심하게 주의를 기울이는 것도 사용자 관점의 제품 만들기로 볼 수 있어요.
저는 플랫폼 성격의 팀에서 일하고 있어요. 인스파이어드로 잘 알려진 마티 케이건의 또 다른 서적, 임파워드에서는 플랫폼팀을 아래와 같이 설명해요.
플랫폼팀은 공통적으로 여러 팀에 영향을 주는데, 한번 구현하여 여러 곳에서 사용할 수 있는 공통 서비스를 제공하기 때문이다. 이러한 예는 다음과 같다.
– 인증 또는 권한과 같은 공유 서비스를 담당하는 플랫폼팀
– 재사용이 가능한 인터페이스 구성 요소 라이브러리를 유지 관리하는 플랫폼팀
– 개발자에게 테스트 및 릴리스 자동화를 위한 도구를 제공하는 플랫폼팀
(중략)
최종 고객은 물론 경영진 및 이해관계자도, 플랫폼팀이 수행하는 작업을 직접 보지 못할 수 있지만, 이런 팀이 중요하지 않다고도 생각하지 않는다.
실제로 업계 최고의 제품 조직에서는 회사의 최고 엔지니어들이 공통의 영향력과 중요성 때문에 플랫폼팀에서 일하고 있다. 소규모 기업에서는 단일 플랫폼팀이 전체 플랫폼을 제공할 수 있다. 업계 상위의 규모 있는 IT 회사에서는 많게는 제품팀의 절반에 달하는 팀이 플랫폼팀이다. 더욱이, 플랫폼은 경험팀의 인지 부하를 감소시킨다.
덕분에 경험팀은 플랫폼 서비스의 구현 방법을 이해할 필요 없이 사용할 수 있다. 복잡한 기술에 시간을 쏟는 대신, 해결하려는 고객이나 비즈니스 문제에 에너지를 집중할 수 있다.
즉 플랫폼 팀이 만드는 제품은 큰 제품의 근간이 되는 제품이자, 조직 내 다양한 사일로와 팀들이 필요할 때 쉽게 우리 팀이 만든 제품을 가져다 쓰게 만들어 그들이 고객이나 비즈니스 문제를 빠르고 리소스 소모 없이 해결할 수 있도록 만들어주어요. 이는 자연스럽게 실제 제품을 사용하는 사용자보다는 조직 내부에서의 소통이 더 많게 되고, 자연스럽게 우리 팀이 만드는 제품은 공급자 관점으로 바라보게 되거나 만들게 돼요. 그리고 본질적으로 비즈니스 문제 또는 사용자 문제를 해결한다는 관점보다는 기술적 맥락의 제품을 다루는 경우가 많아요. 그래서 어떻게 하면 우리 제품을 다른 사일로나 팀이 더 편하게 가져다 쓸 수 있을지를 더 많이 고민하는 경우가 있었어요.
이뿐만 아니라 여러 사일로나 팀이 만드는 제품에 사용되다 보니 그들이 마주하는 각각의 서로 다른 사용자의 요구사항들을 접하게 되고, 이를 모두 만족하게 만들기 쉽지 않은 상황에 직면하는 경우가 많아요. 그래서 많은 경우, 우리 팀의 주요 업무는 새로운 가치를 창출하는 것보다는 기존 제품의 운영/보수가 되는 경우가 많아요. 이러한 환경에서 제품을 만들다 보니 저 또한 자연스럽게 사용자 관점이 아니라 공급자 관점에서 제품을 만드는 시도를 하고 있었어요. 단순하게 “사용자가 이런 행동을 해야 해”라고만 표현하고, 사용자가 이해할 수 없는 이미지나 표현을 사용하는 경우도 많았어요. 왜냐하면 이렇게 표현해도 사용자가 이해할 수 있을 것으로 생각했기 때문이에요.
결론부터 말하자면 이러한 시도는 맥락이나 제품에 대한 이해도가 높았던 팀이나 사일로에서는 이해하기 쉬웠지만 사용자는 이해하기 어려웠어요. 우리가 생각하는 것처럼 지표가 움직이지 않고, 실험들의 결과가 좋지 못해서 UT를 진행했었어요. 이때 공급자의 관점에서 새로운 경험을 제공한다거나, 사용자가 해야 하는 행동만을 유도하는 것은 사용자에게 불편한 경험을 제공하고 있다는 것을 발견했어요. 결국 사용자가 이탈하게 만드는 계기가 되고 있었어요. 우리가 UT를 통해서 얻은 해야 할 일은 사용자의 행동이 무엇을 위한 것인지, 행동의 결과가 무엇인지를 알게 만들어주어야 한다는 것이었어요. 우리는 우리가 당연하게 알고 있는 것들을 사용자 또한 알고 있을 것으로 생각하는 것을 지양하기 위해 노력했어요. 이를 위해 사용자가 무엇을 할지 모르는 상태라고 생각하고 사용자가 쉽게 인지하고 행동할 수 있도록 유도하기 위한 시도를 진행했어요. 이러한 시도가 직접적으로 사용자에게 긍정적인 영향을 만들어냈는지는 알 수 없었지만, 우리가 만든 제품들이 사용자에게 쉽게 전달될수록 팀의 제품을 가져다 쓰는 다른 사일로나 팀의 성과도 좋아질 수 있다는 것을 간접적으로 확인할 수 있었어요.
물론 반대의 의견도 있어요. 누군가는 사용자를 이해시키기 위해 한 페이지에서 보아야 할 정보가 너무 많아져서 오히려 불편함이 가중되고 편의성을 감소하게 만들 수 있다고 말해요. 하지만 그런 것을 잘 풀어내는 것이 UX의 역할이라고 생각해요. “이렇게 복잡한 것을 이렇게 쉽게 이해할 수 있도록 만들었다고?”라는 순간이 오면 UX 경험을 설계하는 Product Designer에게 무한한 신뢰가 생기곤 했어요. 우리가 충분히 세심하게 사용자의 관점에서 생각한다면, 복잡해 보이는 것도 쉽게 풀어낼 수 있어요.
결론
금융이나 핀테크와 같이 보안에 민감한 곳은 사용자가 이 행동을 왜 해야 하는지를 알려주는 것이 필요해요. 사용자는 생각보다 보안에 민감하고, 두려워하는 경우가 많아요. 그게 설사 보편적으로 사용자를 위하는 기능일지라도 말이에요. 사용자에게 우리는 우리가 정말 선한 의도와 사용자를 위하는 마음을 가지고 있다는 것을 전달할 수 있어야 해요. 이런 관점으로 제품을 만들다 보니 점차 사용자의 피드백이 좋아지기 시작했었어요. 사용자의 입장에서 허들이 생기거나, 단계가 추가되어 번거로울 수 있더라도 왜 해야 하는지를 알려주고, 어떤 행동을 하면 되는지 알려주면 허들이나 단계가 번거롭게 느껴지지 않는다는 것을 알게 되었어요.
우리는 의식적으로 사용자의 관점에서 제품을 만들기 위해 노력해야 해요. 당장은 불필요해 보이거나 불편함이 늘어나 보이는 것처럼 느껴지지만 제품을 사용하는 사용자들의 신뢰를 확보하고, 사용자들이 쉽게 인지하고 쉽게 사용할 수 있도록 만드는 것은 더 많은 사용자들을 제품에 유입시켜 활성사용자로 전환하게 만들 수 있어요. 그리고 이는 하나의 제품 경쟁력이 될 수 있어요.
June님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
