쓸모 있는 컴포넌트 만들기
디자이너 5인의 Airbnb 디자인시스템 제작기 3편
이 글은 노트폴리오 디자인 시스템 워크숍 4기 1조 원들이 8주간 함께 만든 디자인 시스템 이야기 중, 3편 - 컴포넌트에 관한 이야기입니다.
안녕하세요.
저는 디자인워크숍 4기 1조의 디자이너 중 한 명인 정현입니다.
앞선 2편에서는 디자인 시스템의 기반이 되는 컬러, 타이포, 섀도우 등을 포함한 파운데이션을 제작했습니다.
이 파운데이션을 활용하여 총 19개의 컴포넌트를 만들게 되었는데, 이번 글에서는 컴포넌트는 무엇이고 우리는 어떤 방식으로 컴포넌트를 제작했는지 그 과정을 공유해 보겠습니다.
컴포넌트란 무엇이고 왜 필요할까?
디자인 시스템에서 컴포넌트는 인터페이스의 재사용 가능한 요소이며 버튼, 입력 필드, 카드 등 UI를 구성하는 기본 단위로 일관된 디자인과 기능을 유지하도록 도와줍니다.
컴포넌트는 각각의 스타일, 동작, 인터랙션을 포함하고 있으며, 이를 통해 개발자와 디자이너가 효율적으로 협업할 수 있습니다.
컴포넌트를 사용하면 개발 시간과 비용을 절감할 수 있으며 유지보수가 용이해집니다. 또한 사용자 경험을 일관되게 제공하여 브랜드 일관성을 유지하고 제품의 품질을 높일 수 있습니다.
컴포넌트, 어떻게 만들까?
위에서 말씀드렸듯이 컴포넌트는 “반복과 재사용성”에 큰 의미를 지니고 있습니다.
새로운 서비스를 구축하는 것이 아닌 기존에 있는 에어비앤비를 기반으로 디자인 시스템을 만들어 보는 것이 목적이라 에어비앤비 서비스에서 2번 이상 반복되는 패턴을 기준으로
폰트 사이즈
컬러
아이콘
섀도값
간격값
패딩 및 높이값
상기 요소들을 우리가 만들었던 파운데이션을 기반으로 하여 UI 컴포넌트를 만들었습니다.
우리가 만든 19개의 컴포넌트 리스트어떤 규칙으로 제작해 볼까?
5명의 디자이너가 컴포넌트를 제작하다 보니 취합할 때 문제가 생기곤 했습니다. 이에 서로 공통으로 지켜야 할 규칙을 만들기로 했습니다.
컴포넌트 이름 표기법
컴포넌트 이름을 표기하는 방법은 크게 4가지가 있습니다.
컴포넌트 이름 표기법 4가지 : 카멜 케이스, 파스칼 케이스, 스네이크 케이스, 케밥 케이스1. Camel Case
모든 단어의 첫 글자는 대문자로 표기하는 방법으로 두 가지 표기 방법이 있습니다.
기본적으로는 맨 첫 글자만 소문자로 표기하는 Lower camel case와, 맨 첫 글자도 대문자로 표기하는 Upper camel case가 있습니다.
2. Pascal Case
모든 단어의 첫 글자를 대문자로 표기하는 방법으로 Upper camel case와 동일한 방법입니다.
3. Snake Case
모든 단어는 소문자로 쓰되 단어 사이를 _ 로 연결하는 방법입니다.
4. Kebab Case
모든 단어는 소문자로 쓰되 단어 사이를 - 로 연결하는 방법입니다.
위 네 가지 케이스는 개발 환경에서 많이 사용하는 용어로 환경에 따라 섞어서 사용하기도 하는데요. 이 중 Pascal Case를 사용하기로 했습니다.
배리언트 상태값 명칭 통일
배리언트의 상태값도 각기 다르게 쓰는 경우가 있었는데 이 경우에는 합의를 통해 일반적으로 많이 쓰이는 용어로 통일했습니다.
예시로 두 가지 케이스를 공유드리겠습니다.
1.Pressed / Hold
모바일에서 버튼이 눌렸을 경우의 상태값을 표기하는 방법이 Hold / Pressed 두 가지의 경우로 나뉘었었는데요. 보통 Pressed를 많이 쓰다 보니 해당 용어로 통합하였습니다.
2.Active / Selected
Active와 Selected는 상황에 따라 다르게 쓸 수 있는데요. 우리가 만드는 디자인 시스템 내에서는 Selected로 용어를 통일하여 사용하기로 하였습니다.
복수형 이름 사용하기
컴포넌트가 큰 지붕 아래 다양한 하위 유형을 가지게 되는 경우가 있습니다.
단일 컴포넌트인 Tab과 여러 하위 유형을 가진 Chip 컴포넌트예를 들면 Tab의 경우 단일 컴포넌트로 쓰이고 있지만, Chips의 경우 해당 컴포넌트 내에 각기 다른 4가지 유형의 칩이 있는 경우처럼요.
이렇게 하위 유형이 많은 컴포넌트들은 상위 개념 컴포넌트 이름 뒤에 s를 붙여 다양한 유형을 담고 있는 것을 내포할 수 있도록 하였습니다.
더 세밀하게 우리만의 것으로
규칙까지 정하고 컴포넌트를 만들어나갔지만, 생각보다 쉽지 않았습니다.
만들어갈수록 궁금한 점들과 고민되는 부분들이 생기더라고요.
우리가 고민한 만큼 더 알게 된 부분을 공유드립니다.
똑같아 보이지만 사실은 다른 유형들
1. 다 똑같은 칩 아닌가요?
칩의 경우 디자이너들이 각자 맡은 화면에서 보이는 형태부터 제작하다 보니, 다양한 스타일의 칩이 생겼습니다. 하나로 통합하기 전에 칩의 개념부터 정리해 봤습니다.
좌: ChoiceChip, 우:FilterChipChoiceChip : 단일 선택이 가능한 칩
FilterChip: 다중 선택이 가능하며, 선택한 항목을 보여주는 필터의 개념을 가진 칩
위와 같이 개념 정리를 통해 칩 유형을 분류하고 통합하였습니다. 지도에 쓰이는 칩의 경우 별도의 개념으로 가져간 경우가 있는데, 이 부분은 다음 파트에서 이어서 말씀드리겠습니다.
2. 다 똑같이 탭 아닌가요?
에어비앤비에서는 위 이미지처럼 흔히들 “탭”이라고 부를 수 있는 요소를 다양한 형태로 확인할 수 있는데요.
탭 또한 디자이너들이 각자 담당한 화면에서 컴포넌트를 만들고 취합하다 보니, 형태는 비슷하지만 각기 다른 명칭을 사용하고 있었습니다.
그래서 컴포넌트의 사용 용도를 정의하고, 시각적인 차이를 통해 분류하고 사용하기로 하였습니다.
Category : 탭과 비슷하지만 아이콘을 함께 사용
Tab : 큰 덩어리로 카테고리화하여 탭 개수가 늘어나게 되면 스와이프 하여 사용 가능
Segment : 사용자의 선택에 따라 보여주는 옵션의 내용이 다르며, 특히 그래프라던지 시각적인 비주얼이 담긴 내용이 달라지는 경우가 많고 되도록 3개 이하로 사용
컴포넌트의 사용 용도를 정의할 때는 기존에 잘 만들어진 타 디자인 시스템을 참고였는데요, 똑같이 만드는 것보다 우리에게 맞는 시스템으로 재정의하는 것이 중요하다는 것을 배웠습니다.
컴포넌트 사용 관련 고민
1. 네이밍시 어떤 걸 고려해야 할까?
컴포넌트 이름은 흔히 알고 있는 명칭으로 만드는 편인데요. 때로는 다른 케이스들이 있기도 합니다. 이 때는 내부에서 협의해 우리 상황에 맞추어 이름을 만들기도 하였습니다.
확장성을 고려한 경우
리스트 컴포넌트 중에 초반에는 “ListSearch”라는 명칭을 사용한 경우가 있었습니다. 하지만 이렇게 검색 리스트라고 한정을 짓게 되면 여러 곳에 재사용할 수 있는 컴포넌트의 의미를 벗어나는 것 같았습니다.
자세히 보면 아이콘과 텍스트의 조합으로 이루어진 컴포넌트이기 때문에 확장성을 고려하여 "ListWithIcon"이라는 명칭으로 변경하였습니다.
특수한 상황을 고려한 경우
만든 칩 유형 중에 지도를 볼 때 사용되는 MapChip이 있는데요.
보통 Chip 컴포넌트는 기본값과 선택값이 있을 텐데, 에어비앤비에서는 지도에서 가격에 따른 숙소 확인을 마치고 다른 칩을 선택할 경우 기존에 ‘확인한 칩’의 형태가 별도로 바뀌는 경우가 있었습니다.
이런 특수한 상황을 고려하여 우리는 이 컴포넌트를 "Viewed"라는 상태값으로 명칭을 정하여 사용하였습니다.
이렇듯 컴포넌트는 내규 합의에 의해 특수성이나 확장성을 고려하여 새로운 명칭을 가질 수 있단 점을 배웠습니다.
2. 모든 경우의 수를 전부 배리언츠로 만드는 게 좋을까?
버튼의 유형은 크게 베이직, 아이콘, 텍스트, fab로 분리했는데요. 이 중 베이직과 텍스트버튼의 경우 아이콘이 옆에 함께 붙는 경우도 있었습니다.
처음에는 모든 경우의 수를 다 배리언츠로 처리했지만, 나열해 보니 너무 많은 종류의 컴포넌트가 생기는 바람에 관리 차원에서는 효율적이지 못하다는 생각이 들었습니다.
이때 불린 기능을 사용하게 되었습니다.
우측 패널의 레이어 영역에서 아이콘 같은 요소를 불린 처리할 수 있는데요, 컴포넌트에서 불린 기능을 사용한 프로퍼티에 On/Off 처리가 되어 필요한 상황에서만 사용할 수 있습니다.
예시로 가져온 불린 처리 전과 후의 배리언츠 개수기존의 수많은 버튼 배리언츠 개수를 불린 기능을 통해 더 콤팩트하게 관리할 수 있었습니다.
우리의 경우 버튼 사이즈를 M, S로 제한해서 사용하고 있었지만 보통의 경우 다양한 버튼 사이즈 값을 사용하고 있기 때문에 그럴 경우에는 많은 숫자의 컴포넌트 관리가 필요하기도 합니다.
관리적인 측면까지 고려한 상황에서는 불린 처리가 유용할 수도 있다는 것을 배울 수 있었습니다.
다음 글로 넘어가며...
컴포넌트를 만들 때 팀원들과 네이밍이나 규칙들을 협의하면서 만들었는데요.
단순히 만드는데서 그치지 않고, “어떻게 하면 다른 디자이너들도 컴포넌트의 용도에 대해 잘 이해하고 쓰기 편한 컴포넌트로는 디벨롭을 할 수 있을까?”를 고민을 하게 되었습니다.
그렇게 시작된 컴포넌트 사용성 디벨롭에 대한 이야기를 다음 회차에서 공유하겠습니다.
최종 디자인 시스템 링크 바로가기
참고자료
