brunch

You can make anything
by writing

C.S.Lewis

[수업 연구일지] 설문 질문 만들 때 주의할 점



수업을 진행하면서 느낀 점들, 피드백을 정리하는 중이에요.

설문 관련해서 학생분들이 종종 놓치곤 했던 부분을 정리해봤어요.






설문 전 할 일


0. 설문 계획서 작성하기!

- 설문 계획서 상세 내용은 아래에 계속.

- 설문 계획서 양식은 이 링크에


1. 목표 적어두기

이 설문을 통해 사용자들로부터 알아내고자 하는 것이 무엇인가? 그 목표 적어두기            

예) 그들이 우리 앱을 사용하면서 느끼는 불편함에 대해 파악하기            

목표를 적어두지 않고 바로 설문질문을 작성하면 알아내고자 하는 핵심 목표와는 별로 상관없는 질문들의 비중이 많아진다거나 무엇부터 어떻게 질문을 만들어야 할지 몰라하는 상황 발생함.            


2. 주요 타겟(설문 대상) 적어두기

예) 우리 앱을 한번이라도 사용해본 사람            

예) 그 중 한달 평균 ㅇㅇ원 이상 구매하는 사람            

설문을 돌린 후 그 데이터를 바탕으로 주요 타겟을 정해도 되지만 나는 개인적으로 우선 대충이라도 주요 타겟 집단을 정한 후 그들을 대상으로 설문을 돌리는 편임. 귀에 피날 정도로 누누히 얘기하고 다니는 것이지만, '정답'은 없음. 상황에 맞게, 본인 성향에 맞게 마음대로 알아서 하면 됨.            


3. 데스크 리서치하기 + 리서치 내용 요약하기 

데스크 리서치 후 설문지 작성하는 순서를 추천함. 완전 아무것도 모른 상태에서 설문질문 작성하는 것보다는 어느 정도 데스크 리스치를 통해 대략적인 불편함에 대해 파악한 후 질문지 작성하는 것이 더 수월함. 

문제 수집 후 어피니티 다이어그램 방법 등 활용해서 수집한 문제들을 정리, 요약하기. 문제를 수집해놓고 보면 중구난방 내용들이 정신 없이 나열만 되어 있어서 한눈에 파악하기 어려움. 정리하는 차원에서 어피니티 다이어그램 방법 활용해서 7개 이내의 카테고리 좁혀 정리해 놓는 것이 좋음.                   






설문 질문 만들 때 할 일


1. 데스크 리서치 자료 활용해서 객관식, 주관식 질문 만들기 

앞서 진행한 리서치를 통해 사용자들이 느끼는 불편함을 많이 수집했을 것임. 그럼 그 불편함들 중 어떤것을 가장 불편해하는지 알아볼 차례. 수집한 질문들을 보기 예시로 죽 나열해놓고 이 중 어떤것이 가장 불편하셨나요? 그렇게 느낀 이유는 무엇인가요? 해당 상황을 자세히 묘사해주세요. 하고 물어보기.            

단, 수집한 데이터 정리를 위해 어피니티로 다이어그램으로 묶어준 것을 설문 보기 예시에다가 그 최상위 카테고리를 그대로 쓸 필요는 없음. 수집한 불편함이 몇 개 없다면 그냥 그대로 보기 예시로 써도 되지만 너무 많다면 적당히 비슷한 것끼리 묶어주고, 내부적으로 설문 돌려서 몇개 추린 후 그 몇개에 대해서만 물어보기.            


2. 거의 대부분의 객관식 질문에는 '기타' 도 넣기. 

기타는 본인이 직접 주관식으로 답변 작성할 수 있어야 함. 구글폼에 이 기능 있음. 팀원들이 미처 생각하지 못했던 내용들이 있을 수 있으므로.            


3. 적당선에서 만족하고 일단 설문 돌리기

설문을 완벽에 가까운 상태로, 스스로 만족한 상태로 만들고서 돌리려고면 시간 오래 걸림. 그냥 적당선에서 만족하고 일단 돌리기!            


4. 파일럿 테스트

미리 우리끼리 직접 설문에 참여해보는 것. 미리 나 혼자서 또는 팀원들끼리 설문에 직접 참여해보고 최종 검토하기. 설문 작성에 참여하지 않았던 다른사람 한두명에게도 돌려보고. 그래야 최대한 객관적으로 놓친 부분, 미흡한 부분들을 보완할 수 있음.      






설문 돌린 후 할 일


1. 회고록 작성하기

아쉬운 점 당연히 있을 수 밖에 없음. 해당 내용들을 회고록에 꼭 적어두고 다음에 설문 돌릴 때 참고하기. 

아쉬운 점이 프로젝트 결과에 안좋은 쪽으로 너무 큰 영향을 미친다고 생각되면 다시 설문 돌리는 것도 좋음. 하지만 왠만하면 회고록에 기록만 해두고 일단은 프로젝트 죽 진행하기. 한단계 한단계의 완벽성보다는 프로젝트 전체를 빠르게 테스트 해보고 빠르게 피드백 반영하는 것이 제품/서비스에 훨씬 더 좋은 영향미침. 사소한 각 단계의 완성도에 너무 집착하지 말기!             

참고: KPT (Keep, Problem, Try)            




UXUI 디자인 강의 프리랜서 강사 니디자인랩










작가의 이전글 과연 정책으로 출생율를 높일 수 있을까?
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari