피그마(Figma)가 알려준 고객 집착 - Show Kuwamoto

 

Show Kuwamoto는 Figma의 부사장이다.

디자인 툴을 넘어, 협업, PT 등 다양한 용도로 사용되는 Figma의 성장 비결은 고객에 대한 집착이라고 그는 말한다.

초창기부터 Figma에 합류한 이후 배워온 고객 집착에 대한 Lenny와의 인터뷰이다.

 

초기의 Figma

figma에 합류한지 얼마 되지 않아, 한 개발자가 버그를 가져왔다.

당시 제품은 소수의 인원에게만 테스트 중이었고, 당시 중요한 프로젝트를 하던 중이기에 개발팀에게 짐을 더하고 싶지 않았다.

하지만 CEO인 Dylan Field는 모든 버그를 즉시 해결하기를 원했다.

그래서 고쳤다.

당시 그 말이 이해되지 않았지만, 왠지 모를 기대가 됐다.

자신보다 고객을 생각하는 보스를 본 적 없기 때문이다.

사실 처음에는 이 10명도 안되는 팀에서 디자이너가 좋아할만한 도구를 만들 수 있을지 의구심이 들었다.

현재, Figma는 내가 상상했던 것보다 훨씬 더 성장했다.

이제는 사람들이 나에게 우선순위를 어떻게 하는지, 제품을 만드는 프로세스를 물어보는 지경에 이르렀다.

이건 Figma에서 나와 팀원들이 특별한 것을 한 것이 아니기에, 대답하기 어려운 질문이다.

 

우리의 프로세스는 체계가 없었고, 실수 투성이었다.

우리는 의사소통 오류와 실수를 반복했다.

하지만 한 가지 Figma가 다른회사보다 잘했던 것은 사용자의 요구사항을 최우선으로 생각한 것이었다.

물론 많은 회사들이 그렇지만, 우리는 고객의 관점을 우리의 것보다 우선으로 생각했다.

그리고 이 것은 초창기부터 우리 회사의 문화로 자리잡았다.

 

 

Customer Support is everyone’s job (고객 지원은 모두의 일이다.)

첫 베타를 출시했을 때, 너무 많은 요청이 들어와 고객 지원에 쓰는 시간이 매우 많았다.

우리는 마치 단체 채팅방처럼 베타 사용자들과 계속 연락을 주고 받았다.

Figma팀은 모두가 같이 일하기 때문에, 사용자의 버그나 사용성 이슈가 발생하면, 모든 것을 멈추고 대응했다.

이 것이 결국 우리의 Customer Support is everyone’s job 문화로 이어졌다.

심지어 고객지원 팀이 생긴 이후에도 디자이너와 개발자들은 직접 사용자를 응대했다.

모든 팀원들은 고객과 가까이 있었다.

물론 개발과 디자인의 시간이 빼았겼고(가끔은 20%가 빼앗기 때도 있었다.) 고객 지원 팀은 개발자나 디자이너가 잘못 이야기할 때 움찔하기도 했다.

하지만 이는 우리 초기 운영에 핵심이었고, 다른 방법은 생각하지 않았다.

 

우리의 리듬은 간단했다.

1. 고객의 문제 이해하기
2. 즉각적인 지원을 통해 문제 해결하기
3. 필요하다면, 제품 전체 업데이트를 통해 사용자들이 같은 문제 겪지 않게하기

이 리듬을 버그를 고치는 것에도 사용했지만, 제품의 빈틈을 찾아내기 위해서도 사용했다.

이러한 빈틈은 우리가 더 크고 대담한 기능으로 해결할 것이다.

이런 태도는 단지 이슈 티켓 하나를 처리하는 것이 아니다.

컴퓨터 성능의 문제로 Figma가 작동하지 않는 고객을 만나기 위해 한 시간을 운전하기도 했다.

또, 중요한 프로젝트를 Figma로 진행하던 어떤 사용자와 주말 내내 챗으로 채팅을 하기도 했다.

그들의 문제는 내 문제이다.

 

개발자의 업무시간 중 20%를 사용자를 돕는데 사용하는 것은 개발 시간을 뺏는 것은 사실이다.

하지만 반대로, 사용자의 문제가 무엇인지 빠르게 찾았고, 빠른 응답에 대한 평판을 얻었다.

사용자들은 개발자들이 몇 줄의 코드를 얼마나 빠르게 작성하는지 판단하지 않는다.

그들은 단지, 중요한 일을 얼마나 빨리 대응하는지 판단할 뿐이다.

이런 문화는 사용자와 이야기할 때마다 반복되었다.

영업팀이 없었을 때, 우리 모두는 영업 전화에 참여했고, 그 방법을 고객을 돕기 위해 사용했다.

 

 

 

Software as a service

각 분야마다 다른 공식을 가지고 있지만, 디자인 툴은 무엇보다 end-user의 행복에 집중해야 한다는 것을 찾았다.

궁극적으로, 사용자는 기능이 좋으면 우리를 선택해할 것이다.

이는 당연해 보이지만 실천하기 어렵다.

 

Figma가 커지면서 고객 관점대신 우리의 관점이 보이기 시작했다.

아마 단순한 아키텍쳐로 설계하거나 더 많은 수익을 얻는 등 우리에게 더 유리한 작업들이 있었을 것이다.

우리 스스로의 관점보다 사용자의 관점을 고수하기 위해 끊임 없는 노력을 해야한다고 생각한다.

 

우리가 했던 방법은 제품을 서비스 산업에 있다고 생각하는 것이었다.

Figma를 호텔이나 레스토랑으로 상상하고, 사용자를 손님으로 상상했다.

SaaS(Software as a Service) 즉 Figma는 서비스를 제공하는 업체이다.

우리는 단지 그 서비스를 소프트웨어로 하는 것 뿐이다. 이것이 바로 Service-Oriented 마인드 셋이다.

Service-Oriented 마인드의 궁극적인 목표인 “사용자의 문제”를 해결하는 데 도움을 주는 도구로 제품을 바라보는 것이다.

 

 

The importance of feel

보통 다른 소프트웨어들은 이성적인 판단 기준에 따르지만, 디자인 도구는 그렇지 않다.

디자이너들에게 디자인 툴은 어떻게 "느껴지는지"가 중요하다.

마치 음악가가 자신에게 맞는 악기를 찾는 것과 유사하다.

 

사용자의 선택을 받기 위해 소프트웨어가 주는 느낌은 매우 중요하다고 믿는다.

특히 Proudct-Led Growth (제품 중심 성장)을 추구할 때 더욱 그렇다.

사람들은 이 느낌을 본능적으로 느낄 수 있으며, 억지로 만들 수 없다.

이것이 Proudct-Led Growth에서 가장 중요한 부분일 수도 있다고 생각한다.

 

우리는 처음부터 Figma의 "느낌"을 제대로 만들려고 노력했다.

Figma를 공식적으로 출시할 때, 우리는 기능을 채우기보다는 잘 디자인인된 핵심 기능만 제공 했다.

우리는 그 핵심 기능에 현재 Figma의 핵심 기능인 컴포넌트, 스타일, 심지어 멀티플레이어도 포함시키지 않았다.

그저 브라우저에서 작동하는 간단한 디자인 도구로서 느끼게 했다.

 

처음부터 멀티플레이어 기능을 제외하는 것은 정말로 힘들었다.

만약 모든 기능을 갖춘 상태에서 나쁜 느낌을 주며 시작했다면 신뢰의 문제를 초래할 수 있다.

하지만 처음부터 모든 기능을 갖추지 않았지만 사용자에게 신뢰를 주었다.

이 신뢰는 추후에 사용자의 피드백을 통해 기능 추가를 할 것이라는 믿음을 주었다.

 

각 제품마다 느낌을 제대로 전달하기 위해 중요한 다양한 측면이 있다.

Figma에서는 다음과 같은 측면에 초점을 맞추었다:

• 성능 - 사용자가 문서를 편집하는 동안 변경 사항을 얼마나 빠르게 표시할 수 있는지 측정한다. 우리는 가능한 경우에는 60프레임/초의 기준을 유지하려고 노력한다.
• 익숙함 - 디자인 도구에는 키보드 단축키와 근육 메모리에 대한 긴 역사가 있다. 예를 들어, 특정한 키보드 키는 객체의 크기 조정에 영향을 미치며, 키가 중간에 눌리거나 해제되는 경우 사용자가 기대하는 특정한 동작이 있다. 또한, 객체를 이동하는 동안 스페이스바를 누르고 있으면 고급 비디오 게임 콤보 동작과 같은 느낌이 난다.
• 일관성 - Figma는 꽤 복잡할 수 있다. 객체는 파일 간에 복제될 수 있고, 서로 중첩되며, 여러 사람이 동시에 편집하는 동안 실시간으로 업데이트될 수 있다. 우리는 모든 것이 어떻게 작동하는지에 대한 내부적인 규칙을 가지고 있으며, 이러한 규칙은 사람들이 도구가 예측 가능하다고 느낄 수 있도록 도와준다. 심지어 그들이 그 규칙이 무엇인지 정확하게 이해하지 못해도 말이다.

 

제품의 "느낌"을 고민할 때는다음을 고려해보라:

사용자가 제품을 얼마나 자주 사용하는지를 고려하라.

이메일/메시징과 같은 커뮤니케이션 도구, IDE, 스프레드시트와 같이 매일 사용하는 제품은 느낌이 결정적인 선택 요소가 될 수 있다.

이러한 높은 빈도 카테고리에서는 일반적으로 사람들이 예전에 사용했던 소프트웨어에서 기대하는 동작들이 있다.

가능하면 이 기대들을 수용하고, 그 이상의 기대를 충족시키는 몇 가지 방법을 찾아보아라.

이는 베끼는 것이 아니라 유용한 느낌을 주며, 좋은 소프트웨어의 품질로 평가받는다..

 

제품의 느낌에 대해서 확신이 어렵다면, 직접 물어보아라!

가장 기본으로 돌아가서, 사용자들에게 제품을 사용하는 것이 좋은지 물어보아라.

그리고 그렇지 않다면 왜 그런지 물어보아라.

때로는 기능의 부재로 인한 것일 수도 있지만, 때로는 설명하기 어려운 느낌이라고 말할 것이다.

이러한 종류의 피드백을 무시하지 말고, 실제로 그것을 이해하려고 최선을 다해봐라.

우리는 모두 소프트웨어에 직관적으로 반응하며, 사용자가 소프트웨어와 실제로 고생하거나 즐길 때, 그 느낌을 직관적으로 느낄 수 있다.

 

 

마무리

마지막으로, 소프트웨어를 개발하는 목적은 무엇일까? 우리는 모두 사람들을 행복하게 만드는 소프트웨어를 만들고 싶지 않을까?

위 요약에서는 자주 사용되는 소프트웨어일수록 "느낌"이 중요하며, 사용자의 기대를 조사하고 초과하는 몇 가지 사항을 도입하는 것이 중요하다는 내용이 담겨 있다.

또한, 고객의 반응을 보여주어 느낌의 중요성을 설득하는 것이 도움이 된다.

마지막으로, 전체적인 느낌을 구현하는 것은 과학보다 예술에 가까우며, 서비스 지향적인 관점을 적용하는 것이 도움이 된다.

이러한 관점에서 우리는 사람들을 행복하게 하는 소프트웨어를 개발하고자 한다.

 

출처 : Lenny 뉴스레터