우리가 구현하는 프로덕트 디자인은 붙이고 마는 스티커가 아니라 외부 환경에 시시각각 변해야 하는 살아 있는 생물체라고 할 수 있다. 화면 사이즈가 달라질 때 마다 레이아웃 안정성을 가지고 동적으로 변화해야하고, 사용자의 제스쳐에 따라서 적절한 피드백도 줘야한다.
1px의 디테일에 집착하면서도 막상 이런 부분들이 고려가 안된 디자인 가이드들이 생각보다 많은데, 이런 부분들이 간과되면 사용자의 사용성을 해칠 뿐만 아니라 개발자와의 커뮤니케이션 비용과 유지 관리 비용 또한 증가한다.
그래서 '디자인은 동적인 상태로 정의하고 구현되어야 한다'라는 생각을 가지는 것 그 자체만으로도 많은 도움이 되는데, 대단한 인터렉션이나 에니메이션을 요구하는 내용은 아니여서 어렵게 생각할 필요는 없다.
가끔씩 프로토타입 개발 코드를 짜려고 오픈소스 코드를 보다보면 엄청 읽기 쉬우면서도 대부분의 상황에 유연하게 대응이 되는 코드를 발견할 때가 있다. 이걸 디자인에 대입해보면 아래 4가지 정도가 아닐까 한다.
- 많은 상황에 유연하게 대처할 수 있는 디자인
- 분기를 최소화하고, 레이어 구조 또한 최소화한 디자인
- 모든 해상도에 잘 대응된 레이아웃 안정성을 고려한 디자인
- 사용자의 모든 제스쳐에 대한 인터렉션을 하나의 문법으로 구현할 수 있게 잘 고려된 디자인
이렇게 유연하고 확장성을 고려한 디자인 가이드들은 개발자의 코드 작업도 쾌적하게 만들어 주는데, 동시에 커뮤니케이션 비용이라던가 위지윅한 디자인 가이드 적용에 대한 부분도 자연스럽게 개선된다.
한가지 예를 들어보자.
아래 그리드 레이아웃 가이드 중에 어떤게 더 명확하고 확장성이 있을까?
A. 기본 2열, 640 이상에서는 4열, 1280 이상에서는 6열
column의 갯수를 정의하는 기준이 외부 요인(viewport width)임
grid-template-columns: repeat(2, 1fr) @media (min-width: 640px) { grid-template-columns: repeat(4, 1fr) { @media (min-width: 1280px) { grid-template-columns: repeat(6, 1fr) {B. 그리드 내부 아이템의 width가 320보다 작아질 거 같으면 줄바꿈해주기
column의 갯수를 정의하는 기준이 내부 요인(그리드를 구성하는 각 요소의 width)임
grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
A 가이드 같은 경우에는 화면 해상도가 639에서 640로 갈 때 레이아웃이 좀 더 덜컹거리고, 화면 해상도가 3600인 디바이스에서는 내부 아이템 사이즈가 600으로 늘어나는 등 여러 어글리 케이스들이 생긴다.
B 가이드는 한줄 정의만으로 해상도에 따라서 레이아웃이 fluid한 방식으로 안정적으로 변하고, 그리드 내부 아이템도 너무 작아지거나 커지지도 않게 된다. (물론 1열 ~ n열로 동적으로 변하면서 처리해야될 문제는 발생하긴한다. 예를 들면 칼럼이 짝수, 홀수가 혼재되면 서버에서 짝지어서 불러오는 갯수가 애매해지거나 하는...)
이런 케이스들 위주로 디자인 가이드를 정의하면 좋을 지 한 번 알아보자.
1. 공통 인터렉션
버튼에 마우스 커서를 올리거나(:hover) 버튼을 클릭할 때(:active) 컬러가 변해야하는 경우 어떻게 정의하면 좋을까?
각 컬러마다 1:1로 상태에 다른 컬러값을 매칭하는 경우가 있는데, 다른 컬러 토큰이 생기거나 다크모드 컬러로 바뀌는 경우 확장성이 많이 떨어진다. 그리고 컬러가 변화하는 트랜지션을 구현하는데 있어서도 hex 코드로 된 rgb가 에니메이션이 되기 때문에 에니메이션 안정성도 상대적으로 떨어진다.
그렇기 때문에 아래처럼 밝기 필터를 통해 공통화 하는편이 좀 더 좋지 않을까한다.
라이트모드일 때
hover시 filter: brightness(0.95);, active시 filter: brightness(0.9);
다크모드일 때
hover시 filter: brightness(1.05);, active시 filter: brightness(1.1);
2. 컬러 opacity
가끔 (opacity가 100%인)솔리드 컬러를 써야할 지, opacity가 포함된 컬러를 써야할 지 고민이 될 때가 있다. (좀 더 와닿는 예시가 생각이 나지 않지만) 아래 예시를 기준으로 보면 주변 상황에 따라서 상대적인 밝기가 필요할 때는 opacity를 활용한 컬러인 hsla를 사용하는 편이 좋다.
3. 폰트 관련 정의
다른 포스팅에서 폰트 사이즈를 rem 단위로 하는게 유리하다는 주제로 얘기를 했었는데, 폰트 사이즈 같은 경우 rem으로 하던 pt로 하던 자기 스스로를 정의할 수 있는 속성이다.
하지만 line-height와 letter-spacing는 얘기가 살짝 달라지는데, 해당 폰트 사이즈에 따라서 상대적으로 정의가 되어야 하는 부분이 있기 때문에 디자이너들은 대부분 폰트 사이즈별로 이 속성값들을 개별로 매칭하는 경향이 있다.
특별히 line-height가 짝수여야 한다는 의도에 의해서 정의 되는건 상관없지만, 얼추 폰트 사이즈의 150% 정도를 줄간격으로 정의하고자 한다면 1.5em 단위를 활용하는 편이 좀 더 낫지않을까?라는 생각을 해본다.
이후에 디자인 시스템에서 폰트 스타일을 정의한 상태에서, line-height를 다르게 조절해야할 경우도 생기는데 line-height 자체를 조정가능한 props로 뺄 때도 1.5em을 1.3em 등으로 조절하는 편이 좀 더 좋기 때문이다.
4. 폰트 패밀리
variable 폰트는 font-weight가 벡터화 되어있기 때문에, 550같은 medium ~ semibold 사이에 있는 값도 쓸 수 있고, font-weight 자체를 에니메이션화할 수도 있다.
용량 자체는 대략적으로 하나의 font-weight 용량의 3배 정도 수준이기 때문에 font-weight를 3개 이상 쓸거라면 variable 폰트를 사용하는 편이 더 좋은 편이다.
웹폰트를 불러오는 과정에서 용량이 문제가 된다면 font-display: fallback; 옵션도 추가해두면 좋다.
5. 아이콘
픽토그램과 같은 아이콘을 사용하는데 있어서, 나중에 이 아이콘을 얼마나 자유롭게 수정해서 쓸 수 있는가? 개발에서 svg로 올렸을 때 stroke-width 같은 프로퍼티를 활용할 수 있는가?에 대한 측면에서 바라봐야한다.
그렇기 때문에 가능하면 면이 아니라 path로 작업하고, path finder와 같은 부분은 가능하면 절제해서 사용하는 편이 낫다.
