아토믹 디자인 시스템으로 컴포넌트 만들기
미드저니 카드 UI 스타일 따라하기
미드저니를 이용하다가 블러 처리된 카드 UI 스타일이 예뻐서 피그마에서 한번 만들어보고 싶어졌다. 최근에 회사에서 디자인 시스템 작업을 진행하면서 컴포넌트의 구성 방식에 대해 고민이 많아졌는데, 피그마 기능 연습도 하고 컴포넌트 구조 연습도 할 겸 Card 컴포넌트를 만들어보기로 했다.
미드저니 블러 레이어
카드 UI에 마우스를 올리면 흐리게 처리된 레이어 위에 유저 정보 및 프롬프트 정보가 표시된다. 이미지의 색상이 레이어에 유지되는 것이 조화롭게 보여서 좋았다. 피그마에서 이런 스타일로 컴포넌트를 만들 수 있을지 궁금해졌다.
일반적인 레이어 스타일
썸네일 위에 레이어를 추가하고 정보를 표시하는 것은 일반적인 방식이다. 가장 빈번한 것은 투명도가 적용된 검정색 레이어를 살짝 깔아서 표현한다. 카카오웹툰처럼 썸네일에서 색상을 하나 추출하여 고정 색상이 아닌 다이나믹 색상(Material의 네이밍에 따르면...)으로 표현하기도 한다.
단색으로 적용하는 것은 피그마에서도 매우 쉬운 작업이기 때문에 굳이 단색 레이어의 카드 UI는 신경 쓰지 않고 블러 효과만 연습해 보기로 했다.
피그마 작업 결과
결론적으로 블러 레이어를 추가하여 이미지의 색상이 은은하게 비치는 카드 UI를 만들었다. 인터랙션도 추가하여 마우스를 올린 상태(hover)에서만 정보가 표시되도록 설정도 해두었다.
(GIF) 이미지 변경
(GIF) 인터랙션컴포넌트 만들기
최종적으로 Card UI는 아래 6개의 컴포넌트로 제작되었다. 한 번에 Card를 구성하지 않고 아토믹 디자인 시스템 방식으로 작은 구성요소를 합쳐서 제작했다.
아토믹 디자인 시스템 방법론은 검색하면 많이 나오니 유명한 이미지와 GhatGpt의 요약 설명만 기록해 두기로...
아토믹 디자인 시스템은 디자인 작업을 간편하게 관리하고 일관성을 유지하기 위한 방법 중 하나입니다. 이 시스템은 디자인을 작은 구성 요소로 분해하고, 이를 조합하여 페이지 및 애플리케이션의 디자인을 구축합니다. 이러한 구성 요소들은 원자 수준부터 시작하여 분자, 조직체, 템플릿 등 다양한 수준으로 나누어집니다.
- ChatGpt
피그마 프로퍼티
프로퍼티는 컴포넌트의 작동 방식을 정의하는 속성으로 피그마에서 설정 가능한 프로퍼티는 Variant, Booelan, Instance swap, Text 4가지가 있다. (자세한 설명은 피그마에 나와있으니 참고)
Boolean
구성요소의 노출 유무를 설정할 수 있다.
(GIF) Boolean 프로퍼티 설Instance swap
구성요소를 변경할 수 있다. 보통 아이콘을 변경할 때 많이 사용된다.
(GIF) Instance swap 프로퍼티 설정Text
텍스트를 변경할 수 있다. 개발 쪽에서는 String이라고 하는 속성이다.
(GIF) Text 프로퍼티 설정Variant
구성요소의 형태나 스타일이 달라질 경우 설정하는 프로퍼티.
(GIF) Variant 프로퍼티 설정프로퍼티를 잘 활용하면 컴포넌트를 굳이 여러 개로 나누지 않더라도 다양한 방식으로 확장성 있게 사용할 수 있다.
1) Blur 레이어
이미지 위에서 흐리게 처리하여 콘텐츠 가독성을 높여주는 레이어
테스트할 이미지를 하나 불러오고 위에 블러 처리할 영역만큼 도형을 만들어준다. 사각형 도형이 만들어졌으면 색상에 투명도를 설정하고(일단 50%로 설정해두었다), Effect에 Background blur와 Layer Blur를 각각 설정해준다.
흐림 효과 설정예시 설정)
Fill > Opacity : 50%
Effect > Background blur : 5
Effect > Layer blur : 50
블러 처리되는 영역이 이미지에 딱 맞을 경우 가장자리가 제대로 흐려지지 않기 때문에 blur 처리된 레이어는 이미지보다 확장시켜준다. 끊기는 부분 없이 제대로 설정된 것을 확인하고, 이미지 바깥으로 넘어가보이지 않도록 마스크 레이어를 하나 추가해서 마스킹 처리를 한다. blur 영역 마스크가 제대로 설정되었으면 컴포넌트로 등록한다.
블러 마스크 컴포넌트단순히 블러 설정과 마스크 처리하여 컴포넌트를 생성하면 아래와 같은 레이어 구조를 갖는 컴포넌트가 생성된다.
이 블러 레이어 컴포넌트가 이미지 위에 표시되었을 때 어떤 룩앤필로 보일지, 가독성 테스트를 위하여 텍스트 UI를 올려서 확인했다.
가독성 이슈별다른 색상 설정을 하지 않았기 때문에 딱 봐도 가독성이 떨어져서 내용이 인지되지 않았다. 따라서 콘텐츠 가독성을 높이기 위하여 blur 레이어의 색상을 다음과 같이 바꾸어주었다.
#fff 단색 → #000 linear로 변경
Blend mode를 Normal → Plus darker로 설정 (실제로 프로덕트에 적용한다면 개발쪽에서 CSS 처리 가능한지 논의는 필요할 것 같다)
설정 변경
블러 레이어 색상 설정 전/후 비교색상 설정 전과 후를 비교했을 때 확실히 내용이 잘 보이는 것을 확인할 수 있다. 블러 레이어 컴포넌트 생성은 되었으니 위에 표시되는 각종 콘텐츠 컴포넌트를 구성해 보기로 했다.
2) Button (Common Button)
버튼은 서비스 이용에 있어서 가장 필수적이고 빈번히 사용되는 UI다. 다양한 맥락에서 다양한 플로우를 설계하는 데에 사용되기 때문에 버튼 컴포넌트를 만들 경우 스타일이나 작동 방식에 관하여 많은 고민이 필요하다. 하지만 지금은 테스트 작업이기 때문에 한 가지 스타일로만 구성을 해보았다.
단순하게 생각했을 때 버튼의 필수 구성 요소는 아이콘과 텍스트라고 할 수 있다.
아이콘 변경
아이콘의 경우 Instance swap을 적용하여 사용처에 따라 변경할 수 있게 구성한다.
아이콘 노출 설정
때에 따라 아이콘 없이 텍스트만으로도 사용할 수 있기 때문에 아이콘 노출 여부를 결정할 수 있도록 Boolean 프로퍼티도 적용했다. (노출 여부를 결정하기 때문에 직관적으로 눈 이모지 추가)
레이블 변경
유도하는 액션이 다르기 때문에 텍스트도 당연히 변경되어야 한다. 텍스트는 text 프로퍼티로 설정한다.
아이콘 좌/우 위치 설정
지금 작업하는 미드저니 카드 UI의 버튼은 좌측에만 아이콘이 있었지만 하는 김에 우측에도 설정할 수 있도록 추가해 보았다.
위처럼 프로퍼티를 추가하면 아이콘 노출 여부, 아이콘 위치, 아이콘의 종류, 텍스트를 변경하여 다양하게 활용할 수 있다.
컴포넌트가 만들어지면 UI를 직접적으로 건드리지 않고 우패널에서 프로퍼티 변경을 통해 작업을 해야 한다.
3) Button (Icon Button)
아이콘 버튼은 2번 Common Button(아이콘+텍스트)보다 간단하게 만들 수 있다. 2번 버튼에 텍스트 노출 여부를 설정하는 프로퍼티를 추가해서 아이콘만 있는 스타일로 사용할 수도 있지만, 아이콘만 표시될 때는 정비율을 유지하고 싶었기 때문에 컴포넌트를 나눠서 만들었다.
아이콘 버튼은 아이콘을 변경할 수 있는 Instance swap만 추가해주면 된다.
4) Contents Group
카드 UI에서 표시할 정보 컴포넌트다. 앞서 만든 Common Button과 Icon Button을 사용하여 텍스트만 추가해서 구성했다.
새로 추가된 텍스트 레이어인 ①Nickname(확장성 있게 사용하기 위해 프로퍼티 이름은 title로 적용)과 아래 ②상세 설명 부분인 Sub text를 text 프로퍼티로 설정한다.
외부 컴포넌트 컨트롤 설정
함께 사용된 버튼의 경우 이미 다른 컴포넌트로 구성했기 때문에 Contents Group 컴포넌트에서는 이미 만들어진 버튼 컴포넌트를 컨트롤할 수 있는 설정만 해주면 된다. 컴포넌트를 선택하고 프로퍼티 추가를 누르면 'Nested instances'에서 다른 컴포넌트를 컨트롤할 수 있는 여부를 결정할 수 있다.
외부 컴포넌트 컨트롤 설정을 하지 않았을 경우 우패널에서 1뎁스 컴포넌트의 프로퍼티만 바로 확인이 가능하고, 설정을 할 경우 함께 사용된 N뎁스 컴포넌트의 프로퍼티도 모두 확인하고 변경할 수 있다.
컴포넌트 구조를 보면 다음과 같다.
반응형 레이아웃
텍스트가 포함된 컴포넌트이기 때문에 Auto layout 설정하여 width가 늘어났을 때 레이아웃이 깨지는 경우가 없도록 한다.
4) Contents Layer
기본적인 컴포넌트는 만들었으니 (1) Blur layer와 (3) Contents Group를 합쳐서 카드 UI에서 정보를 표시할 컴포넌트를 만들어준다.
반응형 레이아웃 설정
서비스를 이용하는 기기는 다양하기 때문에 항상 Auto layout 설정 습관을 들여두면 좋다. (1) Blur layer와 (3) Contents Group을 단순히 그룹할 경우 width가 늘어났을 때 padding이 달라지는 문제가 발생한다.
이는 (3) Contents Group 컴포넌트가 (1) Blur layer 내부에서 Scale로 작동하기 때문인데, Scale로 설정이 되어 있을 경우 %가 유지되며 바뀐다.
ex. 전체 1000px에서 A가 80%(800px), B가 20%(200px)일 때, 전체를 500px로 변경할 경우 A는 400px, B는 100px로 변경된다.
크기가 변경되어도 padding은 유지하고, 글자 수의 차이가 있을 경우 이미지의 Bottom을 기준으로 위로 늘어나도록 하기 위해서 (3) Contents Group의 작동 조건을 아래와 같이 변경해 주었다.
horizontal : Left and right
vertical : Bottom
위와 같이 설정하면 width가 늘어났을 때 레이아웃이 잘 유지되는 것을 확인할 수 있다.
5) Card
(4) Contents Layer와 이미지를 합쳐서 Card 컴포넌트를 구성했다.
하위 컴포넌트 컨트롤 설정
다른 컴포넌트를 합쳐서 또 다른 컴포넌트를 구성할 경우 상위 컴포넌트에서 하위 컴포넌트를 함께 컨트롤할 수 있도록 Nested instances 설정을 잘 해주면 사용성이 좋아진다.
물론 무조건 설정한다고 좋은 것은 아니다. 프로퍼티가 너무 많으면 복잡해 보이고, 굳이 변경되지 않을 경우 볼 필요가 없기 때문에 작동 방식에 따라서 의도적으로 노출하지 않는 것이 좋을 수도 있다.
내부에 사용된 컴포넌트의 프로퍼티를 일괄적으로 확인하고 수정할 수 있다.
카드만 선택하고 내용, 버튼 모두 변경 가능디테일 설정 추가 및 수정
처음부터 완벽하게 만들 수는 없기 때문에 다양하게 사용해 보면서 작동 방식을 보완해나가야 한다. 최종적으로 만들어진 Card 컴포넌트에 다양한 이미지를 적용해 보면서 개선해야 할 부분들을 체크해보았다.
이미지 비율, 다양한 밝기의 이미지를 넣어서 확인해 본 결과 아래와 같은 문제가 있었다.
1. 텍스트 가독성이 떨어진다.
2. 텍스트가 너무 길어진다.
텍스트 가독성 높이기
가독성이 떨어지는 이유는 글자와 배경의 명암비가 낮은 것과 글자와 중첩된 배경 이미지의 복잡성 때문이다. 따라서 아래와 같이 수정 작업을 해주었다.
(1) blur layer의 색상을 더 어둡게 처리한다.
(2) card ui에서 contents layer의 height을 늘려서 블러 처리되는 영역을 확장한다. (글자가 표시되는 위치에는 이미지의 복잡성을 줄여주는 작업)
수정 전/후글자 길어짐 처리
서비스에서 자체적으로 제공하는 문구의 경우 너무 길어지지 않도록 내부적으로 정렬을 하므로 크게 문제 되는 경우는 없겠지만, 고객의 정보가 표시되는 UI의 경우 어느 정도의 내용이 들어가는지 예측을 할 수 없기 때문에 텍스트가 길어질 경우를 항상 고려해야 한다.
Card 컴포넌트에서 Title은 최대 1줄, Sub Text는 최대 3줄까지 표시될 수 있도록 Max lines을 설정했다. 설정한 길이 이상으로 텍스트가 많아지면 말 줄임 처리가 된다.
최대 글자 라인 수를 설정했기 때문에 기존에는 내용이 길어지면 무한정 위로 올라갔다면, 수정 후에는 말 줄임 처리가 되어 과하게 레이아웃이 깨지는 경우를 예방할 수 있다.
최대 글자 라인 수 설정 전/후 비교IconButton 스타일 변경
Icon Button에 Common Button의 스타일을 그대로 가져와서 제작했기 때문에 기본적으로 배경에 살짝 색상이 들어간 상태였다. 하지만 한 화면에서 모든 UI를 강조하게 되면 주의가 산만해질 수 있기 때문에 기능의 중요도에 따라서 위계 구분을 적절히 하면 좋다. 색상 대비는 물론 배경의 유무 또한 UI를 강조하는 기준이 될 수 있다. 따라서 핵심 액션을 하단에 있는 2개의 버튼으로 본다면, 타이틀 우측에 표시된 Icon Button는 위계를 낮추는 것이 메인 액션에 집중할 수 있는 환경을 조성할 수 있다.
물론 위계는 서비스의 목적에 따라 달라질 수 있고 그냥 미드저니의 UI를 보고 짐작해서 판단한 의견이다.
아토믹하게 컴포넌트를 구성했기 때문에 최소 단위 컴포넌트인 Icon Button만 수정을 해주면 Icon Button이 사용된 모든 UI에서 스타일이 변경된다.
(GIF) 스타일 일괄 변경인터랙션 적용
기본 상태에서 모든 정보를 표시하게 되면 정보 인지의 과부하도 있을 뿐만 아니라, 핵심 정보인 이미지가 가려지기 때문에 마우스를 올린 상태(hover)일 때만 contents Layer가 노출되도록 적용이 필요하다.
Hover 상태에서 Contents Layer 노출하기
card 컴포넌트에 variant를 하나 더 추가해서 "default", "hover"로 프로퍼티를 구분한다. "default" 상태에서는 contents layer가 노출되면 안되기 때문에 contents layer의 투명도를 0으로 설정한다. 추가로 "default" → "hover" 상태로 변경될 때 자연스럽게 아래에서 위로 올라오는 느낌을 주고 싶어서 "default"에서의 contents layer 위치를 살짝 아래로 설정했다.
프로토타입 패널에서 "default"를 "hover"에 연결하여 while hovering 상태를 추가한다. Smart animate를 적용하면 끊기는 느낌이 아니라 움직임이 이어지는 효과를 줄 수 있다.
(GIF) 스마트 애니메이션 적용 차이Button 인터랙션
버튼은 기능성 UI이기 때문에 고객의 액션에 따라서 명확하게 상호작용이 되고 있음을 표시해 주는 것이 좋다. 따라서 hover(마우스를 올리고 있는 상태)와 press(클릭하고 있는 상태)를 추가한다.
hover, press 타입을 추가하였고 각 상태별로 배경 색상을 다르게 설정했다.
default → hover : while hovering
hover → press : while pressing
(GIF) 버튼 인터랙션 미적용
(GIF) 버튼 인터랙션 적용컴포넌트 활용
정리된 card 컴포넌트를 그리드로 만들고 다양한 이미지로 변경해보았다.
(GIF) 이미지별 hover 효과
콘텐츠 레이어가 표시된 상태아토믹 시스템
컴포넌트 업데이트
다양한 이미지 적용 및 그리드를 만들어보는 과정에서 이미지 비율이 가로형일 경우 글자가 이미지를 너무 덮는 문제가 있었다. 따라서 이미지 비율에 따라서 Card UI에서 Max Lines을 조절하기로 했다.
가로형 비율일 때 콘텐츠 영역이 너무 꽉 차 보임Card 컴포넌트에 ratio 프로퍼티를 추가하여 비율에 따라서 세로형, 정비율, 가로형인 "vertical", 'square", "horizontal" 3가지를 추가했다. 각 비율에 따라서 Sub Text의 Max lines을 아래와 같이 다르게 설정해 주었다.
ratio="vertical" → 4
ratio="square" → 3
ratio="horizontal" → 1
이미지 비율에 따라서 다른 프로퍼티로 설정하면 레이아웃 이슈를 해결할 수 있다.
카드 비율에 따라 최대 글자 라인 수 다르게 적용Card UI에서 Max Lines을 설정한 이유
Card UI에 사용되는 Contents Layer의 경우 Contents Info라는 컴포넌트를 가져와서 사용하고 있다. 최소 단위의 UI에서 스타일을 관리하면 사용처에서 일괄로 변경할 수 있는 장점이 있지만, 이 장점은 해당 컴포넌트가 어디에 어떻게 사용되었는지 제대로 인지하고 있지 않다면 추후 수정 시 의도치 않은 곳에서도 변경될 수 있는 단점으로 작용할 수도 있다.
디자인 시스템을 관리하는 목적에 따라 다르겠지만, 만약 실제 서비스였다면 Contents Info는 꼭 Card UI가 아니라 다양한 곳에서도 사용될 수 있는 구성 요소이기 때문에 고정으로 글자 수 제약을 하지 않았고, Contents Info가 사용되는 최종 컴포넌트인 Card UI(사용처가 명확히 정해진)에서 조건에 따라서 글자 수 제약을 처리했다.
추후 이렇게 다양하게 사용될 수 있고 목적에 따라서 정보를 많거나 적게 표시해야 할 수 있으니...
컴포넌트 분리 기준
최소 단위의 컴포넌트 스타일을 변경하면 해당 컴포넌트가 사용된 UI에서 일괄적으로 변경된다. 예를 들어 버튼 스타일을 모두 outline 형태로 바꾸고 싶다면 바로 변경해도 무방하다.
위 변경사항으로 인해 모든 Card에서 버튼 스타일이 Surface에서 Ouline으로 변경된다.
그러나 일부 페이지에서는 기존 스타일을 유지하고, 새로운 스타일을 따로 적용하고 싶을 경우에는 컴포넌트를 바로 변경하면 안되고 새 컴포넌트를 추가하거나 새로운 프로퍼티를 추가해야 한다.
원하는 방향이 이 방식이라면
프로퍼티 업데이트. 다른 컴포넌트에 영향주지 않는다.사용처에 따라서 Button 스타일을 정의하는 프로퍼티를 변경해서 사용하면 이미 사용된 UI에도 영향을 주지 않고, 서로 다른 스타일로 유지해서 프로덕트를 구성할 수 있다.
마무리
아토믹 시스템은 UI 구성 요소를 작은 단위로 구성하고 합쳐서 만드는 방식이다. 일괄 변경 및 확장성에 있어서 이상적이고 효율적인 방법임은 분명하다. 하지만 실제 서비스에서 아토믹 방식으로 운영을 한다고 해도 많은 문제에 맞닥뜨리는 것 같다. 일괄적으로 관리하기 위해 최소한의 스타일로 구성하여 여기저기 사용했다고 했을 때, 추후 일부 화면에서만 UI 변경이 필요한 경우 사이드 이펙트를 파악하기가 어려워서 결국 수정하기 어려운 상황이 발생하기도 한다. 반면 컴포넌트를 너무 나눠서 제작할 경우 비슷한 스타일과 작동 방식이 너무 많아져서 여기저기서 바꿔줘야 하는 노가다 작업이 발생한다. 수정이 아니라 사용할 때도 가이드라인이 명확하지 않으면 헷갈린다.
일괄로 관리할 것은 합치고, 나눠서 관리할 것은 나누고. 사실 말은 쉽지만 막상 서비스를 운영하면 초반에는 예상치 못했던 상황이 발생하는 것은 피할 수 없는 것 같다. 완벽한 것은 없으니 이런저런 시행착오를 거치면서 최선의 관리 방식을 찾아보면 좋을 것 같다. 정답은 없다... (하지만 그렇다고 막 해도 안 될 것)
