디자인 및 사용자 인터페이스 변경

디자인 및 사용자 인터페이스(UI) 변경에 기여하거나 검토할 때 이러한 지침을 따르세요. 보다 일반적인 코드 검토에 대한 조언 및 모범 사례에 대해서는 코드 검토 가이드를 참조하세요.

이러한 지침의 대부분은 Pajamas, GitLab 디자인 시스템을 기반으로 합니다. 여러분은 Pajamas에 추가 및 개선을 기여할 것을 권장합니다.

Merge Request 검토

Merge Request(MR) 작성자로서, 반드시 다음을 수행해야 합니다:

  • 변경 내용에 대한 이전이후 스크린샷(또는 비디오)을 설명에 포함시키세요. 이러한 스크린샷/비디오는 모든 리뷰어들에게 매우 도움이 되며, 특히 변경 사항이 작은 경우 리뷰 프로세스를 가속화할 수 있습니다. 설명에는 MR workflow에서 설명한 대로 포함시켜 주시기 바랍니다.
  • 사용자를 대면하는 변경 사항이 있는 모든 Merge Request에는 ~UX 라벨을 부착하세요. 이는 우리의 Reviewer Roulette에게 UX 리뷰어를 제안할 것입니다.

팀 멤버라면: Reviewer Roulette이 제안하는 제품 디자이너를 리뷰어로 지정하는 것을 권장합니다. 이를 통해 작업을 고르게 분배하고 커뮤니케이션을 개선하며 UI를 더 일관되게 만드는 데 도움이 됩니다. 다른 리뷰어를 선택할 이유가 있는 경우, 지정한 제품 디자이너를 언급하기 위해 주석을 추가하세요.

커뮤니티 기여자라면: Reviewer Roulette과 관계없이 기여하는 분야의 도메인 전문가 제품 디자이너를 선택하는 것을 선호합니다.

체크리스트

UI 변경 사항을 _설계_하고 _검토_할 때 다음 사항을 확인하세요.

작성

  • UI 텍스트에 대한 주요 지침으로 Pajamas를 준수하고 보조로 문서 스타일 가이드를 따르세요.
  • 명확하고 일관된 용어 사용.
  • 철자와 문법을 확인하세요.
  • 도움 콘텐츠를 고려하고 가이드라인을 준수하세요.
  • 사용자 관점에서 텍스트의 위치/문맥을 미리보기하거나 이해하기 위해 적절한 기술 작가로부터 검토를 요청하고 특정 파일 또는 줄을 명시하고 방법을 설명하세요.

패턴

  • 제품에서 사용 중인 유사한 패턴을 고려하고, 이와 다르게 할 때 이유를 설명하세요.
  • 적절한 컴포넌트데이터 시각화 사용.

시각적 디자인

브라우저의 요소 검사기를 사용하여 시각적 디자인 속성을 확인하세요 (Chrome, Firefox).

다크 모드

다크 모드 기능이 실험인 동안 다크 모드를 디자인할 필요는 없습니다. UX Foundations 팀은 미래에 다크 모드를 개선할 계획입니다. Pajamas를 제품에 통합하고 다크 모드를 지원하기 위한 기본 디자인 전략이 마련될 때까지 이 모드에서 버그나 부채무리가 발생하지 않을 것을 보장할 수 없습니다. 재량에 따라 다크 모드 패치를 만들 필요성을 평가해 보세요.

상태

브라우저의 _스타일 검사기_를 사용하여 CSS 유사 클래스(:hover 등)를 토글하여 상태를 확인하세요 (Chrome, Firefox).

  • 모든 적용 가능한 상태(에러, 일반, 로딩, 포커스, 호버, 선택, 비활성화)에 대해 고려하세요.
  • 데이터 크기별 상태(비어 있음, 일부 데이터, 대량 데이터)에 대해 고려하세요.
  • 사용자 역할, 사용자 환경, 구독에 따라 달라지는 상태를 고려하세요.
  • 애니메이션 및 전환을 고려하고 가이드라인을 준수하세요.

반응형

브라우저의 _반응형 모드_를 사용하여 반응형 동작을 확인하세요 (Chrome, Firefox).

  • 모든 브레이크포인트에서 요소의 크기 조절, 축소, 이동 또는 래핑에 대해 고려하세요(보다 큰 뷰포트가 우선되는 경우라도).
  • 모든 브레이크포인트에서 동일한 정보 및 작업을 제공하세요.

접근성

브라우저의 _접근성 요소 검사기_를 사용하여 접근성을 확인하세요 (Chrome, Firefox).

인계

디자인이 준비되었을 때, 구현을 시작하기 전에:

후속 조치

어떤 순간이든지, 보통 디자인 구현 과정 중 또는 후에:

  • 디자인 시스템에 추가 사항이나 향상을 위해 Pajamas에 이슈를 기여합니다.
  • 의도적으로 UX 요구 사항과 다른 부분에 대한 ~UX debt 레이블의 이슈를 생성하고, 시간 또는 실현 가능성의 도전으로 합의된 UX 요구 사항에서 의도적으로 벗어난 점에 대한 이슈를 해당 이슈나 MR로 연결합니다.
  • 범위 확장을 피하기 위해 UX 요구 사항에서 합의된 범위를 벗어난 피처 추가 또는 개선을 위한 이슈를 생성합니다.