스케치 파일 최적화: Reduce 앱 생성에서 배운 교훈(사례 연구)

Sketch는 파일 크기에 대한 완전히 새로운 표준을 가져왔습니다. 더 이상 10GB Photoshop 파일이 곳곳에 표시되지 않습니다. 그럼에도 불구하고 거대한 Sketch 파일이 존재하며 Sketch가 느려집니다. 결과적으로 생산성도 저하됩니다.

솔직히 말해서 마법처럼 커지는 것은 디자인 파일이 아닙니다. 불필요한 공간을 차지하는 사용되지 않고 최적화되지 않고 숨겨진 요소로 파일을 채우는 것은 디자이너입니다.

저희 스타트업인 Flawless App에서 이 문제에 직면했습니다. 우리는 각 제품에 대해 별도의 스케치 파일을 가지고 있는 경향이 있습니다. "제품"이란 핵심 메뉴 표시줄 응용 프로그램, 웹 사이트, 소셜 자료, 보도 자료, Medium 블로그의 기사 삽화 등을 의미합니다. 이러한 파일은 다양한 디자인 결정에 대한 끊임없는 반복과 테스트로 인해 시간이 지남에 따라 많이 증가했습니다. 결과적으로 Sketch가 적절한 성능으로 관리하기가 점점 더 어려워졌습니다.

다른 엔지니어들이 하는 것처럼 우리는 자동으로 Sketch 파일을 정리하고 최적화하는 작은 스크립트를 작성하기로 결정했습니다.

스크립트는 훌륭합니다. 즉, 터미널과 같은 언어를 사용하는 경우입니다. 결국 우리는 팀의 더 많은 사람들이 사용할 수 있도록 더 인간적인 접근 방식이 필요하다고 결정했습니다. 우리는 또한 그것을 무료로 만들고 나중에 공개적으로 사용할 수 있기를 원했습니다.

최초의 프로토타입

UI를 그리기 전에 몇 가지 추상적인 개념을 염두에 두었습니다. 주요 목표는 항상 손끝에서 바로 사용할 수 있는 것을 만들고 가능한 한 빨리 파일을 최적화할 수 있도록 하는 것이었습니다. 메뉴 표시줄 응용 프로그램은 확실한 선택이었습니다.

1. 우리는 이미 많은 사용자 정의 기능이 구현된 메뉴 모음 애플리케이션을 위한 내부 프레임워크를 가지고 있었습니다. 몇 가지 배경 설명을 하자면: 당사의 핵심 제품인 Flawless App은 예상 디자인과 개발자의 구현을 실시간으로 비교하는 메뉴 표시줄 응용 프로그램입니다. 이 내부 프레임워크는 핵심 제품을 위해 구축되었습니다.
2. Sketch가 열려 있지 않은 경우에도 메뉴 모음 응용 프로그램을 사용할 수 있습니다.
3. 기본 macOS 앱을 개발하는 것이 CocoaScript를 사용한 Sketch 플러그인보다 훨씬 더 빨랐습니다(이전 경험 덕분에).

또한 사용자에게 다양한 파일에 대해 다양한 최적화 옵션을 토글할 수 있는 기능을 제공하는 것이 중요했습니다.

다음은 멋진 프로토타이핑 도구 없이 구식 종이에 그려진 최초의 와이어프레임입니다.

교훈 #1

UI, 멋진 도구로 프로토타입 또는 종이에 와이어프레임을 만들기 전에 디자인으로 달성해야 하는 목표가 무엇인지 생각해 보세요. 누가 그것을 사용하고 사용자가 응용 프로그램과 어떻게 상호 작용할 것입니다.

컬러 팔레트와 타이포그래피

팀과의 토론에서 우리는 와이어프레임에서 중요한 UX 문제를 찾지 못했습니다. 색상 팔레트를 만들고 글꼴 스키마를 선택하여 시작했습니다.

우리의 핵심 제품인 Flawless App과는 다른 가볍고 시각적인 애플리케이션을 원했습니다. 그래서 나는 다음 팔레트를 생각해 냈습니다.

첫 번째 행은 텍스트 색상을 위한 것입니다(시작 부분의 밝은 배경 추가). 두 번째 행은 강조 색상을 위한 것입니다. 모든 색상은 HSB 색상 시스템에 대한 간단한 규칙을 적용하여 하나의 기본 강조 색상에서 파생되었습니다(H는 색조, S는 채도, B는 밝기).

HSB에서 (212, 67, 89)인 #4A90E2(파란색)의 기본 색상이 있다고 가정해 보겠습니다. 조금 더 어두운 색상을 얻으려면 밝기를 낮추고 채도를 높이고 색조를 약간 움직여야 합니다. 따라서 HSB에서 (210, 82, 79)인 #2477C9를 얻습니다. 다른 모든 색상에 대해 동일한 접근 방식을 사용했습니다.

결국 나는 첫 번째 색상 팔레트(주황색)를 선택했습니다. 스케치 파일과 스케치 로고도 주황색이므로 애플리케이션이 더 유기적으로 보입니다.

교훈 #2

색상은 항상 저에게 까다로웠습니다. 나는 보통 딱 맞는 색상을 찾는 데 많은 시간을 할애합니다. 다음은 색상 탐색에 도움이 되도록 거의 매일 사용하는 몇 가지 리소스입니다.

• Adobe Kuler를 사용하면 모든 색상에 대한 색상 컴패니언을 찾을 수 있습니다.
• Khroma는 기본 설정에 따라 색상 팔레트를 생성하는 AI 기반 도구입니다.
• Erik Kennedy의 기사 "Color in UI Design: A (Practical) Framework"은 순수한 보석입니다. 약 8개월 전에 읽었고 그 이후로 Sketch에서 HSB 색상 시스템을 RGB보다 훨씬 더 많이 사용했습니다.

타이포그래피와 관련하여 대부분의 경우 사용자 지정 항목을 구축하지 않는 한 기본 macOS 응용 프로그램의 기본 글꼴을 사용하는 것이 가장 좋습니다. 렌더링 시간이 더 빨라지고 개발 중에 구현하기가 더 쉽습니다. 하지만 기본 macOS 앱에서 Montserrat를 사용해 보고 너무 기뻤습니다. 그래서 거부할 수 없었습니다.

교훈 #3

글꼴을 탐색할 수 있는 훌륭한 리소스가 많이 있습니다. 그럼에도 불구하고 특정 글꼴의 느낌을 얻기 위해 구식 Google 글꼴을 사용합니다.

첫 번째 설계 반복

초기 와이어프레임에서 그린 것부터 시작했습니다. 다음은 애플리케이션의 일반적인 사용자 흐름입니다.

1. 스케치 파일을 끌어다 놓습니다.
2. 최적화 옵션을 선택합니다.
3. 선택한 파일을 줄입니다.
4. 저장해.

저는 Sketch에서 디자인을 하고 있었는데 전체적인 UI에 완전히 만족했습니다. 이전에 메뉴 모음 응용 프로그램을 디자인한 적이 있기 때문에 텍스트 크기 조정 및 여백은 저에게 매우 표준이었습니다. 그럼에도 불구하고 첫 번째 반복에는 몇 가지 눈에 띄는 문제가 있었습니다. 이에 대해서는 나중에 설명하겠습니다.

교훈 #4

이전에 macOS용으로 디자인한 적이 없다면 Facebook Desktop Design Kit를 확인하십시오. 여기에서 모든 일반적인 macOS UI 요소를 찾을 수 있습니다. 그리고 UI 요소의 크기와 오프셋에 대한 감각을 제공합니다. macOS 메뉴 막대 응용 프로그램의 경우 12~14포인트 글꼴 크기는 완전히 정상입니다.

문제 #1: 누락된 상태

응용 프로그램이 스케치 파일을 처리할 때 중간에 상태를 구축하는 것을 잊었다는 점을 제외하고는 모든 것이 훌륭했습니다. 경험에서 알 수 있듯이 설계 단계에서 놓친 상태는 개발 단계에서 골치 아픈 것과 같습니다.

개발자들은 디자이너가 진공 상태에서 디자인한다고 얼마나 자주 불평합니까? 알다시피, 중간에 누락된 상태, 빈 상태, 완벽한 데이터 세트 사용 등의 문제에 대해 이야기하고 있습니다.

교훈 #5

개발자에게 디자인을 보내기 전에 잊어버린 것이 없는지 확인하십시오. 모든 상태를 지정했는지 확인하여 개발자가 나중에 "[일부 특수 조건]에서 어떻게 보이나요?"라고 묻지 않도록 합니다. 이러한 종류의 놓친 상태를 찾는 좋은 방법은 프로토타이핑 도구를 사용하는 것입니다. 지금까지 프로토타입 기능이 있는 Sketch용 Craft 플러그인(Invision에서 제작)이 이러한 테스트를 수행하는 가장 빠른 방법입니다.

문제 #2: 너무 많은 사용자 지정 요소

당신은 거의 항상 특정 플랫폼을 위해 디자인할 것입니다. 우리의 경우 macOS였습니다. 그리고 macOS에는 이미 어느 정도 표준적인 요소가 있습니다. 따라서 사용자 정의 솔루션 없이는 제품이 작동하지 않는 경우가 아니라면 적절한 표준 요소를 사용하십시오. 개발자들도 감사할 것입니다.

이러한 생각을 염두에 두고 사용자 지정 확인란을 제거하고 기본 확인란으로 교체했습니다. 또한 불필요한 사용자 지정 표시기를 모두 제거하여 진행률 창을 단순화했습니다.

교훈 #6

각 플랫폼의 기본 요소를 이해하려면 다음 자료를 살펴보는 것이 좋습니다.

• iOS: Apple UI 디자인 리소스, Sketch, Photoshop 및 Adobe XD에서 사용 가능
• Android: 머티리얼 디자인 키트
• macOS: Facebook 데스크탑 키트

문제 #3: 마지막에 강조가 충분하지 않음

팀과 몇 번의 피드백 세션 후에 최종 화면에 과부하가 걸렸다는 것이 분명해졌습니다. 최적화에서 파일 크기가 얼마나 변경되었는지 표시되지 않았습니다. 그래서 압축 파일을 잘 표현한 그림과 파일 크기 정보가 있는 레이블로 별도의 화면을 만들었습니다.

교훈 #7

우리는 Slack을 커뮤니케이션의 주요 장소로 사용합니다. Slack으로 보내기는 Sketch의 아트보드를 Slack 채널로 직접 공유하는 작은 플러그인입니다. 팀 피드백 세션에 정말 편리했습니다. 더 많이 공유하고 자주 공유하십시오.

문제 #4: 크고 작은 세부 사항

아래의 문제는 개발 중에 발견되었습니다. 그러나 기사의 구조를 일관되게 유지하기 위해 어쨌든 여기에 배치하겠습니다.

디자인을 구현하기 시작했습니다. 첫 번째 실행 직후 사용자가 응용 프로그램을 종료할 수 있는 방법이 없다는 것을 깨달았습니다.

또한 우리는 Mac App Store 대신 자체 채널을 통해 애플리케이션을 배포하고 싶었습니다. 따라서 애플리케이션에 자동 업데이트 시스템을 추가하는 것이 중요했습니다. 그리고 사용자는 현재 버전을 보고 업데이트를 확인할 수 있어야 합니다. 이 정보와 보조 작업을 한 곳에서 제공하는 메뉴로 끝났습니다.

마지막으로 누락된 세부 사항은 최적화된 파일을 닫고 저장 없이 기본 화면으로 돌아가는 기능이었습니다. 오른쪽 상단 모서리에 있는 "최적화 목록" 창에 나타나는 것과 동일한 "닫기" 버튼을 추가했습니다.

교훈 #8

개발자와 긴밀하게 협력하는 것은 항상 보람이 있습니다. 제 경우에도 같은 사람이 디자인과 개발을 하다보니 모든 문제를 바로 보기가 어렵습니다. 이러한 기능적 문제를 보기 위해 실제로 구축을 시작해야 했습니다. 어쨌든 가능한 한 빨리 개발자를 참여시키십시오. 기능적인 것들에 대한 귀중한 통찰력을 많이 얻을 수 있습니다.

개발을 위한 설계 준비

결국 설계 반복이 끝났습니다. 기술적으로 말하자면 디자인 반복은 결코 끝나지 않습니다. 따라서 개발 단계로 이동할 수 있는 충분한 상태에 도달했다고 가정해 보겠습니다.

디자인을 구현하기 전에 요소의 간격을 수정하여 모든 요소가 4픽셀 가이드에 맞춰졌는지 확인했습니다. 이 가이드 중심의 사고 방식은 개발 단계에서 성과를 거둘 것입니다.

교훈 #9

모든 요소가 올바르게 정렬되면 개발 시간이 크게 단축됩니다. 개발도 제가 담당했기 때문에 모든 속성을 Sketch에서 직접 받았습니다. 그러나 모든 요소가 올바른 위치에 있는지, 모든 색상이 동일한 팔레트에 있는지, 자산이 여러 해상도에 대해 준비되어 있는지 확인하는 것은 확실히 의미가 있습니다.

로고와 이름

마지막으로 중요한 것은 우리 애플리케이션의 이름이 꽤 빨리 나왔다는 것입니다. "줄이다"와 "줄어들다"라는 두 단어가 떠올랐습니다. Product Hunt를 확인했는데 "shrink"가 이미 사용 중이었기 때문에 "reduce"로 이동했습니다.

로고는 저에게 진정한 투쟁이었습니다. 메뉴바 애플리케이션이기 때문에 먼저 메뉴바 아이콘을 만들어야 했습니다.

메뉴바 아이콘은 16 × 16픽셀이어야 하므로 작은 요소는 사용하지 않는 것이 좋습니다. 아이콘은 독특하고 읽을 수 있어야 합니다.

간단한 모양으로 며칠을 씨름하다 포기하고 Google Fonts의 "Featured" 섹션을 열었습니다. 로고(메뉴 표시줄 아이콘뿐만 아니라)에 잘 맞는 멋진 곡선 글꼴을 찾고 있었습니다. 마침내 Pacifico 글꼴이 눈에 띄었고 우리의 목표에 완벽했습니다.

교훈 #10

macOS에는 어둡고 밝은 두 가지 버전의 메뉴 막대가 있습니다. 둘 다에 대한 메뉴 표시줄 아이콘을 준비하십시오. 또한 아이콘이 기본 선택 배경에서 어떻게 작동하는지 테스트하십시오. 기본적으로 사용자가 메뉴 막대 아이콘을 누르면 macOS는 사용자가 일반 설정에서 선택한 색상으로 강조 표시합니다. (Apple은 macOS의 색상에 대한 훌륭한 가이드를 제공합니다.) 테스트하기 위해 모든 기본 색상에 대한 기호를 생성하여 기본 색상 간에 전환하고 다른 배경에서 아이콘이 어떻게 보이는지 확인할 수 있었습니다.

초기 색상 팔레트의 강조 색상을 사용하여 작은 곡선 테두리가 있는 원 안에 "R"을 넣었습니다. 그 당시에는 로고가 나에게 충분했습니다.

결론

아직 개선의 여지가 많습니다. 내가 언급했듯이 디자인 반복은 결코 끝나지 않습니다. 그러나 계속 반복한다면 제품은 영원히 모형으로 남을 것입니다. 빠른배송이 더 좋습니다. 짧은 반복은 더 빠른 피드백을 의미하고 더 빠른 피드백은 더 나은 제품을 의미합니다. Reduce 앱은 우리의 주요 목표가 빠르고 유용하게 만드는 것이었기 때문에 일주일 반 만에 만들어졌습니다.

우리 팀으로부터 많은 긍정적인 피드백을 받았습니다. 메뉴 모음 응용 프로그램이 터미널 스크립트보다 훨씬 빠르고 이해하기 쉽습니다. 또한 공개 출시 동안 커뮤니티는 우리가 다음에 구현할 수 있는 기능과 앱을 개선할 수 있는 방법에 대한 많은 아이디어를 제공했습니다.

다음은 Reduce 앱을 만들면서 배운 내용을 요약한 것입니다.

• 와이어프레임이나 프로토타입을 만들기 전에 제품의 목표와 사용 사례에 대해 생각해 보십시오.
• Adobe Color 및 Khroma와 같은 도구를 사용하여 올바른 색상 팔레트를 더 빠르게 선택하십시오. HSB 색상 시스템에 대한 기본적인 이해도 도움이 될 것입니다.
• 사용자 정의 글꼴로 실험하는 것을 두려워하지 마십시오.
• 모든 플랫폼에는 고유한 표준 세트가 있습니다. 디자인하기 전에 배우십시오.
• 프로토타이핑 도구를 사용하여 전체 흐름을 파악하십시오.
• 사용자 정의 요소로 디자인을 압도하지 마십시오. 때로는 주어진 플랫폼에 대한 기본 컨트롤을 고수하는 것이 더 좋습니다.
• 가능한 한 빨리 디자인에 대한 피드백을 받으십시오.
• 가능한 한 빨리 개발자를 참여시키십시오. 기능적 요소와 "나선형 애니메이션이 있는 작은 그라디언트 버튼"을 구현하는 데 얼마나 많은 시간이 걸릴지에 대한 귀중한 통찰력을 많이 얻을 수 있습니다.
• 플랫폼 표준 그리드를 사용하여 모든 요소를 ​​정렬합니다. 개발자들은 나중에 그것에 대해 감사할 것입니다.
• UI를 완성하기 전에 다양한 사용 사례(밝은 메뉴 막대와 어두운 메뉴 막대 등)에 대해 디자인을 테스트합니다.

Reduce 앱이 당신의 삶(및 Sketch 파일)을 단순화할 수 있다고 생각한다면 무료로 다운로드할 수 있습니다. 그리고 피드백을 주세요. 우리는 그것이 사용자로부터 얻을 수 있는 가장 가치 있는 것이라고 믿습니다.