brunch

매거진 디자이너 성장일기

라이킷 111 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 서한교 Oct 22. 2017

페이스북과 왓츠앱의 디자인 작업방식

미디엄 글 번역

사람마다 일하는 스타일이 다르듯이 회사마다 일하는 스타일이 다릅니다. "들어보니까 이렇게 일하는게 좋다더라" 하면서 따라하는 것 보다는 회사의 비젼에 대해서 고민하고, 이에 어울리는 스타일을 찾는게 중요하다고 생각합니다. 이 글은 Facebook과 WhatsApp에서 어떻게 일하는지에 대한 글입니다.

내용을 개인적으로 재해석하여 의역한 부분이 많습니다. 참고바랍니다 : D

원글 : One Year Designing at WhatsApp

저는 Facebook에서 4년 가까이 프로덕트 디자이너로 활동했습니다. Groups, Sharing, Privacy와 같은 다양한 팀에서 일을 했었고, 작년 이맘때부터 WhatsApp에서 일하고 있습니다.

WhatsApp에서 Facebook과 다른 디자인 경험을 하게 될 것을 알고 있었습니다. 이 경험은 시야를 넓게 해주었고 이전과는 다른 각도에서 문제와 일에 접근할 수 있게 해주었습니다. 지난 한 해 동안 많은 것을 배웠기에 WhatsApp 및 Facebook의 디자인 작업방식을 관찰한 내용을 공유하고 싶습니다.

Strong principles

WhatsApp은 특정한 원칙을 고려해서 프로덕트를 설계하고 제작합니다. 이러한 원칙은 의사 결정 프로세스의 핵심입니다. 다음은 이러한 원칙의 예시입니다.

인터페이스는 사용자의 디바이스와 자연스럽게 어우러져야 합니다.

앱은 가볍고 가능한 한 적은 저장 공간을 필요로 해야 합니다.

인터페이스는 단순해야 합니다.

사용자 행동 그리고 애니메이션은 빠르게 반응해야 합니다.

기능은 설명이 필요 없을 정도로 명확해야 합니다.

Facebook은 비즈니스적으로 큰 목표를 설정하고 이를 기준으로 의사결정을 하지만, WhatsApp은 이미 정해놓은 원칙을 기준으로 제품에만 집중합니다. 그래서 디자인 띵킹을 진행할 때 세부사항까지 얘기가 진행되곤 합니다. 보통의 Facebook 디자이너는 이것에 반발하면서 이렇게 말합니다. "나는 그런 방식이 싫어!", "프로덕트의 방향을 결정하는 사람은 누구야?", "당신이 컨트롤할 수 있는 게 있어?", "원칙을 정해놓으면 새로운 아이디어가 나올까?"

WhatsApp이 로드맵을 작성할 때 Facebook보다 탑다운(top-down) 방식을 더 많이 사용합니다. 개인적으로는 이 방식이 일에 더 집중하게 해준다고 생각합니다. 저는 디자이너이기 때문에 디자인을 통해서 프로덕트에 영향을 끼칩니다.

다시 말하자면, 아이디어를 제안하고 로드맵을 정할 때 내 생각을 충분히 표현할 수 있지만, 대개는 필요하지 않다는 것입니다. 로드맵이 정해지면 이전에 공유된 원칙을 준수해야 합니다. 만약 팀 전체가 동의할 수 있는 강한 디자인 원칙이 있다면, 그것은 여러 방면에서 팀을 효율적으로 만들 것입니다.

프로덕트를 만들 때 문제를 명확하게 정의할 수 있다면, 절반은 해결한 것입니다. 또한 제안된 해결책을 판단할 수 있는 프레임워크가 있다면 진행하는 데 있어 더 효율적입니다.

Utility driving engagement vs. Engagement driving utility

Facebook에서 일할 때, 디자이너는 종종 새로운 기능을 소개하는 임무를 맡곤 했습니다. 이미 유용한 기능이 많은 Facebook에서 이 임무는 어려운 일이었습니다. 왜냐하면 사용자는 새로운 기능이 마냥 좋기만 한 것이 아니기 때문입니다. 하지만 우리의 목적은 사용자가 유용하다고 생각하는 기능을 계속 제공하고 경험을 더 향상시키는 것입니다. 우리가 할 수 있는 것은 새로운 기능을 사용자에게 알려주고, 그들이 가치를 찾을 수 있게 하는 것입니다.

WhatsApp은 이 문제를 다른 실용적인 방식으로 접근합니다. 명백하게 유용한 기능을 설계하고 만들었지만 기능에 대해서 부가적 설명이 필요하다면, 이것은 준비되지 않은 것입니다. WhatsApp은 제품의 새로운 기능에 대해 알리지 않는 경향이 있습니다. 유용한 기능을 만들면 사용자가 기능을 발견하고 자연스럽게 사용할 것으로 가정하는 것이죠. 이 주장은 우리의 시스템에 대한 순진한 믿음이라고 할 수 있습니다.

프로덕트를 발전시키기 위해 정해진 디자인 공식은 없습니다. 유저가 새로운 것을 시도하게 앞에서 도와줄 수도 있고, 뒤에서 격려할 수도 있습니다(발견, 입소문 등).

Design tools and design skills

Facebook에서 프로덕트를 만들 때 가장 좋았던 점은 놀라운 디자인 툴을 사용하던 것이었습니다. Facebook은 디자이너의 작업을 쉽고 효율적으로 만들기 위한 툴을 만드는 팀이 따로 있었습니다. 프로토타이핑을 할 때 오리가미를 사용했고 굉장히 좋았습니다. 그러나 WhatsApp은 공식적인 인터페이스 킷 또는 그래픽 API를 사용하지 않아서 Facebook에서 나를 도와주던 많은 툴들은 내가 하는 일과는 아무 연관이 없게 되었습니다.

회사용 인터페이스 킷을 유지, 관리하는 것이 소규모 팀을 만드는 것보다 더 가치 있을 것입니다. 우리는 플랫폼 고유의 디자인에 크게 의존하므로 커스텀한 요소에 대한 필요성이 줄어듭니다. 우리는 일반적으로 사용되는 패턴이 담긴 스케치 문서를 공유했는데, 구조가 매우 복잡한 Facebook 및 인스타그램 시스템과 비교하면 매우 단순합니다.

WhatsApp에서 놀랐던 부분은 종종 손으로 아이콘과 일러스트를 그렸다는 것입니다. 나는 Facebook에서 UX 스킬은 발전시켰지만, 비주얼 디자인 스킬은 발전시키지 못했습니다. 왜냐하면 재능 있는 일러스트레이터와 훌륭한 툴이 아이콘을 제공했기 때문입니다. 비주얼 디자이너가 아니지만 작은 팀에서는 훌륭한 비주얼 디자인의 세부적인 것을 포함해서 모든 것을 잘해야 합니다.

도구를 사용하는 것은 작업을 보다 쉽게 만듭니다. 그러나 툴의 도움 없이 모든 단계를 진행해보는 것도 좋습니다. 이것은 도구의 유용성에 대한 관점에 도움이 됩니다.

Unique problems

WhatsApp에서 직면한 몇몇 문제는 이전에 경험하지 못한 것들이었습니다.

예를 들어 end-to-end 암호화는 많은 부작용을 가지고 있습니다. 메시지는 유저의 디바이스에 저장되지만 WhatsApp은 사용자의 메시지가 전달되면 메시지를 저장하지 않습니다. 이로 인해 기본적인 기술이해도가 없는 사용자는 이해할 수 없는 동작이 UI에서 발생됩니다. 예를 들어, 새로운 기기에서 WhatsApp에 접속하면 데이터가 서버에 없기 때문에 이전의 메시지가 나타나지 않습니다.

다른 예로 Facebook은 본인의 신분을 증명하는 것이 중요합니다. 그러나 WhatsApp은 사용자에게 프로필 사진과 이름을 요구하지 않습니다. 본인의 신분을 증명하는 것은 Facebook에서 디자인할 때 당연하다고 여기던 것이지만, 신분을 증명하는 것과 관련된 문제가 생기면 더욱 해결하기 어려울 수도 있습니다.

또 다른 흥미로운 예시는 모두가 당연히 텍스트를 읽을 수 있다고 생각하는 것입니다. 사용자는 텍스트 없이 WhatsApp을 통해 서로에게 보이스 메모, 사진 그리고 비디오를 보낼 수 있습니다. 제가 했던 흥미로운 도전과제 중 하나는 WhatsApp의 로그인 인터페이스를 설계하는 것이었습니다. 사용자는 WhatsApp에서 대화를 시작할 때 연락처가 성공적으로 연결되었다는 사실을 알고 싶어 합니다. 그리고 이는 텍스트를 읽을 수 없는 사람도 예외는 아닙니다.

Move slow and deliberate

Facebook은 문제로 시작합니다. 그리고 해결책을 제시합니다. 만약 팀이 관심을 가진다면 해결책을 테스트해볼 수 있습니다. 테스트가 잘 되면 그것을 만들 수 있습니다. 그리고 문제가 잘 해결되었는지 확인할 수 있습니다. 만약 문제가 잘 해결되면 그것을 실제 프로덕트로 만들고 기능을 더 추가하여 사용자에게 공개할 수 있습니다. 이 프로세스는 반복적이며 많은 테스트를 통해 점점 더 견고하고 자연스럽게 만들어질 것입니다. 이 과정을 거친다면 프로덕트는 잘 작동될 것입니다.

WhatsApp도 문제로 시작합니다. 다양한 해결책을 연구합니다. 그리고 앱의 원칙에 충실하게 최고의 해결책으로 보이도록 해결책을 다듬기 시작합니다. 본인이 생각하기에 그것이 틀린 부분이 없는 최고의 솔루션이 될 때까지 더 다듬습니다. 개발자는 해결책을 빌드하고 모든 사용자에게 배포합니다. 이 과정 또한 어느 정도 반복적이지만, 디자인이 더 주요한 역할을 합니다. 그리고 역할에 대한 압박도 더 많이 받습니다.

Facebook은 "빠르게 움직여라"라고 말합니다. Facebook에서 프로젝트를 진행하는 것은 매우 빠르지만 프로덕트를 출시하는 과정은 실제로 많은 시간이 걸릴 수 있습니다.

WhatsApp은 "느리지만 신중하게 움직여라"라고 말합니다. WhatsApp은 디자인 단계에서 훨씬 더 많은 시간을 할애합니다, 개발 단계에서 헤매는 것이 더 안좋기 때문입니다. 엔지니어에게 설계를 맡길 때, 우리는 가능한 최종적이고 많은 스펙을 전달하려고 노력합니다. 이것의 장점은 엔지니어가 작업을 할 때 느끼는 변동 폭이 적다는 것입니다. 잠재적인 단점은 엔지니어가 제품을 설계하고 결정하는 데 있어서 소외감을 느낄 수 있다는 것입니다.

이 두 가지 작업 방식에는 모두 장단점이 있지만 실제로 제가 배운 것은 둘 다 일하는 방식이라는 것입니다. 어느 방식도 다른 방식보다 특히 빠르지 않습니다. 작업 스타일 선호도의 문제입니다. Facebook 스타일은 역할 사이에 더 많은 겹침을 허용하고 WhatsApp 스타일은 각자의 역할에 집중하는 작업방식입니다.

Wrapping up

새로운 작업방식에 대해 생각해보고 팀에 가치를 더할 수 있는 방법을 만드는데 도움이 되기를 바랍니다. 저는 다양한 작업 스타일을 사용하여 우수한 프로덕트를 만들수 있다는 것을 기쁘게 생각합니다. 이것은 실무자에게 효과가 있냐 없냐의 문제입니다. 더불어 일하는 방식을 찾는 것이 매우 중요하다고 믿습니다.