디자인

소프트웨어를 시디에 담아 팔던 시절, 디자인은 마지막 공정이었습니다. 기능이 다 만들어진 화면을 넘겨받아 버튼 색을 고르고 아이콘을 그려 넣는 일이었고, 요청은 대체로 "이거 좀 예쁘게 해 주세요" 한 문장이었습니다. 값을 미리 받고 끝나는 거래였으니 산 사람이 그 프로그램을 능숙하게 쓰든 두어 번 열어 보고 덮어 두든 파는 쪽의 수입은 같았습니다.

제품이 웹과 모바일로 옮겨 가고 먼저 무료로 써 보게 한 뒤 매달 요금을 받는 방식이 퍼지면서 이 계산이 뒤집혔습니다. 가입은 클릭 한 번이고 다른 제품으로 갈아타는 비용도 거의 없으니, 첫 5분 동안 무엇을 해야 할지 알아내지 못한 사람은 그냥 창을 닫습니다. 닫힌 창은 항의도 환불 요구도 남기지 않아서, 무엇이 잘못됐는지조차 알려 주지 않습니다.

그 무렵 회의실에서 자주 나온 말이 있습니다. "기능은 우리가 더 많은데 왜 저쪽을 쓰죠?" 기능 목록을 나란히 놓고 비교하면 이기는데, 가입한 100명 중 다음 날 다시 들어오는 사람은 여덟 명이었습니다. 이유를 물으면 아무도 답하지 못했습니다. 개발은 명세대로 만들었고, 기획은 요구사항을 빠짐없이 적었고, 디자인은 받은 대로 그렸습니다. 각자 자기 몫을 다 했는데 결과가 나오지 않는 상태였고, 빠져 있던 것은 처음 들어온 사람이 이 화면에서 무엇을 하려 하는지를 누군가 미리 정해 두는 일이었습니다.

디자인이 그 질문을 맡으면서 자리가 뒤에서 앞으로 옮겨 왔습니다. 다 만든 것을 다듬는 공정이 아니라 무엇을 만들지 정하는 자리 옆으로 온 겁니다. 그러자 한 사람이 감당할 수 있는 크기를 넘어섰습니다. 사용자를 만나 묻는 일, 내용을 나누고 이름 붙이는 일, 버튼 하나의 반응을 정하는 일, 문구를 쓰는 일, 화면들이 따로 놀지 않게 규칙을 세우는 일이 한꺼번에 이 분야로 들어왔습니다. 디자인 축에 갈래가 유난히 많은 이유가 여기 있습니다.

디자인 축 아래 용어는 열네 갈래입니다. 세 가지 질문으로 묶으면 지도가 한눈에 들어옵니다. 누가 하는가(역할), 무엇을 설계하는가(기본 개념·구조·인터랙션·비주얼·콘텐츠·접근성), 어떻게 일하는가(프로세스·리서치·평가·디자인 시스템·산출물·도구·표준·윤리)입니다.

역할은 사람을 가르는 갈래이고 아홉 자리가 있습니다. 나뉘는 기준은 화면을 그리는 솜씨가 아니라 어디까지를 자기 결정으로 삼느냐입니다.

1. UX 디자이너 — 사용자가 목적을 이루기까지의 과정 전체를 설계합니다. 화면 한 장이 아니라 가입에서 첫 성과까지의 흐름을 다룹니다.
2. UI 디자이너 — 그 흐름을 실제 화면으로 옮깁니다. 무엇을 맨 위에 두고 무엇을 접어 둘지, 글자 크기와 여백을 얼마로 할지를 정합니다.
3. 프로덕트 디자이너 — 문제 정의부터 화면까지 한 사람이 맡습니다. 구성원 100명 아래 회사에서 가장 흔한 직함이고, 위의 두 자리가 아직 갈라지지 않은 상태로 보면 됩니다.
4. 인터랙션 디자이너 — 누르고 끌고 놓는 동작에 제품이 어떻게 반응할지를 설계합니다.
5. UX 리서처 — 사용자를 만나 묻고 관찰하는 일을 설계하고 직접 수행합니다.
6. UX 라이터 — 제품 안에 들어가는 문구를 씁니다.
7. 브랜드 디자이너 — 로고와 색과 서체처럼 회사가 밖에서 보이는 모습을 만듭니다.
8. 디자인 엔지니어 — 시안과 코드 사이를 오가며 구현까지 직접 합니다.
9. 디자인 리드 — 팀의 방향과 품질 기준을 정하고 그 결과를 책임집니다.

작은 회사에서는 3번 한 자리가 나머지를 거의 다 겸합니다. 사람이 늘면 조사(5번)와 문구(6번)가 먼저 떨어져 나오는데, 셋 다 잘하는 사람이 드물어서가 아니라 하루를 쓰는 방식이 서로 다르기 때문입니다. 오전에 사용자 인터뷰 세 건을 하고 오후에 화면을 그리라고 하면 대개 마감이 급한 화면 쪽만 남습니다.

무엇을 설계하는가 쪽은 여섯 갈래입니다. 가장 위에 사용자 경험이 있습니다. 제품을 쓰는 동안 사람이 겪는 것 전부를 가리키는 말이라 화면만이 아니라 가입 안내 메일, 오류 문구, 느린 로딩, 고객센터 응대까지 포함합니다. 나머지 다섯은 그 경험을 이루는 재료를 하나씩 맡습니다.

정보 구조는 내용을 어떻게 나누고 무엇이라 이름 붙이고 어디에 둘지를 정한 뼈대입니다. 건물로 치면 층을 몇 개 둘지와 각 층에 무슨 이름을 붙일지를 정하는 단계라, 여기가 어긋나면 방 안을 아무리 잘 꾸며도 사람들은 원하는 방을 찾지 못합니다. 협업 문서 제품이라면 문서를 폴더로 묶을지 태그로 묶을지, 공유 권한을 문서마다 둘지 폴더마다 둘지가 이 갈래의 질문입니다.

인터랙션 디자인은 조작과 반응을 다룹니다. 저장 버튼을 눌렀는데 아무 표시도 없으면 사람은 3초 안에 한 번 더 누르고, 그래서 같은 문서가 두 번 저장됩니다. 눌린 순간 버튼이 회색으로 바뀌고 저장 중이라는 글자가 뜨면 두 번 누르지 않습니다.

비주얼 디자인은 보이는 요소로 위계를 만듭니다. 한 화면에 같은 크기 같은 색의 버튼이 넷 놓여 있으면 사람은 넷을 다 읽어야 하지만, 하나만 진한 색이면 나머지는 훑고 지나갑니다. 색과 서체를 고르는 일이 취향처럼 보여도 목적은 무엇을 먼저 읽게 할지를 정하는 데 있습니다.

UX 라이팅은 제품 안의 문구를 설계합니다. "오류가 발생했습니다" 와 "파일이 20MB를 넘어 올릴 수 없습니다" 는 같은 상황을 알리지만, 앞엣것을 본 사람은 고객센터에 문의하고 뒤엣것을 본 사람은 파일을 줄여 다시 올립니다.

접근성은 눈이 잘 보이지 않거나 마우스를 쓸 수 없는 상황에서도 제품이 작동하게 만드는 일입니다. 소수를 위한 배려로 읽히기 쉽지만, 실제로는 한 손에 짐을 들고 지하철에서 화면을 보는 사람과 햇빛 아래에서 흐린 회색 글자를 읽어야 하는 사람이 함께 걸리는 문제입니다.

어떻게 일하는가 쪽은 일곱 갈래입니다. 디자인 프로세스는 문제에서 해법까지 가는 순서를 정합니다. 조사하고, 문제를 좁히고, 여러 안을 만들고, 사용자에게 시험해 보고, 고쳐서 내보내는 흐름입니다. UX 리서치 기법은 그 첫 칸과 네 번째 칸에서 꺼내 쓰는 도구 모음입니다. 사용자 인터뷰, 설문, 만든 화면을 실제로 써 보게 하고 막히는 지점을 지켜보는 사용성 테스트 같은 것들이 여기 들어갑니다.

디자인 시스템은 화면마다 다시 정하지 않도록 색과 글자 크기와 간격과 부품을 한 벌로 묶어 둔 기준이고, 그 안에 담기는 재사용 부품 하나하나를 UI 컴포넌트라 부릅니다. 버튼 색이 화면마다 조금씩 다른 상태를 그냥 두면 3년 뒤에는 회색 계열 열일곱 가지를 쓰는 제품이 되고, 새로 들어온 사람은 어느 것이 맞는지 물어볼 데가 없습니다.

나머지 네 갈래는 작업의 바깥 조건을 다룹니다. 디자인 산출물은 시안과 프로토타입과 명세처럼 손에서 나가는 결과물을 가리키고, 디자인 도구는 그 결과물을 만드는 소프트웨어를 가리킵니다. 플랫폼 가이드라인은 애플과 구글이 각자 정해 둔 규범이라, 같은 기능도 아이폰과 안드로이드에서 다른 모양으로 만들어야 할 때가 있습니다. 다크 패턴은 해지 버튼을 일부러 찾기 어려운 자리에 두는 식으로 사용자를 불리한 선택으로 미는 설계를 가리키고, 열네 갈래 중 유일하게 하지 말아야 할 것의 이름입니다.

열네 갈래는 한 줄로 이어집니다. 리서치가 무엇이 문제인지 알려 주면 정보 구조가 뼈대를 세우고, 인터랙션과 비주얼과 문구가 그 뼈대에 살을 붙이고, 디자인 시스템이 그 결과를 다음 화면에서도 쓸 수 있게 묶고, 접근성이 그 전부를 더 많은 상황에서 작동하게 만듭니다. 역할은 이 줄의 어느 구간을 맡느냐로 갈립니다.

"이건 UI 문제가 아니라 정보 구조 문제예요. 메뉴 이름만 바꿔서는 여전히 못 찾습니다."

화면을 다시 그리기 전에 항목을 나누고 이름 붙인 뼈대부터 손봐야 한다는 말입니다.

"시안 보기 전에 리서치에서 뭐가 나왔는지부터 같이 볼까요?"

어느 안이 나은지를 취향으로 다투기 전에 무엇을 근거로 그렸는지를 먼저 맞추자는 제안입니다.

"시스템에 없는 버튼이라 이번 화면에서 새로 그렸는데, 컴포넌트로 올릴까요?"

이번 한 번만 쓰고 말지, 공용 부품으로 등록해 다른 화면도 같은 것을 쓰게 할지 정하자는 물음입니다.

페이지덱에서 공유 설정 화면을 다시 만들기로 했을 때 민서가 가장 먼저 한 일은 화면을 여는 것이 아니라 고객 문의 기록을 읽는 것이었습니다. 문서를 외부 사람에게 보냈는데 열리지 않는다는 문의가 한 달에 40건 넘게 들어오고 있었고, 읽어 보니 원인은 버튼 위치가 아니라 권한이 문서와 폴더 두 군데에 흩어져 있다는 데 있었습니다. 민서는 지현과 함께 권한을 어디에 둘지부터 다시 정하고, 그다음에 화면을 그렸습니다.

시안이 나온 뒤 회의에서는 세 종류의 이야기가 오갔습니다. 태오는 폴더 권한을 바꾸면 기존 문서 전부를 다시 계산해야 한다며 구현 비용을 짚었고, 지현은 무료 플랜에서도 이 화면을 쓸 수 있어야 한다고 범위를 짚었고, 민서는 회색 글자의 대비가 낮아 밝은 곳에서 읽히지 않는다는 점을 짚었습니다. 세 이야기가 각각 엔지니어링과 제품과 디자인의 관심사인데, 셋 중 하나만 빠져도 화면은 다시 만들어집니다.

디자인을 예쁘게 만드는 일로 이해하는 경우가 가장 많습니다. 눈에 보이는 결과물이 화면이고, 회사 밖에서 마주치는 디자인이 대개 포스터나 로고라서 그렇게 읽히기 쉽습니다. 하지만 실제 작업 시간의 대부분은 무엇을 보여 주고 무엇을 감출지, 어떤 순서로 묻고 어떤 말로 안내할지를 정하는 데 들어가고, 화면은 그 판단이 밖으로 나온 모습입니다. 이 오해를 그대로 두면 디자인이 개발이 끝난 뒤 마지막 2주에 들어오게 되고, 그 시점에는 구조를 바꿀 수 없으니 정말로 색과 여백만 손보게 됩니다. 예쁘게 해 달라는 요청이 스스로를 사실로 만드는 셈입니다.

디자인은 취향의 영역이라 옳고 그름이 없다고 보는 것도 흔합니다. 시안을 놓고 "저는 왼쪽이 더 좋은데요" 같은 말이 오가니 그렇게 보이고, 일부는 실제로 취향입니다. 그러나 판정할 수 있는 부분이 생각보다 넓습니다. 목표 지점까지 걸린 시간, 끝까지 마친 사람의 비율, 글자와 배경의 밝기 차이, 손가락이 닿는 영역의 크기, 같은 대상을 화면마다 같은 단어로 부르는지는 재거나 확인할 수 있습니다. 판정 가능한 부분까지 취향으로 넘기면 결정은 그 자리에서 가장 직급이 높은 사람의 감각을 따라가고, 근거가 기록되지 않으니 반년 뒤에 같은 논쟁을 처음부터 다시 하게 됩니다.