MVP 와이어 프레임을 위한 파운데이션 구축하기
파운데이션이란?
예시를 들어 설명해보자면 우리가 화장을 할 때도 베이스 화장 즉, 파운데이션을 바르고 색조를 바르듯이
앱 디자인을 할 때 예쁜 디자인을 얹기 전에 미리 해 놓아야 하는 것이다.
파운데이션은 컬러, 타이포그래피, 스페이싱 등 이고
색조 화장은 컴포넌트와 인터랙션 등 이다.
밖에 나갈 때 급해서 색조 화장은 못하지만 베이스는 바르고 나가는 사람처럼
해커톤을 위해 1R에서 급하지만 기본적인 뼈대, 파운데이션은 갖추고자 하는 것이다..
파운데이션 설정을 하는 이유
최소한의 파운데이션을 설정해두면 추후 디자인을 입힐 때도 번거로운 일이 적을 것 같아서
아직 기획이 확실히 잡히지 않아서 미리 해둘 수 있는 걸 하기 위해서
기준(폰트 사이즈, 8배수 등)이 있으면 오히려 초기에 와이어 프레임 제작할 때 값에 대한 고민이 줄어서 더 빠르게 할 수 있을듯
막 며칠 전에 디자인 시스템 과정을 마친 김에 활용해볼 겸, 그리고 수업 과정에선 클로닝만 해봤으니까 제작도 경험해볼 겸
따라서 현재 만드는 건 협업을 위한 가이드라인을 포함한 디자인 시스템 보다는 당장의 와프를 통일성 있게 만들기 위한 파운데이션 정도가 된다.
그래서 배리어블을 구성해야 되는데 레퍼런스를 차용하여
익숙하게 봐온 당근 seed와 구름 vapor에서 지금 현 상황과 서비스에 맞는 부분만 쏙쏙 빼오려고 했다.
빼오기 위한 혼자만의 규칙을 좀 정했는데
너무 다양한 상황을 고려한 구성은 아예 제외하기 (sementic 컬러, 다크모드, 폰트static, 웹 해상도 등)
아직 어떻게 될 지 모르니 너무 한정 짓지는 말기 (폰트 사이즈, radius, spacing 등 일단 최소, 최대 안에서 다양하게..)
와이어프레임 단계에선 컬러 지정도 제외하기 (나중에 oklch 활용해서 할 것!)
따라서 당장 할 구성은 와이어프레임 구성할 때 필요할
Typography, Radius, Scaling
배리어블의 컬렉션 구성
당근의 SEED(직접 클론한거라 실제와 다를 수 있음) 그리고 구름의 Vapor 그리고 빵빵의 Dough
원티드의 디자인시스템은 Montage, 토스는 TDS
대기업들은 디자인 시스템에 이름을 붙이길래 나도 기분 낼라고.. 빵의 기본이 되는 반죽인 도우, Dough로 지어봤다........
Vapor는 컴포넌트마다 배리어블을 지정한 게 인상적이다.
Dough는 전체적으로 SEED와 비슷하게 하는데 네이밍만 조금 바꿨다
Spacing과 Scaling
SEED : Spacing 컬렉션 안에 dimension 이라는 그룹으로 모든 간격과 크기들을 같은 배리어블로 통일
Vapor : Scaling 컬렉션 안에 fontSize, lineHeight, dimension, space 로 나눔
의견 및 결론
사용 방식은 당근처럼 디멘션과 스페이싱 배리어블을 통일하는 게 개인적으로 DS 클로닝하면서 사용하기에 편하다고 느꼈고
컬렉션 네이밍은 x1, x2 이러한 배리어블로 간격과 크기들을 통일하는 것이기 때문에 Spacing보단 구름이 사용하는 Scaling이 좀 더 와 닿는다고 생각했다.
따라서 구성 방식은 당근처럼, 네이밍은 구름처럼 하기로 결정
*Scaling이라는 컬렉션 안에 x0_5, x1, …,x16 로 지정해서 간격 및 크기에 활용
Typography의 분류 방법
SEED : Typography 컬렉션 아래에 fontFamily, fontSize, lineHeight, fontWeight 지정
Vapor : Scaling 컬렉션 아래에 fontSize, lineHeight 지정 / Typography 컬렉션 아래에 fontFamily, fontWeight, letterSpacing 지정
*의문점 : 컬렉션에도 Typography가 있고 Scaling이라는 컬렉션 안에도 따로 typography가 있는데 왜 이렇게 나눈 건지 약간 궁금하다
의견 및 결론
개인적으로는 타이포라는 큰 컬렉션 아래에서 배리어블을 찾는 게 더 편하다고 느껴서 당근의 방식으로 하되, 구름처럼 letterSpacing도 추가하기로 결정
Typography 배리어블 네이밍
SEED : fontSize와 lineHeight 모두 t1, t2, … , t10 으로 통일 / 추후 스타일 적용 시 t1regular면 fontSize, lineHeight 둘다 t1으로 적용하면 됨
Vapor : fontSize, lineHeight, fontWeight 등 모두 각각 앞에 이름 붙이고 뒤에 -025, -100 등 값 붙임
의견 및 결론
SEED의 장점1 : t1, t2 라는 간소한 네이밍이 Vapor의 fontSize-100 보다 상대적으로 덜 복잡해 보이고 직관적임
SEED의 장점2 : 추후 스타일 적용 시 t1regular는 fontSize : t1, lineHeight : t1, fontWeight : regular 로 짝지어서 적용하는 게 직접 만들면서도 직관적이라 편하다고 느꼈음
SEED의 단점 : fontSize와 lineHeight의 배리어블 네이밍이 t1, t2 로 똑같아서 스타일에 적용할 시 그룹을 확인해야 하는 헷갈림이 있음
Vapor의 장점 : 배리어블 네임 앞에 각각 fontSize, lineHeight 등이 붙어서 각각 어떤 것의 값인지 명확하게 알기 쉬움
Vapor의 단점 : 배리어블 네임 뒤에 -025 부터 -1000까지의 값이 좀 커서 상대적으로 무겁게 느껴짐, 당근의 t1, t2, t3 과 다르게 어떤 숫자인지 한번 더 생각하게 되는 느낌
따라서 SEED처럼 t1, t2 를 활용하고, Vapor처럼 앞에 그룹 네임을 적어주기로 결정
*variables : fontSize_t1, fontSize_t2 …
*style : t1regular, t1medium …
Typo Style 활용 방식
SEED : 비교적 Primitive하게 활용 ex) t1regular, t1medium, t2regular
Vapor : 비교적 Sementic하게 활용 ex) display1, display2, body1
의견 및 결론
이건 뭐가 더 낫다기 보다 환경의 차이가 있을 것 같다고 생각했다.
구름은 서비스 특징 상 코드는 다른 폰트를 사용하기에 Sementic하게 스타일을 설정해야 편할 것 같다. (내 생각)
그에 비해서 당근은 굳이 폰트를 다르게 쓸 일이 많지 않을 것 같아서 Primitive하게 사용했지 않을까
그리고 실제로 당근을 클로닝하며 t1regular와 같은 방식이 오히려 사용할 때 직관적이고 편하다고 느껴졌다. (예 : t1이면 이정도 크기겠군)
또한 확장성 면에서
마지막으로 지금 상황에서 어떤 곳에 어떤 용도로 쓰일지는 알 수 없는 일이기에 당근의 방식으로 하기로 결정했다.
무조건 sementic할수록 좋은 게 아니라 상황에 따라 활용하기 좋은 방식을 택해야 하는구나 생각하게 되었다.
세부적인 값 설정
원래는 제미나이를 활용하여 모바일 기준으로 값을 지정해달라고 요청했으나 부분 부분 극단적인 값을 주는 게 있어서
그냥 대기업분들의 값을 따르기로 결정했다. 어차피 당근도 모바일 기반이라서 호환이 괜찮을 것 이다.
배리어블 네이밍 규칙
배리어블 네임은 다 스네이크 케이스로 통일하기로 했다. (그룹과 추후 컴포넌트들은 카멜 케이스로 통일)
중요한 건 아니지만 이유는 height-t3 보다 height_t3이 하이픈이 중간에 있으면 뭔가 읽을 때 문자로 읽혀서 비교적 방해되는 느낌(?)
언더스코어는 height와 t3이 쪼끔 더 분리되어 보이고 스페이스 효과가 나는 느낌…?
fontFamily 배리어블 네이밍
SEED와 Vapor 둘 다 배리어블 네임은 fontFamily로 해 놓고 밸류에만 폰트 이름을 적었는데
그냥 개인적으로 다른 배포된 DS들을 볼 때 어떤 폰트 쓴 거지 하고 누르면 fontFamily 라고만 보여서 (아래 사진 참고)
조금 답답했던 게 있어서 그냥 배리어블 네임도 폰트 이름으로 해버렸다.
아무래도 확장성 면에서 나중에 폰트를 바꿀 때 배리어블 네임도 바꿔야 하니까 이렇게 한 것 일텐데
그냥 .. 내가 내 DS 사용자로서 이게 더 편안하고 직관적이어서 이렇게 결정했다 ..
만약 폰트 바꿀 일이 있으면 손가락 몇 번 더 움직이기로..