디지털 디자인의 복잡성
디지털 인공물의 디자인이 점점 복잡해지고 있다. 인간이 머리로 다룰 수 있는 복잡성을 오래 전에 한참 벗어났음에도 불구하고 아직 제대로 된 해결책은 없고, 디자이너와 개발자와 사용자 모두 고생하고 있다.
디자인 공간의 조합적 폭발
데스크탑 컴퓨터, 모바일 폰, 키오스크, 자동차 대시보드, 스마트 시계, XR 기기 등 소프트웨어가 실행되는 환경이 매우 다양해졌고 앞으로도 더 다양해질 것이다. 동일한 소프트웨어라도 아래와 같이 다양한 요소를 고려해야 한다.
- 입력 방식: 터치 스크린의 버튼은 마우스로 조작하는 기존 GUI 화면의 버튼보다 더 커야한다. 손가락이 마우스 커서보다 두껍기 때문이다. 그리고 마우스 커서와 달리 손가락은 시야를 가린다는 문제도 고려해야 한다. 스마트폰 등 핸드헬드 기기인 경우 레이아웃을 디자인할 때 엄지손가락이 쉽게 도달할 수 있는 영역을 고려하는 게 좋다. 터치 스크린 이외에도 키보드만 쓰는 경우, 스타일러스를 쓰는 경우, 리모콘, 음성, 수어 등을 쓰는 경우 등을 고려할 필요가 있다.
- 가로 모드-세로 모드: 대부분의 스마트폰과 태블릿은 가속도 센서를 이용하여 가로 모드와 세로 모드를 전환한다. 똑같은 세로 모드라고 하더라도 시스템의 상태창 두께가 달라지거나 온-스크린 키보드가 펼쳐지는 등 다양한 이유에서 화면 비율이 크게 달라질 수 있다.
- 네트워크 상태: 다양한 이유에서 네트워크 속도가 매우 느리거나 일시적으로 네트워크가 끊어질 수 있다. 이런 경우에 어떻게 하면 소프트웨어의 동작이 완전히 멈추는 대신 좀 더 우아하게 대처할 수 있는지 고민해야 한다.
- 다국어 지원: 러시아어나 독일어 단어는 평균적으로 길어서 버튼 모양에 영향을 줄 수 있다. UI를 자칫 잘못 설계하면 어떤 국가에서는 레이아웃이 틀어지거나 레이블을 다 읽지 못하게 되는 등의 문제가 생길 수 있다. 게다가 어떤 국가는 텍스트를 오른쪽에서 왼쪽으로 쓰거나 위에서 아래로 쓴다.
- 글자 크기: 저시력자인 경우 큰 글씨를 선호할 수 있다. 반대로 한 화면에 최대한 많은 정보를 담기 위해 글자크기를 줄여서 쓰는 사용자도 있다.
그 밖에도 고대비(저시력자), 다크 모드, 좁은 여백-넓은 여백, 전자잉크 패널(화면 갱신 속도가 느리고 단색이거나 색재현력이 낮다), 발열 상태(일부 운영체제는 발열 상태에 따라 그래픽 요소의 품질이나 화면 갱신 속도 등을 조절할 수 있다), 모션 줄임(일부 사용자는 모션이 과하면 멀미 증상을 일으킨다) 등 고려할 요소는 끝도 없다.
요소가 추가되면 더하기가 아닌 곱하기가 되기 때문에 경우의 수가 순식간에 어마어마하게 커진다. 예를 들어 입력장치가 4종, 폼팩터가 5종, 화면비가 4종, 색상 옵션이 6종, 글자 옵션이 3종이라면 벌써 개 조합이 나온다. 이를 조합적 폭발이라고 부른다.
기존의 대처 방식: 대부분의 문제를 무시하기
이 문제를 해결할 방법이 아직까지 딱히 없기에 모든 가능한 조합을 고려해야한다는 주장은 비즈니스를 모르는 사람의 한가한 소리 정도로 취급될 수 밖에 없다. 현재 널리 수용되고 있는, ‘비즈니스를 고려한’ 현실적 타협안은 이렇다.
- 상당한 요소를 고려하지 않는다: 예를 들어 글자를 오른쪽에서 왼쪽으로 쓰는 사용자 등 비즈니스적으로 중요하지 않다고 여겨지는 요소를 아예 고려하지 않는다.
- 고려하기로 정한 요소들로 만들어질 수 있는 모든 조합 중 대부분을 고려하지 않는다: 예를 들어 “고대비” 설정을 선택한 사용자는 “다크 모드”를 고를 수 없다거나, 영어 화자는 다섯가지 음성 중 하나를 고를 수 있지만 한국어 화자는 한 가지 음성만 고를 수 있다거나 하는 식으로, 어떤 요소들을 고려하기로 정한 경우에도 각 요소들의 모든 가능한 조합을 다 고려하지 않고 일부만 고려한다. 마치 “디카페인 아메리카노”를 고르는 순간 원두는 고르지 못하게 되는 것과 비슷하다.
이렇게 하면 디자인의 복잡도를 관리 가능한 수준으로 낮출 수 있게 된다. 하지만 이로 인해 오늘날 만들어지는 거의 모든 디지털 인공물은 실제로 해결해야 하는 문제의 극히 일부만 해결한 채로 시장에 나온다. 그 결과, 주변화된 상황에 놓인 이들이 더 다양한 문제를 겪게 된다.
근본 원인: “캔버스에 형태를 배치하기” 메타포
기존의 디자인 방식은 “캔버스에 형태를 배치하기” 메타포에 기반을 두고 있다. 좀 더 자세히 말하자면 “정해진 판형의 캔버스 위에 정적인 그래픽 요소를 배치하기” 메타포에 가깝다.
주요 대학의 디자인 교육 과정도 타이포그래피와 인쇄 매체를 위한 시각 디자인 이론을 주로 다룬다. “디지털 미디어 디자인” 같은 이름을 붙인 학과라도 근본적인 차이가 있는 것 같지는 않다.
거의 모든 디자인 소프트웨어도 마찬가지인데, 화면의 가장 넓은 영역을 “캔버스”가 차지하고 있고 이 영역에 마우스로 무언가를 가져다 놓는 게 핵심 인터페이스다. 과거에 쓰던 도구(예: 포토샵)에 비해 요즘에 쓰는 도구(예: 피그마)는 점진적으로 이 메타포에서 벗어나고 있지만, 여전히 큰 틀에서는 변하지 않았다.
”형태를 배치하기” 대신 “의도를 선언하기”
“형태를 배치하기”와 “의도를 선언하기”의 차이를 살펴보자.
웹 디자인의 초창기에는 상당수의 웹사이트에 “이 사이트는 1024x768 해상도에 최적화되어 있습니다” 같은 문구가 있었고, 실제로 사용자의 브라우저 크기가 이 해상도에 맞지 않으면 사이트를 제대로 이용하기가 어려웠다.
그런데 1024px이라는 건 뭘까? 블로그 글을 담고 있는 <article> 요소의 스타일에 width: 1024px이 설정되어 있다고 치자(당시엔 HTML에 <article> 요소가 없었지만 편의상 있었다고 하자). 너비가 1024px이라는 게 무슨 말일까? 사용자의 모니터 너비가 1024px이고 브라우저가 화면을 꽉 채우고 있을 걸로 가정하고, 그런 사용자가 방문했을 때 본문의 글줄 길이가 화면을 꽉 채우기를 바라며 쓴 수치이다.
하지만 화면이 1024px보다 작다면? 가로 스크롤이 생겨서 글을 읽기가 영 불편해진다. 그렇다면 사실 width: 1024px은 width: 100% 등으로 바뀌어야 한다. 그래야 화면이 좁아져도 가로 스크롤이 안생긴다.
하지만 화면 너비가 1024px이 아니라 이것보다 훨씬 넓다면? 글줄 길이가 너무 길어져서 글을 읽기가 어려워진다. 그렇다면 사실 width: 100%는 아마도 max-width: 960px처럼 바뀌어야 한다. 그래야 화면이 넓어져도 글줄 길이가 너무 커지는 걸 방지할 수 있다.
그런데 960px이라는 수치는 어디에서 나왔을까? 아마 기본 글자 크기가 16px이고 한 줄에 최대 60글자 이내로 나오게 하고 싶어서 쓴 수치일거다. 그렇다면 사실 max-width: 960px은 max-width: 60rem으로 바꿔야 한다. 그래야 사용자가 기본 글자 크기를 키우거나 줄여도 의도가 반영되기 때문이다.
그런데 “너비”가 중요한 이유는 무엇일까? 글을 왼쪽에서 오른쪽으로, 즉 가로로 쓴다고 가정하기 때문이다. 글을 세로로 쓰는 문화권이라면 “글줄 길이”는 “너비”가 아니라 “높이”랑 연결된다. 그렇다면 사실 max-width: 60rem은 아마도 max-inline-size: 60rem으로 바꿔야 한다.
width: 1024px은 “너비를 1024px로 한다”라면, max-inline-size: 60rem은 “글을 쓰는 방향을 고려하여, 글줄 길이가 최대 60글자가 넘지 않도록 한다”라는 뜻이다. 전자는 “캔버스에 형태를 배치하기”에 가깝고 후자는 “디자인 의도를 선언하기”에 가깝다.
피그마 등 일부 디자인 툴이 변수, 자동 레이아웃 등의 기능을 추가하고 있지만 아직 갈 길이 멀다.
도구는 사고에 영향을 준다
우리가 쓰는 도구는 우리의 사고에 지대한 영향을 준다. 일상에서 어떤 방식으로 일하고 일상에서 어떤 도구를 쓰는지 여부에 따라 일상에서 우리의 역량이 얼마나 꾸준히 발달하는지도 달라진다.
“의도를 선언하기”가 아닌 “캔버스에 형태를 배치하기” 패러다임의 도구를 쓰기 때문에 디자이너는 스스로의 의도를 의식적으로 생각하고 명시적으로 서술하는 훈련을 받기 어렵다. 간혹 학교에서 (교수에 따라) 작업물의 의도를 논리적으로 설명하는 능력을 강조하기도 하지만, 애초에 자연어로 서술하는 의도는 모호하고 빈틈이 많다. 게다가 학교에서 만들어내는 대부분의 결과물은 고정된 판형 위에 놓인 거의 (혹은 완전히) 정적인 그래픽 요소들이라는 점에서, 의도와 결과물 사이의 유기적 관계는 “작업”이 끝나는 시점에 사라져버린다.
디자이너-개발자 핸드오프
이상적인 디자이너-개발자 핸드오프는 어떠해야 하나?
가장 이상적으로는, 핸드오프가 없어야 한다. 디자이너의 작업이 끝나면 디자인의 구현 끝나야 하고, 개발자는 디자인에 로직을 이어 붙이는 일에만 집중해야 한다. 이게 가능하려면 디자인 결과물은 “결과물이 이렇게 생겼다”만 담고 있는 파일이어서는 안되고, “결과물은 매체의 특성이나 사용자의 선호에 따라 이러저러하게 변하는데 그 이유는 이러저러한 의도가 있기 때문이다”라는 내용이 논리적으로 모호하지 않게 빈틈없이 담긴 파일이어야 한다.
조금 덜 이상적으로는, 디자이너의 작업물에 디자인의 의도가 최대한 많이 담기고 개발자는 자신들이 쓰는 언어(웹 디자인이라면 CSS)로 이 의도를 충실히 옮기는 작업을 하면 디자인 구현이 끝나야 한다.
하지만 현실에서는, 디자이너의 작업물에 의도가 극히 일부만 명시적으로 담기고(예: 오토레이아웃), 대부분의 의도는 별도의 문서 혹은 디자인 작업물에 담긴 주석 등 자연어 서술로 전달된다. 자연어는 모호하기에 소통 과정에서 정보의 손실이 생기고 엄밀하지 않기 때문에 디자이너의 의도를 빠짐없이 묘사하기도 어렵다. 그 결과 디자이너와 개발자 모두 고생하고 디자인 구현의 품질은 떨어지며, 결과적으로 사용자도 피해를 입는다.