3월 4일 UI/UX 특강은 전날보다 훨씬 더 실무 프로세스 쪽에 가까웠다. 3월 3일이 “좋은 UX가 무엇인가”를 이해하는 시간이었다면, 이번 강의는 “그걸 실제로 어떻게 만들어 가는가”에 더 가까웠다. 화면을 바로 그리는 게 아니라 문제를 발견하고, 정리하고, 아이디어를 발전시키고, 검증하는 흐름 전체를 다뤘다.
강의의 중심에는 더블 다이아몬드 프로세스가 있었다. Discover -> Define -> Develop -> Deliver 네 단계로 나뉘고, 앞에서는 문제를 넓게 탐색하고 뒤에서는 해결안을 넓게 생각한 뒤 다시 좁혀서 실행하는 구조다. 예전에는 디자인이 어느 순간 시안으로 툭 나오는 일처럼 보였는데, 이번 특강을 들으면서 디자인도 꽤 구조적인 문제 해결 과정이라는 점이 더 분명해졌다.
더블 다이아몬드로 보는 UI/UX 디자인 흐름
더블 다이아몬드는 해결할 문제를 찾는 구간과, 찾은 문제를 풀어 가는 구간으로 나뉜다. 문제를 처음부터 정답처럼 고정하지 않고 먼저 충분히 조사한 뒤 핵심 문제를 정리하고, 그다음 해결안을 여러 방향으로 살펴본 뒤 다시 검증하는 구조다. 이 모델이 좋았던 이유는, 성급하게 해결안부터 만들려는 습관을 경계하게 해주기 때문이다.
정의하기 단계에서는 HMW 문제 정의, 사용자 니즈 정리, 리서치 인사이트 정리, 페르소나 설정, 공감 지도, 사용자 여정지도, 서비스 블루프린트, KPI 설정까지 이어진다고 설명했다. 단순히 조사한 사실을 늘어놓는 게 아니라, 그 사실을 묶어서 “우리가 진짜 풀어야 할 문제”를 문장으로 만들 수 있어야 한다는 뜻으로 이해했다.
개발하기 단계에서는 정보구조 설계, 사이트맵, 기능 목록 정리, 유저 플로우, 태스크 플로우, 와이어프레임, 프로토타입, UI 탐색과 스타일 가이드 초안이 나온다. 전달하기 단계에 가면 최종 UI 디자인, 인터랙션 정의, 반응형 설계, 디자인 시스템, 테스트, 사용자 피드백 분석, 반복 개선이 이어진다. 결국 디자인은 시안 한 장으로 끝나는 일이 아니라 점점 구체화해 가는 과정이었다.
Step 1. 발견하기: 리서치가 디자인의 출발점
발견하기 단계에서는 리서치가 가장 중요한 시작점으로 소개됐다. 데스크 리서치는 이미 있는 자료와 데이터를 활용해 시장과 문제를 파악하는 방식이고, 필드 리서치는 실제 사용자 환경에서 직접 만나거나 관찰하는 방식이다. 여기에 사용자 리뷰 분석이나 설문조사처럼 그 사이에 걸쳐 있는 방법도 포함된다.
정량 리서치와 정성 리서치를 나눠 설명한 부분도 기억에 남았다. 정량은 규모와 패턴을 확인하고 가설을 검증할 때 강하고, 정성은 숫자로 잘 안 보이는 동기와 감정을 이해할 때 유용하다. 클릭 수, 전환율, 이탈률, A/B 테스트 같은 지표는 정량에 가깝고, 심층 인터뷰, 관찰 연구, 포커스 그룹, 사용성 테스트는 정성에 가깝다. 결국 둘 중 하나만으로는 부족하고 같이 봐야 한다는 뜻이었다.
경쟁사 분석과 포지셔닝 맵도 소개됐다. 경쟁 서비스를 보는 건 단순히 따라 하기 위해서가 아니라, 시장 안에서 우리 서비스가 어디쯤 설 수 있는지를 보기 위한 과정이었다. SWOT 분석도 같은 맥락으로 나왔다. 강점, 약점, 기회, 위협을 나눠 보면 내부 요소와 외부 환경을 같이 볼 수 있다는 설명이었다.
결국 이 단계에서 중요한 건 “문제를 찾는 것”이지 “바로 해결안을 내는 것”이 아니라는 점이었다. 개발을 하다 보면 뭔가 만들 수 있다는 이유로 해결안부터 떠올리기 쉬운데, 이번 특강은 그 전에 사용자와 맥락을 충분히 이해해야 한다는 점을 계속 강조했다.
사용자 리서치는 공감에서 시작한다
사용자 리서치 파트에서 나온 “공감이 디자인의 핵심이다”라는 문장이 강하게 남았다. 다른 사람이 보고 느끼고 경험하는 걸 이해하지 못하면 디자인은 의미가 없다는 말이었는데, UX를 가장 짧고 분명하게 설명하는 문장처럼 보였다.
설문조사는 다수의 사용자에게 구조화된 질문을 통해 데이터를 모으는 방법으로 정리됐다. 폐쇄형, 개방형, 리커트 척도 같은 질문 형식이 있고, 질문과 답변의 중립성을 지키기, 한 문항에 한 가지만 묻기, 모호한 보기 피하기 같은 주의사항도 함께 나왔다. 설문은 쉬워 보여도 질문을 잘못 쓰면 결과가 쉽게 흔들릴 수 있다는 점이 중요했다.
사용자 인터뷰는 1:1 혹은 그룹 대화를 통해 행동의 이유와 감정을 깊게 보는 정성적 리서치 방법으로 소개됐다. 구조화, 반구조화, 비구조화 인터뷰로 나뉘고, 라포 형성, 비언어적 표현 관찰, 해결책을 먼저 제시하지 않기 같은 원칙이 나왔다. 사용자가 “무엇을 했다”보다 “왜 그렇게 했는가”를 듣는 과정이라는 점에서 중요해 보였다.
사용자 관찰은 실제 환경에서 제품이나 서비스를 사용하는 모습을 직접 보는 방식이다. 인터뷰와 달리 말로 설명되지 않는 행동 패턴을 볼 수 있다는 장점이 있다. 특강에서는 사용자의 행동에 간섭하지 말 것, 해석과 사실을 구분해서 기록할 것, 가능한 자연스러운 상태를 유지할 것 같은 원칙도 같이 정리했다.
Step 2. 정의하기: 데이터에서 인사이트를 뽑아 문제를 선명하게 만든다
리서치가 끝나면 바로 시안을 그리는 게 아니라, 먼저 데이터를 정리하고 패턴을 찾고 인사이트를 도출한 뒤 문제를 정의해야 한다고 했다. 이때 파인딩과 인사이트를 구분해서 설명한 부분이 좋았다. 파인딩은 리서치 과정에서 발견한 사실 자체이고, 인사이트는 그 사실들을 묶어서 뽑아낸 해석에 가까웠다.
어피니티 다이어그램은 많은 아이디어나 데이터를 비슷한 것끼리 묶어서 핵심 패턴을 찾는 방법으로 소개됐다. 포스트잇을 붙이고 묶고 이름을 붙이는 방식인데, 결국 “흩어진 데이터를 의미 있게 정리하는 과정”이라고 이해했다. 인터뷰를 많이 해도 정리가 안 되면 인사이트로 이어지지 않는다는 점을 잘 보여줬다.
공감맵은 사용자가 말하는 것, 생각하는 것, 행동하는 것, 느끼는 것을 나눠서 보는 도구였다. 같은 사용자라도 겉으로 말하는 내용과 실제 감정은 다를 수 있기 때문에, 단순한 요구사항 목록보다 훨씬 입체적으로 이해하게 해주는 도구라고 느꼈다.
페르소나는 목표 사용자 집단 안의 대표 유형을 가상의 인물로 구체화한 것이고, 사용자 여정지도는 서비스 이용 전체 과정을 시간 순서대로 시각화한 것이다. 이 둘은 사용자에 대한 해석을 팀 안에서 공유할 수 있게 만들어 주기 때문에, 기획자와 디자이너, 개발자가 같은 사용자를 떠올리며 일하게 해주는 도구처럼 보였다.
Step 3. 개발하기: 구조와 흐름을 구체적인 화면으로 바꾸기
개발하기 단계는 말 그대로 코드를 짜는 개발이 아니라, 디자인 솔루션을 구체화하는 단계였다. 아이데이션으로 가능한 해결안을 넓게 생각하고, 정보구조도와 플로우차트로 서비스 구조와 경로를 정리하고, 와이어프레임으로 화면 배치를 잡고, 프로토타입으로 실제처럼 움직이게 만드는 흐름이 이어졌다.
정보구조도는 전체 콘텐츠와 기능을 계층 구조로 정리한 자료다. 사이트맵이나 메뉴 체계가 여기에 해당한다. 이 구조가 엉켜 있으면 사용자도 길을 잃기 쉽기 때문에, UI를 다듬기 전에 구조부터 잡는 이유가 납득됐다.
플로우차트는 특정 목적을 달성하기 위해 사용자가 거치는 화면 이동 경로와 의사결정 과정을 정리한 것이다. 회원가입, 상품 구매, 예약 완료 같은 과정을 설계할 때 특히 유용해 보였다. 예외 처리와 분기 흐름을 미리 볼 수 있다는 점에서 개발자 입장에서도 도움이 많이 될 것 같았다.
와이어프레임은 색, 이미지, 폰트보다 레이아웃과 버튼 위치 같은 핵심 요소에 집중한 화면 설계도다. 시각적인 디테일에 끌려가지 않고 구조부터 볼 수 있다는 점이 좋았다. 프로토타입은 여기에 클릭, 스크롤, 전환 효과 같은 인터랙션을 넣어 실제 서비스처럼 움직이게 만든 형태였다. 그냥 그럴듯한 그림이 아니라, 실제 사용 흐름을 점검하는 도구라는 점이 중요했다.
Step 4. 전달하기: 시스템화하고 검증하고 개선한다
전달하기 단계에서 가장 인상적이었던 것은 디자인 시스템이었다. 강의에서는 디자인 시스템을 서비스에 쓰이는 UI 요소의 규칙과 컴포넌트를 정리해 재사용 가능하게 만든 기준이라고 설명했다. 버튼, 컬러, 타이포, 간격 규칙이 정리되어 있으면 화면마다 다시 만들지 않아도 되고, 팀 전체의 일관성도 유지된다.
사용성 테스트 사례는 정말 직관적이었다. 장바구니 화면에서 7명 중 1명만 Edit 버튼을 발견했고, 대부분은 리스트를 누르거나 밀어보면 수정할 수 있을 거라고 생각했다는 예시가 나왔다. 디자이너가 “당연히 보이겠지”라고 생각한 요소가 실제 사용자에게는 전혀 다르게 읽힐 수 있다는 뜻이다. 테스트 없이 확신하는 건 위험하다는 걸 다시 느꼈다.
A/B 테스트는 두 가지 이상 시안을 사용자에게 무작위로 보여 주고 어떤 디자인이 클릭이나 구매 같은 목표를 더 잘 달성하는지 비교하는 방법으로 정리됐다. 취향으로 끝내지 않고 실제 데이터로 판단하는 방식이라는 점에서, 디자인도 결국 검증 가능한 가설 실험이라는 생각이 들었다.
들으면서 남긴 내 생각
이번 3월 4일 특강은 “디자인은 감각만으로 하는 일이 아니라 과정이구나”라는 생각이 가장 크게 남았다. 좋은 결과물은 갑자기 떠오른 아이디어 하나에서 나오는 게 아니라, 리서치로 문제를 보고, 인사이트를 정리하고, 사용자 모델을 만들고, 구조를 설계하고, 검증하면서 다듬는 반복에서 나온다는 흐름이 잘 보였다.
특히 개발을 공부하는 입장에서 많이 와닿았던 건, 디자인 산출물 대부분이 사실 개발 전에 정말 유용한 정리 도구라는 점이다. IA는 구조를 보여주고, 플로우차트는 분기와 예외를 보여주고, 와이어프레임은 필요한 화면을 보여주고, 프로토타입은 기대 동작을 보여준다. 이런 단계가 잘 잡혀 있으면 개발도 훨씬 덜 흔들릴 수밖에 없겠다는 생각이 들었다.
또 하나는 사용자 리서치와 테스트의 중요성이었다. 우리는 종종 “사용자가 이렇게 하겠지”라고 쉽게 가정하지만, 실제 행동은 생각보다 꽤 다를 수 있다. 그래서 이번 강의에서 가장 크게 남은 메시지는, 좋은 UI/UX는 추측이 아니라 관찰과 검증 위에서 만들어진다는 점이었다.
3월 3일 특강이 UI/UX를 보는 눈을 넓혀 준 시간이었다면, 3월 4일 특강은 그걸 실제 프로젝트에서 어떻게 풀어 가야 하는지 알려준 시간에 가까웠다. 앞으로 프로젝트를 할 때도 막연히 화면부터 만들기보다, 문제 정의와 사용자 흐름, 검증 단계를 더 의식하게 될 것 같다.
Community
Comments
Comments appear immediately. Use report if something needs review.
No comments yet.