•
누군가 나에게 DesignOps가 뭐하는 역할이냐고 묻는다면, ‘디자이너를 위해 필요한 모든 일을 한다. 디자인만 빼고.’라고 답할 것이다.
•
혹은 ‘디자이너를 위해 필요하지만 디자이너들이 할 수 없거나, 하지 않을 모든 일들을 한다’고 대답할 것이다.
•
DesignOps는 디자이너-디자이너, 디자이너-다른 관계자, 혹은 디자인 커뮤니티를 연결한다.
◦
DesignOps는 풀(glue)과 같다. 눈에 보이지 않지만 일이 꼬이고, 사람들이 사기가 떨어지기 시작하면 그때서야 DesignOps가 없다는 걸 느끼게 된다.
◦
보통 보이지 않고 눈에 띄지 않는 일들이다.
사람: 디자이너의 행복
•
회사는 채용 이후 디자이너가 회사에 오래 머물기를 원한다.
◦
그들이 성장하고 있다고 느끼고 있는가?
◦
디자이너들끼리 커뮤니티가 형성되었다는 느낌을 받는가?
◦
디자이너들이 함께 일하고 있는가?
◦
다른 디자이너가 무슨 일을 하는지 잘 알고 있는가?
◦
회사 안에서 디자이너로서 다음 커리어를 바라볼 수 있는가?
◦
오늘의 주니어 디자이너가 다음에 시니어 디자이너가 될 수 있도록 준비하고 있는가?
•
이런 일들은 HR에서 이미 하고 있지 않나요? → HR이 디자이너의 커리어 사다리를 디테일하게 챙길 수 없다.
프로세스: 디자인 퀄리티
•
디자이너들이 높은 퀄리티의 아웃풋을 내도록 돕는 것
◦
서로 솔직한 피드백을 주고받을 시간과 기반이 있는가?
◦
디자이너들이 자신이 하는 일이 그저 PM의 스케치를 figma로 옮기는 것 뿐이라고 느끼고 있지는 않는가?
◦
사람들의 스케줄에 서로 대화하고 탐구할 여유가 충분히 있는가?
◦
그들이 무슨 일을, 왜 하고 있는지 잘 알고 있는가?
→ 이 모든 것이 일의 퀄리티로 이어진다.
도구: 피그마 플러그인
•
반복적인 작업, 별 가치 없이 시간이 많이 드는 작업 없애기
◦
이런 작업들을 없앨 기회를 발견하고 있는가?
◦
이런 기회를 찾았다면 툴을 누가 만들고 유지보수 할 것인가?
◦
디자이너들에게 이 도구를 어떻게 알릴 것인가?
•
필요한 툴이 있을 때 어떻게 접근하는지 쉽게 알려주어야 한다.
•
DesignOps는 디자인 팀의 운영 방식에 전략적인 비전을 제시한다.
◦
지금 작업해야 할, 가장 impactful할 일은 무엇인가?
◦
실행 전에 문제를 파악하기: 무엇이 문제인가, 왜 문제인가?
◦
우리의 목표가 무엇인가?
◦
이 문제를 해결하면 세상이 어떻게 바뀔 것인가?
•
내 자신이 필요없는, 자동으로 굴러가는 시스템과 프로세스를 만들어라
•
DesignOps가 하는 일은 필요한 일이며, 누군가는 그 일을 하고 있다.
•
이 부분에 전념하는 사람이 없다면 매번 다른 타이틀의 사람이 이 일을 맡게 된다.
◦
디자인 매니저들이 이런 일을 맡게 되기 쉬움. 그들이 할 수 있는 더 중요한 매니징 업무들이 있음에도!
◦
PM들도 롤의 특성상 이런 일들을 많이 맡곤 함
◦
커뮤니티, 프로젝트 매니지먼트 등 각 업무에 대해 열정있는 직원들이 나머지 일들을 맡곤 함
◦
이런 일들에 대한 노력과 기여가 리뷰에서 성과를 인정받을 수 있는가?
◦
아니면 이런 일들에 시간을 버리느라 패널티를 받는가? → 이런 일에 시간 쓴 사람이 손해를 보게 됨
◦
필요하다면 공식적인 이름을 붙여 Design Ops팀을 만드는 것이 좋을수도
•
DesignOps는 0에서 시작하지 않는다. 이미 잘 되어있는 문서, 미팅을 찾아 거기부터 시작하라.
