피그마의 프로세스
업데이트 방향과 새로운 기능의 가능성
통계를 보니, 많은 브런치 독자님이 '피그마를 시작하자' 글이 많이 찾아주고 계십니다. 그래서 사용자 중심의 작업 원칙에 따라 현재의 피그마 상태를 설명하는 내용을 준비했습니다.
피그마의 업데이트와 변화 방향에 대한 내용입니다.
2023년 10월 기준의 피그마는 초기 모습에 비해서 많은 기능이 추가되었고, 디자인 영역을 넘어서 팀을 위한 도구로 발전했습니다. 20세기에는 프로세스가 도구를 선택했는데, 이젠 도구가 프로세스를 선택하는 것처럼 보입니다.
가장 큰 변화는 2023년에 있었던 Config 2023으로 가장 변화가 큰 업데이트였다고 생각합니다. 협업 디자인 툴로 시작한 피그마는 이제 팀이 문제를 이해하고, 대안을 탐색하며, 해결책을 만드는 것을 돕는 end-to-end 디자인 플랫폼이 되었습니다.
피그마의
작업 공간
처음엔 디자인 영역만 있었던 피그마는 지금 피그잼과 디자인 영역으로 나뉘었습니다.
2023년 하반기에는 디자인 부분에 Dev Mode가 추가 되었습니다.
피그마로 디자인을 하기 위해서는 피그마 구독이 진행되고, 피그잼은 별도로 구매해야 합니다. 프로패셔널 기준으로 피그마는 연간 구독 시 12달러, 피그잼은 3달러입니다.
모든 팀원이 피그잼과 피그마를 구독할 필요는 없지만, 재택 근무 등으로 아이데이션이 필요하고, 피그마로 통합 관리하고 싶다면, 피그잼 사용이 효율적일 수 있습니다. 무료로 3개의 피그잼 보드를 만들 수 있습니다.
FigJam
초시계와 포스트잇을 사지 않아도 됩니다!FigJam은 피그마와 별도로 과금이 됩니다. 그래서 피그잼과 피그마를 함께 사용하면, 비용이 2배가 됩니다. 온라인 화이트보드 중에서 Miro처럼 대안이 많기 때문에 꼭 구매하지 않아도 되지만, 구매한다면, 피그마 플랫폼 안에서 관리할 수 있는 점은 편리합니다.
FigJam은 가상의 화이트보드로 서비스, 제품, 시스템의 설계와 아이디어 발상에 유용한 템플릿을 제공하는 온라인 화이트보드입니다. 가상의 공간을 활용하면, 포스트잇으로 벽을 도배하지 않아도 되고, 아이디어와 콘셉트를 스케치하기도 쉽습니다.
피그마 웹사이트에서 템플릿을 살펴보면, 분류에 따라 다양한 템플릿이 있습니다. 알려져 있는 거의 모든 다이어그램과 방법론 도식을 확인할 수 있었습니다.
그런데 스타일이 약간 캐주얼한 편입니다. 최근 아이데이션 툴이나 문서 툴은 아이디어를 잘 표현하기 위해 일부러 정교하지 않게 만든다고 합니다. 형식을 구체적으로 만들면, 아이디어에 집중할 수 없다고 합니다.
정교한 오브젝트가 필요한 경우, 피그마의 작업을 복사해서 FigJam으로 붙여 넣기도 할 수 있습니다.
Dev Mode
디자인 영역은 디자인 - 프로토타이핑 - 데브 모드로 구분되어 있습니다. 화면이 아주 나누어있지 않고, 필요에 따라 UI가 변하면서 작업 공간이 변하게 됩니다. UI는 다르지만, 겹쳐 있는 구성은 하나의 제품을 보는 디자이너와 개발자의 시각 차이를 보여줍니다.
디자이너에게 가장 극단적인 부분이 Dev Mode입니다. 이 부분은 일반적인 디자이너는 보지 않겠지만, 퍼블리싱이나 디자인 시스템 구성 시의 문제를 해결하려면 어느 정도 보는 법만 알면 됩니다.
섹션을 설명할 때, 대략적인 흐름을 만들었는데요, 실제 사례가 필요해서 이 부분은 추후 별도로 다루겠습니다. 프런트엔드 개발자 중에 관심이 있는 분이 있다면, 좋겠네요.
실무를 바꾸는
프로세스
플랫폼 관점에서 피그마의 각 영역을 Board, Design, Prototype, Dev Mode로 나누어 업무 절차에 대입하여 보았습니다.
전통적인 직군 구성의 경우, 기획자가 기획 문서를 만들고, 디자이너가 디자인을 하고, 가이드와 이미지 파일을 만든 후, 개발자에게 전달합니다. 이 시기에는 포토샵, 스케치와 피그마의 차이는 협업 방식이었습니다. 디자이너가 분업을 하거나 디자인 작업을 중간에 다른 직군이 참여하여 커뮤니케이션하는 정도였습니다.
조금 더 발전된 체계에서는 기획(설계) 직군이 피그마로 기획 문서를 작성하는 방법을 시도하고, 디자이너는 UX/UI 역할을 맡기 시작했습니다. 개발 직군은 프런트엔드와 백엔드로 나뉘어서 프런트엔드 개발자의 참여가 많아졌습니다.
피그마에서 개발자에게 결과물을 전달하는 기능이 개선되었습니다.
프로덕트 디자이너의 장점은 제품의 목적성과 일관성이 유지되기 쉽고, 제품의 질을 높일 수 있다는 점입니다. UX 디자인 영역이 분화되면서 더 실무적인 부분이 강조되기 시작했습니다. 피그잼의 활용이 많아지고, 피그마로 설계부터 시작하는 경우가 많아졌습니다.
프로덕트 디자인 개념의 문제는 이론은 이상적이지만, 역할과 책임을 부여하는 것이 어려워졌습니다. 모든 팀원이 모든 책임을 지거나, 아무도 책임지지 않는 상황도 발생할 수 있습니다. 또 프로덕트 디자이너는 설계, 기획, UX, 비즈니스의 부담이 커졌고, 프런트엔드 개발자는 디자인 부담이 커졌습니다. 디자인 시스템이 많아지면서 제품을 만들기 위한 제품도 개발해야 하는 부담도 생겼습니다.
피그마가 플랫폼으로 제시하는 해결책은 아이디어와 제품 개발, 공유를 구분하여, 반복(이터레이션) 부분의 효율성을 높이는 것이었습니다. 효율성은 디자인과 프로토타이핑의 반복 구간에서 디자인 영역의 일부를 개발 영역에 가깝게 하면서 높아졌습니다.
배리어블을 적용하여, 프로토타입의 멀티 디바이스나 플랫폼에 대한 디자인의 적응력을 높이고, 개발에서 유용한 최대, 최소 개념과 컨테이너의 폭에 따른 정렬 방식을 개선해서, 디자인을 더 빨리 코드로 전환하는 효율성을 제시했습니다.
디자이'너'가 아니라 디자인으로 구분해야 한다피그마의 디자인 - 반복 - 공유라는 생각이 다시 팀에 영향을 준다면, 적절한 방식으로 작업 영역의 부담이 줄어들면서 특정 부분으로 집중될 것으로 예상됩니다.
프로덕트 디자인의 부담이 실제 제품 개발로 집중되고, UX 디자인은 더 실질적인 프로토타이핑을 경험할 수 있고, 디자인 시스템 제작은 기존 방식보다 개발에 더 가까운 방식으로 시작되고, 프런트엔드 개발자의 디자인 영역에 대한 부담이 줄어들 것으로 보입니다.
FigJam에서 시작하여, Dev Mode까지 함께 진행하면, 모든 팀원이 프로덕트 제작의 처음과 끝까지 참여하고 기여할 수 있습니다. 일정과 진행에 대한 정보도 모두와 공유할 수 있습니다.
그래서 한 사람이 프로세스를 진행할 때는 아이디어와 제작의 구분이 명확하고, 팀으로 작업할 때는 각 영역에 투입하는 인원과 역량에 따라서 제품 개발이 아이디어의 실현인지, 심도 있는 개발인지, 성장을 위한 개선인지 구분할 수 있을 것 같습니다.
문서, 공간, 디자이너
포토샵으로 진행되는 협업은 PSD 파일의 공유로 이루어졌고, PSD 파일의 구성 중에서 레이어의 이름과 정리 방식이 중요했습니다.
피그마도 Figjam Board와 Figma Design 파일을 PSD 파일처럼 사용할 수 있습니다. 하지만 피그마는 문서처럼 규약을 갖춘 PSD파일을 납품하지 않고, 피그잼, 피그마 캔버스와 같은 작업 공간의 권한을 통제하는 방법으로 작업을 공유합니다.
실제로 포토샵으로 PSD 파일을 공유하려면, 상대방이 포토샵을 설치해야 합니다. 하지만, 피그마는 피그마를 설치하지 않아도, 작업에 참여할 수 있습니다.
문서를 전달하는 대신, 문서를 작성하는 사무실의 출입 권한을 제한하는 방식으로 작업을 공유하는 것으로 비유할 수 있습니다. 단, 에디터로 참여할 때 자동으로 과금이 되어 청구되니 조심하세요.
마무리...
디자이너의 역할은 시간과 시장에 따라 항상 변했습니다.
문제는 이 역할이 항상 회사마다 다르고, 업계를 주도하는 회사의 방식을 도입하려는 회사가 많다 보니, 뭔가 이상한 방식으로 디자이너의 역할이 정의되는 경우가 많습니다. 그래서 역할을 정할 때, '어떤 일'에 집중하는지 피그마의 기준을 적용해 보는 것도 좋겠다는 생각이 듭니다.
