지난 편에서 맥락 조사가 무엇인지를 알아봤어요. 이번 편에서는 맥락 조사를 디자인에 실질적으로 적용하는 맥락 기반 디자인(Contextual Design)에 대해 알아볼 거예요.
1. 맥락 조사에서 맥락 기반 디자인으로
맥락 조사(Contextual Inquiry)는 날것의, 지저분한 데이터를 만들어내요. 그 데이터 자체만으로는 별로 유용하지 않죠.
데이터가 가치를 갖게 되는 순간은, 팀이 함께 논의할 수 있는 공유된 산출물(Shared Artifact)로 전환될 때예요. 여기서 맥락 기반 디자인이 등장해요.
맥락 기반 디자인이 없으면, 사용자에 대한 이해는 누군가의 노트 속에, 리서처의 머릿 속에, 흩어진 일화와 문서들 속에 조용히 묻혀져가요.
1) 맥락 기반 디자인의 역할
맥락 기반 디자인은 리서치 방법론이 아니에요. 맥락 조사에서 배운 것을 구조화하고 외부화하는 방법이에요.
맥락 기반 디자인은 다음과 같은 역할을 해요.
- 관찰을 눈에 보이는 모델로 전환
- 개인의 인사이트를 공유된 이해로 전환
- 지저분한 현실을 팀이 함께 다룰 수 있는 형태로 전환
산출물은 “디자인 파일”이 아니에요. 명확함(Clarity)이에요.
맥락 기반 디자인은 워크플로우 모델, 어피니티 다이어그램(Affinity Diagram), 스토리보드(Storyboard) 같은 산출물을 통해 맥락을 시각적으로 만들어줘요.
맥락 기반 디자인이 효과적으로 수행되면 팀이 다음과 같은 것들을 뚜렷하게 볼 수 있게 돼요.
- 일이 실제로 어떻게 흘러가는가
- 어디서 문제가 발생하는가
- 어떤 제약이 여러 사용자에 걸쳐 반복되고 있는가
이 지점에서 지저분했던 맥락이 정돈되어 논의 가능한 것이 되는 거예요.
2) 맥락이 외부화되면 대화가 바뀐다
맥락이 외부화되면, 대화의 성격이 바뀌어요.
팀이 더 이상 개인적 선호에 기반한 주장을 하지 않게 되거든요. 사용자가 처한 현실에 대한 해석을 함께 논의하기 시작해요.
이전에는 아래와 같이 말했다면요.
- “이게 더 단순한 것 같아요”
- “사용자가 그렇게 할 것 같지 않아요”
이제는 이렇게 바뀌죠.
- “이 단계에서 반복적인 이탈이 발생해요”
- “이 우회 방법이 여러 세션에서 나타나요”
논쟁이 더 이상 팀원 개인의 취향에 관한 것이 아니게 돼요. 사용자에게 갖는 의미에 관한 것이 되죠.
3) 맥락 기반 디자인은 팀의 의사결정 도구다
이렇게 보면, 맥락 기반 디자인은 UX만의 것이 아니에요.
이 방법론은 여러 역할 사이에 위치해요.
- 리서치
- 프로덕트
- 디자인
- 개발
팀이 같은 근거에서 추론할 수 있게 해주죠.
결과적으로 나올 해결책에 동의하지 않더라도요.
3. 실무 적용: 맥락 기반 디자인 워크플로우
맥락 조사에서 배운 것을 구체적으로 정리하는 방법이에요.
1) 워크플로우 모델링
일의 실제 흐름을 시각화해요.
- 단계별 행동을 표시
- 각 단계에서의 의사결정 지점을 표시
- 문제가 발생하는 지점을 표시
2) 어피니티 다이어그래밍(Affinity Diagraming)
관찰들을 공통 주제로 묶어요.
- 개별 관찰을 포스트잇에 표시
- 유사성에 따라 그룹핑
- 각 그룹에 테마 이름 붙임
3) 스토리보드
사용자 여정을 이야기로 재구성해요.
- 핵심 순간들을 시각적으로 표현
- 각 단계에서의 감정과 생각을 포함시킴
- 맥락 정보를 함께 제시
4. 맥락에서 의사결정으로
맥락은 의사결정에 영향을 미칠 때 비로소 가치가 있어요.
사용자가 일하는 모습을 지켜보는 것이 목표가 아니에요. 더 나은 프로덕트를 만드는 것이 목표예요.
이 둘을 연결하는 다리가 체계적인 해석 과정이에요.
| 전환 단계 | 무엇이 일어나는가 | 핵심 질문 |
|---|---|---|
| 관찰 → 인사이트 | – 의미를 부여하지 않고 구체적 행동을 포착 – 초기 가설이 형성되기 시작 |
이 행동이 왜 존재하는가? |
| 인사이트 → 패턴 | – 여러 조사에 걸쳐 반복되는 인사이트가 구조적 유사성을 드러냄 | 이것이 반복적인가, 상황적인가? |
| 패턴 → 문제 정의 | – 패턴을 해결책의 형태가 아닌 사용자의 맥락적 문제로 정의 | 무엇이 문제가 되고 있고, 어떤 맥락에서인가? |
| 문제 정의 → 해결책 정의 | – 가능한 솔루션을 관찰된 현실과 제약에 비추어 평가 | 이것이 관찰된 문제를 해결하는가? |
1) 관찰에서 인사이트로
모든 것은 관찰에서 시작돼요.
관찰은 가리킬 수 있는 무언가예요.
- “사용자가 하나의 과업 중에 도구를 세 번 전환한다”
- “제출 버튼을 누르기 전에 멈칫한다”
- “시스템 밖에서 메모를 작성한다”
아직 의미는 없어요. 그냥 현실이에요.
인사이트는 이 행동이 왜 존재하는지 물을 때 생겨나요.
- 왜 도구를 전환할까?
- 왜 망설일까?
- 왜 외부 메모를 쓸까?
여기서 가설이 형성되지만, 아직은 리스크를 가진 정보예요.
2) 인사이트에서 패턴으로
하나의 인사이트는 흥미로운 것에 불과해요. 반복되는 인사이트가 패턴을 형성하죠.
패턴은 이런 질문에 답해줘요.
- 이것이 흔한가, 드문가?
- 상황적인가, 구조적인가?
- 다른 사용자들에게도 나타나는가?
맥락적 탐구가 보통 여러 세션을 거치는 이유가 여기에 있어요. 패턴은 일화를 근거로 전환시켜줘요.
3) 패턴에서 문제 정의로
패턴을 발견했다고 해서 바로 기능과 같은 해결책을 만드려고 해선 안 돼요. 먼저 문제로 정의되어야 해요.
좋은 문제 정의는 이런 특성이 있어요.
- 문제점을 구체적으로 서술한다
- 맥락을 명시한다
- 해결책을 제안하지 않는다
예를 들면 이래요.
“사용자가 워크플로우를 떠나지 않으면 데이터를 검증할 수 없기 때문에, 제출 전에 자신감을 잃는다.”
이건 기능을 제안하지 않으면서도 실행 가능한 문제 정의예요.
4) 문제 정의에서 해결책 정의로
문제가 명확해진 후에 어떤 해결책을 만들지가 논의에 들어와야 해요.
이 단계에서 해결책은 맥락에 비추어 평가돼요.
- 관찰된 문제점을 줄여주는가?
- 실제 워크플로우에 맞는가?
- 새로운 마찰을 만들어내지 않는가?
맥락이 필터가 되는 거예요. 팀원 개인의 선호도가 아니라요.
패턴을 가시화하는 실용적인 기법 중 하나로 어피니티 다이어그램(Affinity Diagram), KJ 기법이 있어요.
- 관찰을 개별적으로 적는다
- 유사성에 따라 그룹핑한다
- 떠오르는 테마에 이름을 붙인다
이 방법은 사고를 외부화하고, 성급한 결론을 방지하며, 팀 참여를 유도해줘요.
5. 심층 인터뷰: 직접 관찰이 불가능할 때
현실에서 완전한 맥락적 탐구가 항상 가능한 건 아니에요.
- 제한된 접근
- 민감한 환경
- 시간과 리소스가 부족
특히 B2B나 사내 도구를 다루는 프로덕트 팀에서는, 단순히 “사용자가 일하는 모습을 지켜보기”가 옵션이 아닌 경우가 많아요.
그렇다고 맥락을 포기해야 하는 건 아니에요.
신중하게 비슷한 데이터를 구할 수 있는 방법을 찾아야 한다는 뜻이에요.
1) 심층 인터뷰로 맥락을 포착하는 방법
심층 인터뷰는 의견이 아니라 실제 상황을 재구성하도록 설계했을 때 유용해요.
핵심 차이는 인터뷰를 어떻게 진행하느냐에 있어요.
효과적인 인터뷰가 집중하는 것들은 다음과 같아요.
- 최근의 구체적인 사건
- 실제로 취한 행동
- 실제로 사용한 도구
- 무언가가 문제가 됐던 순간
질문이 이렇게 바뀌어야 해요.
효과가 낮은 질문:
- “뭘 원하세요?”
- “이 기능에 대해 어떻게 생각하세요?”
맥락 지향 질문:
- “마지막으로 이런 상황이 있었을 때, 과정을 처음부터 말해주시겠어요?”
- “그 순간에 화면에 뭐가 열려 있었나요?”
- “이 단계가 실패했을 때 바로 다음에 뭘 하셨나요?”
대화가 실제 행동에 가까울수록, 맥락에 더 가까워지는 거예요.
6. 맥락에서 의사결정까지의 과정과 대안적 관찰법의 중요성
제품은 혼자 존재하지 않아요.
제품은 항상 이런 조건 안에서 사용돼요.
- 특정 사용자에 의해
- 특정 작업을 완료하기 위해
- 특정 도구를 가지고
- 특정 환경 안에서
이 조건들을 무시하거나 지나치게 단순화하면, 사용성은 머릿속에만 존재하는 이론적 개념이 돼요.
로드맵이나 디자인 리뷰에서 명확해 보이던 것이 실제 상황에서는 무너지곤 해요. “맞게” 만들어진 프로덕트가 여전히 무관하게 느껴질 수 있는 이유가 여기에 있어요.
미팅은 말하기 위한 자리가 아니에요. 맥락을 이해하고, 이해한 것 위에서 결정하기 위한 자리예요.
마무리: 맥락이 제품의 성공과 실패를 설명하는 이유
프로덕트는 혼자 존재하지 않아요.
프로덕트는 항상 이런 조건 안에서 사용돼요.
- 특정 사용자에 의해
- 특정 과업을 완료하기 위해
- 특정 도구를 가지고
- 특정 환경 안에서
이 조건들을 무시하거나 지나치게 단순화하면, 사용성은 이론적 개념이 돼요.
로드맵이나 디자인 리뷰에서 명확해 보이던 것이 실제 상황에서는 무너지곤 해요. “맞게” 만들어진 프로덕트가 여전히 무관하게 느껴질 수 있는 이유가 여기에 있어요.
맥락을 무시한 채 만든 프로덕트는 최적화의 결과가 아니라 우연의 결과가 돼요. 사용자가 프로덕트를 어떻게 경험하는지, 어떤 제약에서 작업하는지, 실제로 어떤 문제를 해결하려고 하는지를 알아야, 비로소 의도적인 설계가 가능해요.
팀의 의사결정이 기억에 의존하지 않도록, 추측이 아닌 관찰에 기반하도록, 그리고 각자의 해석이 아닌 공유된 현실에 기반하도록 하려면, 맥락의 외부화는 선택이 아니라 필수예요.
미팅은 말하기 위한 자리가 아니에요. 맥락을 이해하고, 이해한 것 위에서 결정하기 위한 자리예요.
이것이 맥락 기반 디자인의 핵심이에요.