Figma의 컨퍼런스인 Config 2022에서 진행된 Inayaili León의 ‘DesignOps: The API of design teams’를 번역한 글입니다. 국내에서는 아직 생소한 Design Ops라는 조직을 좀 더 이해하는 데에 도움이 되길 바랍니다.
- 디자인 시스템, 워크 플로우, 온보딩, 채용… 등 많은 일을 하고 있었지만 이 일에 이름을 붙이지 못하고 있었다.
- Design Ops라는 이름을 듣고 이게 내가 하는 일을 정의해줄 수 있겠구나! 하고 단번에 느꼈다.
- Design Ops는 회사 안 팎으로 endpoint를 연결해주는 API와 같은 팀이다.
- 서로 다른 것들이 상호작용 할 수 있도록 해준다.
- 당신이 자각하고 있지 않아도 Desgin Ops일 수 있다.
- Design Ops는 회사에 따라 매우 다른 일을 맡고 있다.
- Design Ops는 팀이 가진 ‘간극’을 매우기 때문에, 각 팀이 가진 특성에 따라 다른 역할을 가질 수 밖에 없다.
- 누군가 나에게 Design Ops가 뭐하는 역할이냐고 묻는다면, ‘디자이너를 위해 필요한 모든 일을 한다. 디자인만 빼고.’라고 답할 것이다.
- 혹은 ‘디자이너를 위해 필요하지만 디자이너들이 할 수 없거나, 하지 않을 모든 일들을 한다’고 대답할 것이다.
- Design Ops는 디자이너-디자이너, 디자이너-다른 관계자, 혹은 디자인 커뮤니티를 연결한다.
- Design Ops는 풀(glue)과 같다. 눈에 보이지 않지만 일이 꼬이고, 사람들이 사기가 떨어지기 시작하면 그 때서야 Design Ops가 없다는걸 느끼게 된다.
- 보통 보이지 않고 눈에 띄지 않는 일들이다.
보통 Design Ops가 하는 일을 3가지 테마로 나눌 수 있다. 사람, 프로세스, 도구
사람: 디자이너의 행복
- 회사는 채용 이후 디자이너가 회사에 오래 머물기를 원한다.
- 그들이 성장하고 있다고 느끼고 있는가?
- 디자이너들끼리 커뮤니티가 형성되었다는 느낌을 받는가?
- 디자이너들이 함께 일하고 있는가?
- 다른 디자이너가 무슨 일을 하는지 잘 알고 있는가?
- 회사 안에서 디자이너로서 다음 커리어를 바라볼 수 있는가?
- 오늘의 주니어 디자이너가 다음에 시니어 디자이너가 될 수 있도록 준비하고 있는가?
- 이런 일들은 HR에서 이미 하고 있지 않나요? → HR이 디자이너의 커리어 사다리를 디테일하게 챙길 수 없다.
프로세스: 디자인 퀄리티
- 디자이너들이 높은 퀄리티의 아웃풋을 내도록 돕는 것
- 서로 솔직한 피드백을 주고받을 시간과 기반이 있는가?
- 디자이너들이 자신이 하는 일이 그저 PM의 스케치를 figma로 옮기는 것 뿐이라고 느끼고 있지는 않는가?
- 사람들의 스케줄에 서로 대화하고 탐구할 여유가 충분히 있는가?
- 그들이 무슨 일을, 왜 하고 있는지 잘 알고 있는가?
- → 이 모든 것이 일의 퀄리티로 이어진다.
도구: 피그마 플러그인
- 반복적인 작업, 별 가치 없이 시간이 많이 드는 작업 없애기
- 이런 작업들을 없앨 기회를 발견하고 있는가?
- 이런 기회를 찾았다면 툴을 누가 만들고 유지보수 할 것인가?
- 디자이너들에게 이 도구를 어떻게 알릴 것인가?
- 필요한 툴이 있을 때 어떻게 접근하는지 쉽게 알려주어야 한다.
- Design Ops는 디자인 팀의 운영 방식에 전략적인 비전을 제시한다.
- 지금 작업해야 할, 가장 impactful할 일은 무엇인가?
- 실행 전에 문제를 파악하기: 무엇이 문제인가, 왜 문제인가?
- 우리의 목표가 무엇인가?
- 이 문제를 해결하면 세상이 어떻게 바뀔 것인가?
- 내 자신이 필요없는, 자동으로 굴러가는 시스템과 프로세스를 만들어라
Github의 Design Ops
- Github에서도 Design Ops는 아직 안정된 것이 아니고 아직 빌딩중
디자인 온보딩 프로젝트
- 다양한 나라와 타임존을 가진 사람들이 근무중
- 사람들이 첫 주부터 성취감을 느끼고 뭔가를 하고 있다고 느끼길 원했음
- 신규 입사자들에게 계속 피드백을 받으며 조금씩 수정중
- 피드백을 장려하고, 이를 들을 시간을 마련하는 것이 중요!
- 방어적인 태도를 갖지 말 것
“우리가 일하는 법” 문서
- 질문들을 올리면 누구나 대답해주는 문서
- ex) “휴가를 내려면 어떻게 해야하나요?”
- 불렛 포인트 달린 작은 문서로 시작. 각 언어로 번역되어 접근성 높은 곳에 위치
‘자기 일을 공유하기’ → 잘 되지 않은 사례
- 다른 디자이너가 무슨 일을 하는지 서로 궁금해했음
- 여러가지 방식을 시도해봄
- 2-3분동안 자기가 한 것 공유하기
- 매주 자기가 한 작업 figma 프로토타입 링크 달아두기 등
- 타임존이 다양하고 다른 미팅도 많기 때문에 디자이너들이 참석하기가 어려웠음.
- 작업해야 하는 다른 것들도 많아서 싱크 미팅은 옵션처럼 생각됨
- → 변화에 대한 필요와 안정에 대한 인간의 욕구 사이에서 균형을 잡아야 함
- Design Ops가 하는 일은 필요한 일이며, 누군가는 그 일을 하고 있다.
- 이 부분에 전념하는 사람이 없다면 매번 다른 타이틀의 사람이 이 일을 맡게 된다.
- 디자인 매니저들이 이런 일을 맡게 되기 쉬움. 그들이 할 수 있는 더 중요한 매니징 업무들이 있음에도!
- PM들도 롤의 특성상 이런 일들을 많이 맡곤 함
- 커뮤니티, 프로젝트 매니지먼트 등 각 업무에 대해 열정있는 직원들이 나머지 일들을 맡곤 함
- 이런 일들에 대한 노력과 기여가 리뷰에서 성과를 인정받을 수 있는가?
- 아니면 이런 일들에 시간을 버리느라 패널티를 받는가? → 이런 일에 시간 쓴 사람이 손해를 보게 됨
- 필요하다면 공식적인 이름을 붙여 Design Ops팀을 만드는 것이 좋을수도
- Design Ops는 0에서 시작하지 않는다. 이미 잘 되어있는 문서, 미팅을 찾아 거기부터 시작하라.