#2 게임 UI 제작에 프로토타이핑 툴 활용해보기
왜? 어떻게?
#1 게임 UI 개발 프로세스에 대해 : https://brunch.co.kr/@niboos/3
앞 글에서 간단히 언급하였듯이 협업 커뮤니케이션 과정 속에서 UI 프로토타이핑에 대한 니즈를 많이 느꼈습니다. 옳고 그름을 떠나 의견만 들어보면 다 일리가 있고 맞는 말이었기 때문입니다. 단지, 초점과 방향이 다를 뿐이었습니다. 때문에 토론은 종종 결론 없이 빙글빙글 돌 때가 많았습니다. 또 효율적인 답을 찾았을 때 보단 한쪽에서 양보를 함으로써 일이 진행되는 경우도 많았습니다.
그래서 저는 프로토타이핑이 이런 상황에서 하나의 목표를 위해 효율적으로 커뮤니케이션이 진행되게 할 수 있을 꺼라 판단했습니다.
또 게임의 특성상 게임 자체의 CORE를 더 중요시 하기에 개발 협업 과정에서 UI의 UX적인 측면이 소홀히 다뤄지는 상황도 가~끔 존재합니다. 이럴 땐 시안 이미지가 아닌 확실하게 주장하고 설득을 뒷받침해주는 무언가가 필요했습니다. 저는 그것이 프로토타이핑이라 생각했습니다.
전 연구가 아닌 실제 실무 일정 속에 프로토타이핑 툴을 활용하는 것에 대해서만 생각하고 이 글을 쓰고 있습니다.
왜 사용하는가?
프로토타이핑을 하는 가장 포괄적인 이유는 검증하여 UI의 사용성을 높이는 것입니다.
게임 UI 개발 시 실무에서 프로토타이핑이 필요하다고 생각되는 상황들은 아래와 같습니다.
- 시안만으로 판단하기 애매할 때
- 검증하여 코드 작업이 들어가기 전 확실히 시안을 fix 해야 할 때
- 의견이 엇갈릴 때
- 설득이 필요할 때
멈춰진 화면을 보며 머리 속으로 생각하는 것과 실제로 조작해보는 거는 의외로 큰 차이가 있습니다.
각자의 생각만 쌓이고 쌓이면 산으로 갈 수도 있습니다. 서로가 자신의 생각이 옳다고 느끼기 때문입니다.
다양한 변수가 있는 게임 화면에서 정보를 유저에게 어떻게 하면 효율적으로 노출 시킬 수 있을까?
단순 선택 화면에서도 어떻게 하면 유저의 몰입을 도울 것인가?UI의 UX 검증 과정에서 말보다는 보여주는 게 좋고, 보여주는 것보단 직접 만져보는 것이 확실합니다.
게임 UI 개발 과정에서의 프로토타이핑 툴은 뛰어난 커뮤니케이션 도구가 될 수 있습니다. 그 외의 용도로써 실무에 적용하기에는 애매하다는 것이 개인적인 생각입니다. UI 모션과 같은 인터랙션 영역은 게임 UI 개발 프로세스의 'UI 스키닝' 단계에서 UI 디자이너가 직접 넣고 수정하며 지속적으로 테스트하며 바로바로 개발에 적용 가능하고 테스트 빌드로 확인할 수 있기 때문입니다. 이 과정 속에 프로토타이핑을 활용하기엔 단계를 더 만드며 일정에 영향을 주며 크게 효율적이지 않다는 것이 저의 생각합니다.
실무 경험상 하나의 기능 기준으로 일정에 많은 영향을 주며 결정을 위한 커뮤니케이션 비용이 많이 지는 '시안 제작'과 '코드 스켈레톤' 단계를 위한 활용이 가장 베스트라 생각됩니다.
물론 일정상 주어진 시간이 많다면 여러 과정 속에서 프로토타이핑 툴을 이용하여 연구하는 것도 나쁘지 않습니다.
어느 분야든 같겠지만 프로토타이핑은 전체 일정에 영향을 주지 않는 선에서 정말 필요한 상황일 때 진행되어야 한다고 생각합니다.(정말 연구가 필요하면 해당 일정을 따로 생성/추가하는 게 맞다고 봅니다.)
어떻게 활용해야 할까?
다양한 프로토타이핑 툴이 있었고, 저는 무엇이 게임 UI 개발 프로세스 속에서 잘 활용될 수 있을까 고민했습니다. 일단 게임 개발 환경에선 마이크로 인터랙션 같은 디테일한 UI 모션들은 디자이너가 직접 전담할 수 있었기에 개발 환경 등을 고려하면 High Fidelity 툴까지는 필요 없다고 판단했습니다.
게임 UI는 한 페이지에 소모되는 디자인 코스트가 많았기에 시안 제작에 상당한 시간이 할애됩니다. 그래서 저는 제작된 시안 이미지로만으로 활용할 수 있는 툴이 적합하다고 생각했습니다.
일정에 무리 없이 플로우와 뎁스를 빠르게 체크 가능한 Low Fidelity 툴을 쓰는 게 적합했습니다.
간혹 인터랙션 모션을 구현하는 과정에서 개발자의 지원이 필요한 경우가 있는데, 이때를 위해 Mid Fidelity 툴 까지는 적당하다고 생각하고 그 이상은 게임 개발과정에서는 일정적으로 비효율이라 생각됩니다.
앞에서도 언급했지만, 프로토타이핑 툴이 필요해지는 시점은 3-4 과정 사이였습니다.
어느 정도 나온 시안을 가지고 기획자랑 개발자와의 많은 토론이 발생하기 때문입니다. 설득이 가장 많이 필요한 시점도 이때였고요.
UX 검증이 애매한 상태인 시안을 개발자에게 넘겼고, 코드 스켈레톤이 나왔는데 UX 관련 커뮤니케이션 과정에서 시안이 바뀌어야 하는 상황이 생길 때가 있습니다. 이때 상황이 단순 버튼 위치의 이동 정도면 괜찮지만, 플로우나 뎁스가 바뀌는 경우가 있고(경험상 보통 대부분의 이유가 이것) 이것 때문에 세팅된 코드를 뒤집어야 하는 경우가 발생할 때가 생깁니다. 또는 멈춰있는 시안상으로 검증할 땐 괜찮았지만 UI 스키닝을 하면서 빌드로 테스트하는 과정에서 UX 오류를 발견하고 화면을 수정해야 하는 경우도 있는데, 이러한 과정에서 소모되는 일정으로 인해 생기는 리스크가 클 때가 자주 발생합니다.
보기에는 괜찮은데 조작해봐야 알 것 같어~! (본 화면과는 상관없습니다.)프로토타이핑을 함으로써 UX 검증뿐만 아니라 중간에 UX를 뒤집는 상황에 대한 확률을 줄여 일정에 대한 리스크를 방지할 수 있다고 생각합니다.
프로토타이핑 툴은 UI 사용성을 검증하기 위한 과정이기에 완벽하게 완성된 시안까지는 필요 없다고 생각합니다. 저는 의견이 많이 엇갈리거나 설득이 필요한 페이지의 큰 틀을 빠르게 잡아 진행하여 방향을 결정하고 설득하고자 했습니다.
무엇을 사용했나?
개발 환경상 게임 UI 제작 환경은 대부분 Window입니다.
일단 개인적으로 연구와 간단한 활용을 위해 사용하는 거라 선택의 폭은 작았습니다.(Window환경인 것도 컸고요!)
- 일단은 당장 써보기 위해 무료로 사용 가능해야 함
- 쉽게 공유 가능해야 함
- 시안 이미지로 빠르게 제작할 수 있어야 함
- Low/Mid Fidelity
- Window환경
위와 같이 저의 환경을 고려하여 툴 선택에 필요한 조건을 간추려보고 툴을 찾아보았습니다.
다양한 툴을 찾아보았고, 당시 저의 환경과 조건에 가장 알맞은 툴은 Invision과 Atomic이었습니다.
둘 다 Window에서도 사용 가능했고, 웹 브라우저에서 작업하여 쉽게 타인에게 공유를 할 수 있었습니다.
체험 형식으로 무료 사용이 가능했던 것도 선택에 큰 영향을 줬습니다. :)
*해당 툴들에 대한 정보는 지홍 님의 글에서 간략히 확인 가능합니다.(https://brunch.co.kr/@jihere1001/12)
Invision
인비전은 개인적으로 화면 플로우에 대한 나의 주장을 뒷받침하는 용도로 사용했습니다.
시안을 만들면 어차피 jpg로 추출하니, 그 시안의 jpg 파일들을 인비전에 올려 간단하게 각 페이지를 연결하여 테스트했었습니다. 툴이 매우 쉽고, 시안 이미지만으로도 최소한의 프로토타이핑이 가능하였습니다.
멈춰있는 시안 이미지를 열어두고 모니터를 꾹꾹 누르고, 다음 이미지를 넘기는 식으로 보며 토론하는 방식에서 최소한의 인터랙션 동선이 파악되면서 좀 더 스마트해지고 정확해졌었습니다.
기존의 방식으론 인터랙션에 대해서도 각자의 느낌과 생각이 다 다른데 멈춰있는 시안 이미지를 통해서면 커뮤니케이션을 하니 각자가 머리 속에서 그리는 것이 달라 결정까지의 대화가 소모적으로 길어지는 경우가 많았습니다. 인비전은 이런 상황에서 매우 유용했습니다.
Atomic
아토믹은 Mid Fidelity툴로써 화면 속의 개별 각 요소를 조절 가능하여 시안 이미지가 페이지 잧 였던 인비전과 다르게 아트보드가 존재했고 그 위에 ui에셋을 조각내어 올려 더 디테일한 모션 작업이 쉽고 빠르게 가능했습니다. 모션의 퀄리티도 상당하여 실제 구현 느낌을 보고 싶을때 사용하기 적합해 보였습니다.
개발자가 코드로 모션을 줘야 하거나 코드 스켈레톤을 잡기 전 복잡한 인터랙션 모션이 들어갈 것 같은 화면의 UX 테스트가 필요한 경우에 유용하게 쓸 수 있었습니다.(UI 모션을 단순 보여주기만 해도 되는 경우에는 오히러 에펙이나 플래시가 작업이 빠르고 효율적인 경우도 있는 것 같습니다.)
아토믹은 팝업 트랜지션 테스트와 필요성에 대한 근거를 만들기 위해 사용했었습니다.
기획자와 개발자가 트랜지션에 모션에 필요성에 대해 의문을 가졌었고, 저는 이에 대한 필요성을 여러 차례 주장 해오던 상황이었습니다.
처음에는 레퍼런스 자료와 함께 말로 주장을 했었고, 두 번째는 영상을 만들어 보여드리면서 화면 구조적인 관점에 대한 의견을 설명했습니다.
결국 '보여주고 말하고, 보여주고 말하고' 였기에 인터랙션과 사용성은 각자의 머릿속으로 상상을 해야 했습니다. 때문에 이 두 번의 설득은 별 성과 없이 미적지근하게 끝나버렸습니다.
마지막으로 아토믹으로 빠르게 실제 적용됐을 때와 유사한 수준으로 프로토타입을 구현하여, 기획자와 개발자에게 링크를 드렸습니다. 반응은 매우 긍정적이었습니다.
그동안 제가 주장해왔던 부분들은 화면을 조작해볼 수 없었기에 와 닿지 않았었지만, 아토믹으로 제작된 프로토타입을 조작해보고 느껴보니 두 분은 저의 주장들을 이해할 수 있었고, 그 후 개발과정은 일직선으로 순탄하게 갈 수 있었습니다.
수십 번 보고 머리로 조작을 상상하는 것보다는, 한번 만져보는 것이 훨씬 효율적이라 생각합니다.
프로토타이핑 툴들은 기본적으로 모바일 앱을 위해 만들어졌습니다.
때문에 게임 UI랑은 먼 존재로 생각할 때가 있었습니다. 하지만 툴들이 매우 편리하여 호기심에 잠깐 사용해봤던 경험이 게임 UI 제작에도 활용할 수 있겠다는 가능성을 보았습니다.
아직은 걸음마 단계지만 계속 연구하고 공부해봐야 할 부분인 것 같습니다.
The division (이런거 할때가 개발자의 도움이 필요해요..!)앞에서 언급했지만, UX 검증이 구두/시안으로만으로 가능할 때는 프로토타이핑을 할 필요는 없다고 생각합니다. 오히려 일정에 리스크만 줄 뿐입니다.
그리고 보여주기만 되는 정도면 에펙이나 플래시로 목업을 제작하는 게 빠르고 효율적일 수도 있습니다.
툴을 사용해보고 느낀 점은 프로토타이핑은 협업 커뮤니케이션을 위한 툴이라는 점입니다.
플로우나 뎁스 등 UX 사용성이 애매하고 이 때문에 일정이 길어질 때, 사용하면 효율적일 것입니다.
멈춰있는 시안을 보며 머리 속으로 사용감을 상상하는 것과 프로토타입을 만들어 직접 사용하여 느껴보는 것에는 큰 차이가 있다고 생각합니다.
설명으로 보면 작업시간이 오래 걸릴 것 같지만, 툴들이 정말 쉬워서 짧은 시간 안에 제작을 할 수 있습니다. 이게 프로토타이핑 툴들의 핵심이기도 하고요.
게임 UI 개발 프로세스에서 이 프로토타이핑 툴이 많이 효율적인가에 대해선 확신이 서진 않습니다.
계속 활용해봐야 할 것 같습니다 :)
