[TIL] 24.10.11(금)

피그마 3주차 강의 내용 정리(5~7강)

마스터 컴포넌트와 인스턴스

컴포넌트: 구성품 이라는 뜻으로, UI디자인에서 컴포넌트는 파운데이션을 조합해 만들어지는 구성품을 의미(=피그마로 만든 UI 블록)

마스터 컴포넌트: 컴포넌트 기능의 핵심으로, 반복적인 디자인을 빠르게 하기 위해 디자인을 복사해서 사용할 수 있도록 해줌(복사된 디자인을 한 번에 수정하거나 편집할 수 있도록 해줌)

마스터 컴포넌트의 특징: 마스터 컴포넌트는 '원본'으로 변하지 않음, 자유로운 수정 및 삭제 가능, 마스터 컴포넌트 복제 > 인스턴스 생성

인스턴스: 마스터 컴포넌트의 복제본으로, 마스터 컴포넌트의 속성을 그대로 이어받음 / 수정 불가능

* 마스터 컴포넌트 수정 > 인스턴스에 반영됨

* 인스턴스를 먼저 수정해도 마스터 컴포넌트에는 반영되지 않음 / 인스턴스 수정 후 마스터 컴포넌트를 수정해도 인스턴스에 적용X / 마스터 컴포넌트를 삭제해도 인스턴스는 남아있음 / 인스턴스의 연결을 해제(Detach)하면 마스터 컴포넌트와 분리되어 일반 프레임으로 바뀜

 

디자인 시스템

디자인 시스템이 필요한 이유: UI를 매번 새로 만들기 어렵고, 매번 사용자가 겪는 문제가 뭔지 파악할 시간도 부족하기 때문에, UI를 미리 만들어 놓고 필요할 때 가져와서 사용하기 위해 > 결과적으로 프로덕트(웹과 앱)의 효율적인 운영이 가능해짐

* 반복적으로 사용하는 UI를 효율적으로 관리

* 팀 전체가 같은 정도로 이해(어떤 디자이너가 UI를 사용하더라도 일관된 사용법을 지킬 수 있고, 어떤 개발자가 UI를 개발하더라도 디자이너의 생각을 이해하고 만들 수 있게 해줌)

 * 디자인 시스템은 UI 자체뿐만 아니라 UI의 규격과 스펙, 사용 사례, 주의사항 등이 총망라된 종합적인 제품 가이드라인

 

디자인 시스템의 장단점

장점

디자인을 반복해서 사용 > 시간과 비용이 감소함(그만큼 디자이너들도 더 중요한 일에 집중 가능)

누가 만들어도 동일한 품질의 제품 설계 가능(팀 전체가 한 사람처럼 일할 수 있음)

단점

다양한 형태의 UI를 모아 하나로 통일하는 과정이 매우 오래걸림(디자이너는 물론 개발자, 기획자도 모두 동의해야함)

필요한 것에 비해 UI가 과하게 많아질 수 있음(디자인 시스템이 너무 방대해서 오히려 업데이트 유지보수에 대한 비용이 커질 수 있음)

새로운 디자인이 필요할 때, 디자인 시스템을 활용하려다 보니 혁신이 줄어듦(팀 전체의 아이디어가 경직될 가능성)

> 디자인 시스템은 효율적인 제품 설계를 가능하게 해주는 강력한 방법이지만, 그만큼 준비 과정이 어렵기 때문에 디자인 시스템을 제작한다면 팀원들과 매우 신중하게 의논하는 과정이 필요함

 

UI키트와 디자인 시스템의 차이점

UI 키트: 사용하는 규칙과 방법 없이 단순히 UI를 모아둔 것

디자인 시스템: UI의 구조, 사용 방법, 유의점까지 상세하게 적혀있는 문서(문서의 형태를 가지고 있어야 함)

* 팀과 제품의 발전 단계에 따라 무엇을 선택할지 유연하게 결정해야함

 

디자인 시스템의 구성 요소와 원리

요소들은 그 자체로는 기능을 가지고 있지 않지만, 요소들을 모아서 '버튼'이라는 UI로 결합하면 '눌러서 작동시킨다'라는 기능이 생김

아토믹 디자인 시스템(Atomic Design System): 대부분의 디자인 시스템은 이 원리를 바탕으로 가장 작은 원자 요소들을 설계하고, 그 원자들을 모으고 결합하는 규칙을 만들어서 우리가 아는 버튼, 체크박스, 바텀시트, 모달 등을 만들어 냄

UI의 분류

형태도 다양하고 종류도 많지만 크게 6가지로 분류, 임의적인 분류이기 때문에 UI가 어떤 상황에서 어떤 기능을 하는지가 중요함

- 액션(Action): 사용자가 중요한 행동을 수행할 때 사용(버튼 등)

- 인풋(Input): 사용자의 입력을 받을 때 사용(텍스트 필드, 셀렉트 박스 등)

- 인포메이션(Information): 사용자에게 서비스의 상태나 안내 사항 전달할 때 사용(토스트 메시지, 스낵바, 라벨 등)

- 컨테이너(Container): 컴포넌트 여러개가 결합되어 하나의 덩어리를 이루는 컴포넌트(카드, 바텀시트, 리스트 등 복잡한 구조)

- 내비게이션(Navigation): 사용자가 페이지를 이동할 때 사용(네비게이션 바, 앱 바, 화면 하단의 탭 바, 사이드 바 등)

- 컨트롤(Control): 사용자가 설정이나 값을 수정할 때 사용(라디오, 체크박스, 스위치 등)

 

의사 상태(Pseudo State)

컴포넌트도 기본 자체는 유지한 채, 상황에 따라 다른 스타일을 가지는 경우가 존재함 > 그런 다른 스타일을 '의사 상태'라고 함

의사 상태에서 의사: 가짜의, 가상의(Pseudo: '수도'라고 발음)라는 뜻

의사상태는 컴포넌트의 가상의 상태를 표시할 때 사용함

ex. 버튼에 마우스오버를 했을 때 색깔이 바뀌는 건 실제 버튼이 다른 걸로 바뀐것이 아닌 버튼이 가진 가상의 상태를 나타내는 것

*의사 상태 설계 시 주의 사항: 의사 상태의 종류는 다양한 경우 존재(버튼에 마우스 오버, 버튼 클릭, 텍스트를 입력하기 위해 눌렀을 때, 체크박스 클릭, 누를 수 없을 때 등) > 하지만 컴포넌트마다 쓸 수 있는 것과 없는 것 존재함(버튼인데 체크된 것은 불가능하고, 체크박스가 링크인것이 존재할 수 없는것처럼) > 컴포넌트에 의사 상태를 적용해서 만들 때는, 실제 구현할 개발자와 많은 소통을 통해 구현 여부를 잘 논의하는 과정이 필수

 

 

디자인 시스템 링크

https://m3.material.io/

https://designsystem.line.me/LDSM

https://brunch.co.kr/@milliedesign/9

https://www.lightningdesignsystem.com/