시각화 설계 과정: 과업 분석, 상호작용, 평가

차트 한 장이 아니라 대시보드나 분석 도구처럼 사람이 계속 쓰는 시각화 시스템을 만들 때는 제품을 만드는 것과 같은 과정을 밟는다. 누가 무엇을 하려는지 알아내고, 싸게 시도해 보고, 상호작용을 설계하고, 쓸모를 검증한다.

데이터 + 과업 = 시각화

같은 데이터라도 하려는 일이 다르면 맞는 시각화가 다르다. 매출 데이터로 "지난달 대비 어느 지점이 떨어졌나"를 보려는 지점 관리자와 "계절성이 있나"를 보려는 분석가에게 필요한 차트는 다르다. 데이터를 어떻게 그릴지부터 정하면 아무도 안 쓰는 화면이 나온다.

과업(task) 은 사용자가 시각화로 목적을 이루려고 하는 활동이다. 프로그래밍의 함수처럼 큰 목적을 작은 단위로 나눈 것이라고 보면 된다.

수준	질문	예
상위	왜 시각화를 쓰나	이상 거래를 찾으려고
중간	무엇을 하나	탐색한다, 검색한다, 정리한다
하위	무엇을 찾나	특정 값, 최댓값, 두 값의 차이

과업 끌어내기

사용자에게서 과업을 알아내는 일을 과업 끌어내기(task elicitation) 라고 한다. 도메인 전문가 인터뷰와 같은 분야의 기존 자료 조사가 주된 방법이다. 아래 여섯 질문으로 정리하면 빠진 곳이 보인다.

질문	볼 것	선택지
왜(목적)	사용자의 목표	새 정보 탐색, 이미 아는 것 확인, 남에게 전달, 그냥 즐기기
어떻게(수단)	사용자가 데이터와 어떻게 상호작용하나	이리저리 이동, 표현 방식 재정리, 데이터 안의 관계 찾기
무엇을(데이터 특성)	알고 싶은 것	개별 값의 추정·비교(하위) 또는 여러 값의 추세·평균(상위)
어디서(대상과 범위)	데이터의 어느 부분인가, 얼마나 넓게	시간·공간 같은 절대 기준과 비교하나, 다른 데이터와 비교하나 / 한 요소, 일부, 전체
언제(흐름)	과업의 순서와 이력	질문과 답이 꼬리를 물며 이어진다. 거쳐 온 과업의 이력(provenance)을 남기면 돌아가기 쉽다
누가(역할)	사용자가 누구인가	분석가, 일반 청중, 관리자

시각화가 항상 답은 아니다. 사용자가 숫자 하나(이번 달 이탈률)만 원하면 큰 숫자 하나를 보여 주는 편이 낫다.

디자인 방법: 싸게 그려 보고 반복하기

사용자 중심 설계와 같다. 사용자와 함께 세 가지를 정리한다. 가진 데이터(데이터 추상화), 가진 질문(과업 분석), 시각화 전략.

프로토타입 충실도

수준	형태	쓰임
저충실도	종이 스케치, 화이트보드	아이디어를 많이 내고 빨리 피드백 받기
고충실도	실제 데이터로 그린 동작하는 시안	마지막 단계의 확인

스케치는 싸고 빨라 여러 번 반복할 수 있고 사용자와 대화하기 좋다. 대신 실제 데이터로 그려 보기 전에는 성공 여부를 알 수 없다. 화면 설계 산출물 전반의 충실도 구분은 와이어프레임, 목업, 프로토타입에 있다.

다섯 장 디자인 시트(Five Design-Sheet)

로버츠(Roberts) 등이 제안한 스케치 방법으로, 종이 다섯 장으로 이해관계자와 대화한다.

시트	하는 일
1. 브레인스토밍	아이디어를 최대한 많이 내고, 불가능·중복을 거르고, 비슷한 것끼리 묶고, 좋은 것을 합쳐 다듬는다
2~4. 초기 디자인 세 가지	각 시트에 전체 레이아웃, 핵심 부분 확대(focus), 사용자 조작 방법(operations), 장단점 논의를 적는다
5. 실현	2~4에서 고르거나 섞은 최종안. 알고리즘, 색·모양 같은 세부, 예상 작업 시간, 하드웨어·소프트웨어 요구까지 적는다

시안을 하나가 아니라 세 개 그리게 하는 점이 핵심이다. 첫 아이디어에 매달리지 않게 한다.

디자인 스터디 방법론

실제 문제를 가진 도메인 전문가와 협업해 시각화 시스템을 만들고, 끝난 뒤 배운 점을 정리하는 프로젝트를 디자인 스터디라고 한다. 세들마이어(Sedlmair) 등이 2012년에 정리한 아홉 단계가 널리 쓰인다.

범주	단계	내용
준비	학습(learn)	도메인 문헌을 읽고 전문가와 이야기해 말이 통하게 한다
	선별(winnow)	함께 일할 유망한 협업자를 고른다
	역할 정하기(cast)	실제 분석가, 문지기(접근 권한을 쥔 사람), 공동 디자이너 등 협업자의 역할을 파악한다
핵심	발견(discover)	어떤 과업을 풀려는지, 어떤 데이터가 있는지 문제를 정의하고 추상화한다
	설계(design)	데이터를 가공하고 시각 표현과 상호작용을 만든다. 스케치 단계
	구현(implement)	도구와 알고리즘을 골라 실제 데이터로 동작하게 만든다
	배포(deploy)	사용자에게 주고, 실제로 일하는 방식이 바뀌는지 본다
분석	회고(reflect)	디자인과 도메인에 대한 가설을 확인하거나 고친다
	기록(write)	과정과 배운 점을 문서나 글로 남긴다

이전 단계로 돌아가는 건 자유지만 건너뛰기는 안 된다. 구현 없이 배포할 수 없다. 과업 중심, 사용자 중심, 반복, 평가가 이 방법론의 성격이다.

상호작용 설계

시각화 시스템은 표현(데이터를 그림으로 바꾸기, 컴퓨터 그래픽스의 영역)과 상호작용(사용자와 시스템의 대화, HCI의 영역)으로 이뤄진다. 정적인 차트 한 장에 모든 것을 담을 수 없을 때 상호작용이 그 몫을 나눠 맡는다.

정보 탐색 만트라

벤 슈나이더만(Ben Shneiderman)의 원칙이다. "개관 먼저, 확대와 필터, 그다음 필요할 때 세부."

개관(overview): 전체 데이터를 한눈에
확대·필터(zoom & filter): 관심 있는 부분만 남기기
요청 시 세부(details on demand): 마우스를 올리면 툴팁으로 상세 값

일곱 가지 상호작용 의도

이(Yi) 등(2007)은 사용자가 상호작용으로 하려는 일을 일곱 가지로 나눴다.

의도	사용자가 원하는 것	기법 예
선택(select)	이것을 표시해 둬	클릭한 점 강조, 나머지 흐리게
탐색(explore)	다른 부분을 보여 줘	패닝(확대 없이 시점 이동)
추상/구체화(abstract/elaborate)	더 많이 또는 더 적게	확대·축소, 의미론적 확대(확대 수준에 따라 표시 내용이 바뀜)
재구성(reconfigure)	다른 배치로	값 순 정렬, 군집끼리 모으기, 단위 바꾸기
인코딩(encode)	다른 표현으로	막대를 선으로 바꾸기, 색 기준 바꾸기, 여러 차트를 대시보드로
필터(filter)	조건에 맞는 것만	영역 드래그 선택, 체크박스, 범위 슬라이더
연결(connect)	관련된 것을 함께	한 차트에서 고른 항목을 다른 차트에서도 강조(brushing & linking)

얻는 것과 잃는 것

장점	단점
표현을 바꿔 가며 새 패턴을 찾는다	잘못 설계하면 중요한 부분이 숨는다. 사용자가 클릭하지 않으면 못 본다
관심 영역만 세밀하게 본다	기기마다 가능한 조작이 다르다(마우스 호버는 터치에 없다)
일부를 떼어 강조한다	화면이 바뀔 때마다 새로 읽어야 해 인지 부담이 커진다
집계된 개관에서 시작해 대용량 데이터도 다룬다

확대와 패닝을 하다 보면 지금 전체의 어디를 보고 있는지 잃어버린다. 이를 사막의 안개(desert fog) 라고 부른다. 해결책은 두 가지다.

개관 + 세부(overview + detail): 전체 미니맵과 확대 화면을 따로 나란히 두고, 미니맵에 현재 위치를 표시한다.
초점 + 맥락(focus + context): 한 화면 안에서 관심 영역은 크고 자세하게, 나머지는 작고 단순하게(어안 렌즈 효과).

웹에서는 D3.js, Vega-Lite, Plotly 같은 라이브러리로 이런 상호작용을 구현한다. 터치 기기에서 호버를 대체하는 문제처럼 일반 UI와 같은 고민은 반응형 UI 패턴과 접근 가능한 위젯이 참고가 된다.

평가

무엇을 평가하나

시각화 프로젝트의 단계마다 확인할 질문이 있다. 앞 단계가 틀리면 뒤를 아무리 잘해도 소용없다.

단계	확인할 것
문제 정의	사용자가 개발자의 가정에 동의하나, 문제의 범위를 제대로 이해했나
데이터와 과업	고른 데이터에 필요한 정보가 있나, 과업으로 원하는 지식을 얻을 수 있나
인코딩	사용자가 이 인코딩에서 패턴을 찾을 수 있나
구현	매핑 알고리즘이 데이터에 맞고 충분히 빠른가
상호작용	빠르고 직관적으로 조작할 수 있나

단계별 비공식 인터뷰만으로는 전체 목표를 이뤘는지 알기 어렵고 시간도 많이 든다. 먼저 전체를 평가하고, 문제가 보이는 단계를 골라 세부 평가한다.

통찰 기반 평가와 실험 기반 평가

	통찰 기반 평가	실험 기반 평가
묻는 것	사용자가 이 도구로 어떤 새 지식을 얻나, 그게 얼마나 가치 있나	이 방법이 다른 방법보다 빠르고 정확한가, 차이가 통계적으로 유의한가
성격	정성적	정량적
방법	반구조화 인터뷰, 소리 내어 생각하기(think-aloud), 일기 연구	통제 실험
측정	통찰을 얻기까지 걸린 시간, 통찰의 개수·중요도·깊이, 도구 채택률	과업 정확도, 완료 시간
장점	음성·영상·글 등 풍부한 피드백, 실제 사용 환경과 비슷	정확하고 일반화하기 쉽다
단점	통제가 덜 되고 오래 걸리며 덜 정확하다	실제 환경과 다르고, 더 추상적이다

여기서 통찰은 "데이터에 대한 하나의 발견"이다. 복잡하고, 오래 쌓이며 깊어지고, 수치로 딱 떨어지지 않고, 예상 밖이며, 도메인 지식과 엮여야 의미가 생긴다. 그래서 정성적으로 잴 수밖에 없다.

통찰 기반 방법 세 가지:

반구조화 인터뷰: 질문 목록을 준비하되 답에 따라 유연하게 파고든다. 개발자가 아니라 사용자가 답할 수 있는 질문이어야 한다. 프로토타입 단계처럼 초반에 맞다.
소리 내어 생각하기: 사용법을 간단히 알려 주고 질문 하나를 준 뒤, 사용자가 자유롭게 탐색하며 관찰·추론·결론을 말로 하게 한다.
일기 연구: 도구를 주고 개입하지 않는다. 사용자가 통찰을 얻을 때마다 중요도, 새로운지 여부, 얻은 과정을 적는다. 중요도로 가중치를 매겨 합산할 수 있다.

실험 기반 평가는 다섯 요소로 설계한다.

요소	뜻	예
실험 과업	참가자가 할 일	두 막대 중 큰 쪽이 몇 배인지 답하기
자극	과업에 쓰는 시각화	같은 데이터를 위치·길이·각도·면적 등 여섯 방식으로 그린 차트
독립변수	바꿔 가며 비교할 조건	인코딩 방식
종속변수	잴 것	답의 오차, 응답 시간
통제변수	결과에 영향을 줄 수 있어 고정할 것	데이터셋, 참가자 인구통계

절차는 질문 → 가설("위치 인코딩이 가장 정확할 것이다") → 변수 결정 → 자극과 실험 환경 제작 → 실행 → 통계 분석이다. 인코딩 정확도 순위(데이터 시각화)도 이런 실험에서 나왔다.

두 방식은 보완 관계다. 일반 제품의 사용성 테스트·리서치 방법과 겹치는 부분은 사용자 리서치에 있다.

정리

데이터보다 과업이 먼저다. 왜·어떻게·무엇을·어디서·언제·누가로 사용자의 과업을 끌어낸다.
스케치로 여러 안을 싸게 시도하고(다섯 장 디자인 시트), 실제 문제와 협업자가 있으면 디자인 스터디 아홉 단계를 따른다.
상호작용은 개관 → 확대·필터 → 세부. 위치를 잃지 않게 개관+세부나 초점+맥락을 쓴다.
평가는 통찰(정성)과 실험(정량)을 함께. 앞 단계(문제 정의)가 틀리면 뒤 단계 평가는 의미가 없다.

관련 노트: 데이터 시각화, 사용자 리서치, 유스케이스 다이어그램

버그 제보