피그마 팀은 어떻게 제품을 만들까 (트위터 의역본)

Sho Kuwamoto, Director of Product at Figma

쇼 쿠와모토라는 피그마 디자이너가 트위터에 남긴 제품개발 프로세스를 의역해봤습니다.

 

1/n

오늘 누가 우리 디자인/개발 프로세스에 대해 묻길래.. 여기 관심있으신 분이 있을런지 모르겠지만, 정돈 안된 비공식 프로세스 버전을 한번 써보려합니다.

 

2/n

0단계 - 브레인스토밍: 아이디어 창고는 항상 흘러 넘칩니다. 이걸 모두 할 시간은 물-론 없지만 일단 다 기록해두는거죠. 아이디어는 보통 1. 유저요청 다이렉트 기능이거나 2. 일하다가 얻는 인사이트입니다.

 

3/n

어쩔땐 아직 로드맵에 올리지도 않은 아이디어를 발전시키는 사람도 있습니다. 디자이너든, PM이든 엔지니어든, 무언가를 개선시키는데는 모두 열정적이니까요.

 

4/n

이렇게 초기 아이디어를 살펴보는건 중요합니다. 뭐가 진짜 보석일지는 모르는거니까요.

 

5/n

1단계 - 로드매핑: 어떤 기능이 확실히 중요하다고 얘기가 되면, 그때 이 기능을 로드맵에 올립니다. 유저 피드백, 시장 상황, 그리고 많-은 내부토론을 거쳐서 로드맵을 완성합니다.

 

6/n

어떤 기능을 로드맵에 올리면, 이제 이런 것들을 좀 더 깊게 고려하기 시작합니다: "누굴 위한 기능인가?" 그리고 "어떤 상황에서 이 기능을 필요로 하는가?". 기능이 딴 길로 새지 않기 위해, 이런 질문을 묻는 것이 중요합니다.

 

7/n

2단계 - 킥오프: 이제 이 기능을 하기로 어느정도 결정했으면 디자이너 1명, PM 1명, 여러 엔지니어들로 TF task force를 꾸립니다. 팀원 세팅은 킥오프부터 완성하려합니다. 그래야 처음부터 모든 사람이 미팅에 빠짐없이 참여할 수 있으니까요.

 

8/n

이 단계에서 마일스톤 (=스프린트보다 긴 단위인 4주)도 정해봅니다. 마일스톤은 "첫 스테이징 버전 배포하기" 같은 구체적인 목표를 가져야합니다.

 

9/n

솔직히 당장 눈앞의 마일스톤 다음에 어떤일이 있을지 까지는 잘 모를 때가 많습니다. 뭐, 근데 몰라도 괜찮아요.

 

10/n

3단계 - 발산: 디자인 발산 단계는 프로젝트 사이즈에 따라 다른데, 길면 몇주까지 걸릴 수 도 있습니다. 이 단계에선 디자인 크리틱 + 팀 체크인 미팅을 하면서 산출물을 트래킹합니다.

 

11/n

발산 단계의 최종산출물/성공기준은: (1) 이 기능의 전체 모델이 그려졌는가? (2) UI 방향성이 잡혔는가? 입니다. 1번 모델이 이 단계에서 가장 중요한 산출물입니다.

 

12/n

예를 들어, states 기능을 만들 때였는데요. 이 기능을 구현하기 위한 방식을, property가 style로 쓰이는 모델로 가기로 결정했습니다.

 

13/n

일단 그렇게 정해놓고, 그 다음에 엄-청 싸웠, 아니 토론했습니다. 이 모델의 경우 색상을 처리하는게 까다로웠는데, 그런 디테일을 잡는데 신경썼습니다.

 

14/n

4단계 - 개발: 발산이 끝났으면 디자인을 수렴합니다. 디자인 정돈이 얼추 됐다 싶으면 이제부턴 본격적으로 개발을 시작합니다. 피그마는 Asana를 쓰는데, 여기서 개발 태스크를 트래킹합니다.

 

15/n

관련 팀원들은 1주일에 몇번 만나면서 디자인과 개발 싱크가 맞는지 체크하는 시간을 가집니다. 물론 이 단계에서도 디자인이 바뀔 수 있습니다: (1) 개발 상황에 따라 (2) 디자이너의 새로운 인사이트로 인해.

 

16/n

개발 단계에서 디자인이 바뀌는 경우는 사실 흔합니다. 실제 개발을 해봐야, 뭐가 되고 뭐가 안되는지 전에는 잘 몰랐던 것들이 명확해지니까요.

 

17/n

그리고, 디자인 단계에서 뭔가 중요한 것을 까먹을 가능성은 항상 50대 50입니다. 개발단계에 와서야 "오 쉣. 이걸 어쩌지?" 하고 다시 생각해야 하는 경우도 있습니다.

 

18/n

5단계 - 테스트와 정비단계: 개발이 거의 다 되면, 이제 스테이징 서버에 올려서 테스트를 합니다. 좀 규모가 있는 기능은 생각한대로 작동하지 않을 가능성이 높습니다.

 

19/n

보통은 스테이징 서버에 올려서 내부적으로 테스트를 하는데, 어쩔땐 외부인들에게도 테스트를 요청합니다. 이 단계도 한 몇주 걸리는데, 기능이 크면 그만큼 더 걸립니다. 고통스럽지만, 기능이 만족스러울때까지 기능을 tweak and tweak합니다.

 

20/n

명심할 것은, 기능들은 대체적으로 우리가 원했던대로 나오지 않는다는 것입니다. 이 단계에서 정말 노답인 기능은 아예 서비스에서 빼거나, 잠정적으로 중단하거나 결단을 내립니다.

 

21/n

6단계 - 배포 가즈아!

 

22/n

이게 근데 완벽한 프로세스일까요? 절대 노우입니다. 이 프로세스는 별로 정돈된 프로세스도 아니고 실제로 왔다리갔다리를 엄청 많이 했습니다. 다른 팀에 비해, 저희는 발산 단계에 시간을 더 쓰고 개발 단계에서 디자인을 바꾸는 케이스가 많다고 봅니다.

 

23/n

무언가 다시 해야한다는 것은 정말 빡- 아니 답답한 일입니다. 하지만 우리가 만족하는 제품을 만드는 것이 우리 모두가 공유하는 목표이고, 우선 이 목표를 달성하기 위해 지금보다 더 나은 방법을 아직은 찾지 못했습니다.

 

24/n

팀이 성장하면서, 확실히 시스템도 계속해서 정리해가고 있습니다. 요즘은 예전보다 낭비적인 일을 덜 하고 있긴 합니다만, 그래도 실제 코드까지 가봐야만 알 수 있는 것들은 *항-상* 존재합니다.

 

25/25

이게 다예요! 다른 분들은 어떤 식으로 일하는지 궁금하네요. 

 

부록: 어떻게 하면 디자인을 좀더 오픈되게 할 수 있을지 고민중인데요. 만약 초기 디자인을 커뮤니티에 공유해서 여러분의 피드백을 받는다면 어떨 것 같나요?

 

부록2: 제가 여기 말한 프로세스는, 제가 가장 가깝게 일하는 팀이 일하는 프로세스입니다. 그 팀은 에디터 팀이어서 디자인을 아주 많이 하는 팀인데요. 인프라 팀은 아마 또 프로세스가 아주 다를 거예요.

 

그럼 이-만.

---

원문

https://twitter.com/skuwamoto/status/1235042668494741504

 

쇼 쿠와모토에 대해 더 궁금하다면

https://www.youtube.com/watch?v=lcSKQS716WI