아래 글은 게임 디자인을 하는 학생들에게 유용한 글이라 공유합니다.
원본출처는 아래와 같습니다.
https://make-game.tistory.com/2?category=806318
원문: https://celiahodent.com/how-we-introduced-ux-to-epic-games-production-pipeline-gdc16/
이번 번역은 구어체입니다.
GDC 발표를 2명이서 대화하듯 풀어냈던 세션입니다. 이를 논문식으로 번역하다보니 생동감이 없고 부자연스러워서 구어체로 변경했습니다.
이 슬라이드들은 Fortnite (Epic Games)의 수석 프로듀서인 Heather Chandler와 함께한 내 GDC 2016 발표에서 나온 슬라이드들이야. 따라서 이번 발표는 UX 부서(Celia)와 프로덕션(Heather)의 관점에서 설명하고 있지. 이 프레젠테이션의 비디오를 여기서 볼 수 있어. 또한 UX에 관심이 있으시면 2016년 5월 12일에 열리는 Game UX Summit을 확인해보기 바라. (놀라운 라인업이 준비되어있다고! ^^)
// 역자 주: 게임 UX 서밋의 링크가 망가져있으므로 링크를 해제해놓았습니다.
UX 관점 (Celia) – 게임 산업에서 사용자 경험의 영향이 커지고 있어. 현재 산업 디자인과 많은 기술 회사에서 잘 자리를 잡은 UX 전문가들은 비디오 게임 산업과 함께 일하기를 열망하고 있지.
프로덕션 관점 (Heather) – 그러나 많은 팀들은 UX를 위협으로 보고 있어 – 요상한 외계인들이 침입하여 난장판을 만들고 있는 것처럼 말야. 왜 우리가 그들을 또 필요하다는거지? 우리는 그들 없이 잘 지내고 있었어.(적어도 우린 그렇게 생각했지.) 이것은 에픽에서 발생한 일이고, 이 토크의 목적은 개발과 UX 사이에서 더 나은 이해를 할 수 있도록 양쪽 관점을 모두 제공하는데 있어. 만약 우리가 서로를 이해한다면 우리는 그 관계에서 더 많은 것을 얻을거야. 이 관계의 시작은 험난했지. – UX 팀은 유용한 통찰력을 얻을 수 있기 위해 프로세스 초기에 많은 테스트를 실시하려고 밀어붙였지만 프로덕션 팀(제작진)은 더 큰 문제를 해결해야 한다고 생각했어. – 그들은 이미 UX 문제가 있다는 것을 알고 있었지만 나중에 해결할 계획이었지.
시작하기 전에, 에픽 게임즈가 어떻게 구성되어 있는지에 대해 간단히 설명해줄게. 우리는 자체 퍼블리싱을 하기 때문에 지원팀과 운영팀을 비롯해 여러 제작팀을 보유하고 있어.
제작팀에는 UX 설계자들이 있지만, UX 설계가 필요하다면 UX팀이 추가 도움을 제공하고, UX 분석과 UX 연구를 수행하기 위한 도구, 방법론, 지식을 제공하지. UX팀은 모든 제작팀을 서포팅해.
Fortnite는 UX와 초기부터 협업한 첫 번째의 선구적인 팀이었어. Fortnite는 RPG 매카닉을 가진 액션게임이자 빌딩게임으로써, 현재 알파 단계에서 라이브를 하고 있어.
먼저 오해부터 이야기해보자.
여러 면에서, UX는 개발팀을 껴안고, 사랑받고, 도움이 되고싶은 고슴도치야. 개발팀 관점에서 바라보면, 가시는 마음에 들지 않고 이 새로운 생명체는 의심스러워보이지. 하지만 그것은 모두 관점의 문제일 뿐이야. UX관점에서 시작해보자.
Celia - UX의 간략한 정의는: 기획의도가 경험에 개입하는 정도를 포함하여(cf. Isbister and Schaffer, 2008) 타겟 유저가 소프트웨어와 상호작용하는 것을 의미해. UX는 일반적으로 제품, 시스템, 혹은 서비스의 목표 청중이 기획의도와 사업적 의도를 궁극적으로 경험하게끔 하지. 게임이 좋은 사용성과 몰입도를 가지는지 확인하기 위해 신경과학과 심리학 지식을 활용하고 게임 유저 연구 방법론(예: 플레이테스트와 분석)을 적용해.
UX는 Human Factors와 HCI(Human-Computer Interaction; 인간과 컴퓨터 간의 상호작용을 연구하는 학문, 역자 주)뿌리를 두고 있어. 이는 누군가 설계한 것에 대해 별도의 가이드 없이 시스템을 유저가 이해하고 상호작용하는 방법을 살펴보게끔 해. 이로써 개발자의 멘탈 모델을 플레이어의 멘탈 모델과 일치시키게 해.(cf. Norman, 1988)
참고로, 여기서 말하는 UX는 UX 설계, UX 테스팅(유저 리서치), UX 전략 등의 전반적인 UX 입문에 대한 것들이야. 다양한 UX 분야들에 대해 꽤 많은 오해가 발생할 수 있는데, 이는 다른 강연에서 다루기로 할게. ^^
Celia –내가 10년 전에 엔터테인먼트 산업에서 시작할 때는, UX는 별게 없었어. 내 타이틀은 "UX 뭐시깽이"가 아니었지. 처음으로 UX 타이틀을 갖게된 건 LucasArts에서 일할 때였는데, 고작 4년 전이야. 그리고 그건 내 공식 직함도 아니었고. 새 팀과 일을 시작할 때마다 매번 내 첫 숙제는 UX가 가진 오해들을 풀어내는 것이었어. 이건 내 UX판 Groundhog Day(역자 주: 매일 같은 날을 사는 영화 제목) 같았다고.
여기 Top 5를 뽑아봤어.
Heather – UX는 기획자의 창의성을 해칠 것이며, 모든 플레이어에게 게임을 엄청 쉽게 만들어놓을거야! 게임을 다크소울마냥 죽여가고 있다고.
Celia – 우린 감히 그런 일을 벌이지 않아! 실제로, UX 프렉티스의 주 목적은 기획자가 의도한 경험을 그들의 목표 청중에게 제공하는 거야. 그러므로, 네 청중이 하드코어 게이머이고 그들이 고통받길 원한다면, UX 가이드라인은 네 세디스트같은 목표를 달성하기 위해 전적으로 도와줄거야.
Heather – 이 모든건 상식일 뿐- 우린 UX를 테스트할 필요가 없어. 플레이어들은 그들이 해야할 걸 명확히 이해하고 있을거라고!
Celia – 당근 상식적인 것들도 좀 있겠지, 비록 문제점들이 항상 사후에 쉽게 보이지만 말야.(사후 확신 편향효과) 모든 UX 권고사항이 상식을 통하는건 아냐. 인간의 뇌는 지각, 인지, 그리고 사회적 편향으로 가득차있어서 개발자나 플레이어 모두에게 영향을 미친다고. 이것이 연구자들이 어떤 필드에서든 굉장히 표준화된 프로토콜로 그들의 가설을 검증하는 이유야; 그리고 무엇이 일어나고 있는지를 놓치거나, 잘못이해하기 쉽기도 하니까.
뇌의 구성은 지각으로 되어있어. UX는 진짜 문제가 무엇인지 더 빠르고 정확하게 밝혀내는데 도움을 줄거야.
Heather – UX는 그저 우리 게임의 다른 의견일 뿐, 네가 제공하는 그 의견은 마케팅 담당자의 의견에 비해 그 이상 그 이하의 값어치도 지니지 않아.
Celia – 게임 개발자들은 여러 의견들을 확실히 다뤄야만 하지; 게임팀 안으로부터, 마케팅팀으로부터, 퍼블리싱 팀으로부터, 경영진, 등등. 그렇기 때문에 너는 UX피드백을 다른 네가 다뤄야하는 의견들마냥 인식할 수 있을거야. 어찌나 귀찮은 일인지! 하지만, UX 프로세스는 엄격한 리서치를 통해 가설을 검증하고 분석을 통해 문제를 예측하는걸 의미해. 여기서 실제로 UX 전문가는 의견을 주지 않아. 우린 뇌에 대한 그들의 지식과 과거 경험, 그리고 가용한 데이터에 기반한 분석을 제공하지.
Heather – 우리는 UX를 할 시간따윈 없어. – 우리는 실제 게임을 만들어야만 한다고! 우리의 돈은 아트나 프로그래밍같은, 더 나은 곳에 쓰여야 해.
Celia – 네녀석들은 QA테스팅같은걸 말하지 않는다는게 재밌네. 분명히, 너는 버그없이 게임이 출하할 수 있도록 보장하기 위해 시간과 돈을 투자하지. 그렇다면 어떻게 UX문제가 덜한 게임을 배포할 수 있을까? 만약 네 게임이 치명적인 UX 문제를 안고 배포되었다면, 그건 네 판매에 영향을 미칠테고 모두가 슬플거야: 게임이 원한만큼 달성하지 못한 개발팀, 수익을 내지 못하는 경영진, 게임에 좌절한 플레이어들... UX 프로세스는 투자야: 네 스스로에게 UX를 생각할 여유가 있는지를 묻지 말고, 여유가 없는지를 물어봐.
Heather – 그래, 좋은 지적이야. 그럼, 나중에 게임에 UX를 하자. 우리가 준비가 되면 말이지.
Celia – 그런 마음가짐으로 했다간 어떻게 되는지 알지? 팀은 폐쇄된 원 안에서 빙빙 돌기를 반복할 거고, 우린 멀리서 반복 프로세스에 앞서 도움을 줄 수 있는 걸 알면서도 멀리서 지켜만보게 될거야. 어느 순간이 되면, 우린 그걸 억제할 수 없게 되어버려: 우린 네가 테스트와 협업을 시작하자고 요청하는걸 포기하게 되겠지. 대게의 경우, 우리가 듣는 대답은 '아직 준비되지 않았아요'이고, 게임은 엉망진창으로 망가져있지.
위험한건 게임이 출시되기 전에 할 수 있는 빠른 패치들만 이행할 수 있을 때, 그제서야 테스트와 평가가 지나치게 늦게 끝마치게 되는거야. 그래서, 이미 만들어진 게임에 관한 구조와 중요한 결정이 내려진 후에 어느 시점에 이르면 나는 유감스럽지만 "이걸 UX"할 수는 없게 되어버려. 그나저나, "UX"는 심지어 동사도 아닌데...
Heather – 그래, 그래. 알았어. 하지만 내 시점에서 생각해보면... 이건 내가 처리해야만 하는 일들이야.
Celia – 개발자들은 UX의 모든 중요한 세부요소들을 제대로 이해하지 못하는 것 같아.
Heather – 그들이 UX 박사학위를 받기 전까지는, 설계자(기획자)는 플레이어가 게임과 상호작용하는 쉬운 방법이 좋은 게임 디자인의 일부라고 이해해. 개발팀은 UX 피드백을 듣는걸 원하지 않을 수도 있는데, 그 이유는 음, 네가 기획자가 아니기 때문이야. 하지만, 대부분의 시간동안 개발팀은 그저 바쁘게 모든걸 함께 쑤셔넣고, 그리고는 UX피드백을 듣기 위한 약간의 정신적 공간을 비워두지.
Celia – 개발팀은 우리랑 일하기를 원치 않아 – 너는 우리를 골칫거리라고 생각하지!
Heather – 난 골칫거리라고 말하지 않을게... 대부분의 개발팀은 궁극적으로 플레이어들을 위해 게임을 더 낫게 만들 수 있는 자원을 활용하는걸 좋아해. 만약 둘 모두 잘 굴러가는 프로세스라면, 개발팀은 UX와 일하는걸 좋아할거야. 진짜 문제는 네가 지나치게 구체적이거나 개발 프로세스 상의 것에 해당하지 않는 피드백을 제공한다는거야. 우린 개발 사이클에 주어진 시간동안 유용한 피드백을 조정하려고 해. 또한, UX가 개발팀이 함께 일하는데 익숙하지 않다면, 관계가 제대로 작동하게 하는데 시간이 필요할거야.
Celia – 개발팀은 언제나 UX 테스트를 할 시간이 없다고 핑계대곤 해. 이건 네 부분 중 많은 시간을 요구하지도 않아. – 우린 모든 테스트와 리포트를 처리할 수 있다고!
Heather – 결국 좋은 UX 프로세스가 개발팀의 시간을 절약해준다는건 인정해. 하지만 초기에, 프로세스에 UX가 붙ㅇ는건 더 많은 시간을 요구하잖아. 너 테스트에 할당해야만 하고, 피드백을 리뷰잉하면서 추적도 해야하고, UX 프랙티스를 팀에 교육하고, 기타 등등 말야. 그건 일정에 통합될 필요가 있고, 그게 안되면 그건 무시될거야. UX를 개발 프로세스에 통합시키는 것은 밤을 샌다고 되는 일이 아니고, 그저 신발끈을 묶는 프로세스라는걸 알아둬야 해. 너는 팀을 준비시키고, 지원받고, 그걸 점진적으로 소개할 수 있는 방법들을 찾아내야 해. 그저 테스트를 하고 리포트를 작성하는건 사실 실제론 UX를 우리 프로세스로 통합시키는게 아니야.
Celia – UX피드백을 구현하는건 딱히 어렵지 않다고! 그저 우선순위의 문제지. 맞지?
Heather – 네 팀은 게임을 어떻게 개선시킬 수 있는지에 대한 훌륭한 제안을 제공해줄 수 있어. 이런 발견과 제안은 구현하기 쉬워보일 수 있겠지만, 실제론 나는 이것을 개발 과정의 다른 피드백으로 취급하고 다른 모든 우선순위에 대해 따져봐야 해. 텍스트를 다시 쓴다거나 컬러를 바꾸는건 쉬운 일처럼 보이지만, 누군가에게 맡겨지고, 수행되고, 테스트되어야 하지. 많은 변화일수록 더 많은 관련자들을 필요하게 되고, 더 많은 테스팅, 더 많은 통합, 등등. UX 변화는 구현하는데 큰 일이 될 수 있어. 특히 플래닝이 완료되어있다면 말이지.
Heather – 궁극적으로, UX팀은 제작에서 고려해야할 또다른 투입요소이야. 관건은 어떤 투입물이 그 과정에서 어떤 포인트에서 게임팀에 가장 큰 가치를 갖게 될지를 결정하는 것이지. 개발팀은 또한 경영진과 마케팅팀이 원하는 바에 대해 UX 피드백을 우선순위화 하는 방법을 이해할 필요가 있어.
UX가 데이터에 기반하기 때문에, 구현하는데 있어 언제 어떤 피드백이 유용한지를 결정하는건 더 쉬워지지. 그리고 한 번 구현하고나면, 그것이 원하는대로 영향을 미쳤는지를 재시험할 수 있어. 이처럼, 관계로부터 모든걸 끌어내기위해 개발 과정을 통해 함께 일하는건 말이 되는 이야기지.
너희팀이 할 수 있는 가장 중요한건 우리의 신뢰를 얻는 일이고, 그 반대도 마찬가지야.
Heather – 내가 나의 작품을 말하고 개발팀을 대표했으므로, 이제 Celia가 개발팀과 UX 사이에 다리를 놓기 시작했을 때 일어난 변화에 대해 말할거야. 내가 그녀의 범죄 파트너로 있지 않았기 때문에, 그녀는 첫 해동안 혼자서 이것에 직면해야 했어. 그녀는 이 관계를 만들놓기 위해 많은 기반공사를 했지.
Celia – 음, 네가 먼저 이러한 오해들을 극복한걸 얘기했으니 "우리"가 새로운 파트너인 외계인으로서 UX 사람들이 뗐던 첫 발자국에 대해 논해보려고 해. 나는 사용성 가이드라인과 관련된 팀을 맡는걸 그만둬야했고 개발중에 일어나는 명백한 UX 규칙 위반마다 매번 성가시게 하는걸 그만둬야 했어.
대신, 나는 "UX를 UX"하려 했지: 나는 팀의 의견을 듣고(내 청중), 그들이 필요한게 뭔지를 이해하려 했으며(내 청중의 의도된 경험), 그리고 그들의 관점을 이용해서 해야할 일을 성취해냈지. 이 파트는 그 여정을 기록한거야.
Celia – 내가 Fortnite에서 했던(그래, 내가 UX 팀의 일원일 때말야) 첫 사용성 테스트와 리뷰는, 준비되지 않은 것들과 제대로 동작하지 않는 것들에 대해 팀이 이미 알고 있을때, 두목행세하는 것처럼 보였었어. 나는 그저 공을 굴리고 파이프라인을 시작하려고 할 때, 프로세스는 뻔한걸 명시할 뿐인 것처럼 보였고 몇 개발자들은 무엇이 잘못되고있는지를 경영진에 보고하기 위한 "권한"으로서 나를 대해야만 했어. UX는 개발팀에게 그 가치를 입증하기 전에 지나치게 열심히 프로세스를 진행하려고 했지. 나는 초기에 너무 열심히였기 때문에, UX의 가치를 입증하기 위해 언제든 모든걸 테스트하려고 했어. 난 서서히 "사용성 경찰"이 되어가고 있다고 느끼기 시작했지. 날 믿어봐, 너무 짜증나게 되고 싶지 않으면 말야.
Celia – 당시 나는 몇몇 UX 옹호자들의 도움을 받아서 프로젝트가 어디쯤 와있는지 살펴보고, 기획자들에게 그들의 의도에 대한 이해, 그리고 경영진의 사업 플랜에 대한 이해를 물었어. 그런 뒤, UX 테스트가 시행되거나 UX 측정이 이뤄졌지. 대화를 시작하고 무엇이 기획에 따른 것이고, 무엇이 이미 파이프라인 상에서 고쳐졌고, 무엇이 새로운 UX문제인지를 이해할 수 있도록 기획자로부터 피드백을 받기를 바라면서 모든 이슈의 거대한 리포트에 살아숨쉬는 UX가 제공되었어. 하지만, 리포트의 양이 너무너무너무 많았어.
문제는 그들이 잘 모르는 팀의 일원으로부터 리포트가 보내졌다는 것, 그리고 UX에 관심이 있는 몇몇 기획자를 제외하면 나는 그 어떤 개발자와도 논의할 기회가 전혀 없었다는 거야. 그래서 결국, 개발팀은 이 전체의 것들에 대해 특별히 흥미로워하지도 않았고, 그 어떤 연결도 만들어지지 않았으며, 나는 개발팀의 플랜에 대한 전체 그림을 가지지 못했지.
Celia – 그래서 나는 UX에 관심있어하는 기획자를 데리고 팀을 꾸렸고, 그리고 우리는 전체 경험의 큰 리뷰를 하는 것 대신, 메인 이슈와 도전거리들에 대해 조잘거렸지. 이건 보다 맞춤화된 UX-개발자 관계의 출발점이었어. 그때, 팀에는 UX기획자가 없었기 때문에 나는 몇 UX 설계 도전거리들을 도왔어. (예컨대 경영진과 의사소통할때 그들의 비전을 돕기 위한 가벼운 목업같은 걸 만들어낸다거나.) 우리는 또한 기획자들은 UX 프로세스에 참여할 수 있도록 아주 구체적인 설계 질문을 갖고 작은 것들을 테스트하기 시작했어.(아이콘, HUD, 코어 루프, 기타등등.)
왼쪽의 그림은 3년 전에 기획자의 메타게임의 비전을 내가 빠르게 대충 그린 일러스트레이션이고(내 아트... 'ㅅ';; ) 오른쪽은 오늘날의 Fortnite의 홈베이스야. 나는 분명히 UX 설계자는 아니지만 기본적인 파워포인트 기술들을 사용했고 모두가 설계 방향을 시각화할 수 있도록 함께 물건들을 집어던져가며 만들었지.
Celia – Epic이 UX 연구소를 지을 준비를 할 때(그 큰게 꽤 빨리 만들어지더라), 개발팀이 그들의 책상에서 지켜볼 수 있도록 우리가 테스트를 스트리밍하는걸 많은 사람들이 원했어.
나는 거절했지. 난 UX 비밀의 방이 우리가 물리적으로 동영상 플레이어의 뒤에 있지 않으면서, 농담을 건내면서 아이디어를 교환할 수 있는 장소가 되는걸 원했거든. 플레이테스트를 본다는건 (개발팀이 멀티태스킹을 하는 동안 할 수 있는 것이 아닌) 별도의 해야하는 일이자 (다른 개발팀 인원들과 UX 팀 인원들 간의) 사회적 경험이 되었지.
그러므로, 그 비밀의 방은 철저하게 방음되었고 멋진 분위기를 갖게 되었어: 우리가 어울리고 심지어 파티도 할 수 있는 곳이 되었지.(한 달에 한 번, 나는 UX 연구소에서 파티를 열었어. - 하지 말아야 할 이유가 없으니까.) 이렇게해서 UX테스트는 프로세스 상의 재미있는 측면이 되었지. 뭐 그래. 네 기획의도를 알지 못하는 플레이어를 보는건 꽤 힘든 일이지만, 캐주얼하고 친근한 환경에서 하는건 훨씬 더 나은 결과를 만들었어.
물론, 그런 화려한 연구소를 지을 수는 없겠지만, 더 싸게 할 수 있는 방법도 있어: 플레이테스트 참가자들을 집어넣고 다른 방으로 녹화해서 스트리밍하는 방같은 거 말야. 가장 중요한 건 개발팀이 테스트를 수행하는 사람 중 한명이 되어선 안된다는거야. 네 스스로 편향을 제거할 수는 없기 때문에, UX 연구자를 고용하지 못한다면, 실험심리학 인턴이나 네 연구를 수행할 Human Factors 인턴을 알아봐. 그걸 할 수 있는 사람을 못구한다면, 꼭 Games User Research 사람들에게 테스트를 돌리는 방법에 대해 몇가지 조언을 요청하도록 해. 그들은 링크드인과 트위터에 있으니까, 도움받기 쉬울꺼야.
Heather – 그 변화가 있을 때 나는 Epic에서 일하기 시작했어. 나는 내가 일했던 이전 게임들을 바탕으로 UX의 가치를 이해했었고 Epic이 완전한 UX부서를 갖고 있다는데 완전히 신났었지! 개발팀이 왜 UX를 불편해하는지를 이해하고 싶기도 하고, 어떻게 우리가 프로세스를 개선할 수 있을지 알아내고려고 했어. 개발 초기에는 개발자들이 UX 피드백의 가치를 알아보지 못했지. 개발팀은 게임이 아주 러프하고 많은 피처들을 실험하고 있던걸 알았었어. UX는 기획자가 테스트를 할 준비가 되었다고 느낄때가 되어서야만 할 수 있는 것처럼 보였고, 다른 형태의 피드백처럼 취급되었지.
Celia – 그들은 UX피드백이 더 중립적이고 과학적(제대로 했을때에 한해서)이란 걸 완전히 깨닫지 못했어. UX피드백은 다른데, 왜냐하면 UX 전문가들은 HCI(휴먼-컴퓨터 인터렉션) 문제와 그걸 고치는데 필요한 인지/실험 심리학과 Human Factors 교육을 받았거든.
Heather – 개발팀은 또한 제공되는 정보들의 양에 압도되어버렸어. 거대한 스프레드시트에서 추적된 리포트 페이지들과 모든 피드백들이었지. 개발팀은 그 피드백을 모두 소화해내고 어떤게 게임에 적용되어야할지(그리고 언제 적용할지)를 결정하기에는 시간이 부족하다고 느꼈어.
Celia – 맞아, UX리포트들은 확실히 압도적이긴 해. 하지만 우린 철두철미 하고싶었어! 어쩌면 너무 많았을런지도 모르겠네. 적은게 더 많은건데. UX세계에서조차도 목표 테스트는 확실히 더 실용적이고 덜 압도적이거든.
Heather – 개발팀이 마일스톤을 마치려고 빠르게 일을 해내고 있었기 때문에, UX 피드백은 높은 우선순위로 검토되지 않았어. 리포트는 만들어질테지만, 때때로 심층적으로 검토되지 않을 수 있지. 피드백을 검토할 때, UX테스트가 있었던 때로부터 게임 상 굉장히 많은게 바뀌어버렸기 때문에 개발팀은 유용한 걸 찾아낼 수 없었어.
Celia – UX피드백은 다른 피드백들보다 가장 중립적이고 과학적이기 때문에, 가장 우선순위에 둬야 해(제대로 했다면 말이지). 그건 개발팀을 한걸음 물러나게 하고 그들의 게임을 다른 -적은 바이어스를 가진 - 관점으로 바라보는데 도움이 될거야.
Heather – 새로운 프로세스/시스템을 개발 파이프라인에 억지로 밀어넣는 걸로 UX에 접근하는 대신, 우린 UX를 팀의 일원이라고 생각하기 시작했어. 우린 그들이 기획 의도를 알고 게임의 현재 부딪힌 문제에 따른 그들의 피드백을 조정할 수 있도록 팀의 일부분으로 느끼게 하려고 했지.
Celia – 이상적으로, 너는 UX가 게임과 일정한 거리를 두고 개발팀과 가깝게 되길 원하고 있지. 그게 아니면 우린 게임과 지나치게 가깝게 되어버려서 우린 바이어스를 갖기 시작하게 될거야.
Heather – 팀을 UX의 아이디어에 익숙하게 만들게 하기 위해서, 우린 서로를 알아야만 했어. 개발팀이 이 관계강화에 딱히 흥미있어하지 않았기 때문에, UX팀은 개발팀의 관점에 맞춰서 개발팀과 일하는 방법을 찾았어. UX는 개발팀에게 손쉽게 이용 가능한 자원이 되도록 만들었지. 누군가가 Celia의 팀과 이야기하고 피드백을 얻는데는 거의 마찰이 없었어. 팀원이라면 누구든 자유롭게 사용할 수 있었지. - 그어떤 고생스러운 일도 필요치 않았어. UX실은 모두를 위해 정중앙에 위치했고 문은 언제나 열려있었어. 프로덕션은 UX를 전도시켰고 그들의 일을 개발팀에게 더 눈에 띄게 만들었지(간단한 것들 - 연구소에서 컨설팅 미팅을 한다는걸 사람들에게 상기싴고, UX테스트를 볼 수 있도록 사람들을 초대하고, 팀 미팅에 Celia를 초대하는 등 말이야). 게임이 통과해야만 하는 또다른 관문이 되지 않으면서, Celia가 구축하고 개발팀에 UX가 팀의 일부가 될 수 있는 방법을 보여주는걸 꾸려내는게 중요했어.
Celia – 전사 혹은 게임팀에 UX를 강요하는 것 대신, 나는 먼저 개발팀에 귀를 기울였고 UX에 관심있어하는 이들과 파트너가 되었지. 덜 주목받는 작은 프로젝트를 선택했어. 그건 우리를 설계-테스트-반복-다시 테스트하는걸 매우 빠르게 진행시킬 수 있게 해서, 우리는 빠른 승리를 만들어 낼 수 있었지. 이 승리들은 다른 팀들에게 인정받을 수 있었고 UX 사랑이 퍼지기 시작했어. 그나저나, 이 일러스트는 UX프로세스가 작게 시작하는게 실제로 유리했었기 때문에 작은 팀들이나 스튜디오들에게 쉽게 효익을 낼 수 있는 방법을 보여주고 있어. 점차적으로, 몇 번의 UX 테스트를 마치고 몇몇 좋은 결과를 본 뒤에, 팀은 UX가 그들을 도울 수 있는 방법에 대해 감명받았고, UX는 그저 누군가의 UX팀이 아닌 모두의 관심사가 되었지. UX 팀은 누구나 이용할 수 있는 자원이 되었고 UX 설계자(Derek Diaz)는 Fortnite 팀에 고용되었어. 우린 개발 파이프라인의 일부가 되기 위해 UX를 계획하기 시작했지.
Heather – 내가 Celia와 일하기 시작했을 때, 그녀는 이 스프레드시트의 모든 UX 피드백을 추적했어. 그 당시, 이건 가장 효과적인 방법이었지. 보다시피 상당히 밀도가 빡빡해. 팀에게 주어진 UX피드백, 우선순위, 언제 구현되었는지, 그리고 혹시 재테스트가 되었는지를 추적해. 이 시트는 UX와 게임팀 간에 주 정보전달로써 사용되었는데, 개발자가 이 프로세스를 이끌거나 유지하지 않았기 때문에 주로 UX를 위한 도구였어.
이 일은 초기엔 잘 되었어. 게임에는 몇가지 쉬운 해결책이 있었지. 하지만 몇달 후가 되자, 200개가 넘는 항목이 추적되고 있었고, 그것들 중 극소수가 다뤄졌지 -혹은 언젠가 할 일로 표시되어있었거나.
Heather – 내가 Epic에서 일할 때말야, 난 이게 UX가 하는 모든 일에서 일방통행같은 대화가 보였어. 프로세스는 제대로 정의되거나 일관되지 않았고, 그래서 UX가 무작위로 일어나는 것이란 인상을 주었어. 개발팀은 정기적으로 UX와 이 시트를 검토하려고 했지만, 그건 개발 프로세스의 필수 부분이 아니었지. 개발팀에 명확한 오너가 없었기 때문에 게임에 게임에 적용된 변경점을 알기가 어려웠고 UX에 다시 테스트해달라고 돌아오는 커뮤니케이션이 되었어.
그리고 그건 걷잡을 수 없게 되어버렸어! 팀의 누군가가 이걸 독립적으로 검토하고 정보를 분석하고 계획 상 다음 라운드를 위해 고려하는데 무엇이 중요하고 유용한지를 결정하는건 아주 힘들었지. 그래서 그들은 그걸 무시하는 경향이 있었어.
Heather – Ceila와 내가 함께 일하기 시작했을 때, 그녀는 프로세스를 정의하고 운영하는데 혼자가 아니었어. 우린 우리가 가진걸 개선하고 우리가 가진걸 개선하고 UX를 더 개발 프로세스의 필수적인 부분이 되도록 만들기 위해 협력할 수 있는 방법들을 논의했어. 관계가 최상으로 작동하게 만들기 위해서, 우리의 릴리즈에 싱크가 맞게 우리의 프로세스가 작동하길 원했어. Fortnite에서, 우리는 매 6~8주마다 온라인 테스트가 릴리즈하는걸로 시작했고 릴리즈 간의 시간을 줄여왔어. 우리는 온라인 테스트에서 릴리즈된 새로운 콘텐츠에 어떤 효익을 가져다 줄지를 결정하기 위해 UX와 긴밀하게 협력해.
Heather – 우리는 프로세스를 개조하고 팀의 가치를 높이기 위해 매주 미팅을 갖기 시작했어. 우리는 변경이 필요한 프로세스의 부분을 골라냈지. 가장 첫번째로 우리가 한 일은 스프레드시트에 있는 UX정보들을 죄다 JIRA로 변경하는 일이었어. 이를통해 팀은 즉시 더 쉽게 접근할 수 있었고 UX는 우선순위 스택에서 더 쉽게 보여지게 되었지. 이건 UX대시보드의 스크린샷인데, 구현해야 할 것, 우선순위를 위해 분류가 필요한 것, 그리고 다시 테스트해야 할 것을 보는데 사용한거야.
Heather – 우리는 또한 두 팀 간에 접점을 늘리기 위한 몇가지를 구현했는데, 덕분에 우린 목표와 우선순위를 더 밀접하게 조정했어. 우린 향후 6개월간 릴리즈할 메이저 마일스톤을 보고 테스트할 피쳐들의 우선순위를 정의했지. 우린 게임의 우선순위에 맞게 UX 우선순위를 자세히 조정해서 테스트하는 것에 가치가 있게 하고 있었어. 우리는 게다가 키 마일스톤을 위한 UX 테스트 목표들을 정의했어. 우리는 개발에서 어떤 지점에서 테스트가 이뤄지는지, 그리고 어떤 유형의 테스트가 이뤄지는지(3일짜리 UX 테스트 vs 1일짜리 UX 테스트)를 공식화했어.
UX테스트는 개발 일정의 일부였고 개발팀에 배포되었지. 팀들은 이제 이런 지점들에서 UX테스트를 위한 계획을 해야만 한다는걸 알았지. - 제대로된 방향으로 한 걸음을 내딛었어! 우린 팀들을 UX테스트에 초대하는데 노력을 기울였고(다른 사람들이 네 게임을 플레이하는걸 보는건 진짜로 가치있는 일이야), 그들이 UX를 초기에 그리고 이따금씩 자원으로써 사용하도록 했지.
Heather – 이건 우리가 Fortnite에서 UX/개발 파이프라인으로 사용하는 현재 프로세스야. 우리는 라이브게임이기 때문에, 이 프로세스는 플래닝, 피쳐만들기, 테스팅, 구현 피드백, 그리고 재테스트를 포함하는 하나의 전체 릴리즈 사이클을 다루고 있어. 우리는 세밀하게 조정하고 UX 서포트는 우리의 개발 프로세스 안에서 더 필수적이 되지.
자세한 내용은 아래와 같아.
Celia – 이는 팀이 다음 온라인 테스트에 대한 가설을 특정할 때 시작된다. 개발팀, 분석팀, 마케팅팀 혹은 경영진으로부터 질문이 들어와. 우린 답변해야할 질문을 결정해(테스트를 계획할 때는 항상 목적을 갖는게 중요하지).일단 질문이 정의되면, 그에따라 UX팀은 실험적 프로토콜을 준비해. 우리는 범위를 갖고 실험을 조정해. 때때로 우리는 라이브빌드로 긴 세션에서 밀어넣는 테스트하기도 하지만, 프로토타입으로 더 짧고 빠르고-지져분한 테스트를 하기도 해(종이로 한다거나, 상호작용가능한 프로토타입이거나, 심지어 때때로 에디터에서 직접 해보거나).
Celia – 주어진 테스트의 포커스와 프로토콜에 따라, 우리는 언제/어떻게/누구에게 테스트를 할지를 계획하고 어떤 빌드를 사용할지를 결정해.
Heather – 테스트 요구항목들의 밑그림이 그려지면, 나는 팀들과 어떤 빌드를 사용할지를 계획해. 우리는 우리가 테스트하고자 하는 피쳐들이 제대로 작동하는지를 확인할 필요가 있어. 만약 빌드가 망가진다면, 테스트는 취소돼. 그렇기때문에 우리는 이틀 전에 그 빌드를 검토해서 그것이 준비가 되었는지 안되었는지를 결정해. 만약 준비가 안되어있다면, 테스트는 취소되거나, 준비가 안될 것 같다면, 범위를 재조정해. 만약 팀이 테스트에 대해 몇 주 전에 먼저 안다면, 안정적인 빌드를 얻기 위해 그들의 작업과 버그들을 우선순위화하는게 그들에게 훨씬 더 쉬워지지.
Celia – UX테스트가 실행되고 팀이 실시간으로 실험 참가자를 관찰해. 우리는 팀을 초대해서 관찰하게 하지.
Heather – 그리고 나는 팀이 자유롭게 그들을 관찰할 수 있도록 그날에는 미팅 일정을 잡지 않도록 하지.
Celia – 테스트가 끝나면, 우린 데이터를 분석하고 자세한 UX리포트를 제작해. 하지만 이 시간에 더 집중하지.
Celia – 리포트를 제출한 뒤에는, 우린 리포트를 함께 흝어보는 빠른 미팅을 계획하고, 우리끼리 조정된걸 확인하고, 팀은 등장한 이슈에 대한 피드백을 직접 우리에게 줄 수 있지.
각 이슈에 대해서, 기획의도대로 되었기 때문에 그대로 둘지, UX팀이 JIRA에 넣도록 콜아웃이 필요한건지, 이미 수정된 것이므로 나중에 재테스트하기 위해 팔로우업해야할지 등등를 함께 결정해. UX연구소가 JIRA에 들어가면, 우리는 우리가 테스트에서 관찰한데 대한 설명, 위반한 사용성 휴리스틱 설명(예컨대, 일관성 위반이라든가, 이 항목의 형식이 기능했어야 할 것과 다른 식으로 지각되게 전달되었다든가, 기타 등등)같은 자세한 정보를 입력해. 우린 UX테스트에서의 스크린샷과 비디오를 첨부해. UXLabFeedback이라는 태그를 달아서 UX와 관련된 모든 이슈가 대시보드에서 나타나게 하지. 모든 새로운 UX 테스트 전에, 우리는 대시보드를 참고해서 어떤 이슈가 고쳐졌는지를 보기 때문에 UX 이슈가 실제로 해결되었는지를 확인할 수 있어.
Heather – UX가 JIRA에 입력하고나면, 긴급도 분류 프로세스(triage process)가 개발팀에게 그것들을 검토하고 그 이슈가 다음 릴리즈에 해결할지, 미래의 릴리즈에 해결할지, 혹은 아예 안다뤄질지를 결정하는 방법이 돼. 만약 팀이 어떤 UX 피드백에 동의하지 않거나 우선순위를 바꾸고자 한다면, 그들은 그 옵션을 논의하기위해 UX 연구소와 미팅을 잡아야 해. 두 그룹이 합의하면, 그 작업은 개발 일정 안에서 적절하게 우선순위화 되지.
네가 상상하다시피, UX팀이 Pri-1이라고 표시해둔 어떤 것은, 팀에게 낮은 우선순위로 간주될 수 있어. 몇몇 피드백은 당장 해결할 수 없는 큰 재작업을 요구하기 때문에 미래 계획의 일부가 되어야만 하지. 일부 피드백은 기획 의도에 반대되기 때문에 문제를 해결하는 방법에 대해 UX와 긴 대화를 필요로 하지. 스트라이크 팀의 리더들은 피드백을 검토하고 그어떤 질문이나 의견 불일치에 대해서 UX와 추가 대화를 시작하게할 책임이 있어.
// 역자 주: 유비소프트를 포함한 미국 게임회사에서는 스트라이크 팀이라는 해결사 집단이 있습니다. 관련 내용은 https://www.gamasutra.com/view/feature/130808/postcard_from_gdc_europe_2005_.php을 참고하세요.
Heather – UX작업이 완료되면, 우린 JIRA 이슈를 클로즈로 표시해서 Celia의 팀이 다음 테스트에서 재확인할 수 있도록 해.
Celia – 데이터는 다른 소스들(분석팀, 고객지원팀, 마케팅팀, 알파 참가자들에게 냈던 UX 설문들 등)로부터 크로스체크되고 팀에게 다시 알려줘서 그들이 UX를 개선시킬 계획을 세울 수 있게 하지.
그러면, 우린 경영진과 퍼블리싱팀에게 관련 정보를 전달하고 개발팀은 이미 제기된 이슈를 고치기 위한 계획을 공개할 수 있지. 이건 상호협력적인 프로세스(collaborative process)야; 우린 퍼블리싱팀이나 경영진에게 절대 개발팀과 싱크를 맞추지 않은 피드백을 직접 주지 않아. 갑작스런 뒤통수치기나 서프라이즈같은건 없지. 우린 개발팀이 그들의 목표를 달성하는걸 서포트하기위해 여기에 왔지, 지 혼자 잘난 잘난척쟁이들처럼 굴려고 온게 아냐.
또한, UX팀은 중립적이기 때문에, 유저와 씨름하는 것 외에는 그 어떤 아젠다도 제공하지 않아. 덕분에 그 공간에 있는 모든 사람들이 게임에 대한 개인적인 관점과 의견을 재조정하는데 도움이 되지(그래, 이게 언제나 성공한다고는 말하진 않겠어).
마지막으로, 게임에 있는 이슈들뿐만 아니라 개발팀이 지금까지 만들어오고 해결한 UX이슈의 모든 과정을 UX팀이 강조하는게 가장 중요해. 경영진은 뭔가 진행되고있는걸 보는걸 아주 좋아하니까(그리고 이슈가 지적될 때 그것들이 관리되고있다고 안심하기도 하고 말야). 개발팀은 우리가 얼마나 많이 진척되었는지를 알려주는걸 완전 좋아하고, 이렇게 모두가 행복해지지. 대부분의 경우 그렇다는... (게임 개발을 한다는건 결국 모두에게 힘들고 감정적인 노력이 드는 일이야.)
Heather – 우리는 통합되고 정의된 프로세스를 가지고 있지만 여전히 일이 필요해! 첫 번째 부분은 잘 작동하니까, 이제 우리는 긴급도 분류(triage)와 검증 단계를 개선하는데 초점을 맞춰야 해. 프로듀서들은 JIRA가 업데이트되고있게 해야 하고 팀은 활발히 UX이슈들을 붙들고있어야 해(그리고 그냥 다음 마일스톤으로 그것들은 마킹하고 넘기지 말고 말야). 만약 걸러지지 않고 적절히 조정되지 않는게 있다면, 그건 가시성을 잃게 돼. 두 팀 모두 UX피드백이 언제 구현될지를 더 잘 이해해야 재 테스트가 될 수 있어. 그건 재테스트를 하고 이슈가 해결되었다고 보이기 전까지는 제대로 고쳐지지 않아. UX의 높은 가시성을 확보하고 유지하기 위해서, 개발팀 인원들은 UX테스트를 관찰해야 할거야. 그리고 더 좋은걸 만들기 위해 워크플로우와 프로세스를 조정하는데 항상 열려있어야 해!
네가 상상하듯, 처리해야할 일들이 여전히 있지만, 우린 먼 여정을 해왔어! 우린 서로에 대해 많이 배웠고 두려운건 줄어들었지. 이 모든건 관점의 문제야.
그리고 지금, UX은 프로세스의 진정한 일부가 되었어...
Heather – 잘못된 생각에 대해 그게 틀렸다는걸 드러내자. 서로 두려워하지 말자!
Celia – UX의 빠른 승리를 보여주려면 UX에 관심있어하는 개발자들로 작게 시작해.
Celia – UX 경찰이 되지 말고, 대신 성공을 위해 함께 일하고, 프로세스를 진단하고 커뮤니케이션하자.
Heather – 강한 피드백과 구현 루프를 수립하고 두팀이 프로세스가 작동하는 방식에 대해 확실히 이해하게 하자. 필요에 따라 조정하고.
Both – 함께 축하하자!
