FramerX가 React를 품은 이유?
#Framer #FramerX #React #ES #왜바꿨냐?
Framer가 바뀜!
FramerX가 발표되고 나서 한동안 디자인 커뮤니티 안에서 많은 이야기가 오갔습니다.
Framer 툴을 애정해왔던 저로서도 많은 변화에 어색하기만 하더군요.
FramerX 관련영상을 보던중, 데모 관련 영상에서 Framer 팀 창업자인 쿤(Koen)이 FramerX는 디자인시스템 타겟하고 있음을 얘기합니다. 공식 블로그에서도 쿤(Koen)이 얘기한 내용을 언급하고 있네요.
더 깊이 들어가기전에 제가 알고 있는 것에 대해 나열해봅니다.
Classic Framer(구 Framer)
영어로 "interactive design for everyone with code" 요렇게 누군가 표현했던 것 같은데,,,,
hi-fi 프로토타이핑 툴로서, 정적 이미지의 표현에서 인터랙티브한 프로토타입으로 표현의 범위를 넓히고, 그렇게 함으로써 커뮤니케이션 코스트까지 줄이는 역할을 해옴
상상을 코딩으로 표현하므로써 발산형 사고를 수렴적 사고로의 훈련을 하기에도 매우 좋은 툴, 즉 코딩 배우기 좋은 툴
한마디로 "상상이 코딩으로 이루어진다"로 표현이 되겠네요. 많이 애정해오던 툴이였는데, 큰 변화로 저도 조금 당황스럽기도하고 조금 아쉽기도하고..
FramerX
아직 잘모름
이런 과감한 변화로의 선택이 매우 궁금
뭐..... 잘 아직 잘모르기 때문에 FramerX를 좀 더 리서치를 좀 해 보았습니다.
수능문제 풀때도 보면, 출제자의 의도를 파악하라고 하죠?(수능은 일단 풀기라도 해야했지만, 이것은 여차하면 안풀어도 되는 문제가 될수 있으니...ㅎ)
Framer를 하나의 문제라고 보면, 문제를 풀어보기 전에 출제자의 의도를 파악해서 내가 진짜 풀어볼법한가 아닌가 판단하기 위해 조사해 봅니다. (Classic 버젼은 "생각을 쉽게 코딩으로 표현한다"는 의미에서 만져볼 만했었습니다)
디자인시스템?
이번 FramerX가 리액트를 품은 이유는 "디자인시스템"이라고 위에서 말씀드렸습니다.
먼저, 왜 디자인 시스템이 필요한가?를 고민해봅니다.
왜?
한가지 서비스를 오래 하다 보면, 여러 팀원들이 몇년에 걸쳐 서비스를 위해 작업을 해나갑니다. 그러다 보면, 디자인의 일관성이 매 작업마다 조금씩 떨어지게 되는 경우를 보게 됩니다.
이렇게 축적된 비일관성은 결국 사용성의 끈김을 초래하기 마련입니다. 개인적으로는 PC와 모바일간의 사용성의 끈김을 디자인의 비일관성을 통해 경험을 하기도 하고 만들기도(ㅠㅠ) 해봤습니다.
그림으로 디자인시스템 맛보기
hubspot는 디자인시스템을 도입하기 전과 후에 대해서 자세하게 블로그에 남겨 놓았습니다.
도입전
한 시점에 얼마나 많은 디자인 컴퍼넌트가 산재해 있었는지 보여줍니다.
출처 hubspot 블로그도입후
많은 UIComponent들이 이전과 달리 매우깔끔하게 정리된 모습
출처 hubspot 블로그디자인시스템은 위의 그림 비교에서 확인 할수 있듯이, 정리가 안된 부분을 좀 더 정리해보자는 문제의식에서 시작이 된다고 이해했습니다.
인비젼 아티클에서는 디자인시스템을 아래와 같이 정의하고 있네요.
A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications
위의 정의를 크게 3개로 나누어 보면
reusable components
guided by clear standards
that can be assembled together to build any number of applications
이것을 한단어로 표현해보면
재사용성
일관성
확장성
위의 세가지 속성을 통해서 회사는 통일된 디자인을 확장성 있고 빠르게 가져 갈수 있게 됩니다.
이것은 회사 입장에서 많은 사람들의 시간을 줄여줄 수 있고, 결국 시간의 절약이 비용의 절감으로 이어진다는 얘기로 이어지게 되겠습니다. 결국 돈이...
AirBnb 나 IBM 등 이미 디자인 시스템을 적극적으로 도입한 회사들의 경우,
공통의 언어를 통해서 이해당사자들에게 협업간 많은 효용성을 얻고 있다고 자랑.. 아니 공유 해주고 있습니다.
AirBnb’s DLS(Design Language System)
shopify's Polaris Design System
디자인시스템 결과물? 응용?
[AirBnb] 디자인시스템 + 인공지능 응용
출처 유투브손그림 to 컴퍼넌트
손으로 슥삭슥삭한 스케치를 인식
슥삭슥삭 스케치를 기존의 디자인시스템에서 해당하는 UIComponent 로 구성 및 배열
[AirBnb] React to Sketch
출처 Airbnb Github리액트를 이용해서 스케치 뽑기
[IBM] Public Carbon Design System
출처 www.carbondesignsystem.comCarbon Design System을 오픈해서 디자이너 개발자 모두 기여 할수 있게 만듬
코드 공개 (리액트 코드)
위의 사례들을 보면, 디자인시스템 도입을 통한 다양한 응용 및 실험들을 해보고 그 결과물들도 나오고 있음을 확인 할 수 있었습니다.
눈치 빠르신 분들 혹은 개발 관심이 많으신 분들은 알수 있는 공통점이 있는데요. 바로 위의 예들은 React 기반의 프로젝트인 점입니다. (Carbon Design System은 React 말고도 Angular, HTML등 다양하게 공유함)
여러 회사들이 React를 기반으로, 그 위에 디자인시스템을 열심히 빌드하고 있는 것을 확인 할 수 있습니다.
FramerX 가 디자인시스템을 품기 위해 왜 React를 선택했는지 명확히 이해가 가는 부분입니다.
React 품기
디자인시스템을 품기 위해 React 를 품어야 하는것은 이제 꽤 일리 있는 의견으로 보입니다.
그렇다고 framer 팀도 분명 React및 ES로의 급진적인 변경은 조심스러웠을 것 같습니다.
그렇기 때문에 쿤은 오랫동안 커뮤니티를 통해 프레이머 사용자들에게 의견들을 받아왔던 것을 알수가 있습니다.
출처: facebook framer group아마 이 설문의 결과도 React와 javascript를 품는 FramerX를 빌드하는데 힘을 실어주지 않았나 싶습니다.
"Interactive prototype" to "Design system"
결국 제품의 방향성을 Interactive prototype tool에서 design system tool로,
제품을 통해 풀려는 문제도 각 툴이 갖는 의미 만큼이나 다르게 변하게 된 것으로 보입니다.
그리고 이러한 피보팅 준비를 꾀나 오랫 동안 커뮤니티를 통해서도 슬쩍쓸쩍하면서 해온것 같아 보입니다.
결국 회사란 집단에선, 불필요한 시간을 줄이므로써 비용 절감을하고, 새로 얻은 시간을 통해서 다양한 시도를 하고, 그것을 통해 이익을 내려고 하는데, 디자인시스템이 그에 걸맞는 도구? 방법?으로 보이는게 현재 업계의 트렌드 입니다.
프레이머 팀도 결국에는 이익을 내야 하는 회사로써, 좀더 크고 임팩트가 클 수 있는 디자인시스템 문제를 건드린것도 자연스럽게 이해가 되긴합니다.
회사 입장에서 볼때, 디자인 시스템을 통해서 시간 절감 및 그것으로 많은 비용을 줄일수 있다면, 리액트 아니 리액트 할아버지라도 도입할수 있다고 생각이 됩니다.
결론
Framer 팀은 디자인시스템을 통한 업무의 효율성 높이는데 FramerX가 역할을 하길 바라는 것으로 보입니다.. 요즘 계속 그렇게 마케팅하면서 밀고 나가고 있습니다.
이것은 분명 기존의 Framer 가 풀려는 문제랑은 결이 달라 보입니다.
인비젼의 디자인시스템 정의에서 3가지 속성(재사용성, 일관성, 확장성)을 React를 이용한 UI Component를 통해 풀려고 함을 확인 할수가 있는데요. 특히, 컴퍼넌트 스토어를 통해서 이런 의도들을 많이 엿볼수가 있었습니다.
출처 프레이머 공식홈물론, 현재 국내의 많은 회사들이 디자인시스템 도입에 얼마나 많은 관심을 가지고 있는지 모릅니다. 피부로 느끼는 것은 아직까진 적어 보입니다.
그럼, 디자인 시스템을 고려하지 않은 회사를 다니는 개인들에게 FramerX는 당장 많은 의미를 없는것일까요?당장은 FrameX를 이용해 디자인시스템을 구축해보자는게 아니면 의미가 적을수 있겠다는게 개인적인 생각입니다.
기존의 프레이머 사용자들에게는 많은 고민을 던져준 FramerX 출시인데요, 주변 분들과 대화를 통해서 얻은 고민들을 몇가지 타입으로 나누어 보면 아래와 같습니다.
내가 생각한 인터랙션을 코드로 표현하고 싶은 사람
React를 심히 고려해보는 사람
디자인 시스템을 빌드 하는(혹은 계획이 있는) 사람
각 타입별로 개인적인 제 생각을 더해 보면 아래와 같습니다.
내가 생각한 인터랙션을 코드로 표현하고 싶은 사람
클래식 Framer를 통해 계속 표현해보는 것도 좋을듯
FramerX를 통해 굳이 표현 하려면 리액트를 배우는 학습시간도 많이 들기 때문에
React를 심히 고려해보는 사람
React를 배워야 하는 이유를 고민해보기, 굳이 FramerX를 쓰기 위해서?라면.. 비추
개발 분야로서 확장을 위해 배우겠다는 이해가 되고, 강추(예를 들면, 웹개발, 퍼블리싱, 앱개발등…)
디자인 시스템을 빌드 하는(혹은 계획이 있는) 사람
현재 UIComponent들이 어떻게 관리 되고 있는지 확인 필요 (현재 서비스에서 UI component들이 얼마나 다양하게 있는지 a.k.a 진짜 끔찍한 작업 or 진짜 대의를 위해 희생할일...., 그리고 혹시 코드로 관리되는지 등등)
어느 시점부터 어떻게 UIComponent들을 코드로 관리 할것인지
리액트로 관리한다면 FramerX를 도입할수 있는 부분은 어디가 있는지
위의 내용은 지극히 주관적인 생각이므로 다양한 의견은 항상 환영입니다.
FramerX 왜 써야하는지 각자 고민을 해보고, 한번 이용해보는 것도 좋을것 같습니다.
코딩을 통해 인터랙션을 구현해보고 싶다하면, 기존의 Framer로도 얼마든지 표현이 가능할것 같습니다.
디자인시스템은 아티클들을 보니 나름 품이 많이 들어가고, 다양한 직군의 동의를 통해서 빌드를 해나가야 할것 같습니다. 이렇게 크고 복잡한 문제일수록.. 작은 문제 부터 하나씩 풀어야 합니다. 당장 비효율적인 것을 찾아내는 것이 디자인시스템 빌딩의 첫걸음 일것 같습니다.
이렇게 오늘은 그동안 출시 이후 시끌시끌했던 FramerX의 배경에 대해 고민해봤습니다.
감사합니다 :)
