조직 전체가 활용하는 피그마 환경 구축하기
디자인툴을 넘어 프로덕트를 빌딩하는 플랫폼으로써 피그마를 활용하는 방법
안녕하세요. 오랜만에 글을 올리네요.
작년 봄 이후로 포스팅을 멈췄었는데, 제가 작성했던 글이 꾸준히 조회수가 올라가는 것을 지켜보며 여러사람들에게 도움이 된 것 같아 뿌듯해하곤 했었습니다.
그렇게 ‘언젠가 또 유익한 글을 올려야지’ 생각만 하고 있었는데, 시간이 지나 경험이 쌓여 새로운 글로 찾아뵙게 되었네요.
이 글은 조직에서 피그마를 활용하는 방법에 대한 이야기인데요, 제가 다니고있는 회사에서의 경험을 토대로 작성해 보았어요.
총 2편이고, 두번째 편은 여기에 있어요. 이 글을 통해 어디선가 피그마로 협업하는 모든 분들께 도움이 되길 바랍니다.
Intro
페이히어에는 프로덕트, 마케팅, 비즈니스, CX, P&C 등 다양한 팀이 있습니다. 신기한 건 이 모든 팀이 피그마를 사용한다는 점이에요. 자료를 참고하는 것부터 작업물을 만들기까지 다양한 목적으로 활용하죠.
다양한 사람들이 활용하는 툴인 만큼, 멤버 수가 많아짐에 따라 체계적인 정리가 필요합니다. 이번 포스팅에서는 조직이 피그마를 잘 활용할 수 있도록 정리했던 경험에 대해 이야기 해보려 합니다.
글은 총 두편이 될 예정이에요. 이 글(첫번째 글)은 전체 조직 측면에서의 피그마 환경 구축에 대한 이야기를, 두번째 글은 애자일 조직에 맞는 프로덕트 팀만의 피그마 환경 구축에 대한 이야기를 공유드리려 해요.
재밌게 읽어주시면 감사하겠습니다.
문제
피그마는 사내 많은 팀에서 사용하는 전사적인 툴인만큼 일단 원하는 파일을 찾기 쉬워야합니다. 그러나, 이전의 페이히어는 (아래 이미지처럼) 접근이 자유롭지 못하고 찾기 어려운 부분이 있었어요. 그 결과로 작지만 필요하지는 않은 커뮤니케이션 코스트가 발생하기도 했었죠. 이 글을 보시는 분들 중에서도 공감하시는 분들이 있으실거라 생각해요.
슬랙 채널에 올라오는 피그마 링크를 눌러 들어갈 수는 있었지만, 자신이 피그마를 켜서 직접 찾아 들어가기란 어려운 일이었죠. 슬랙 링크는 유용하지만 메시지가 쌓여감에 따라 다시 찾기 불편해지기 때문에 완벽하지는 않았거든요. 어떤 유저이든 시간에 관계없이 접근할 수 있는 루트를 제공할 필요가 있었어요.
또한, 프로덕트 관점에서 멤버들은 파일 안의 원하는 화면과 플로우를 찾는 것에도 어려워하시기도 했어요. 피그마를 자주 사용하는 유저가 아닐수록 구조가 익숙하지 않아 불필요한 시간을 할애해야 했죠.
여러 가지 확인된 문제와 더불어 개인적으로는 조직이 피그마를 활용할 수 있는 여지가 더 많다고도 느꼈어요. 단순히 디자인 툴을 너머, 각 조직이 문제를 해결하는 데 도움을 줄 수 있는 도구로써의 활용을 말이죠. 멤버들에게는 문제로 느껴지지 않았던, 사용자는 알아채기 어려운 문제로써 피그마라는 툴이 의도하는 방향에 맞게 저만의 가설을 세워 문제 해결 과정에 살을 덧붙일 수 있었어요.
발견한 인사이트를 토대로 몇 가지 예시를 들어볼게요.
스쿼드는 기획을 구상하고, 서로의 의견을 맞추어 공감대를 올릴 수 있는 수단으로 활용할 수 있을 것이다.
개발팀은 분산되어 있던 소프트웨어 아키텍처를 한 곳에 관리하는 수단으로 활용할 수 있을 것이다.
세일즈팀은 현재 프로세스의 문제점을 도식화하고 이를 해결하기 위한 아이디어를 만드는데 활용할 수 있을 것이다.
해결
우선 원하는 것을 잘 찾기 위해 어떻게 해야 했을까요? 피그마를 켰을 때, 자신과 관련된 것만 눈에 잘띄면 되지 않을까요? 그래서 페이히어는 프로덕트 직군을 위한 워크스페이스와 비프로덕트 직군을 위한 워크스페이스를 나눠서 자신의 업무에 깊은 연관성이 있는 것이 먼저 보일 수 있도록 환경을 구축했어요.
그에 따라 프로덕트 조직은 프로덕트, 애자일 조직에 맞는 파일 구조를 구성할 수 있었고요. 비프로덕트 조직 역시 프로덕트로 인한 폴더 생성에 제약을 없애고 더 자유롭게 피그마를 활용할 수 있게 되었어요.
페이히어 멤버라면 누구나 뷰어권한을 갖고 두 가지 워크스페이스를 넘나들며 확인할 수 있게 했고, 특정 권한(편집/데브모드)이 필요한 분들은 요청을 통해서 해당 워크스페이스 내에서 권한을 부여받는 방식으로 운영하게 되었어요.
환경 변화에는 반드시 교육이 수반되어야 해요. 위처럼 변화된 방식에 대해 전체 공지도 하고, 사람들이 어떻게 활용하면 업무에 도움이 될지 크고 작은 온보딩 세션을 여러번 갖기도 했어요.
결과
이를 통해서 어떤 효과가 있었냐고요? 우선 사람들이 가장 많이 겪는다고 생각했던 파일과 화면 찾기 문제를 해소할 수 있었어요. 이전보다 보기 편해졌다, 찾기 쉬워졌다는 피드백이 개편 이후에 꽤 있었거든요.
그리고 각 팀이 원하는 목적에 맞게 활용하는 사례가 많아졌어요. PM팀은 전략/기획, 개발팀은 아키텍쳐 설계, QM(Quality Management)팀은 테스트를 위한 화면 흐름도를 만들었고, 프로덕트 디비전 뿐만 아니라 CX와 SalesOps팀까지도 피그마를 활용하는 사례를 확인할 수 있었습니다.
기존에도 있었겠지만, 피그마라는 하나의 도구 안에서 모든 팀이 각자의 문제 해결과 기록(아카이빙)하는 것을 확인하고 쌓아지는 것을 보게되니 히스토리 관리 측면에서 앞으로가 기대되더라고요.
마지막으로 어쩌면 가장 임팩트가 클 수 도 있는.. 회사의 비용 절감에도 기여할 수 있었어요. 시스템을 확장하는 것은 필연적이었고, 두 워크스페이스로 관리하는 방법은 비용적인 리스크를 줄이면서 더 커진 시스템으로 만드는 관점에서 좋은 전략이기도 했었거든요.
다음 편에서 계속..
다음 글은 두 워크스페이스 중 프로덕트 조직에서는 어떻게 피그마 환경을 구축했을지에 대해 조금 더 깊은 이야기를 들려드릴게요. (두번째 글 링크는 여기)
그리고 앞으로 페이히어 블로그에도 유익한 글 많이 올라갈 예정이니 지켜봐주세요. 그럼 안녕!
