대규모 설계: Figma와 함께 1년

이 기사에서는 대규모 팀이 보다 개방적이고 협업적인 도구를 사용하여 이점을 얻을 수 있는 방법과 채택 및 마이그레이션을 실현 가능하고 즐겁게 만드는 방법에 대해 설명합니다. 또한 기사 제목에서 아직 짐작하지 못하셨다면 Figma와 우리 팀에서 이 디자인 도구를 채택하는 데 성공한 방법에 대한 내용이 대부분일 것입니다.

대상 대상은 디자인 시스템이 있는 대규모 팀에서 일하는 경험 많은 디자이너, 개발자 또는 제품 관리자가 조직 내에서 교차 기능 팀이 작업하는 방식을 개선하고자 하는 것입니다.

저는 10년 이상 전문적인 환경에서 디자인 도구를 사용해 왔으며, 항상 제가 봉사하는 팀을 보다 효율적이고 효과적으로 만들기 위해 노력하고 있습니다. Photoshop의 스크립팅 및 작업부터 Axure의 위젯 라이브러리, Sketch 플러그인, 그리고 이제 Figma까지 — 저는 개발자나 제품 관리자를 뒤처지게 하지 않고 디자인 팀이 최첨단을 유지할 수 있도록 도왔습니다.

디자인 시스템 및 도구에 대한 기본 지식이 도움이 될 것이지만 특정 예와 팀 또는 상황에 맞게 조정할 수 있는 "고수준" 개념 및 방법을 공유하기를 희망하므로 필요하지 않습니다.

2015년경의 설계 워크플로

2015년에 우리의 주요 도구는 스케치였으며 공통점이 거의 거기서 멈추었습니다. 우리 모두는 이해 관계자(InVision, Axure, Marvel, Google Slides 및 구식 Adobe PDF) 및 개발자(Avocode, Zeplin, Measure와 같은 독립 실행형 앱이 없는 플러그인)와 디자인을 프로토타이핑하고 내보내고 공유하는 서로 다른 방법을 사용했습니다. 드문 경우지만 MacBook과 Sketch 라이선스의 희귀한 조합을 가질 만큼 운이 좋은 엔지니어에게 직접 파일을 보낼 수 있었습니다.

InVision이 Craft 플러그인을 출시했을 때 우리는 매우 기뻤습니다. Sketch에서 InVision으로 화면을 프로토타입 및 업로드할 수 있고 파일 간에 초기 라이브러리의 구성 요소와 스타일을 공유할 수 있는 것은 디자이너의 꿈이 실현된 것이었습니다.

결국 우리는 모두 InVision 플랫폼으로 수렴했습니다. 우리는 이해 관계자 협업 및 개발자 핸드오프에서 많은 마찰을 줄이는 데 도움이 되는 프로세스를 만들고 문서화했습니다. 그러나 복잡한 권한 구조로 인해 InVision은 폐쇄된 생태계로 남아 있었습니다. 디자이너가 아닌 경우 InVision 계정을 얻기 어렵게 만드는 승인 체인이 있었고 일단 계정을 얻으면 추가해야 했습니다. 올바른 그룹에.

버전 및 파일을 수동으로 관리하고, 공유 드라이브에 저장 및 구성하고, 동기화 충돌을 처리하는 것은 우리에게 많은 골칫거리를 일으킨 몇 가지에 불과했습니다.

Google 문서도구의 실시간 협업 및 커뮤니케이션 기능과 함께 Sketch 및 InVision의 최고의 기능을 모두 갖춘 올인원 도구가 과연 있을 수 있을까요? 컨텍스트 전환으로 인한 오버헤드를 줄이는 것 외에도 세 가지 도구 구독(목업, 프로토타이핑 및 개발자 핸드오프)에서 하나만으로 단순화할 수도 있습니다.

과정

우리 팀의 첫 번째 디자이너가 Figma를 채택한 2016년 첫 번째 Figma 베타가 출시되었을 때 이를 실험하기 시작했습니다. 기능은 제한적이었지만 우리가 필요로 하는 것의 80%를 차지했습니다. 스케치 가져오기는 버그가 있었지만 실시간으로 협업할 수 있다는 점에서 여전히 엄청난 가치를 발견했으며 가장 중요한 것은 단일 도구 내에서 프로젝트의 디자인 작업의 90%를 수행할 수 있다는 것입니다. 이해 관계자 피드백, 수정 및 개발자 핸드오프가 기하급수적으로 향상되었습니다.

2017년까지 몇몇 디자이너가 대부분의 작업에 이를 사용했고 Lexicon 디자이너(Liferay의 디자인 시스템) 중 한 명인 Emiliano Cicero는 빠르게 전도자가 되었습니다. 팀을 전환합니다.

Figma 2.0이 2017년 여름에 선보였을 때 프로토타입 기능이 추가되고 개발자 핸드오프 기능이 크게 개선되었을 때 이것이 우리 글로벌 팀을 위한 실행 가능한 도구가 될 수 있다는 것을 알았습니다. 하지만 20명 이상의 디자이너가 수년간 편안하게 사용했던 도구와 워크플로를 포기하도록 설득하는 방법은 무엇입니까?

그 주제에 대한 시리즈를 작성할 수도 있지만 가장 큰 두 가지가 바로 작게 시작 하고 견고한 인프라 를 구축하는 것이라고 요약하겠습니다.

작게 시작하기

2017년 가을, 우리는 미국과 브라질에 분산된 제품 팀과 함께 Figma의 첫 번째 시험을 시작했습니다. 우리는 운 좋게도 로스앤젤레스 사무실에서 함께 일주일 간의 시작을 알렸습니다. Figma에서 흐름과 와이어프레임을 함께 설계하는 것이 훨씬 빠르고 효율적이었습니다. 폴더나 라이브러리의 지속적인 동기화에 대해 걱정할 필요 없이 작업을 분할하고 파일과 구성 요소를 공유할 수 있었습니다.

2018년 1월의 글로벌 모임에서 우리는 이 팀의 경험을 사용하여 조직의 나머지 부분에 필요한 인프라를 형성하는 데 도움을 주어 마이그레이션이 최대한 원활하게 이루어질 수 있도록 천천히 Figma를 채택할 계획을 세웠습니다.

우리가 직면한 가장 큰 과제는 촉박한 기한이었습니다. 전 세계에 분산된 여러 엔지니어링 팀과 제품 관리자가 있는 프로젝트의 규모로 인해 검토 및 전달 프로세스를 재작업하는 것은 의미가 없었습니다. 최종 결과가 더 좋았을 지라도 타이밍이 맞지 않았습니다. 또 다른 요인은 Figma의 안정적인 오프라인 디자인 경험이 부족했기 때문입니다 (자세한 내용은 나중에 설명) . 이러한 이유로 팀은 와이어프레임과 목업에 Sketch와 Figma를 사용하기로 결정했지만 모든 프로토타입이나 검토는 InVision에서 수행해야 했습니다.

견고한 Figma 구조 만들기

첫 번째 단계 중 하나는 프로젝트, 파일 및 구성 요소 구성에 대한 대략적인 지침을 공식화하는 것이었습니다. 이러한 것들의 기초는 두 명의 주니어(당시) 디자이너 Abel Hancock과 Naoki Hisamoto에 의해 시작되었습니다. 이들은 Photoshop에서 이를 잘 아는 디자이너에게서 오는 나쁜 레이어 이름 지정 습관을 전혀 개발하지 않았습니다. Liferay.com 자산을 위한 작은 구성 요소 라이브러리를 개발하는 데 1년을 소비한 것과 함께 이 구성 방법은 나머지 글로벌 팀을 성공으로 이끄는 데 중요했습니다.

Ben의 트윗에서 영감을 받아 Liferay.com 디자이너 중 한 명이 만든 초기 조직 개선 은 표지 시스템이었습니다 .

복사하려는 경우 이 파일을 사용할 수 있도록 했습니다. 그렇지 않으면 매우 간단한 해킹입니다.

1. 파일의 첫 페이지에 620×320 크기의 단일 프레임을 만듭니다.
2. 디자인을 추가합니다. 텍스트가 있는 경우 최소 크기가 ~24이고 예제의 제목은 48로 설정되어 있습니다.
3. 즐기다!

참고: 표지 주변에는 항상 약간의 여백이 있지만 페이지 캔버스를 카드와 같은 색상으로 설정하면 이 여백의 모양이 줄어듭니다.

이는 디자이너뿐 아니라 프로젝트 및 제품 관리자와 빠르게 물건을 찾으려는 엔지니어를 위해 라이브러리를 변환하는 데 도움이 되었습니다. 검색 기능은 이미 훌륭했지만 표지는 사람들이 범위를 더 빨리 좁히는 데 도움이 되었고 주어진 파일의 상태를 즉시 전달할 수 있게 해주었습니다.

Figma를 사용하기 전에 '마스터' 디자인 시스템 Sketch 파일 외에도 대부분의 디자이너는 와이어프레임 요소 및 기본 구성요소와 같은 시간에 따라 개발한 기본 파일을 가지고 있었습니다. 하나의 패턴으로 통합되면서 모든 것을 결합하고 하나의 라이브러리로 정제하기 시작했습니다. 우리는 Figma에서 와이어프레임, 목업 및 프로토타입을 만들고 있었기 때문에 Figma에서 자체 작업 흐름 구성 요소를 만드는 대신 Lucidchart와 같은 흐름 앱을 포기하기 시작했습니다.

우리가 시간이 지남에 따라 개발한 다른 유틸리티는 정확한 핸드오프 사양을 만들기 위한 레드라인 구성 요소, 선호도 다이어그램(및 거의 모든 것)에 대한 스티커 메모 및 흐름 노드였습니다.

Figma에서 이 작업을 수행할 때의 가장 큰 이점 중 하나는 모든 디자이너가 만든 이러한 구성 요소에 대한 개선 사항을 라이브러리로 쉽게 가져온 다음 모든 인스턴스에 푸시할 수 있다는 것입니다. 이를 중앙 집중식으로 두면 팀의 누구나 비교적 간단한 프로세스로 개선에 기여할 수 있으므로 유지 관리가 훨씬 쉬워집니다.

수정 지시 문서 는 개발자가 UI 구성 요소 또는 구성 요소 집합의 치수, 시각적 사양 및 기타 속성을 더 쉽게 알 수 있도록 하기 위한 것입니다. 이 주제에 관심이 있다면 Dmitriy Fabrikant의 설계 청사진에 대한 기사도 확인할 수 있습니다.

구성 요소를 생성할 때 염두에 두어야 할 몇 가지 권장 사항:

1. 강력한 기본 구성 요소에 대한 재정의 및 마스터 사용(자세한 내용은 여기)
2. 명명에 대한 일관된 패턴을 설정합니다(우리는 원자 모델을 사용합니다).
3. 모든 것, 특히 레이어를 문서화하고 레이블을 지정합니다.

2017년 6월 초에 출시된 고급 스타일링 기능으로 시스템 팀은 7월의 대규모 제품 출시와 8월의 출시 사이에 Lexicon 라이브러리의 전체 버전을 완성했습니다. 이것은 우리가 글로벌 팀을 지원하는 데 필요한 마지막 조각이었습니다. 마케팅 및 기타 부서에서 일하는 디자이너는 이미 Figma를 사용한지 꽤 되었지만 지난 가을까지 거의 모든 다른 제품 팀이 Figma로의 전환을 완료했습니다.

현재 대부분의 제품 디자이너는 Figma만 사용하고 있으며, Figma로 가져올 가치가 없는 기존의 복잡한 Sketch 프로토타입이 많이 있는 레거시 시스템에서 작업하는 디자이너도 몇 명 있습니다. 또 다른 예외는 가끔 Figma에서 할 수 없는 고급 애니메이션을 위해 Principle 또는 Adobe After Effects와 같은 앱을 사용하는 일부 디자이너입니다. 우리는 특히 모든 종류의 데이터를 대규모로 활용해야 하는 작업에서 더욱 강력한 프로토타입을 위해 Framer X를 탐색하는 디자이너도 몇 명 있습니다. 일부 디자이너는 정기적으로 여러 도구를 사용하지만 제품 디자이너의 80%는 모든 디자인 및 프로토타이핑 작업에 Figma를 사용합니다.

지속적인 개선

우리는 항상 보다 효과적으로 작업할 수 있는 방법을 연구하고 있으며 현재 반복하고 있는 것 중 하나는 페이지 이름 지정에 대한 모범 사례입니다. 처음에는 페이지 이름에 따라 페이지 이름을 지정했지만 문제가 있음이 판명되었으며 라이브러리를 개선함에 따라 여러 페이지가 포함된 더 큰 파일의 필요성이 줄어들었습니다.

현재 우리는 파일 내에서 번호 매기기 시스템을 사용하고 있으며 개발자에게 전달되는 최상위 페이지가 있습니다. 오늘날 우리가 논의하고 있는 다음 단계는 명시적 레이블(와이어프레임, 목업, 중단점 등)을 사용하여 버전을 보다 의미 있게 만들고 Figma의 기본 제공 버전 관리를 더 잘 활용하여 버전을 저장하는 시기와 방법에 대한 모범 사례를 수립하는 것입니다.

Final_Final_Last_2 — 이제 그만!

나는 일반적으로 '게임 체인저'라는 용어를 사용하는 것을 싫어하지만, Figma가 지난 3월 버전 기록에 이름 지정/주석을 추가했을 때 파일 구성 방식이 크게 바뀌었습니다. 이전에는 반복 및 버전을 저장하는 방법이 모두 달랐습니다.

일반적으로 우리는 단일 파일 내에서 새 페이지를 생성하고 때로는 큰 파일을 사용하여 페이지를 복제하고 파일 이름 끝에 문자를 추가하여 반복 신호를 보냅니다. 과감한 변경을 수행하려는 경우 새 파일을 만들고 버전 번호를 추가할 수 있습니다. 이것은 모든 것에 대해 여러 파일을 관리하는 Photoshop/Sketch 패러다임에서 비롯된 매우 자연스러운 일이었습니다.

특정 시점의 이름을 지정하고 주석을 달기 위해 주기적으로 일시 중지하고 작업하는 기능은 이전에 Git과 같은 버전 제어를 사용한 적이 있는 사람에게 매우 친숙할 것입니다. 전체 파일 기록을 보고 과거 스냅샷으로 이동하여 하나를 선택하고 이름을 지정하고 주석을 달 수도 있습니다.

돌아가서 과거 버전으로 되돌리려면 복원하고 기록의 해당 지점에서 해당 파일에 대해 작업할 수 있습니다. 가장 좋은 점은 '복원'한 버전이 아무 것도 삭제하지 않았기 때문에 작업을 잃지 않았다는 것입니다. 그것은 단순히 그 상태를 복사하여 상단에 붙여넣는 것이었습니다.

이 그림에서 디자이너는 final 1.1 을 복원한 후 final 3.0 에 도달했지만 파일 버전 기록은 여전히 ​​완전히 표시되고 액세스할 수 있습니다.

새 프로젝트를 시작하거나 파일을 정말 극적으로 변경하려는 경우 파일을 '포크'해야 할 수 있습니다. Figma를 사용하면 기록의 특정 지점에서 파일을 복제할 수 있지만 파일 기록은 복사 되지 않는다는 점에 유의해야 합니다.

이 버전 시스템에서 작업하는 좋은 방법은 개발자가 git을 사용하는 것과 유사한 방식으로 파일 기록을 사용하는 것입니다. Figma 버전을 커밋 또는 풀 요청으로 생각하고 다음과 같이 이름을 지정하고 주석을 추가합니다. 그런. 이에 대한 더 똑똑한 생각을 하려면 Seth Robertson의 Commit When, Perfect Later, Publish Once: Git Best Practices 를 추천합니다. 이것은 버전 제어 에코시스템에서 작업하는 방법에 대한 좋은 일반 철학입니다. 또한 Chris Beams의 Git 커밋 메시지 작성 방법 은 작업하면서 의미 있고 유용한 메모를 작성하기 위한 훌륭한 가이드입니다.

우리가 발견한 몇 가지 실용적인 팁:

1. 제목을 25자 이하로 유지하십시오 .
   더 긴 제목은 잘리므로 버전 기록에서 메모를 두 번 클릭하여 '버전 정보 편집' 모달을 열어 읽어야 합니다.
2. 설명을 140자 이하로 유지하십시오 .
   전체 설명이 항상 표시되므로 요점만 유지하면 기록을 읽을 수 있는 상태로 유지하는 데 도움이 됩니다.
3. 제목에 명령형 분위기를 사용하십시오 .
   이렇게 하면 "버튼 색상을 파란색으로 변경" 대 "버튼을 파란색으로 변경"과 같이 해당 시점을 클릭할 때 어떤 일이 일어날지 미래에 더 명확하게 알 수 있습니다.
4. 설명을 사용하여 '무엇'과 '왜' 대 '어떻게'를 설명합니다 .
   '이유'에 답하는 것은 모든 디자이너 작업의 중요한 부분이므로 작업할 때 중요한 것에 집중하고 앞으로 더 나은 정보를 제공하는 데 도움이 됩니다.

오프라인 작업

면책 조항: 이것은 우리 자신의 경험을 기반으로 하며 대부분이 작동 방식에 대한 최선의 추측입니다.

앞서 언급했듯이 Figma의 오프라인 지원은 미약합니다. 오프라인으로 전환하기 전에 이미 파일이 열려 있는 경우 파일 작업을 계속할 수 있습니다. 변경할 때마다 타임스탬프가 찍힌 것 같습니다. 오프라인 상태에서 다른 사람이 동일한 파일 에 대해 작업하는 경우 온라인으로 다시 전환되면 최신 변경 사항이 렌더링됩니다.

이 간단한 예에서는 그렇게 큰 문제가 아닌 것처럼 보이지만 실제 생활에서는 매우 복잡하고 빠르게 진행될 수 있습니다. 누군가가 작업을 무시할 가능성이 높을 뿐만 아니라 프레임과 그룹이 서로 겹쳐질 수 있습니다.

우리의 워크플로는 오프라인이 되기 전(또는 후에) 페이지를 복제한 다음 해당 복사본에서 작업을 수행하는 것입니다. 그렇게 하면 온라인 상태로 돌아올 때 변경되지 않고 필요한 병합을 수동으로 수행할 수 있습니다.

"F"는 미래를 위한 것입니다

새로운 도구를 채택하는 것은 결코 쉬운 일이 아니지만 결국에는 비용보다 이점이 훨씬 클 수 있습니다.

우리 팀이 경험한 가장 큰 개선 영역:

• 협동
  팀 및 커뮤니티와 작업 및 개선 사항을 공유하는 것이 훨씬 쉽습니다.
• 투명도
  기본적으로 열려 있는 시스템은 자연스럽게 디자인 분야 외부의 사람들에게 더 포괄적입니다.
• 진화
  설계자와 엔지니어 사이의 "계층"을 제거하여 설계 성숙도의 다음 단계로 나아갈 수 있습니다.
• 운영
  와이어프레임, 모형, 프로토타입 및 개발자 핸드오프를 위한 단일 도구를 채택하면 회계, IT 및 관리 작업이 더 쉬워집니다.

전체 구독 수를 줄이는 것은 우리 팀에 정말 도움이 되었지만 비용은 '무료'에서 연간 $500 이상까지 다양할 수 있으므로 특정 상황과 요구 사항에 맞지 않을 수 있습니다. 전체 분석은 Figma의 가격 페이지를 참조하십시오.

성장하고 더 나아지기

물론 완벽한 도구는 없으며 항상 개선의 여지가 있습니다. 우리가 사용한 이전 도구에서 누락된 몇 가지 사항은 다음과 같습니다.

1. 플러그인 생태계가 없습니다 .
   Sketch의 확장성은 Photoshop에서 간단하게 전환하는 데 큰 역할을 했습니다. Figma에는 웹 API가 있지만 현재 '쓰기' 기능은 없습니다. 현재 Sketch는 활발한 확장 및 플러그인 커뮤니티를 통해 시장 리더로 남아 있습니다. (물론, Figma가 플러그인 개발 단계도 열어준다면 앞으로 상황이 바뀔 수도 있습니다.)
2. 프로토타입에서 웹 또는 JSON 데이터 가져오기 .
   실제 데이터로 설계하는 것이 훨씬 쉬울 것입니다. Sketch는 최근 v.52에서 "데이터" 기능을 도입했습니다. InVision의 Craft 플러그인은 많은 양의 다양한 데이터를 쉽게 추가할 수 있다는 점에서 여전히 최고의 표준입니다. 현재로서는 수동으로 텍스트 필드를 채우는 데 어려움을 겪고 있습니다.
3. 더 많은 움직임 .
   Principle 통합은 훌륭하지만(Principle이 있는 경우) Figma에 기본 애니메이션과 고급 프로토타이핑 기능이 있으면 훨씬 더 좋습니다.
4. 더 부드러운 오프라인 경험
   이전에 언급했듯이 오프라인으로 전환하기 전에 Figma 파일을 열어 두기만 하면 문제가 없습니다. 이것은 아마도 대부분의 사람들에게 괜찮을 것입니다. 그러나 매일 밤 컴퓨터를 종료하고 싶다면 기차나 비행기에서 아침에 컴퓨터를 열고 Figma를 열어 두는 것을 잊었다는 것을 깨달을 때 고통스러울 수 있습니다.

오픈 소스 디자인

몇 달 전 항상 논란이 되고 있는 Dann Petty는 최근 트윗을 통해 개발자에게는 GitHub가 있고 사진 작가는 Unsplash가 있지만 디자이너는 무료로 공유할 수 있는 플랫폼이 없다고 트윗했습니다. Design Twitter️가 습격하여 내가 스크린샷을 찍기도 전에 자신의 트윗을 삭제했습니다. 하지만 한 가지 언급하고 싶은 것은 Liferay에서 우리가 매우 열정적으로 여기는 것은 오픈 소스라는 것입니다. 이를 위해 디자인 커뮤니티와 공유할 리소스를 위해 Figma 프로젝트를 만들었습니다.

이 파일에 액세스하려면 liferay.design/resources/fiigma를 확인하고 우리가 더 많이 성장하고 공유할 때 계속 지켜봐 주십시오!

추가 읽기

• "Figma를 사용한 첫 6개월", Danny Saltaren
• "디자인 팀의 구성 요소 라이브러리 구축 시작 신호를 기다리고 있습니까?", William Newton
• Nicole Saidy, "Figma를 사용하여 UI/UX 워크플로를 간소화하는 방법"
• "Figma 조직에서 팀 시작하기", Thomas Lowry
• "Figma에서 페이지를 사용하여 워크플로를 구성하는 5가지 방법", Josh Dunsterville
• "모범 사례: 구성 요소, 스타일 및 공유 라이브러리", Thomas Lowry
• "Figma: 구성 요소가 포함된 타이포그래피에 대한 유체 및 모듈식 디자인 접근", Mirko Santangelo

기타 리소스

• 스펙트럼의 Figma 커뮤니티
• David Ukauwa의 Figma 디자인 핸드북