[번역] 에픽 게임즈의 프로덕션 파이프라인에 UX를 도입한 방법

원문: https://celiahodent.com/how-we-introduced-ux-to-epic-games-production-pipeline-gdc16/

이번 번역은 구어체입니다.

GDC 발표를 2명이서 대화하듯 풀어냈던 세션입니다. 이를 논문식으로 번역하다보니 생동감이 없고 부자연스러워서 구어체로 변경했습니다. 

---

These are the slides from the my GDC 2016 presentation with Heather Chandler, Senior Producer on Fortnite (Epic Games). Therefore, this presentation is about both UX’ (Celia) and Prod’s (Heather) perspectives. You can watch the video of this presentation here. Also, if you’re interested in UX, go check our Game UX Summit happening on May 12th 2016 (we have an amazing lineup! :) ).

이 슬라이드들은 Fortnite (Epic Games)의 수석 프로듀서인 Heather Chandler와 함께한 내 GDC 2016 발표에서 나온 슬라이드들이야. 따라서 이번 발표는 UX 부서(Celia)와 프로덕션(Heather)의 관점에서 설명하고 있지. 이 프레젠테이션의 비디오를 여기서 볼 수 있어. 또한 UX에 관심이 있으시면 2016년 5월 12일에 열리는 Game UX Summit을 확인해보기 바라. (놀라운 라인업이 준비되어있다고! ^^) 

// 역자 주: 게임 UX 서밋의 링크가 망가져있으므로 링크를 해제해놓았습니다.

 

 

UX Perpective (Celia) – The influence of User Experience is growing in the gaming industry. UX professionals – who are now well established in industrial design and many tech companies – are eager to start working with the video game industry.

Prod Perspective (Heather) – However, many teams see UX as a threat – weird aliens are invading and making a mess. Why did we need them again? We were doing fine without them (or so we thought). This is kind of what happened at Epic and the purpose of this talk is to provide both perspectives, so there is better understanding between development and ux. If we understand each other we get more out of the relationship. The relationship got off to a rocky start – the UX team was pushing to do a lot of testing early in the process, so they could acquire useful insights; but the production team thought there were bigger challenges to deal with – they already knew there were UX issues, but were planning to fix them later.

UX 관점 (Celia) – 게임 산업에서 사용자 경험의 영향이 커지고 있어. 현재 산업 디자인과 많은 기술 회사에서 잘 자리를 잡은 UX 전문가들은 비디오 게임 산업과 함께 일하기를 열망하고 있지.

프로덕션 관점 (Heather) – 그러나 많은 팀들은 UX를 위협으로 보고 있어 – 요상한 외계인들이 침입하여 난장판을 만들고 있는 것처럼 말야. 왜 우리가 그들을 또 필요하다는거지? 우리는 그들 없이 잘 지내고 있었어.(적어도 우린 그렇게 생각했지.) 이것은 에픽에서 발생한 일이고, 이 토크의 목적은 개발과 UX 사이에서 더 나은 이해를 할 수 있도록 양쪽 관점을 모두 제공하는데 있어. 만약 우리가 서로를 이해한다면 우리는 그 관계에서 더 많은 것을 얻을거야. 이 관계의 시작은 험난했지. – UX 팀은 유용한 통찰력을 얻을 수 있기 위해 프로세스 초기에 많은 테스트를 실시하려고 밀어붙였지만 프로덕션 팀(제작진)은 더 큰 문제를 해결해야 한다고 생각했어. – 그들은 이미 UX 문제가 있다는 것을 알고 있었지만 나중에 해결할 계획이었지.

 

Before we start, here’s a quick explanation of how Epic Games is structured: we have multiple product teams as well as support/operation teams since Epic is self-published.

There are UX designers within product teams, but the UX team provides extra help on UX design if needed and provides the tools, methodology, and knowledge to conduct UX analyses and UX research. The UX team is supporting all of these product teams.

Fortnite was the pioneering team that first started to work with UX. Fortnite is currently live in its Alpha stage – it’s an action-building game with RPG mechanics. 

 시작하기 전에, 에픽 게임즈가 어떻게 구성되어 있는지에 대해 간단히 설명해줄게. 우리는 자체 퍼블리싱을 하기 때문에 지원팀과 운영팀을 비롯해 여러 제작팀을 보유하고 있어.

제작팀에는 UX 설계자들이 있지만, UX 설계가 필요하다면 UX팀이 추가 도움을 제공하고, UX 분석과 UX 연구를 수행하기 위한 도구, 방법론, 지식을 제공하지. UX팀은 모든 제작팀을 서포팅해.

Fortnite는 UX와 초기부터 협업한 첫 번째의 선구적인 팀이었어. Fortnite는 RPG 매카닉을 가진 액션게임이자 빌딩게임으로써, 현재 알파 단계에서 라이브를 하고 있어.

 

Let’s start by discussing misconceptions.

In many ways, UX is a hedgehog that wants to hug the dev team and be loved and helpful. From the dev team perspective though, the spikes aren’t appealing and this new creature is suspicious. But it’s all a matter a perspective. Let’s start from the UX perspective.

먼저 오해부터 이야기해보자.

여러 면에서, UX는 개발팀을 껴안고, 사랑받고, 도움이 되고싶은 고슴도치야. 개발팀 관점에서 바라보면, 가시는 마음에 들지 않고 이 새로운 생명체는 의심스러워보이지. 하지만 그것은 모두 관점의 문제일 뿐이야. UX관점에서 시작해보자.

 

Celia – Here’s a quick definition of User Experience: it entails what it is like for the targeted user to interact with a software, including how engaging the experience is (cf. Isbister and Schaffer, 2008), relative to the design intentions. UX is mainly about making sure the design and the business intents are the ones ultimately experienced by the target audience of a product, system, or service. It uses neuroscience and psychology knowledge and applies game user research methodologies (e.g. playtests and analytics) to make sure that the game has good usability and is immersive.

UX has its roots in Human Factors and Human-Computer Interaction (HCI). It’s about looking at how a user understands and interacts with a system without the guidance of the humans who designed it. So it’s about aligning the developers’ mental model with the player’s (cf. Norman, 1988).

NOTE! When we say UX here, we talk about the whole UX initiative: UX design, UX testing (user research), UX strategy, etc. There are a lot of misunderstanding about these different UX disciplines, but this is for another talk 

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 – When I started in the entertainment industry 10 years ago, UX was not really a thing yet. My title wasn’t “UX something”. The first time I had UX in my title was at LucasArts, so only about 4 years ago. And it wasn’t even my official title. Every time I start working with a new team, I face the same misconceptions about UX that I first need to debunk. It’s like my Groundhog Day of UX.

Here’s my top 5:

Celia –내가 10년 전에 엔터테인먼트 산업에서 시작할 때는, UX는 별게 없었어. 내 타이틀은 "UX 뭐시깽이"가 아니었지. 처음으로 UX 타이틀을 갖게된 건 LucasArts에서 일할 때였는데, 고작 4년 전이야. 그리고 그건 내 공식 직함도 아니었고. 새 팀과 일을 시작할 때마다 매번 내 첫 숙제는 UX가 가진 오해들을 풀어내는 것이었어. 이건 내 UX판 Groundhog Day(역자 주: 매일 같은 날을 사는 영화 제목) 같았다고. 

 

여기 Top 5를 뽑아봤어.

Heather – UX is going to hamper the designer’s creativity and make the game TOO EASY for the players! You’re going kill games like Dark Souls.

Celia – We would never dare do such a thing! In reality, the main purpose of UX practices is to offer the experience the designers have intended to their target audience. Therefore, if your audience is hardcore gamers and the experience you want for them is suffering, then UX guidelines will absolutely help you accomplish your sadistic goal.

Heather – UX는 기획자의 창의성을 해칠 것이며, 모든 플레이어에게 게임을 엄청 쉽게 만들어놓을거야! 게임을 다크소울마냥 죽여가고 있다고.

Celia – 우린 감히 그런 일을 벌이지 않아! 실제로, UX 프렉티스의 주 목적은 기획자가 의도한 경험을 그들의 목표 청중에게 제공하는 거야. 그러므로, 네 청중이 하드코어 게이머이고 그들이 고통받길 원한다면, UX 가이드라인은 네 세디스트같은 목표를 달성하기 위해 전적으로 도와줄거야.

 

 

Heather – All this is just common sense – we don’t need to test the UX, the player will definitely understand what they are supposed to do!

Celia – There is some common sense for sure, although issues are always easier to spot after the facts (hindsight effect). Not all UX recommendations are common sense though. The human brain is filled with perception, cognitive, and social biases that affect both the developers and the players. It’s for a reason that researchers from any field use very standardized protocols to test their hypotheses; and that’s because it’s very easy to miss or misinterpret what’s going on.

Perception is a construction of the brain. UX will help you figure out faster and more precisely what the real problems are.

Heather – 이 모든건 상식일 뿐- 우린 UX를 테스트할 필요가 없어. 플레이어들은 그들이 해야할 걸 명확히 이해하고 있을거라고! 

Celia – 당근 상식적인 것들도 좀 있겠지, 비록 문제점들이 항상 사후에 쉽게 보이지만 말야.(사후 확신 편향효과) 모든 UX 권고사항이 상식을 통하는건 아냐. 인간의 뇌는 지각, 인지, 그리고 사회적 편향으로 가득차있어서 개발자나 플레이어 모두에게 영향을 미친다고. 이것이 연구자들이 어떤 필드에서든 굉장히 표준화된 프로토콜로 그들의 가설을 검증하는 이유야; 그리고 무엇이 일어나고 있는지를 놓치거나, 잘못이해하기 쉽기도 하니까.

뇌의 구성은 지각으로 되어있어. UX는 진짜 문제가 무엇인지 더 빠르고 정확하게 밝혀내는데 도움을 줄거야.

 

Heather – UX is just another opinion on our game, the opinions you provide are no more or less meaningful then someone from marketing.

Celia – Game developers have to deal with many opinions for sure; from within the game team, from marketing team, publishing team, executive team, etc. You can therefore perceive UX feedback as yet another opinion you have to deal with. How annoying! However, UX processes are meant to test hypotheses through rigorous research and anticipate problems through analysis. There, in reality, UX experts do not give opinions, we provide an analysis based on their knowledge of the brain, past experience, and data when it’s available.

Heather – UX는 그저 우리 게임의 다른 의견일 뿐, 네가 제공하는 그 의견은 마케팅 담당자의 의견에 비해 그 이상 그 이하의 값어치도 지니지 않아.

Celia – 게임 개발자들은 여러 의견들을 확실히 다뤄야만 하지; 게임팀 안으로부터, 마케팅팀으로부터, 퍼블리싱 팀으로부터,  경영진, 등등. 그렇기 때문에 너는 UX피드백을 다른 네가 다뤄야하는 의견들마냥 인식할 수 있을거야. 어찌나 귀찮은 일인지! 하지만, UX 프로세스는 엄격한 리서치를 통해 가설을 검증하고 분석을 통해 문제를 예측하는걸 의미해. 여기서 실제로 UX 전문가는 의견을 주지 않아. 우린 뇌에 대한 그들의 지식과 과거 경험, 그리고 가용한 데이터에 기반한 분석을 제공하지. 

 

Heather – We don’t have enough time to do UX – we have to make the actual game! Our money is better spent elsewhere, on art and programming.

Celia – It’s funny that you guys don’t say that about QA testing. Clearly, you invest time and money in ensuring the game will ship without bugs. So how can shipping a game with UX issues be less of a problem? If your game ships with critical UX issues, it’s gonna affect your sales and everyone will be sad: the dev team because the game is not achieving what they have hoped for, the executives because it doesn’t make money, the players because they are frustrated with the game… The UX process is an investment: Don’t ask yourself if you can afford thinking about UX, ask yourself if you can afford not to.

Heather – 우리는 UX를 할 시간따윈 없어. – 우리는 실제 게임을 만들어야만 한다고! 우리의 돈은 아트나 프로그래밍같은, 더 나은 곳에 쓰여야 해.

Celia – 네녀석들은 QA테스팅같은걸 말하지 않는다는게 재밌네. 분명히, 너는 버그없이 게임이 출하할 수 있도록 보장하기 위해 시간과 돈을 투자하지. 그렇다면 어떻게 UX문제가 덜한 게임을 배포할 수 있을까? 만약 네 게임이 치명적인 UX 문제를 안고 배포되었다면, 그건 네 판매에 영향을 미칠테고 모두가 슬플거야: 게임이 원한만큼 달성하지 못한 개발팀, 수익을 내지 못하는 경영진, 게임에 좌절한 플레이어들... UX 프로세스는 투자야: 네 스스로에게 UX를 생각할 여유가 있는지를 묻지 말고, 여유가 없는지를 물어봐.

 

Heather – Okay, that’s a good point. So let’s, “UX the game” later, when WE’RE ready.

Celia – You know what’s gonna happen with that mindset? The team will iterate within a closed circle and we’re gonna look at you from afar knowing we could have helped you earlier in the iterative process. At some point, we won’t be able to refrain from it: we’re gonna waive at you asking to start testing and collaborating. Usually, the answer we receive is that’s you’re not ready, the game looks ugly, it’s broken, etc.

The danger is that the game ends up being tested and evaluated too late, when only quick patches can be done before the game ships. So, I’m awfully sorry but we cannot “UX this” at some point after the architecture and important decisions about the game are already made. By the way, “UX” is not even a verb…

Heather – Ok, ok I get it. But consider my perspective… this is what I have to deal with.

Heather – 그래, 좋은 지적이야. 그럼, 나중에 게임에 UX를 하자. 우리가 준비가 되면 말이지. 

Celia – 그런 마음가짐으로 했다간 어떻게 되는지 알지? 팀은 폐쇄된 원 안에서 빙빙 돌기를 반복할 거고, 우린 멀리서 반복 프로세스에 앞서 도움을 줄 수 있는 걸 알면서도 멀리서 지켜만보게 될거야. 어느 순간이 되면, 우린 그걸 억제할 수 없게 되어버려: 우린 네가 테스트와 협업을 시작하자고 요청하는걸 포기하게 되겠지. 대게의 경우, 우리가 듣는 대답은 '아직 준비되지 않았아요'이고, 게임은 엉망진창으로 망가져있지. 

위험한건 게임이 출시되기 전에 할 수 있는 빠른 패치들만 이행할 수 있을 때, 그제서야 테스트와 평가가 지나치게 늦게 끝마치게 되는거야. 그래서, 이미 만들어진 게임에 관한 구조와 중요한 결정이 내려진 후에  어느 시점에 이르면 나는 유감스럽지만 "이걸 UX"할 수는 없게 되어버려. 그나저나, "UX"는 심지어 동사도 아닌데...

Heather – 그래, 그래. 알았어. 하지만 내 시점에서 생각해보면... 이건 내가 처리해야만 하는 일들이야.

 

Celia – The developers don’t really understand all the subtleties of UX.

Heather – While they may not have a PhD in UX, a designer understands that providing an easy way for the player to interact with the game is part of good game design. The dev team may not want to listen to UX feedback because, well, you are not designers. However, most of the time the dev team is just busy putting everything together, and then they free up some mental space to listen to UX feedback.

Celia – 개발자들은 UX의 모든 중요한 세부요소들을 제대로 이해하지 못하는 것 같아. 

Heather – 그들이 UX 박사학위를 받기 전까지는, 설계자(기획자)는 플레이어가 게임과 상호작용하는 쉬운 방법이 좋은 게임 디자인의 일부라고 이해해. 개발팀은 UX 피드백을 듣는걸 원하지 않을 수도 있는데, 그 이유는 음, 네가 기획자가 아니기 때문이야. 하지만, 대부분의 시간동안 개발팀은 그저 바쁘게 모든걸 함께 쑤셔넣고, 그리고는 UX피드백을 듣기 위한 약간의 정신적 공간을 비워두지. 

 

Celia – The dev team doesn’t want to work with us – you think we are a nuisance!

Heather – I wouldn’t say nuisance… Most dev teams are happy to utilize resources that will ultimately make the game better for the players. If a process is in place that works well for both, the dev team is happy to work with UX as a partner. The real issue is that you may offer feedback that is too detailed and not applicable to where things are in the development process. We need to be aligned on what feedback is useful at any given time in the development cycle. Also, if UX is not something the dev team is used to working with, time is needed to establish a working relationship.

Celia – 개발팀은 우리랑 일하기를 원치 않아 – 너는 우리를 골칫거리라고 생각하지!

Heather – 난 골칫거리라고 말하지 않을게... 대부분의 개발팀은 궁극적으로 플레이어들을 위해 게임을 더 낫게 만들 수 있는 자원을 활용하는걸 좋아해. 만약 둘 모두 잘 굴러가는 프로세스라면, 개발팀은 UX와 일하는걸 좋아할거야. 진짜 문제는 네가 지나치게 구체적이거나 개발 프로세스 상의 것에 해당하지 않는 피드백을 제공한다는거야. 우린 개발 사이클에  주어진 시간동안 유용한 피드백을 조정하려고 해. 또한, UX가 개발팀이 함께 일하는데 익숙하지 않다면, 관계가 제대로 작동하게 하는데 시간이 필요할거야. 

 

Celia – The dev team always gives the excuse that they don’t have time to do UX testing. This doesn’t require a lot of time on your part – we can handle all the tests and reports!

Heather – I will admit that in the end, a good UX process saves time for the dev team. But initially, adding UX into the process requires more time. You have to allot for tests, reviewing and tracking feedback, educating the team on UX practices, and so on.  It needs to be integrated into schedule, otherwise it will be ignored. It’s important to note that integrating UX into the development process can’t be done overnight and just shoe-horned the process.  You need to prep the team, get buy-in, and come up with ways that gradually introduce it.  Just having tests and generating reports is not actually integrating UX into our process.

Celia – 개발팀은 언제나 UX 테스트를 할 시간이 없다고 핑계대곤 해. 이건 네 부분 중 많은 시간을 요구하지도 않아. – 우린 모든 테스트와 리포트를 처리할 수 있다고!

Heather – 결국 좋은 UX 프로세스가 개발팀의 시간을 절약해준다는건 인정해. 하지만 초기에, 프로세스에 UX가 붙ㅇ는건 더 많은 시간을 요구하잖아. 너 테스트에 할당해야만 하고, 피드백을 리뷰잉하면서 추적도 해야하고, UX 프랙티스를 팀에 교육하고, 기타 등등 말야. 그건 일정에 통합될 필요가 있고, 그게 안되면 그건 무시될거야. UX를 개발 프로세스에 통합시키는 것은 밤을 샌다고 되는 일이 아니고, 그저 신발끈을 묶는 프로세스라는걸 알아둬야 해. 너는 팀을 준비시키고, 지원받고, 그걸 점진적으로 소개할 수 있는 방법들을 찾아내야 해. 그저 테스트를 하고 리포트를 작성하는건 사실 실제론 UX를 우리 프로세스로 통합시키는게 아니야. 

 

Celia – Implementing UX feedback is not that hard! It’s just a matter of priority, right?

Heather – Your team can provide great suggestions on how to make improvements to the game.  These findings and suggestions may seem simple to implement, but in reality I have to treat this as another form of feedback in the development process and weigh it against all the other priorities. Rewriting text or changing colors may seem easy, but they still need to be tasked out, completed, and tested. Larger changes require more people to be involved, more testing, more iteration, etc. UX changes can be a big deal to implement, especially if planning has already been completed.

Celia – UX피드백을 구현하는건 딱히 어렵지 않다고! 그저 우선순위의 문제지. 맞지?

Heather – 네 팀은 게임을 어떻게 개선시킬 수 있는지에 대한 훌륭한 제안을 제공해줄 수 있어. 이런 발견과 제안은 구현하기 쉬워보일 수 있겠지만, 실제론 나는 이것을 개발 과정의 다른 피드백으로 취급하고 다른 모든 우선순위에 대해 따져봐야 해. 텍스트를 다시 쓴다거나 컬러를 바꾸는건 쉬운 일처럼 보이지만, 누군가에게 맡겨지고, 수행되고, 테스트되어야 하지. 많은 변화일수록 더 많은 관련자들을 필요하게 되고, 더 많은 테스팅, 더 많은 통합, 등등. UX 변화는 구현하는데 큰 일이 될 수 있어. 특히 플래닝이 완료되어있다면 말이지.

 

Heather – Ultimately, the UX team is another input that production has to account for. The key is to determine which inputs are going to have the most value for the game team at whatever point they are in the process. The dev team also needs to understand how to prioritize the UX feedback against things that Execs and Marketing want.

Since UX is based on data, it is easier to determine when a piece of feedback is useful to implement. And once it is implemented, it can be retested to see if it had the desired impact. So, it does make sense for us to work together throughout the development process to get the most from the relationship.

The most important thing your team can do is to gain our trust, and vice versa.

Heather – 궁극적으로, UX팀은 제작에서 고려해야할 또다른 투입요소이야. 관건은 어떤 투입물이 그 과정에서 어떤 포인트에서 게임팀에 가장 큰 가치를 갖게 될지를 결정하는 것이지. 개발팀은 또한 경영진과 마케팅팀이 원하는 바에 대해 UX 피드백을 우선순위화 하는 방법을 이해할 필요가 있어. 

UX가 데이터에 기반하기 때문에, 구현하는데 있어 언제 어떤 피드백이 유용한지를 결정하는건 더 쉬워지지. 그리고 한 번 구현하고나면, 그것이 원하는대로 영향을 미쳤는지를 재시험할 수 있어. 이처럼, 관계로부터 모든걸 끌어내기위해 개발 과정을 통해 함께 일하는건 말이 되는 이야기지.

너희팀이 할 수 있는 가장 중요한건 우리의 신뢰를 얻는 일이고, 그 반대도 마찬가지야.

 

Heather – Now, that I’ve said my piece and represented for the dev team, Celia is going to discuss the shift that occurred when she started to build bridges with the them. She had to face this alone for the first year, since she didn’t have me as her partner in crime. She laid a lot of ground work for building this relationship.

Celia – Well, I’d say that you first need to overcome these misconceptions, and I would argue that the first step has to be done by the UX peeps, because *we* are the new partners, the aliens. I had to stop bossing the team around about usability guidelines and stop pestering each time obvious UX rules were being violated during development.

Instead, I tried to “UX the UX”: I listened to the team (my audience), tried to understand what they needed (the intended experience for my audience), and I used their perspective to accomplish what needed to be done. This part describes this journey.

Heather – 내가 나의 작품을 말하고 개발팀을 대표했으므로, 이제 Celia가 개발팀과 UX 사이에 다리를 놓기 시작했을 때 일어난 변화에 대해 말할거야. 내가 그녀의 범죄 파트너로 있지 않았기 때문에, 그녀는 첫 해동안 혼자서 이것에 직면해야 했어. 그녀는 이 관계를 만들놓기 위해 많은 기반공사를 했지.

Celia – 음, 네가 먼저 이러한 오해들을 극복한걸 얘기했으니 "우리"가 새로운 파트너인 외계인으로서 UX 사람들이 뗐던 첫 발자국에 대해 논해보려고 해. 나는 사용성 가이드라인과 관련된 팀을 맡는걸 그만둬야했고 개발중에 일어나는 명백한 UX 규칙 위반마다 매번 성가시게 하는걸 그만둬야 했어. 

대신, 나는 "UX를 UX"하려 했지: 나는 팀의 의견을 듣고(내 청중), 그들이 필요한게 뭔지를 이해하려 했으며(내 청중의 의도된 경험), 그리고 그들의 관점을 이용해서 해야할 일을 성취해냈지. 이 파트는 그 여정을 기록한거야.

 

Celia – The first usability tests and reviews that I did for Fortnite (yeah I was sort of a UX team of one) were seen as being bossy when the team already knew that things were not ready and not working well. When I just wanted to get the ball rolling and start a pipeline, the process could be seen as just stating the obvious and some devs thought they had to deal with me as an “authority” that would report back to execs what was going wrong. UX was trying too hard to put in place a process before proving its value for the dev team. Because I was initially too zealous, I wanted to test everything anytime to prove the value of UX. I started to be felt as the “usability police”. Believe me, you don’t want to become too annoying…

Celia – 내가 Fortnite에서 했던(그래, 내가 UX 팀의 일원일 때말야) 첫 사용성 테스트와 리뷰는, 준비되지 않은 것들과 제대로 동작하지 않는 것들에 대해 팀이 이미 알고 있을때, 두목행세하는 것처럼 보였었어. 나는 그저 공을 굴리고 파이프라인을 시작하려고 할 때, 프로세스는 뻔한걸 명시할 뿐인 것처럼 보였고 몇 개발자들은 무엇이 잘못되고있는지를 경영진에 보고하기 위한 "권한"으로서 나를 대해야만 했어. UX는 개발팀에게 그 가치를 입증하기 전에 지나치게 열심히 프로세스를 진행하려고 했지. 나는 초기에 너무 열심히였기 때문에, UX의 가치를 입증하기 위해 언제든 모든걸 테스트하려고 했어. 난 서서히 "사용성 경찰"이 되어가고 있다고 느끼기 시작했지. 날 믿어봐, 너무 짜증나게 되고 싶지 않으면 말야.

 

Celia – At that time, with the help of a few UX advocates, I looked at where the project was, asked questions to designers to understand their intentions, and to executives to understand the business plan. Then, a UX test was conducted, or a UX evaluation was done. UX provided a huge report of all the issues, just to have a heartbeat, hoping to start a conversation and get feedback from designers to understand what was by design, what was already in the pipeline to fix, what was new UX issue to them, etc. However, the report was HUGE.

The problem is that the report was sent from a team-of-one they didn’t know well, and I never really got a chance to discuss with the devs, except for a few designers interested in UX. So in the end, the dev team was not particularly excited by the whole thing, connection was not made, and I did not have the full picture of the dev’s team plan.

Celia – 당시 나는 몇몇 UX 옹호자들의 도움을 받아서 프로젝트가 어디쯤 와있는지 살펴보고, 기획자들에게 그들의 의도에 대한 이해, 그리고 경영진의 사업 플랜에 대한 이해를 물었어. 그런 뒤, UX 테스트가 시행되거나 UX 측정이 이뤄졌지. 대화를 시작하고 무엇이 기획에 따른 것이고, 무엇이 이미 파이프라인 상에서 고쳐졌고, 무엇이 새로운 UX문제인지를 이해할 수 있도록 기획자로부터 피드백을 받기를 바라면서 모든 이슈의 거대한 리포트에 살아숨쉬는 UX가 제공되었어. 하지만, 리포트의 양이 너무너무너무 많았어.

문제는 그들이 잘 모르는 팀의 일원으로부터 리포트가 보내졌다는 것, 그리고 UX에 관심이 있는 몇몇 기획자를 제외하면 나는 그 어떤 개발자와도 논의할 기회가 전혀 없었다는 거야. 그래서 결국, 개발팀은 이 전체의 것들에 대해 특별히 흥미로워하지도 않았고, 그 어떤 연결도 만들어지지 않았으며, 나는 개발팀의 플랜에 대한 전체 그림을 가지지 못했지.

 

Celia – So I teamed up with the designers that were interested in UX, and instead of doing a big review of the whole experience, we chatted about their main issues and challenges. That was the starting point of a more tailored UX-Dev relationship. At that time, there was no UX designer on the team so I helped them with some UX design challenges (such as making dirty mocks to help them communicate their vision with the Execs). We also started to test smaller things (icons, HUD, core loop, etc.) with very specific design questions so designers were taking part in the UX process.

The picture on the left is my quick and dirty illustration of the designers’ vision of the metagame from 3 years ago (my art :p) to what Fortnite’s HomeBase is today. I’m obviously not a UX designer but I just used basic Powerpoint functionalities and threw stuff together to help everyone visualize the design direction.

Celia – 그래서 나는 UX에 관심있어하는 기획자를 데리고 팀을 꾸렸고, 그리고 우리는 전체 경험의 큰 리뷰를 하는 것 대신, 메인 이슈와 도전거리들에 대해 조잘거렸지. 이건 보다 맞춤화된 UX-개발자 관계의 출발점이었어. 그때, 팀에는 UX기획자가 없었기 때문에 나는 몇 UX 설계 도전거리들을 도왔어. (예컨대 경영진과 의사소통할때 그들의 비전을 돕기 위한 가벼운 목업같은 걸 만들어낸다거나.) 우리는 또한 기획자들은 UX 프로세스에 참여할 수 있도록 아주 구체적인 설계 질문을 갖고 작은 것들을 테스트하기 시작했어.(아이콘, HUD, 코어 루프, 기타등등.)

왼쪽의 그림은 3년 전에 기획자의 메타게임의 비전을 내가 빠르게 대충 그린 일러스트레이션이고(내 아트... 'ㅅ';; ) 오른쪽은 오늘날의 Fortnite의 홈베이스야. 나는 분명히 UX 설계자는 아니지만 기본적인 파워포인트 기술들을 사용했고 모두가 설계 방향을 시각화할 수 있도록 함께 물건들을 집어던져가며 만들었지.

 

Celia – When Epic was ready to build a UX lab (fairly fast which was great), a lot of people wanted that we streamed the tests so the devs could watch them from their desks.

I refused. I wanted the UX secret room to become a place where not only we could physically be behind the players, but also a place where we could joke and exchange ideas. Watching a playtest then became a commitment (not something the devs could do while multitasking) and a social experience (with other dev team members and UX team members).

Therefore, the secret room is completely sound proofed and has a cool ambiance: it became a place where we could mingle and even party (once a month I organize a party in the ux lab – because why not). This is how the ux tests became a fun aspect of the process. Sort of. Yes, it’s hard to watch players not getting your intended design, but doing so in a casual and friendly environment makes it much better.

Of course, you might not be able to build such a fancy lab, but there are ways to do it cheaply: just a room where you put playtest participants and stream the capture to another room. The most important thing is that the devs should not be the ones conducting the tests. If you cannot hire a UX researcher, try an intern in experimental psychology or Human Factors to run your studies, as it’s quite difficult to remove biases if you do it yourself. If you can’t have someone else do it, make sure to ask a Games User Research person some advice about how to run the tests. They are out there, on LinkedIn and Twitter, eager to help.

Celia – Epic이 UX 연구소를 지을 준비를 할 때(그 큰게 꽤 빨리 만들어지더라), 개발팀이 그들의 책상에서 지켜볼 수 있도록 우리가 테스트를 스트리밍하는걸 많은 사람들이 원했어.

나는 거절했지. 난 UX 비밀의 방이 우리가 물리적으로 동영상 플레이어의 뒤에 있지 않으면서, 농담을 건내면서 아이디어를 교환할 수 있는 장소가 되는걸 원했거든. 플레이테스트를 본다는건 (개발팀이 멀티태스킹을 하는 동안 할 수 있는 것이 아닌) 별도의 해야하는 일이자 (다른 개발팀 인원들과 UX 팀 인원들 간의) 사회적 경험이 되었지.

그러므로, 그 비밀의 방은 철저하게 방음되었고 멋진 분위기를 갖게 되었어: 우리가 어울리고 심지어 파티도 할 수 있는 곳이 되었지.(한 달에 한 번, 나는 UX 연구소에서 파티를 열었어. - 하지 말아야 할 이유가 없으니까.) 이렇게해서 UX테스트는 프로세스 상의 재미있는 측면이 되었지. 뭐 그래. 네 기획의도를 알지 못하는 플레이어를 보는건 꽤 힘든 일이지만, 캐주얼하고 친근한 환경에서 하는건 훨씬 더 나은 결과를 만들었어. 

물론, 그런 화려한 연구소를 지을 수는 없겠지만, 더 싸게 할 수 있는 방법도 있어: 플레이테스트 참가자들을 집어넣고 다른 방으로 녹화해서 스트리밍하는 방같은 거 말야. 가장 중요한 건 개발팀이 테스트를 수행하는 사람 중 한명이 되어선 안된다는거야. 네 스스로 편향을 제거할 수는 없기 때문에, UX 연구자를 고용하지 못한다면, 실험심리학 인턴이나 네 연구를 수행할 Human Factors 인턴을 알아봐. 그걸 할 수 있는 사람을 못구한다면, 꼭 Games User Research 사람들에게 테스트를 돌리는 방법에 대해 몇가지 조언을 요청하도록 해. 그들은 링크드인과 트위터에 있으니까, 도움받기 쉬울꺼야.

 

Heather – I started working at Epic during the shift. I understood the value of UX based on previous games I’d worked on and I was excited that Epic had an entire UX department! I wanted to understand why the dev team was uncomfortable with UX and figure out how we could improve the process. When the game was in early development the devs didn’t see the value of UX feedback. The team knew that game was very rough, and they were experimenting with various features. UX was seen to be something to do only when the designer had something they felt was ready for testing, and it was treated as another form of feedback.

Celia – They didn’t fully recognize that UX feedback is more neutral and scientific (when done correctly). UX feedback is different because UX professionals are trained in cognitive/experimental psychology and Human Factors to understand HCI issues and fix them.

Heather – The team was also overwhelmed at the amount of information provided. There were pages of reports and all the feedback was also tracked in a humongous spreadsheet. The dev team felt like there wasn’t enough time to thoroughly digest the feedback and determine which should be applied to the game (and at what point it should be applied).

Celia – Yeah, UX reports tend to be overwhelming for sure. But we wanna be thorough! Maybe too much. Less is more, even in the UX world, so targeted tests are certainly more actionable and less overwhelming.

Heather – Because the dev team was working quickly to finish milestones, UX feedback was not a priority to review. The reports would be generated, but might not be reviewed in depth for some time. By the time the feedback was reviewed, the team didn’t find it as useful since so many things had changed in the game since the UX test.

Celia – UX feedback should have priority over all other feedback because (if done well) it’s the most neutral and “scientific”. It will help the team take a step back and see their game through a different – less biased – perspective.

Heather – Instead of approaching UX as a new process/system to shoe horn into the development pipeline, we started thinking about UX as a member of the team. We needed them to feel part of the team so they know the design intentions and can adjust their feedback depending on the current challenges of the game.

Celia – Ideally, you want UX to be close to the team while trying to keep a certain distance with the game itself, or else we too will become too close to the game and we’ll start being biased.

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 – To get the team more used to the idea of UX, we had to get to know each other. Since the dev team was less interested in strengthening this relationship, the UX team found ways to work with the dev team on their terms. UX made themselves readily available as a resource to the team. There was low friction for someone to talk with Celia’s team and get feedback. Anyone from team is free to use them – no need to go through any hoops. The UX room is centrally located for everyone and the door is always open. Production evangelized UX and made their work more visible to the team (simple things – like reminding people in meetings to consult with the lab, inviting people to view UX tests, and inviting Celia to team meetings). It was important to build on what Celia had established and show the devs how UX could be a part of the team, without becoming another “gate” the game had to pass through.

Heather – 팀을 UX의 아이디어에 익숙하게 만들게 하기 위해서, 우린 서로를 알아야만 했어. 개발팀이 이 관계강화에 딱히 흥미있어하지 않았기 때문에, UX팀은 개발팀의 관점에 맞춰서 개발팀과 일하는 방법을 찾았어. UX는 개발팀에게 손쉽게 이용 가능한 자원이 되도록 만들었지. 누군가가 Celia의 팀과 이야기하고 피드백을 얻는데는 거의 마찰이 없었어. 팀원이라면 누구든 자유롭게 사용할 수 있었지. - 그어떤 고생스러운 일도 필요치 않았어. UX실은 모두를 위해 정중앙에 위치했고 문은 언제나 열려있었어. 프로덕션은 UX를 전도시켰고 그들의 일을 개발팀에게 더 눈에 띄게 만들었지(간단한 것들 - 연구소에서 컨설팅 미팅을 한다는걸 사람들에게 상기싴고, UX테스트를 볼 수 있도록 사람들을 초대하고, 팀 미팅에 Celia를 초대하는 등 말이야). 게임이 통과해야만 하는 또다른 관문이 되지 않으면서, Celia가 구축하고 개발팀에 UX가 팀의 일부가 될 수 있는 방법을 보여주는걸 꾸려내는게 중요했어. 

 

Celia – Instead of trying to force UX process on the whole company or game team, I first listened to the dev team and partnered with those who were interested in UX. I chose small projects that were less under the spotlight. It allowed us to go through the design – test – iterate – retest very fast so we could make quick wins. These wins could then be acknowledged by other teams and UX love started to spread. By the way, this illustrates how a UX process can easily benefit smaller teams and studios as starting small is actually an advantage. Gradually, after doing a few UX tests and seeing some good results, the team came to appreciate how UX can help them and UX became a concern of everyone, not just the UX team of one.  The UX team became a resource anyone could use and a UX designer was hired on the Fortnite team (Derek Diaz). We started planning UX as part of our development pipeline.

Celia – 전사 혹은 게임팀에 UX를 강요하는 것 대신, 나는 먼저 개발팀에 귀를 기울였고 UX에 관심있어하는 이들과 파트너가 되었지.  덜 주목받는 작은 프로젝트를 선택했어. 그건 우리를 설계-테스트-반복-다시 테스트하는걸 매우 빠르게 진행시킬 수 있게 해서, 우리는 빠른 승리를 만들어 낼 수 있었지. 이 승리들은 다른 팀들에게 인정받을 수 있었고 UX 사랑이 퍼지기 시작했어. 그나저나, 이 일러스트는 UX프로세스가 작게 시작하는게 실제로 유리했었기 때문에 작은 팀들이나 스튜디오들에게 쉽게 효익을 낼 수 있는 방법을 보여주고 있어. 점차적으로, 몇 번의 UX 테스트를 마치고 몇몇 좋은 결과를 본 뒤에, 팀은 UX가 그들을 도울 수 있는 방법에 대해 감명받았고, UX는 그저 누군가의 UX팀이 아닌 모두의 관심사가 되었지. UX 팀은 누구나 이용할 수 있는 자원이 되었고 UX 설계자(Derek Diaz)는 Fortnite 팀에 고용되었어. 우린 개발 파이프라인의 일부가 되기 위해 UX를 계획하기 시작했지.

 

Heather – When I started working with Celia, she tracked all the UX feedback in this spreadsheet. At the time, this was the most effective way. As you can see it’s quite dense. It tracks the UX feedback given to the team, the priority, when it was implemented, and if it was retested. The sheet was used as the main transfer of information between the UX and game team, but was mainly a tool for UX since the devs were not involved in driving or maintaining this process.

This worked ok at the beginning. There were some easy fixes to make in the game. But after a few months, it was tracking over 200 items, and very few of them had been addressed – or had been marked as something to do for the future.

Heather – 내가 Celia와 일하기 시작했을 때, 그녀는 이 스프레드시트의 모든 UX 피드백을 추적했어. 그 당시, 이건 가장 효과적인 방법이었지. 보다시피 상당히 밀도가 빡빡해. 팀에게 주어진 UX피드백, 우선순위, 언제 구현되었는지, 그리고 혹시 재테스트가 되었는지를 추적해. 이 시트는 UX와 게임팀 간에 주 정보전달로써 사용되었는데, 개발자가 이 프로세스를 이끌거나 유지하지 않았기 때문에 주로 UX를 위한 도구였어. 

이 일은 초기엔 잘 되었어. 게임에는 몇가지 쉬운 해결책이 있었지. 하지만 몇달 후가 되자, 200개가 넘는 항목이 추적되고 있었고, 그것들 중 극소수가 다뤄졌지 -혹은 언젠가 할 일로 표시되어있었거나.

 

Heather – So when I started working at Epic, I saw this as a one-side conversation with UX doing all the work. The process was not well-defined or consistent, so it gave the impression that UX was something that happened randomly. The dev team was willing to review this sheet with UX on a periodic basis, but it was not an integral part of the development process. It had no clear owner on the dev team side and thus it was difficult to get changes into the game and communicated back to UX for retesting.

And it was Overwhelming! It was very difficult for someone on the team to review this independently and parse through the information and determine what was important or useful to consider for the next round of planning. So they tended to ignore it.

Heather – 내가 Epic에서 일할 때말야, 난 이게 UX가 하는 모든 일에서 일방통행같은 대화가 보였어. 프로세스는 제대로 정의되거나 일관되지 않았고, 그래서 UX가 무작위로 일어나는 것이란 인상을 주었어. 개발팀은 정기적으로 UX와 이 시트를 검토하려고 했지만, 그건 개발 프로세스의 필수 부분이 아니었지. 개발팀에 명확한 오너가 없었기 때문에 게임에 게임에 적용된 변경점을 알기가 어려웠고 UX에 다시 테스트해달라고 돌아오는 커뮤니케이션이 되었어. 

그리고 그건 걷잡을 수 없게 되어버렸어! 팀의 누군가가 이걸 독립적으로 검토하고 정보를 분석하고 계획 상 다음 라운드를 위해 고려하는데 무엇이 중요하고 유용한지를 결정하는건 아주 힘들었지. 그래서 그들은 그걸 무시하는 경향이 있었어.

 

Heather – When Celia and I started working together, she wasn’t alone in defining and driving the process. We discussed ways we could work together to improve what we had and to make UX a more integrated part of the development process. In order to make the relationship work best, we wanted our process to work in sync with our releases. On Fortnite, we began by releasing online tests every 6 – 8 weeks and have been reducing the time between releases. We work closely with UX to determine what is going to bring benefit to new content released in our Online Tests.

Heather – Ceila와 내가 함께 일하기 시작했을 때, 그녀는 프로세스를 정의하고 운영하는데 혼자가 아니었어. 우린 우리가 가진걸 개선하고 우리가 가진걸 개선하고 UX를 더 개발 프로세스의 필수적인 부분이 되도록 만들기 위해 협력할 수 있는 방법들을 논의했어. 관계가 최상으로 작동하게 만들기 위해서, 우리의 릴리즈에 싱크가 맞게 우리의 프로세스가 작동하길 원했어. Fortnite에서, 우리는 매 6~8주마다 온라인 테스트가 릴리즈하는걸로 시작했고 릴리즈 간의 시간을 줄여왔어. 우리는 온라인 테스트에서 릴리즈된 새로운 콘텐츠에 어떤 효익을 가져다 줄지를 결정하기 위해 UX와 긴밀하게 협력해.

 

Heather – We started having weekly one on one meetings to revamp the process and make it more valuable for the team. We identified areas where the process needed to change. One of the first things we did was convert all the existing UX information from the Spreadsheet into JIRA. This immediately made it more accessible to the team and gave UX more visibility within the priority stack. This is a screenshot of the UX dashboard, which we use to see what needs to be implemented, triaged, and re-tested.

Heather – 우리는 프로세스를 개조하고 팀의 가치를 높이기 위해 매주 미팅을 갖기 시작했어. 우리는 변경이 필요한 프로세스의 부분을 골라냈지. 가장 첫번째로 우리가 한 일은 스프레드시트에 있는 UX정보들을 죄다 JIRA로 변경하는 일이었어. 이를통해 팀은 즉시 더 쉽게 접근할 수 있었고 UX는 우선순위 스택에서 더 쉽게 보여지게 되었지. 이건 UX대시보드의 스크린샷인데, 구현해야 할 것, 우선순위를 위해 분류가 필요한 것, 그리고 다시 테스트해야 할 것을 보는데 사용한거야.

 

Heather – We also implemented a few other things to increase the touchpoints between the two teams so we were more closely aligned on goals and priorities. We looked at the major milestones we were releasing in the next 6 months and defined the priorities of the features to test. We wanted to closely align the UX priorities with the game priorities, so that there was value in what was being tested. We also defined the UX testing goals for key milestones. We formalized at what points testing occurred in development and what type of testing would occur (3 day UX test vs. 1 day UX test).

The UX tests were part of the development schedule and publicized to the team. The teams were now aware that they had to plan for UX tests at these points – a step in the right direction! We made concerted efforts to invite the team to the UX tests (it’s really valuable to watch other people play your game), and made sure they used UX as a resource early and often.

Heather – 우리는 또한 두 팀 간에 접점을 늘리기 위한 몇가지를 구현했는데, 덕분에 우린 목표와 우선순위를 더 밀접하게 조정했어. 우린 향후 6개월간 릴리즈할 메이저 마일스톤을 보고 테스트할 피쳐들의 우선순위를 정의했지. 우린 게임의 우선순위에 맞게 UX 우선순위를 자세히 조정해서 테스트하는 것에 가치가 있게 하고 있었어. 우리는 게다가 키 마일스톤을 위한 UX 테스트 목표들을 정의했어. 우리는 개발에서 어떤 지점에서 테스트가 이뤄지는지, 그리고 어떤 유형의 테스트가 이뤄지는지(3일짜리 UX 테스트 vs 1일짜리 UX 테스트)를 공식화했어.

UX테스트는 개발 일정의 일부였고 개발팀에 배포되었지. 팀들은 이제 이런 지점들에서 UX테스트를 위한 계획을 해야만 한다는걸 알았지. - 제대로된 방향으로 한 걸음을 내딛었어! 우린 팀들을 UX테스트에 초대하는데 노력을 기울였고(다른 사람들이 네 게임을 플레이하는걸 보는건 진짜로 가치있는 일이야), 그들이 UX를 초기에 그리고 이따금씩 자원으로써 사용하도록 했지.

 

Heather – This is the current process we use for the UX/Dev pipeline on Fortnite. Since we are a live game, this process covers one full release cycle that includes planning, building features, testing, implementing feedback, and retesting. We are closely aligned and UX support is more integral in our development process.

Here are the details:

Heather – 이건 우리가 Fortnite에서 UX/개발 파이프라인으로 사용하는 현재 프로세스야. 우리는 라이브게임이기 때문에, 이 프로세스는 플래닝, 피쳐만들기, 테스팅, 구현 피드백, 그리고 재테스트를 포함하는 하나의 전체 릴리즈 사이클을 다루고 있어. 우리는 세밀하게 조정하고 UX 서포트는 우리의 개발 프로세스 안에서 더 필수적이 되지. 

자세한 내용은 아래와 같아.

 

Celia – It begins when the team specifies their hypotheses for the next online test. Questions come in from Devs, Analytics team, Marketing, or Execs. We determine what questions need to be answered (it’s important to always have a purpose when planning a test). Once the questions are defined, the UX team prepares accordingly an experimental protocol. We also adjust the test with the scope. Sometimes we test the live build that has just been pushed in long sessions, but we also do shorter and quick-and-dirty tests with prototypes (on paper, interactive prototypes, and even sometimes directly in the editor).

Celia – 이는 팀이 다음 온라인 테스트에 대한 가설을 특정할 때 시작된다. 개발팀, 분석팀, 마케팅팀 혹은 경영진으로부터 질문이 들어와. 우린 답변해야할 질문을 결정해(테스트를 계획할 때는 항상 목적을 갖는게 중요하지).일단 질문이 정의되면, 그에따라 UX팀은 실험적 프로토콜을 준비해. 우리는 범위를 갖고 실험을 조정해. 때때로 우리는 라이브빌드로 긴 세션에서 밀어넣는 테스트하기도 하지만, 프로토타입으로 더 짧고 빠르고-지져분한 테스트를 하기도 해(종이로 한다거나, 상호작용가능한 프로토타입이거나, 심지어 때때로 에디터에서 직접 해보거나).

 

Celia – Given the focus of the test and its protocol, we plan when/how/with whom to do it and we decide which build to use.

Celia – 주어진 테스트의 포커스와 프로토콜에 따라, 우리는 언제/어떻게/누구에게 테스트를 할지를 계획하고 어떤 빌드를 사용할지를 결정해.

 

Heather – Once we have the testing requirements outlined, I work with the team to plan for which build to use. We need to make sure the features we want to test are working. If the build has blockers, the test is cancelled. So we review the build two days before to determine if it ready or not. If not, the test is canceled or, more likely, re-scoped. If the team knows a few weeks ahead of time about the test, it is much easier for them to prioritize their tasks and bugs in order to get a stable build.

Heather – 테스트 요구항목들의 밑그림이 그려지면, 나는 팀들과 어떤 빌드를 사용할지를 계획해. 우리는 우리가 테스트하고자 하는 피쳐들이 제대로 작동하는지를 확인할 필요가 있어. 만약 빌드가 망가진다면, 테스트는 취소돼. 그렇기때문에 우리는 이틀 전에 그 빌드를 검토해서 그것이 준비가 되었는지 안되었는지를 결정해. 만약 준비가 안되어있다면, 테스트는  취소되거나, 준비가 안될 것 같다면, 범위를 재조정해. 만약 팀이 테스트에 대해 몇 주 전에 먼저 안다면, 안정적인 빌드를 얻기 위해 그들의 작업과 버그들을 우선순위화하는게 그들에게 훨씬 더 쉬워지지.

 

Celia – UX tests are conducted and the team observes the participants in real time. We invite the team to come watch.

Heather – And I try not to schedule meetings on the days we have tests so the team is freed up to watch them.

Celia – UX테스트가 실행되고 팀이 실시간으로 실험 참가자를 관찰해. 우리는 팀을 초대해서 관찰하게 하지.

Heather – 그리고 나는 팀이 자유롭게 그들을 관찰할 수 있도록 그날에는 미팅 일정을 잡지 않도록 하지.

Celia – Once the test is over, we analyze the data and a detailed UX report is generated. But more focused this time.

Celia – 테스트가 끝나면, 우린 데이터를 분석하고 자세한 UX리포트를 제작해. 하지만 이 시간에 더 집중하지.

Celia – After we send the report, we plan a quick meeting to go through the report together, so we can make sure we’re aligned and the team can give us their feedback directly regarding the issues raised.

For each issue, we decide together if it’s by design so we let it be, if it needs a callout so the UX team enters a JIRA, if it’s already in the process of being fixed so we follow-up to retest the feature later, etc. When UX-lab enters JIRAs, we enter detailed info: description of what we observed in the test and/or description of a violated usability heuristic (e.g. consistency violation, or the form of this item conveys a different perception than its functionality, etc.). We add screenshots and videos from the UX test. We tag it “UXLabFeedback” so all issues entered with a UX concern appear in a dashboard. Before every new UX test, we consult the dashboard and look at what issues were marked as fixed so we can verify if the UX issue is indeed resolved.

Celia – 리포트를 제출한 뒤에는, 우린 리포트를 함께 흝어보는 빠른 미팅을 계획하고, 우리끼리 조정된걸 확인하고, 팀은 등장한 이슈에 대한 피드백을 직접 우리에게 줄 수 있지. 

각 이슈에 대해서, 기획의도대로 되었기 때문에 그대로 둘지, UX팀이 JIRA에 넣도록 콜아웃이 필요한건지, 이미 수정된 것이므로 나중에 재테스트하기 위해 팔로우업해야할지 등등를 함께 결정해. UX연구소가 JIRA에 들어가면, 우리는 우리가 테스트에서 관찰한데 대한 설명, 위반한 사용성 휴리스틱 설명(예컨대, 일관성 위반이라든가, 이 항목의 형식이 기능했어야 할 것과 다른 식으로 지각되게 전달되었다든가, 기타 등등)같은 자세한 정보를 입력해. 우린 UX테스트에서의 스크린샷과 비디오를 첨부해. UXLabFeedback이라는 태그를 달아서 UX와 관련된 모든 이슈가 대시보드에서 나타나게 하지. 모든 새로운 UX 테스트 전에, 우리는 대시보드를 참고해서 어떤 이슈가 고쳐졌는지를 보기 때문에 UX 이슈가 실제로 해결되었는지를 확인할 수 있어.

 

Heather – Once UX enters JIRAs, the triage process is a way for the dev team to review them and determine if the issues will be addressed in the next release, a future release, or not at all. If the team disagrees with any of the UX feedback or wants to change the priority, they will meet with the UX lab to discuss the options. Once both groups are in consensus, the task is prioritized appropriately in the development schedule.

As you can imagine, something that the UX team marks as a Pri-1, may be viewed as a lower priority for the team. Some of the feedback may require large reworks that can’t be addressed immediately and thus will have to be part of future planning. Some of the feedback may be in opposition of the design intent and require a longer conversation with UX about how to solve the problem. The strike team leads are responsible for reviewing the feedback and initiating further conversations with UX about any questions or disagreements.

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 – Once a UX task is completed, we marked closed in JIRA and so that Celia’s team knows to re-check it in the next test.

Heather – UX작업이 완료되면, 우린 JIRA 이슈를 클로즈로 표시해서 Celia의 팀이 다음 테스트에서 재확인할 수 있도록 해.

Celia – The data is crossed-checked with information from other sources (Analytics, Customer Support, Marketing, UX surveys sent to the alpha participants etc.) and communicated back to the team so they can come up with a plan for improving the UX.

Then, we communicate to the executives and Publishing team the relevant information and the dev team can already expose their plan to fix the issues raised. It’s a collaborative process; we never give feedback directly to the publishing/executive team without first syncing with the team dev. There are no surprises and certainly no back stabbing. We’re here to support the dev team accomplishing their goals, not to act like self-absorbed smartasses.

Also, since the UX team is neutral, it doesn’t serve any agenda other than fighting for the user. So it helps everyone in the room to re-adjust their personal perspective and opinion on the game (ok, this is not always successful I have to admit).

Lastly, it’s very important that the UX team emphasizes not only the issues the game has, but also all the progress that the dev team has made so far and the UX issues solved. Execs love to see things progress (and love when issues are pointed out so they are reassured that they are taken care of). The dev team loves when we acknowledge how much progress was made (backed up with science, even!), so everyone is happy. Most of the time -ish … (developing games is after all a hard and an emotional endeavor for everyone).

Celia – 데이터는 다른 소스들(분석팀, 고객지원팀, 마케팅팀, 알파 참가자들에게 냈던 UX 설문들 등)로부터 크로스체크되고 팀에게 다시 알려줘서 그들이 UX를 개선시킬 계획을 세울 수 있게 하지. 

그러면, 우린 경영진과 퍼블리싱팀에게 관련 정보를 전달하고 개발팀은 이미 제기된 이슈를 고치기 위한 계획을 공개할 수 있지. 이건 상호협력적인 프로세스(collaborative process)야; 우린 퍼블리싱팀이나 경영진에게 절대 개발팀과 싱크를 맞추지 않은 피드백을 직접 주지 않아. 갑작스런 뒤통수치기나 서프라이즈같은건 없지. 우린 개발팀이 그들의 목표를 달성하는걸 서포트하기위해 여기에 왔지, 지 혼자 잘난 잘난척쟁이들처럼 굴려고 온게 아냐.

또한, UX팀은 중립적이기 때문에, 유저와 씨름하는 것 외에는 그 어떤 아젠다도 제공하지 않아. 덕분에 그 공간에 있는 모든 사람들이 게임에 대한 개인적인 관점과 의견을 재조정하는데 도움이 되지(그래, 이게 언제나 성공한다고는 말하진 않겠어).

마지막으로, 게임에 있는 이슈들뿐만 아니라 개발팀이 지금까지 만들어오고 해결한 UX이슈의 모든 과정을 UX팀이 강조하는게 가장 중요해. 경영진은 뭔가 진행되고있는걸 보는걸 아주 좋아하니까(그리고 이슈가 지적될 때 그것들이 관리되고있다고 안심하기도 하고 말야). 개발팀은 우리가 얼마나 많이 진척되었는지를 알려주는걸 완전 좋아하고, 이렇게 모두가 행복해지지. 대부분의 경우 그렇다는... (게임 개발을 한다는건 결국 모두에게 힘들고 감정적인 노력이 드는 일이야.)

 

Heather – While we have a unified and defined process it still needs work! The first part is working well, now we need to focus on improving the triage and verification phases. The producers need to ensure that JIRA is being updated and team is actively tackling UX issues (and not just marking them for future milestones). If things are not filtered and assigned appropriately, they lose visibility. Both teams need to have a better understanding of when UX feedback is implemented so that it can be re-tested. It’s not truly fixed until it’s retested and shows that issue has been addressed. In order to get and maintain high visibility of UX, the dev team members are expected to observe UX tests. And we always need to be open to adjust our workflow and process to make things better!

Heather – 우리는 통합되고 정의된 프로세스를 가지고 있지만 여전히 일이 필요해! 첫 번째 부분은 잘 작동하니까, 이제 우리는 긴급도 분류(triage)와 검증 단계를 개선하는데 초점을 맞춰야 해. 프로듀서들은 JIRA가 업데이트되고있게 해야 하고 팀은 활발히 UX이슈들을 붙들고있어야 해(그리고 그냥 다음 마일스톤으로 그것들은 마킹하고 넘기지 말고 말야). 만약 걸러지지 않고 적절히 조정되지 않는게 있다면, 그건 가시성을 잃게 돼. 두 팀 모두 UX피드백이 언제 구현될지를 더 잘 이해해야 재 테스트가 될 수 있어. 그건 재테스트를 하고 이슈가 해결되었다고 보이기 전까지는 제대로 고쳐지지 않아. UX의 높은 가시성을 확보하고 유지하기 위해서, 개발팀 인원들은 UX테스트를 관찰해야 할거야. 그리고 더 좋은걸 만들기 위해 워크플로우와 프로세스를 조정하는데 항상 열려있어야 해!

 

As you can imagine, there is still work to be done, but we’ve come a long way! We’ve learned a lot about each other and are less afraid. It’s all a matter of perspective.

네가 상상하듯, 처리해야할 일들이 여전히 있지만, 우린 먼 여정을 해왔어! 우린 서로에 대해 많이 배웠고 두려운건 줄어들었지. 이 모든건 관점의 문제야.

 

And now, UX is truly part of the process …

그리고 지금, UX은 프로세스의 진정한 일부가 되었어...

 

Heather – Debunk misconceptions. Don’t be afraid of each other!

Celia – Start small with developers interested in UX to demonstrate UX quick wins

Celia – Don’t be UX police, instead work together to be successful and measure/communicate the progress

Heather – Establish a strong feedback and implementation loop and make sure both teams understand how the process works. Adjust as necessary.

Both – Celebrate together!

Heather – 잘못된 생각에 대해 그게 틀렸다는걸 드러내자. 서로 두려워하지 말자!

Celia – UX의 빠른 승리를 보여주려면 UX에 관심있어하는 개발자들로 작게 시작해.

Celia – UX 경찰이 되지 말고, 대신 성공을 위해 함께 일하고, 프로세스를 진단하고 커뮤니케이션하자.

Heather – 강한 피드백과 구현 루프를 수립하고 두팀이 프로세스가 작동하는 방식에 대해 확실히 이해하게 하자. 필요에 따라 조정하고.

Both – 함께 축하하자!