Back_to_Basics

{3줄 요약}

디자인은 가설에서 시작하며, "이렇게 하면 더 쉬울 것 같다"는 생각도 모두 가설입니다.
가설은 검증되기 전까지 추측이고, 실험이 그 추측을 증거로 바꿉니다.
작게 실험하고 빨리 배우는 편이 크게 만든 뒤 고치는 것보다 비용이 적습니다.

"이 버튼을 여기 두면 더 많이 누를 것 같아요. " "색을 바꾸면 더 잘 보일 것 같아요. " "이 단계를 없애면 이탈이 줄어들 것 같아요. "

이런 말들은 모두 가설이에요. 맞을 수도 있고 틀릴 수도 있어요. 확인하기 전까지는 모르는 거예요.

그래서 좋은 제품 팀은 디자인을 결정하기 전에 가설을 먼저 명확하게 써요.
그리고 그 가설을 가장 빠르게 확인할 수 있는 실험을 설계해요.

Jeff Gothelf는 《Lean UX》에서 이 사이클을 핵심으로 봐요.
가정 → 실험 → 측정 → 학습 → 다시 가정.
이 반복이 제품을 점점 사용자에게 맞게 만들어간다고요.

넷플릭스 썸네일 이야기가 유명해요.
같은 드라마도 어떤 썸네일을 보여주느냐에 따라 클릭률이 2~3배 차이가 났어요.
장르마다, 국가마다 반응이 달랐고요.

넷플릭스가 이걸 어떻게 알았을까요?
A/B 테스트(A/B Test, 같은 사용자 그룹을 둘로 나눠 서로 다른 버전을 보여주고 결과를 비교하는 방식)로요.

실제 배포 전에 일부 사용자에게만 새 버전을 보여줘요.
데이터가 충분히 모이면 어느 쪽이 더 좋은지 판단해요.
틀렸으면 원래대로 돌아가면 되고, 맞았으면 전체에 적용해요.

이 방식은 쿠팡, 배달의민족 같은 국내 커머스 앱들도 매일 쓰고 있어요.
홈 화면 배너 위치, 버튼 색상, 문구 하나까지 실험으로 결정해요.

실험 없이 만들면 두 가지 문제가 생겨요.

첫째, 나중에 고치는 비용이 커요. 개발까지 완료한 뒤에 "이거 사용자가 못 찾는다"는 걸 발견하면, 구조 자체를 다시 잡아야 할 수 있어요.
프로토타입 단계에서 발견했다면 30분이면 됐을 것을요.

둘째, 팀 내 논쟁이 해결되지 않아요. "난 이게 낫다고 생각해", "난 저게 낫다고 생각해" - 이 논쟁은 데이터가 있어야 끝나요.
실험 없이는 의견이 계속 충돌해요.

거창하게 시작할 필요 없어요. 아래 순서로 시작하면 돼요.

1단계 - 가설을 문장으로 써요 "우리는 [무엇을 바꾸면] [어떤 사용자가] [이런 행동을 더 할 것]이라고 생각해요. "

예: "장바구니 화면에서 배송비를 더 일찍 보여주면, 결제 중도 이탈이 줄어들 것이다. "

2단계 - 측정 기준을 먼저 정해요 실험 전에 "어떤 숫자가 바뀌면 성공인가"를 정해야 해요.
실험 후에 정하면 원하는 결과에 맞춰 해석하게 돼요.

3단계 - 최소한의 형태로 실험해요 전부 만들지 않아도 돼요.
핵심 가정 하나만 빠르게 확인할 수 있는 방법을 찾아요.

4단계 - 결과를 기록하고 다음 가설로 이어요 실패한 실험도 학습이에요.
"이 방향은 아니다"는 것도 중요한 정보예요.

가설 만드는 구조가 더 궁금하다면 디자인 가설 만들기를 먼저 보세요. 프로토타입으로 빠르게 실험하는 방법은 Prototype의 역할에서 다뤄요.