디자이너와 개발자 간의 격차 해소

이 기사는 상태, JS 표현식, 변수, 조건부 상호 작용, Git 동기화와 같은 초능력을 프로토타입에 제공하는 UI 디자인 및 프로토타이핑 도구 인 UXPin의 친구들이 친절하게 제공합니다. 단, 이 글은 UXPin의 영향을 전혀 받지 않으며 작성자의 독립적인 의견 을 표현하고 있습니다. 감사합니다!

지난 몇 년 동안 우리의 디자인 도구가 기하급수적으로 발전했다는 것은 비밀이 아닙니다. 많은 사람들이 훌륭한 구성 요소 관리 및 프로토타이핑을 가지고 있기 때문에 다음에 어떤 큰 도약을 할 수 있을지 궁금할 것입니다.

일반적인 딜레마를 살펴보겠습니다.

구성 요소, 변형을 만들고 변경되거나 변경되지 않을 수 있는 모든 사용 사례와 속성을 문서화하는 데 많은 시간을 소비하는 디자인 시스템 팀의 디자이너라고 가정해 보겠습니다. 마침내 크고 복잡한 구성 요소를 완성하여 개발자에게 전달합니다.

코드가 동일한 UI인지 어떻게 알 수 있습니까? 모든 단일 구성 요소를 감사해야 합니까? 지속적으로 검토를 수행하는 오버헤드 없이 개발된 것과 설계된 것 사이의 이 격차를 어떻게 메울 수 있습니까?

이 모든 것과 당신은 사람들에게 구성 요소를 사용하는 다양한 방법 , 반응형 웹을 위한 적절한 간격 및 디자인을 가르치는 데 도움을 주어야 하며, 물론 구성 요소는 향후 사용 사례를 위해 업데이트되어야 합니다.

많은 접점이 있고 관련된 사람들이 있습니다. 우리가 디자인 시스템으로 더 깊이 들어갈수록 모든 사람에게 더 많은 오버헤드가 있는 것처럼 느껴집니다! 이제 터널 끝의 불빛이 반짝이고 있는 것 같고, 다음 큰 일이 다가오고 있습니다.

모든 혼돈 속에 숨겨진 보석

나는 최근에 꽤 오랫동안 사용하지 않았던 도구를 다시 살펴볼 기회가 있었습니다. 이 도구는 이 간극을 메우고 모든 오버헤드를 최소화하는 것을 목표로 하는 도구인 UXPin입니다. 팀이 기대하는 민첩성과 품질을 향상시키면서 디자인과 개발의 틈을 헤쳐나가는 데 도움이 되는 "병합"이라는 새로운 기능이 출시되었습니다. 이 새로운 기술은 전체 설계 및 엔지니어링 팀이 사용 사례 및 건물 구성 요소를 통해 협력하고 작업하는 방법을 재고하게 할 수 있습니다.

이전 프로세스와 함께

오늘날 대부분의 회사에서 사용하는 현재 프로세스를 살펴보면 몇 가지 명백한 결함이 있어 꽤 지루할 수 있습니다. 새 구성 요소를 처음부터 만들 때 구성 요소의 기본 수준을 디자인하고 변형을 추가하고 문서를 작성하고 라이브러리에 게시하고 개발자에게 전달합니다. 프로세스를 나열하는 것은 오래 걸리지만 운 좋게도 한 번만 수행하면 됩니다(희망).

이제 구성 요소를 업데이트해야 하는 경우 어떻게 됩니까? 새로운 사용 사례가 생겼습니까? 아니면 테두리를 둥근 것에서 아주 날카로운 것으로 변경하기로 결정한 것입니까? 이제 라이브러리에 변형을 추가하고 (아마도) 문서를 다시 업데이트하고 게시하여 개발자에게 전달해야 합니다. 휴! 구성 요소를 재구성하는 과정에서 디자이너에게 아무 문제가 없었기를 바랍니다 .

거의 잊어버렸습니다. 우리는 여전히 개발 라이브러리에 업데이트를 게시해야 합니다! 제품 팀이 기한을 맞추기 위해 각자의 길을 가기 전에 완료할 수 있기를 바랍니다.

새로운 프로세스와 함께

그렇다면 UXPin Merge의 기술이 오늘날 우리 모두가 사용하는 이 오버톱 프로세스에 어떻게 도움이 되는지 궁금하실 것입니다. 자, 아래 도표를 한 번 보세요. 대부분의 경우 구성 요소 및 변형 생성이 필요하지 않다는 것을 알 수 있습니다. 이 새로운 프로세스는 이제 개발자와 시너지 효과를 내는 관계로 인해 자동 레이아웃 도구를 사용하는 번거로움을 줄여줍니다 .

문서화 및 구현에 필요한 세부 수준만 설계하면 됩니다. 버튼이나 기타 원자 수준 구성 요소와 같은 간단한 구성 요소는 디자인할 필요가 없습니다. 약간의 오버헤드로 즉시 개발을 시작할 수 있는데 왜 두 배로 시간을 낭비 합니까? 어떤 면에서 우리는 완전한 원을 이루었습니다. 정적 구성 요소가 설명서에서 몇 가지 상호 작용만 표시했을 때 이전 방식으로 돌아가고 있습니다.

라이브러리에 게시하는 것은 이제 프로세스의 마지막 단계에 있습니다. 개발자가 구성 요소를 완성하면 이제 병합을 사용하여 UXPin의 디자이너가 사용할 수 있고 물론 모든 제품 개발자가 동시에 사용할 수 있기 때문입니다!

구성 요소를 업데이트할 때 시나리오에 따라 첫 번째 단계를 건너뛸 수도 있다는 점을 제외하고는 기본적으로 새 것과 동일합니다. 예를 들어 버튼에 아이콘을 추가하는 옵션을 추가하고 싶다고 가정해 보겠습니다. 이것은 디자인해야 하는 것이 아니라 개발 중인 새로운 가장 친한 친구와 소통해야 합니다.

이 새로운 관계가 개발자와 형성되는 동안 공식적으로 디자이너에게 구성 요소를 출시하는 새로운 방법은 개발자가 릴리스해야 할 수 있습니다. 제품 개발자가 구성 요소를 사용할 수 있는지 묻는 제품 디자이너의 시대는 지났습니다. 라이브러리에 있는 경우 개발 단계에서 사용할 수 있으며 디자이너가 즉시 작업할 수 있습니다.

그러나 그 과정에 대해서는 충분합니다. UXPin Merge가 어떻게 작동하는지 살펴보겠습니다.

라이브러리 관리

가장 좋은 점은 라이브러리를 GitHub, Bitbucket, GitLab(React 구성 요소에서만 작동) 또는 심지어 Storybook과 같은 코드 리포지토리에서 직접 가져올 수 있다는 것입니다. 라이브러리가 생성되면 라이브러리 이름을 지정할 수 있는 옵션이 제공됩니다.

Storybook으로 가져올 때 프로세스는 매우 간단합니다. 라이브러리 URL을 가져오기만 하면 나머지는 UXPin이 알아서 처리합니다. React 구성 요소를 사용하면 CLI를 사용하여 UXPin 라이브러리의 고유 토큰을 지정하여 게시되는 구성 요소를 제어 할 수 있습니다.

버전 관리 및 테스트

디자이너와 디자인 시스템 팀의 가장 큰 관심사 중 하나는 버전 관리입니다. 이 UXPin의 병합 기능으로 대부분의 문제를 해결할 수 있습니다. 빠른 그림을 그려 봅시다.

오늘날 우리가 구성 요소를 업그레이드하려고 할 때 항상 이름이 바뀌고 정리될 수 있는 구성 요소 또는 계층이 손상될 수 있다는 두려움이 있습니다. 구성 요소의 전체 재구성이 발생할 수 있으며, 이는 구성 요소를 업그레이드해야 하는지 아니면 기존 구성을 고수해야 하는지에 대해 설계자 측에서 종종 불안으로 이어집니다.

그러나 구성 요소가 개발될 때 속성이 동일하게 유지되는 한 구성 요소 레이아웃이 어떻게 변경되거나 구성 요소의 실제 마크업이 변경되는지는 중요하지 않습니다. 이를 통해 설계자는 자신 있게 구성 요소를 최신 버전으로 업그레이드할 수 있습니다 .

물론 모든 코딩 프로젝트와 마찬가지로 구성 요소가 완전히 엉망이 되는 아주 드문 순간에 쉽게 롤백하고 구성 요소의 이전 버전을 다시 게시할 수 있습니다.

업데이트 테스트

새로운 구성 요소나 업데이트를 테스트할 때 오늘날에는 그렇게 쉬운 일이 아닙니다. 우리는 분명히 기존 디자인 라이브러리를 편집하여 테스트할 수 없습니다. 이 라이브러리는 실수로 게시될 수 있고 준비된 다른 업데이트는 차단할 수 있기 때문입니다. 새 파일에 구성 요소를 만들고 테스트한 다음 레이어를 끊지 않고 현재 라이브러리에 다시 병합을 처리하는 것도 매우 번거롭습니다.

다행스럽게도 개발자들은 이 문제를 오래 전에 파악했으며 UXPin의 Merge 기술에 딱 맞습니다. 새 구성 요소를 테스트할 때 이미 코드를 분기하거나 분기하는 것이 가장 좋은 방법 이며 이 새 분기는 UXPin 내의 테스트 환경에 게시될 수 있습니다. 팀에서 테스트하거나 회사의 소규모 베타 테스터 그룹에 액세스 권한을 부여할 수 있습니다. 구성 요소가 테스트되고 시도되면 구성 요소를 스티치 없이 기본 디자인 라이브러리에 빠르게 도입하고 게시할 수 있습니다.

코드로 디자인하기

그렇다면 현장에서 우리 팀원들은 어떻게 설계하고 이 기술이 그들에게 의미하는 바는 무엇입니까? 질문해주셔서 기쁩니다! 제품 디자이너의 입장에서 보면 별 차이가 없습니다. 디자이너가 Merge를 활용하여 개발 라이브러리의 구성 요소를 사용하는 경우 각 구성 요소에 대해 주황색 육각형으로 표시됩니다 . 새로운 것은 개발자의 라이브러리와 정확히 동일하게 계속 작동합니다.

개발자의 구성 요소에는 제한 사항이 정의되어 있을 수 있지만 좋은 방법입니다. 일반적인 문제는 버튼 구성 요소에서 아이콘을 래핑하는 대신 아이콘을 링크로 사용 하는 것입니다. 라이브러리의 아이콘만 사용하는 경우 잠겨 있고 사용자는 상호 작용을 추가할 수 없습니다.

또는 아래 아이콘 버튼을 사용하여 상호 작용할 수 있습니다. 이를 통해 상호 작용해야 하는 구성 요소와 그렇지 않은 구성 요소를 실제로 수정하고 제어할 수 있습니다. 표준적인 관점과 접근성 모두에서.

이러한 유형의 제한을 통해 디자인 시스템 팀은 구성 요소가 적절한 방식으로 사용되어야 하고, 오버라이드된 경우 레이어 패널에서 무언가 맞춤 제작되었음을 분명히 알 수 있습니다.

핸드오프

개발자에게 전달할 준비가 되면 완성된 프로토타입은 각 구성 요소와 구성을 표시하여 개발자 도구에 복사하여 붙여넣고 프로젝트를 빠르게 빌드할 수 있습니다. 팀에 아직 구성 요소 라이브러리가 없는 경우 UXPin은 기본 라이브러리와 함께 제공되거나 UXPin에서 직접 사용 가능한 일부 공개 라이브러리를 쉽게 가져올 수 있습니다.

접근성

접근성에 대해 말하자면, 종종 간과되거나 모든 meta 레이블, aria 태그 등에 대한 문서를 작성할 시간이 충분하지 않습니다. 디자이너는 어떤 태그를 입력해야 하는지 모르고 개발자는 번거로움을 겪고 싶지 않습니다.

UXPin을 사용하면 ARIA 레이블과 같이 인터페이스에서 볼 수 없는 메타 수준 데이터라도 여러 속성을 노출할 수 있습니다. 그런 다음 디자이너는 필요한 모든 정보를 입력할 수 있으며(또는 운이 좋은 경우 카피라이터) 제품 개발자가 구현해야 하는 오버헤드가 거의 또는 전혀 없습니다.

레이아웃, 템플릿 및 그리드

제목을 읽기만 해도 무슨 일이 벌어지고 있는지 알 수 있습니다. 지금쯤이면 의자에서 펄쩍펄쩍 뛰고 있을 것입니다. 저도 압니다. 그리드, 레이아웃 및 심지어 페이지 템플릿을 '구성 요소'로 라이브러리에 가져올 수 있어 사용자가 구성 요소를 페이지의 활성 영역으로 가져올 수 있고 모든 간격이 개발 라이브러리에서 처리되도록 할 수 있습니다.

공통 템플릿(예: 로그인 화면, 완성 페이지, 양식, 프로필 페이지 등)을 모두 끌어서 놓기 구성 요소로 사용할 수도 있습니다. 프로세스 속도를 높이고 설계 시 인적 오류를 줄이는 방법에 대해 이야기하십시오!

마감 중

도약할 준비가 되었다면 워크플로를 개선하기 위해 새로운 소프트웨어와 새로운 프로세스를 시도하기에 너무 늦지 않았습니다. 결국 우리 모두는 최대한 민첩하고 수용적인 사람이 되기를 원합니다. 팀 간에 더 강력한 관계를 구축 하고 작업량을 줄이며 보다 효율적으로 작업합시다. UXPin Merge와 같은 도구를 사용하면 훨씬 더 원활한 작업 환경에 가까워집니다.