{3줄 요약}

디자인 가설은 왜 이 결정이 효과가 날지 검증 가능하게 적는 문장이에요.
가설이 없으면 감으로 움직여 실험 결과를 해석하기가 훨씬 더 어려워져요.
가설을 세우면 추측이 아닌 학습 계획으로 디자인 결정을 다룰 수 있어요.

디자인 결정 뒤에는 가정이 있어요

어떤 인터페이스를 만들든 그 안에는 가정이 있어요.

"사용자가 이 버튼을 볼 것이다" "이 흐름이 자연스럽게 느껴질 것이다" "이 기능이 사용자에게 필요할 것이다"

이 가정들을 확인하지 않으면 어느 날 지표가 안 움직이는 이유를 알 수 없어요.
반대로 가정을 명확하게 적어두면 무엇을 검증해야 하는지가 보여요.

그게 가설이에요.

좋은 가설의 구조

Jeff Gothelf는 《Lean UX》에서 이 형식을 제안해요.

"우리는 [이것]을 만들면 [이 사용자]가 [이 결과]를 달성할 수 있을 것이라고 믿어요. 우리는 [이 지표]가 변화하는 것을 보고 이를 확인할 거예요. "

예시로 써볼게요.

나쁜 가설:

"검색 기능을 개선하면 사용자 경험이 좋아질 것이에요."

좋은 가설:

"검색 결과 화면에 카테고리 필터를 추가하면, 처음 방문하는 사용자가 원하는 상품을 더 빠르게 찾을 것이에요.
검색 후 3분 이내 장바구니 추가율이 15% 이상 높아지면 이를 확인할 수 있어요.
"

차이가 보이나요?
좋은 가설은 대상, 행동, 결과, 측정 방법이 모두 있어요.
이게 있어야 나중에 "맞았나, 틀렸나"를 판단할 수 있어요.

가설이 필요한 순간

모든 설계 결정에 가설이 필요하지는 않아요.
명백한 것, 이미 검증된 패턴은 가설 없이 해도 돼요.

가설이 특히 필요한 순간은 이럴 때예요.

  • 새로운 기능을 추가할 때
  • 기존 흐름을 바꿀 때
  • 두 가지 방향 중 하나를 선택해야 할 때
  • 비용이 크게 드는 결정일 때

이런 상황에서 "그냥 해보자"는 비용이 가장 크게 드는 선택이에요.
가설을 먼저 만들고 작은 실험으로 확인하는 게 더 빠르고 저렴해요.

토스의 실험 방식

토스 팀은 가설 기반 실험을 일상적으로 운영해요.

예를 들어 메인 화면에 특정 기능 버튼을 추가할지 말지 결정해야 한다고 해요.
"추가하면 좋을 것 같다"는 직관 대신, 이런 가설을 세워요.

"송금 직후 화면에서 '영수증 공유' 버튼을 노출하면, 사용자가 자연스럽게 앱을 지인에게 소개하는 행동이 늘어날 것이다. 공유 버튼 클릭률 2% 이상을 목표로 한다. "

이렇게 가설을 세우면 A/B 테스트로 검증이 가능해요.
가설이 맞으면 전체에 적용하고, 틀리면 다른 가설을 만들어요.

가설을 만들지 못하면 어떻게 돼요

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

첫째, 결과를 어떻게 판단해야 할지 모르게 돼요.
출시 후 지표가 움직이지 않을 때 "왜 안 됐지?"에 대한 답이 없어요.

둘째, 팀 내 의견 충돌이 해결되지 않아요.
"이렇게 하면 좋지 않을까요?"와 "저는 이게 더 나을 것 같은데요"는 둘 다 가정이에요.
어떤 게 맞는지 판단할 기준이 없어요.

가설은 이 두 가지를 모두 해결해요.

가설 쓰는 연습

지금 작업 중인 것에 아래 형식을 적용해보세요.

우리는 [무엇을 만들거나 바꾸면],
[어떤 사용자가] [어떤 행동을 하거나 어떤 결과를 얻을 것]이라고 믿어요.
[어떤 지표]가 [어떻게 변하면] 이를 확인할 수 있어요.

처음에는 어색해요.
하지만 이 형식에 맞춰 쓰는 연습을 하면, 설계 결정 앞에서 "왜 이렇게 해야 하는가"를 더 명확하게 말할 수 있게 돼요.

가설 검증을 위한 실험 설계는 디자인 실험과 검증에서 다뤄요. 데이터를 어떻게 활용하는지는 디자인과 데이터의 관계에서 이어서 볼 수 있어요.

관련 아티클

참고 문헌