우리는 테스트와 피드백이 필요한 것을 알지만 무엇을 위해서 필요한지는 정확히 모를 때가 있다.
그래서 알아보려고 한다.
우선 User Testing이 무엇을 위한 것일까?
The purpose of user testing is to gather qualitative and quantitative information about how well your design and its current implementation is meeting the user needs that the experience is designed to address.
우리가 만든 게임에 대해서 양적, 질적으로 우수한 정보를 취합해서 그에 대한 유저들의 니즈를 반영하기 위함.
User testing isn’t a once-and-done activity.
하지만 이 과정은 한 번으로 끝나는 과정이 절대 아니다.
User testing must be embedded throughout the phases of production.
우리가 만드는 모든 과정 단계마다 이루어져야 할 항목이기도 하다.
It will ensure a high-quality final product that meets the needs of your target audience.
이를 통해서 우리는 목표 고객층에 대한 니즈를 파악하여 그에 맞는 양질의 서비스를 제공할 수 있다.
우리가 처음에 설계 명세서를 작성하지만 목표 고객층이 존재하는 한 유저친화적인 환경을 제공해야 하므로 모든 단계마다 테스팅을 통해 정보를 얻는 것이다.
언제나 우리는 수정을 위해 살듯이.. 유저 테스팅은 우리의 작품에 수정을 하고 또 하는 것이다.
비유하자면 대장간 풀무질이랄까? 할 수록 좋아지는 그런 거 있잖아.
그렇다고 해서 무턱대고 테스팅을 하는 것은 아니다.
테스팅에도 단계가 있다.
It’s a structured process designed to get as much specific and useful information from the tester as possible.
이렇게 짜여진 과정 속에서 우리는 유저 테스팅을 진행해야 한다.
정확히 말하자면 정보를 얻고 나서 우리가 수정할 부분을 생각하는 것이 아니라
우리가 처음부터 수정할 분야를 나누어서 유저에게 정보를 구하는 것이 맞다고 보면 된다.
예를 들어서 내가 스킬 구현을 했다고 하자?
"이 때 이 스킬의 이펙트는 어때?" " 사운드는 적절해?" " 쿨타임은 괜찮아?"
이런 것들이 직접적으로 수정을 하는 것에 도움을 주는 질문일 것이다.
그냥 게임 한 번 해봐~ 그러고
어때? 괜찮아? 이러면
무슨 피드백을 받을 수 있을까? 받아봤자
어.... 괜찮은데? 그 정도일 것이다.
그래서 어떤 순서로 진행하는데?
크게 4가지로 나눌 수 있다.
++물론 세부적으로 더 많이 있고 알아봐야 한다.
Define the objectives. 목표 설정
Plan the session. 세션 계획
Facilitate the session. 세션 진행
Evaluate the results. 결과 정리
더 자세히 알아보자
Define the objectives
우리는 물어볼 질문을 만들기 전에 몇가지를 확실하게 하고 넘어가야 한다.
- 나는 내 작품에 대해서 무엇을 느끼길 바라는가?(어떤 의도를 가지고 만들었는가?)
- 내 작품의 어떤 부분에서 피드백을 받을 것인지?(세부적인 부분)
위의 사항을 고려해야 우리가 좀 더 양질의 프로그램을 만들 수 있을 것이다.
질문을 준비해야 한다고 했다.질문의 종류는 2가지가 있다.
열린 질문, Open-ended questions give the user freedom to explain their answers.
닫힌 질문, Closed-ended questions have predetermined answers, like those found in surveys.
우리가 어떤 방식을 원하느냐에 따라 다르게 구성하면 된다.
열린 질문의 뭔지 예시를 들어 알아보자
- 하면서 이해가 안되거나 약간 어려운 부분 있었어?
- 유저들이 더 필요한게 있을까?
- 게임의 몰입을 방해하는 부분이 있나?
등등이 있다.
닫힌 질문은 위의 항목과 같은 것에 대해서
1점부터 5점까지 점수를 매기거나
Yes / No 답변으로 어느 정도인지를 판단한다.
열린 질문들이 유저와 소통하고 직접적으로 정보를 얻기 쉽겠지만 정보를 간추리기 어렵다.
닫힌 질문은 바로바로 점수화 시켜서 분석할 수 있다.
어느 한쪽을 몰아서 하기보다는, 분산해서 하는 것이 낫겠다.
예를 들어 "유저들에게 편의성을 제공하는 무엇인가 필요할까?"
닫힌 질문에선 Yes라고 나오던 대답들이
열린 질문에서는 "미니맵이 필요한 것 같아", " 아이템 창이 열기가 너무 어렵다" 등등
"게임의 그래픽들이 어느정도 생생해?"
닫힌질문에선 "4점"
열린 질문에선 "괜찮은데?"
실질적으로 도움되는 질문의 종류를 맞춰서 질문을 해야한다는 것이다.
질문에 What이 들어간다면, 즉 무엇을 이끌어내려면 열린 질문이 괜찮을 것 같고
질문에 How가 들어가서, 즉, 어떤지 물어보려면 닫힌 질문이 괜찮을 것 같다.
그냥 개인적인 내 생각이다.
Plan the session
딱히 특별한 것은.. 없고 그냥 하면 된다.
Identify the best time and date. 시기 적절한 때
Determine how to find testers from your target audience. 목표 고객에 맞는 테스터들
Identify the ideal number of testers. 유의미한 표본 수
Create an agenda for the testing session(s). 관련 문서 만들기
Plan to record the session (if applicable). 기록할 준비
Choose a leader and note-takers for the session, if working in a team. 역할 분담
위를 고려해서 계획한다.
facilitating the session
이러한 세션 진행을 원활하게 하기 위해서는 몇가지 참고할 사항이 있다.
Observe rather than guide
만약 우리가 테스터가 게임하는 것을 지켜보고만 있고 다할 때까지 기다리는 것은 정말.. 아무 의미 없는 일이다.
그래서 보기만 하는 것 보다는 작품을 잘 알고있는 사람이 옆에서 도와주는 역할을 해주는 것이다.
예를 들어 space bar가 점프인데 자꾸 C를 눌러서 점프를 한다던가?
게임이 진행이 안되어버리면 피드백조차 줄 수 없기 때문에 도와줘야한다.
다만 여기서 바로 도와주는 것이 아닌 어려워 하는 부분을 적어놓거나 표시해놔야 하는 것이다.
이 또한 피드백의 일부가 되는 것이다.
Don’t explain or justify your design choices
하지만 피드백을 받을 때는..? 우리가 어떤 의도로 ~~한 것을 디자인 했고 ~~했다라는 것을 테스터에게 말하면 안된다.
솔직한 피드백에 방해가 되기 때문이다.
우리가 말을 했다면 테스터가 자기도 알게 모르게 그것을 기반으로 피드백을 할 수 있기 때문이다.
좋은 피드백과는 거리가 멀어지는 것이다.
Emphasize that you want all feedback, and negative feedback can actually be more helpful than positive feedback.
사실 부정적인 피드백을 위해서 테스팅을 하는 것이라고 봐도 좋다.
When the testing begins, make sure that you stop talking and record your observations in detail. Things that seem clear in the moment can easily get fuzzy if you only rely on your memory.
기록하자. 내 머리도 믿지만 손을 더 믿는다.
위의 참고사항을 바탕으로
진행하면 된다.
아래 사항은 테스트를 조금 더 원활하게 할 수 있는 과정들이다.
-Make introductions if testing as a group. 테스터들 그룹화
++ 목표 고객별로 나누겠지?
-Identify the goal of the session.
테스트의 목적 명확하게 한다.
-Explain the recording policy (if applicable) and confirm the tester's consent to this.
기록을 한다면 동의를 받자.
-Provide the materials for testing, and observe the testers as they use or review them.
테스팅에 필요한 물품들 지급 후 관찰
-Ask the questions you have prepared.
준비한 문서 배부
-Provide summaries of participant answers for clarification purposes.
테스터들의 설문지를 목적에 따라 분류
After the session
세션이 끝나면 또 할 것이 생긴다.
Make sure the session was recorded (if applicable).
녹화 확인
Write down any additional notes or observations.
기록 확인
Debrief with fellow team members (if applicable).
팀원들과 상황 보고
Create a summary document highlighting areas to address.
요약본 작성 및 중요부분 체크
Determine what you will and will not change based on the data and feedback collected.
실제로 피드백을 반영할 부분인가? 에 대한 결정
Evaluating and acting on feedback
모은 피드백들을 어떻게 평가하고 뭘 해야할까?
모든 피드백, 기록, 설문지를 읽어서 요약본을 만들고 긍정적인 부분과 부정적인 부분을 나눈다.
예를 들어
" 유저들이 다른 종류의 포탑이 있는지 몰랐다"
" 유저들이 메뉴 사용법을 쉽게 이해했다"
등등
이런 식으로 나누어서 요약해서 보게 된다면, 우리가 할 것은 그저 그것이 우리 작품을 향상시킬 요소인가? 를 판단하면 된다.
이렇게 다 하고나면.. 실제로 반영을 하게 되면 끝이 나게 된다.
근데 또 수정이 끝나고 테스팅을 해봐야겠지? ㅎ
수작은 이렇게 만들어진다.
'Game Development, 게임개발' 카테고리의 다른 글
| 읽기 시작한 책, Introduction to GAME DESIGN, PROTOTYPING, and DEVELOPMENT , Jeremy Gibson (0) | 2021.03.26 |
|---|---|
| Object Pooling, 오브젝트 풀링, 디자인 패턴 [Game Development] (0) | 2021.03.26 |
| 게임 개발자가 되는 법, To Become A Game Developer (0) | 2021.03.25 |
| 파이썬 살짝 접고 C++ 다시 공부 (0) | 2021.03.23 |
| 게임 개발자의 길,Game-Devloper Roadmap (0) | 2021.03.08 |