01. DesignSystem

👉 [강의 보기]

학습 키워드

• 반응형 웹 디자인(Responsive web design)

• 디자인 시스템(Design System)

• Atomic Design

반응형 웹 디자인 (RWD)

• 웹 페이지가 모든 화면 크기와 해상도에서 잘 렌더링되도록 하면서도 사용성을 보장하는 웹 디자인 접근 방식

• 멀티 디바이스 웹을 위한 디자인 방식

• HTML은 기본적으로 반응형 또는 유동적

• CSS 없이 HTML만 포함된 웹 페이지를 만들고 창 크기를 조정하면 브라우저는 뷰포트에 맞게 텍스트를 자동으로 리플로우

• 별도의 기술이 아니라 하나의 접근 방식

• 콘텐츠를 보는 데 사용되는 모든 기기에 대응할 수 있는 레이아웃을 만드는 데 사용되는 일련의 모범 사례를 설명하는 데 사용되는 용어

• Flexibale Web Design

• CSS를 사용한 유동적이고 탄력적인 레이아웃을 만들어내는 것

• 사용성과 접근성을 극대화하고 변화하는 수 많은 컨텐츠에 적응하는 매력적인 웹사이트를 디자인하고 구축하는 방법

• 다양한 사용자의 선호도 아래에서 hold up 하는

• 유동적이고 유연한(Liquid and Fluid) 레이아웃은 사용자의 고유한 장치의 보기 크기에 따라 너비가 달라집니다.

• 탄력적인(Elastic) 레이아웃은 유저의 고유한 텍스트 크기에 따라 가로 너비가 달라집니다.

• 두 유형 모두 유저의 니즈에 맞춘 크기의 사이트를 볼 수 있게 만듭니다.

• 완벽한 픽셀 컨트롤에 익숙한 디자이너들에게는 챌린지를 줄수 있습니다.

미디어 쿼리

• 분기점: 미디어 쿼리가 도입되고 레이아웃이 변경되는 지점

• 모바일 우선 디자인: 화면이 좁은 디바이스를 위해 간단한 단일 열 레이아웃을 만든 다음

  • 화면이 더 넓은지 확인하고 화면 너비가 충분하다고 판단되면 다중 열 레이아웃을 구현

  • 개별 디바이스의 절대 크기보다는 CSS 값과 단위를 사용하여 미디어 쿼리 분기점을 정의

• 다단 레이아웃

  • column-count: 분할할 최대 열 수 = 화면 크기에 따라 변경되는 크기를 계산( 열의 너비가 변경 )

  • column-width: 화면 크기에 따라 열의 수를 계산 ( 열의 수가 변경 )

• Flexbox, 그리드

• 반응형 이미지

  • <picture> (en-US)와 <img> 요소의 srcset 및 sizes 속성

  • 사용자의 뷰포트와 디바이스의 해상도에 맞는 이미지를 제공할 수 있습니다.

  • 예를 들어 모바일용 정사각형 이미지, 데스크톱에서는 가로 이미지

  • <picture> 요소를 사용하면

    • "hints"(이미지가 가장 적합한 화면 크기 및 해상도를 설명하는 메타데이터)와 함께

    • 여러 크기를 제공할 수 있으며,

    • 브라우저는 각 디바이스에 가장 적합한 이미지를 선택

    • 사용자가 사용 중인 디바이스에 적합한 이미지 크기를 다운로드할 수 있습니다.

• 반응형 타이포그래피

  • 폰트 사이즈에 rem 사용하기

    • 1레벨 머리글 4rem = 기본 글꼴크기(16px)의 4배

    • 큰 크기의 제목은 더 큰 화면 크기에서만 사용해야 하므로

    • 먼저 더 작은 제목을 만든 다음

    • 사용자의 화면 크기가 1200px 이상인 경우 미디어 쿼리를 사용하여 더 큰 크기로 덮어씁니다.

  • vw, vh(뷰포트 단위) 사용하기

    • 위와 같이 할 때의 문제점은 텍스트가 항상 뷰포트의 크기와 관련되어 있기 때문에

    • 사용자가 'vw' 단위를 사용하여 설정한 텍스트를 확대/축소할 수 없다는 것입니다.

    • 따라서 뷰포트 단위만 사용하여 텍스트를 설정해서는 안 됩니다.

    • calc()를 사용하라.

    • em 또는 rem과 같은 고정 크기를 사용하여 설정된 값에 vw 단위를 추가

    • vw 단위는 확대된 값 위에 추가됩니다.

    • vw, vh => 윈도우 창 크기에 따라 변화

    • rem, em => 사용자가 확대 축소함에 따라 변화

  • 야매 반응형

    • html 에 폰트사이즈를 모두 62.5%로 해주면 1rem(==16px) 이 10px이 됨

    • 그럼 나머지 요소에서 rem을 10px처럼 쓸 수 있음

    • 1.6rem, 1.2rem, 1.0rem

  • 뷰포트 메타 태그

    • <meta name="viewport" content="width=device-width,initial-scale=1">

    • 모바일 브라우저에 뷰포트의 너비를 기기 너비로 설정하고

    • 문서의 크기를 의도한 크기의 100%로 조정하여

    • 문서를 모바일에 최적화된 크기로 표시해야 함을 알려줌

디자인 시스템(Design System)

• 레퍼런스
• 오늘날 디자이너와 개발자들은 UI 컴포넌트 구조화를 위해 노력하고 있습니다.

• UI 컴포넌트는 사용자 인터페이스를 이루는 조각들의 시각적이고 기능적인 속성을 캡슐화합니다.

• 최근에 등장한 유저 인터페이스들은 다양한 사용자 경험을 제공하기 위해 수백 개의 모듈식 UI 컴포넌트가 재배열된 구조로 이루어져 있습니다.

• 🏗 재사용이 가능한 공용 UI 컴포넌트

• 🎨 디자인 토큰: 브랜드 색상, 간격과 같은 스타일 변수

• 📕 문서: 사용 방법, 설명, 좋은 예와 나쁜 예

• 같은 UI 컴포넌트를 다양한 프로젝트에서 공유할수록 효용이 커집니다. 따라서 이 가이드는 같은 UI 컴포넌트를 여러 앱이나 팀 작업에 가져다 붙이는 일이 잦은 개발자를 위해 제작되었다고 보시면 됩니다.

작업 흐름

디자인 시스템은 프런트엔드 인프라에 대한 투자입니다. 이 가이드에서는 위의 기술을 사용하는 방법 외에도 적용과 유지 보수를 단순화하는 핵심 작업 흐름에 대해서도 중점적으로 설명할 것입니다. 가능한 모든 수동 작업은 자동화가 될 것입니다. 다음은 우리가 마주하게 될 활동들입니다.

• UI 컴포넌트는 분리하여 작업하기

  • 모든 디자인 시스템은 UI 컴포넌트로 구성됩니다. 우리는 스토리북을 "워크벤치(workbench)"로 사용하여 소비자 앱 밖에서 UI 컴포넌트를 구축할 것입니다. 그 다음엔 스토리북에서 컴포넌트의 내구성을 향상시키는 애드온(Actions, Source, Knobs)을 통합합니다.

• 리뷰를 통해 합의를 이끌어내고 피드백을 수집하기

  • UI 개발은 개발자, 디자이너 및 다른 분야 간의 조정이 필요한 팀 스포츠입니다. 스토리북에서는 작업 중인 UI 컴포넌트들을 게시하여 이해관계자들을 개발 과정에 포함시키도록 합니다. 이를 통해 서비스 출시 시기를 앞당길 수 있습니다.

• UI에서 발생하는 버그를 방지하기위해 테스트 하는 법

  • 디자인 시스템들은 단일한 진실의 원천(source of truth)이며 단일 실패 지점(single point of failure)입니다. 기본 컴포넌트에 있는 사소한 UI 버그가 순식간에 회사 전체의 사고로 이어질 수도 있습니다. 스토리북은 테스트를 자동화하여 불가피하게 발생하는 버그를 방지하고, 접근성과 내구성이 뛰어난 UI 컴포넌트를 안심하고 사용할 수 있도록 합니다.

• 빠른 적용을 위한 문서화

  • 문서화는 필수적이지만 개발자에게 우선순위 작업이 아닌 경우가 많습니다. 스토리북은 이런 개발자의 편의를 위해 자동으로 최소 요건을 갖춘 문서를 생성해줍니다. 이렇게 생성된 문서는 개발자가 필요에 따라 사용자화할 수 있습니다.

• 사용자 프로젝트에 디자인 시스템 배포하기

  • 문서화가 잘 된 UI 컴포넌트가 완성되면 다른 팀에 배포를 할 차례입니다. 패키징, 배포 및 다른 스토리북에서 디자인 시스템을 표시하는 방법에 대해 알아볼 예정입니다.

1. 아토믹 디자인 시스템

1. 개념 및 정의

   1. 디자인 시스템 방법론 중의 하나

   2. 주기율표 상의 원자(atom)들이 어떻게 결합하느냐에 따라서 세상 모든 것들을 생성할 수 있듯이

   3. 웹페이지의 컴포넌트를 5가지 레벨로 나눠 체계화하는 방법

2. 필요성 및 의의

   1. 규칙을 제각각으로 만들면, 관심사가 너무 많거나

   2. 재사용이나 확장할 수 없는 컴포넌트가 생기는 문제를 해결하기 위해

3. 특징

   1. atom - molecule - organism - Template - page으로 컴포넌트를 쪼개는 방법

   2. atom: 더이상 쪼갤 수 없는 단일요소 (ex. 태그, 글꼴, 컬러팔레트, 레이아웃 등)

   3. molecule: 여러 atom을 결합, 고유의 특성을 가짐, 한가지 동작을 함(SRP, Single Responsibility Principle) - 테스트하기 쉽고, 재사용성 높음

   4. organism: 특정 컨텍스트를 가짐, 상대적으로 구체적, 재사용성 낮음 (ex. header)

   5. Template: 컴포넌트를 배치하고 구조를 잡는 와이어프레임, 컨텐츠가 없는 page (스켈레톤)

   6. Page: 유저가 보는, 실제 컨텐츠를 담은 요소, template의 인스턴스라고 볼 수 있음.

4. 방법

   1. Molecule vs Organism

      1. SRP, Single Responsibility Principle을 지킬 수 있느냐

      2. Context가 없어도 컴포넌트의 역할이 설명이 되느냐

      3. 그래도 모호하면 일단 Organism

   2. 중복 컴포넌트

      1. compound 컴포넌트 (합성 컴포넌트)로 해결하기

      2. UI 제어하는 상태 이런거는 다 외부에서 주입하기 (스토리북 유용)

      3. 마진, 패딩과 같은 레이아웃 관련 스타일도 외부에서 주입하기

   3. UI 모델링

      1. 하나의 컴포넌트의 단위를 쪼개고 네이밍 하는 과정을 피그잼을 통해 함께 진행하기

5. 개인적인 생각(추가적인 질문 또는 인사이트)