📚 지식 노트

UX, UI, 제품 디자인: 범위가 다르다

UI(user interface)는 화면 위에서 보고 만지는 것이다. 버튼, 글자, 색, 아이콘, 배치가 여기에 든다. UX(user experience)는 훨씬 넓다. 돈 노먼과 야콥 닐슨은 UX를 "최종 사용자가 회사와 그 서비스·제품을 만나는 모든 측면"이라고 정의했다(NN/g). 광고를 처음 보는 순간부터 가입, 사용, 결제, 배송, 고객 센터까지가 모두 경험이다.

그래서 UI가 좋아도 UX가 나쁠 수 있다. 같은 글은 영화 검색 화면이 아무리 잘 만들어져도 데이터베이스에 독립 영화가 없으면 그 영화를 찾는 사람의 경험은 나쁘다는 예를 든다. 사용성(usability)은 UI의 품질 속성으로, 배우기 쉬운지, 효율적인지, 쓰기 즐거운지를 말한다. 제품 디자인은 회사마다 뜻이 조금씩 다르지만, 대개 사용자 경험에 사업 목표와 기술 제약까지 함께 놓고 무엇을 만들지 정하는 일을 가리킨다.

사람의 지각과 인지가 화면에 어떻게 작용하는지(피츠의 법칙, 작업 기억, 휴리스틱 등)는 HCI와 UX 노트에 있다. 이 모음은 그 원리를 실제 화면과 제품으로 옮기는 과정과 기법을 다룬다.

사용자 중심 설계: 만들기 전에 쓰는 사람을 본다

사용자 중심 설계(user-centered design, 사람 중심 설계라고도 한다)는 "우리가 만들고 싶은 것"이 아니라 "쓰는 사람이 해내야 하는 일"에서 시작하는 태도다. 순서는 단순하다. 누가 어떤 상황에서 쓰는지 이해하고, 그 사람이 무엇을 해내야 하는지 요구를 정하고, 설계안을 만들고, 실제 사용자에게 평가받는다. 평가에서 요구를 못 맞추면 앞으로 되돌아간다.

여기서 중요한 것은 "사용자에게 무엇을 원하는지 묻고 그대로 만든다"가 아니라는 점이다. 사람들이 말하는 것과 실제로 하는 것은 다르다. 그래서 관찰하고, 만들어 보이고, 써 보게 하는 방법을 섞는다. 어떤 방법을 언제 쓰는지는 사용자 조사와 문제 정의에서 다룬다.

더블 다이아몬드: 문제를 넓혔다 좁히고, 답을 넓혔다 좁힌다

영국 디자인 카운슬(Design Council)이 2004년에 내놓은 더블 다이아몬드는 디자인 과정을 마름모 두 개로 그린다. 각 마름모는 넓게 펼치는 발산과 하나로 모으는 수렴이다. 앞 마름모는 문제를 다루고 뒤 마름모는 답을 다룬다. 네 단계의 이름은 발견(Discover), 정의(Define), 전개(Develop), 전달(Deliver)이다.

• 발견: 문제가 무엇이라고 짐작하지 말고, 그 문제를 겪는 사람들과 이야기하고 시간을 보내며 실제 문제를 이해한다.
• 정의: 발견에서 얻은 통찰로 과제를 새로 정의한다. 처음 받은 과제가 그대로 남는 일은 드물다.
• 전개: 정의한 문제에 여러 답을 만든다. 다른 분야에서 아이디어를 얻고, 다양한 사람과 함께 설계한다.
• 전달: 답을 작게 시험해 통하지 않는 것은 버리고 통하는 것을 다듬는다.

디자인 카운슬은 이 과정이 직선이 아니라고 분명히 적는다. 시험에서 나온 사실이 문제 정의를 다시 열기도 한다. 함께 내놓은 네 원칙은 사람을 먼저 두기, 눈에 보이게 그리고 모두가 이해하게 소통하기, 함께 만들기, 그리고 되풀이하기다. 가장 흔한 실수는 첫 마름모를 건너뛰는 것이다. 받은 과제("검색을 고쳐 주세요")를 곧바로 답의 마름모로 가져가면, 잘 만든 답이 엉뚱한 문제를 푼다.

디자인 씽킹: 여섯 단계와 되돌아가는 고리

디자인 씽킹은 같은 생각을 다른 이름으로 나눈 틀이다. NN/g의 정리에서는 공감(사용자가 하고, 말하고, 생각하고, 느끼는 것을 조사), 정의(조사를 통찰로 묶어 문제를 짚음), 발상(거르지 말고 많은 아이디어를 냄), 프로토타입(고른 아이디어를 손에 잡히는 형태로 만듦), 시험(실제 사용자에게 돌아가 확인), 실행(실제로 내놓음)의 여섯 단계다.

같은 글은 각 단계가 엄격한 순서가 아니라 되풀이되는 고리이고, 시험한 뒤 공감과 정의로 돌아가는 일이 흔하다고 적는다. 정해진 요리법이 아니라 비계(발판)에 가깝다는 것이다. 더블 다이아몬드와 디자인 씽킹은 경쟁하는 방법론이 아니다. 둘 다 "문제를 먼저 이해하고, 넓게 떠올리고, 만들어 시험하고, 되돌아간다"는 뼈대를 공유한다. 팀이 같은 단어로 이야기할 수 있으면 어느 쪽을 써도 된다.

린 UX와 가설: 결과물이 아니라 배움을 단위로

린 UX는 애자일 개발처럼 짧게 도는 팀에 맞춘 방식이다. 두꺼운 명세서를 먼저 완성하는 대신, 디자인을 가설로 적고 가장 작은 실험으로 확인한다. 가설에는 무엇을 바꾸는지, 누구에게, 어떤 변화가 생길지, 그리고 무엇을 보면 맞았다고 볼지가 들어간다. 마지막 부분이 빠지면 가설이 아니라 희망이다.

예를 들면 이렇다. 책 상세에 "지금 대출 가능" 표시를 넣으면 도서관에 가려던 이용자가 헛걸음을 덜 할 것이다. "가 보니 책이 없었다"는 문의가 줄면 맞았다고 본다.

지표가 움직이지 않으면 가설을 고치거나 버린다. 이것이 실패가 아니라 배움이라는 합의가 팀에 있어야 린 UX가 돈다. 실험 설계와 A/B 테스트의 함정(미리 정하지 않고 결과를 들여다보다 멈추기 등)은 HCI와 UX 노트의 A/B 테스트 절과 UX 라이팅·평가·실험에서 다룬다.

와이어프레임, 목업, 프로토타입: 충실도를 고르는 법

디자인 산출물은 실제 제품과 얼마나 닮았는지, 곧 충실도(fidelity)로 나뉜다. NN/g는 충실도를 세 축으로 본다. 상호작용(링크와 메뉴가 실제로 움직이나), 시각(배치·위계·화면 크기가 실제와 닮았나), 내용(진짜 글과 데이터가 들어갔나)이다.

• 와이어프레임: 회색 상자와 선으로 무엇이 어디에 놓이는지만 정한 뼈대 그림이다. 종이 스케치도 여기에 든다.
• 목업(mockup): 실제 글자·색·이미지를 넣은 정지 화면이다. 시각 디자인과 글을 검토한다.
• 프로토타입: 누르면 반응하는 시제품이다. 충실도가 낮은 종이 프로토타입부터, 실제 앱처럼 움직이는 것까지 폭이 넓다.

표는 NN/g의 비교를 줄인 것이다. 고르는 기준은 "지금 무엇을 알고 싶은가"다. 배치와 흐름을 정하는 초기에는 낮게, 글자 가독성이나 응답 시간처럼 세부가 중요한 질문에는 높게 간다. 화면 사이의 흐름이 중요한 앱은 와이어프레임을 화살표로 잇는 와이어플로로 그리면 한 장에서 흐름과 화면을 함께 본다.

핸드오프와 개발 협업: 그림이 아니라 규칙을 넘긴다

핸드오프는 디자인을 개발로 넘기는 일이다. 디자인 도구에 화면 몇 장을 올려 두는 것으로 끝나지 않는다. 개발자가 실제로 묻게 되는 것은 화면에 없는 경우들이다. 이름이 두 줄로 넘치면? 목록이 비면? 서버가 오류를 내면? 버튼을 두 번 누르면?

• 값 대신 토큰: "#4263EB, 16px"보다 "color.primary, space.4"로 넘긴다. 색을 바꿀 때 한 곳만 고치면 된다. 토큰과 컴포넌트는 디자인 시스템에서 다룬다.
• 상태를 모두: 기본·호버·포커스·누름·비활성·로딩·오류. 키보드 포커스 모양은 특히 자주 빠진다. 상태 설계는 인터랙션과 상태에 있다.
• 극단의 내용: 가장 긴 이름, 0건과 1만 건, 번역해서 길어진 문구를 넣어 본다.
• 일찍, 자주: 개발자를 마지막에 부르면 구현 비용이 큰 결정이 이미 굳어 있다. 발견과 전개 단계에서 기술 제약을 함께 본다.

누가 무엇을 하나: 역할

작은 팀에서는 한 사람이 모든 역할을 맡고, 큰 조직에서는 역할이 잘게 나뉜다. 이름은 회사마다 다르지만 흔히 보는 역할은 이렇다.

• UX 리서처: 인터뷰·관찰·사용성 테스트로 사용자를 이해하고, 그 결과를 팀이 쓸 수 있는 통찰로 바꾼다.
• UX·인터랙션 디자이너: 흐름, 정보 구조, 화면 사이의 상호작용을 설계한다.
• UI·비주얼 디자이너: 타이포그래피, 색, 아이콘, 레이아웃으로 화면의 모습을 정한다.
• 프로덕트 디자이너: 위 일들을 넓게 맡으면서 사업 목표와 지표까지 함께 책임지는 경우가 많다.
• UX 라이터: 제목, 버튼 문구, 안내와 오류 메시지처럼 화면의 말을 쓰고 어조를 맞춘다. NN/g는 이것을 픽셀 대신 말로 하는 디자인이라고 설명한다.

흔한 오해

• "UX는 화면을 예쁘게 만드는 일이다": 예쁜 화면은 UI의 일부다. UX는 배송 지연이나 해지 절차처럼 화면 밖의 경험까지 포함한다.
• "사용자에게 원하는 것을 물어보고 그대로 만들면 된다": 사람들은 미래 행동을 잘 예측하지 못하고, 말과 행동이 다르다. 묻기보다 관찰하고 시험한다.
• "프로세스를 순서대로 따르면 좋은 디자인이 나온다": 더블 다이아몬드도 디자인 씽킹도 되돌아가는 고리가 핵심이다. 단계를 지키는 것보다 배운 것으로 되돌아가는 것이 중요하다.
• "프로토타입은 완성도가 높을수록 좋다": 초기에는 오히려 해롭다. 다 된 것처럼 보이면 근본적인 비판이 나오지 않는다.
• "핸드오프는 마지막에 한 번 하는 일이다": 개발자가 일찍 들어와야 구현할 수 없는 디자인을 미리 피한다. 핸드오프는 협업의 끝이 아니라 중간 점검이다.
• "디자인 씽킹은 디자이너만 하는 것이다": 문제를 이해하고 시험하며 배우는 방식이라 기획·개발·운영 누구나 쓴다.

핵심 자료