제한된 환경에서 Rapid 하게 UX 챙기기
중요한 것을 지키며 빠르게 일하기
다양한 분야의 사람들과 함께 빠른 성장을 지향하는 조직이라면, 모든 단계를 빠짐없이 완벽히 하는 것보다 중요한 것 이외의 것을 덜어내고 빠르게 실험해보는 것이 더 중요하다고 생각한다. 특히나 작은 규모의 스타트업에서 일을 하다 보면 프로젝트에서 모든 프로세스의 완벽을 요구하는 것은 꽤나 불가능한 일이다. 낭비되는 시간을 줄이고, 빠르게 시장의 반응을 확인하기 위해서는 어느 정도 단계를 생략하고, 축소하며 진행하는 데에 더 최적화되어야 한다.
그러나 급하다고 해서 모든 것을 생략하는데만 초점을 맞출 수는 없다. 프로젝트를 빠르게 실험하여 원하는 것을 성공적으로 학습하기 위해서는 '핵심을 챙기고 압축하는 것'을 잘해야 한다. 또한 더해서 이런 빠르게 진행되는 상황에서 '얼마나 개인은 성장할 수 있을까?'에도 많은 노력을 기울여야 한다. 조직의 성장보다는 개인의 성장을 우선해야 한다는 생각을 하기 때문에 어떠한 상황에서도 배움의 기회를 잘 캐치해내는 것도 중요할 것이다.
소규모로 일을 하다 보면 개개인의 역할 또한 어느 정도 희석되는 경향이 있다. 디자이너라면 본인의 강점을 잘 파악하고 이를 잘 쌓아 올려야 할 것 같은데, 결국 회사 내에서는 기획부터 BI 디자인, UX 디자인, UI 디자인, 비주얼 디자인, 편집디자인, QA 등을 모두 진행해야 하기 때문에 사실 명확한 포지션을 가진다기보다 그냥 닥치는 대로 모든 것을 하게 되어 버린다. (대부분의 스타트업의 외로운 디자이너들은 때때로 맥가이버가 되어야 하는 것에 공감하지 않을까!) 이런 상황에서 본인이 원하는 포지션의 역량을 발전하기 위해서는 배움을 잘 설계하는 것도 하나의 큰 과제일 것이다.
PXD가 제공하는 더블다이아몬드 프로세스(출처:http://pxd.co.kr)UX 디자이너의 역할과 프로세스를 대략적으로 살펴보면 사용자 및 시장 현황을 조사, 분석하고, 페르소나와 시나리오 설계를 한 후, IA(Information Architecture)를 구조화하는 것이다. 또한 IA를 수정 및 보완하기 위해 카드 소팅 등을 통해 사용자 피드백을 받고, 이를 기반으로 Wireframe을 제작, 그리고 프로토타이핑을 제작하여 UT(Usability Test)를 진행한다.
UX 프로세스에서는 PXD에서 프로세스 화한 '더블 다이아몬드 UX 프로세스'가 가장 적용하기에 완성도 높은 방법이라고 생각한다. 이는 Problem을 정의하고 Solution을 도출해내는 것의 큰 틀 안에서 Discover, Define, Develop, Deliver의 단계를 진행하며, 이 안에서 지속적인 발산과 수렴 과정을 통해 하나의 솔루션을 완성해나가는 것이다.
하지만 분명 이 모든 프로세스를 완전하게 적용하여 프로덕트를 생산, 수정하는 것은 불가능한 일이다. 그렇기 때문에 PXD에서도 RAPID UX를 적용하는 방법에 대해서 설명한 바가 있으며, 빠르게 프로젝트를 진행하기 위해, 덜어내기, 압축하기, 라이브러리 활용이라는 세 가지의 TIP으로 프로세스를 어떻게 단순화하여 진행하는지에 대해서 정리하기도 하였다.
덜어내기 : 불필요한 단계를 덜어내는 방식
압축하기 : 단계를 진행하기는 하지만 압축해서 빠르게 진행 가능
라이브러리 활용 : 프로젝트마다 쌓인 지식과 경험을 라이브러리로 구축하고 다음 프로젝트에서 활용
UX의 직무를 맡고 있다면 '사용자의 경험'을 책임지고 제대로 설계해야 하며, 팀의 성장을 함께 하면서도 본인의 성장을 지향해야 한다. 그렇기 때문에 나는 어떻게 하면 사용자 경험을 잘 설계하고, 효과적으로 배움도 얻어낼 수 있을지 생각했고, 그를 위해 일하며 놓치지 말아야 하는 것들에 대해 스스로 기준을 세우게 된 것 같다. 이전에는 이러한 기준이 없었기 때문에 중요하지 않다고 생각하고 제대로 하지 않아 프로젝트의 진행이 오히려 더뎌지고, 같은 실수를 지속적으로 반복하며, 많은 시행착오를 겪기도 했다. 그래서 현재까지 지속적으로 어떻게 하면 더 효율작으로 성장할까를 고민하고 있으며, 제대로 된 기준이 정립되어가면서 일과 배움의 효율이 올라갈 것이라고 믿는다.
위의 이유를 들어 정리한 이 글은 사용자 경험을 제대로 설계하고, 팀의 성장을 함께 하며 본인의 성장을 이루어내는 것기 위한 고민에 대한 것이라고 할 수 있을 것이다.
기획의 목적을 명확히 하는 것
UX를 잘 설계하기 위해서는 기획 단계에서 굉장히 치밀하게 설계를 해야 한다고 생각한다. 결국 UX를 설계하는 것의 목표는 단순한 경험보다는 본질적으로 전달하는 가치의 목적을 얼마나 잘 전달하는가 이다. 기획 단계에서는 지금 만드는 것이 명확하게 무엇인지, 만들려고 하는 것이 비전과 가치에 긴밀하게 연결된 것인지, 어떤 경험을 줄 수 있을지, 지금 당장 해야 하는 일인지, 가장 빠르게 시장의 반응을 확인할 수 있는 방법인지 자주 묻고 대답할 수 있어야 한다고 생각한다.
출처 https://germweapon.tistory.com/354기획을 착실히 하지 않았던 것이 한동안 가장 시행착오를 많이 했던 부분이라고 생각한다. 가끔 아이디어에 심취해 본질을 파악하지 못하고 장기간의 프로젝트를 진행하고 끝나고 나서야 지금 당장 필요하지 않은 일이었다는 것을 알게 된다. 중요하지 않은 일에 시간을 쏟게 되면 정말 가치 있는 중요한 일을 해낼 수 있는 시간을 허비하게 되어버리는 것 같다.
팀이 일을 하며 기획에 시간을 쏟는 것에 대해 중요하게 생각하지 않을 때도 있다. 기획서를 작성하는 것이 제품을 실현해 내는 것이 아닌 단계이기 때문에 그 중요성에 대해 간과했던 것 같다. 하지만 확실하게 기획서가 얼마나 치밀하고 명료한지에 따라 그 후에 취하게 되는 전체의 행동이 달라질 것이다.
이것에서는 얼마나 디자이너 개인이 관여할 수 있을까 하는 것에서는 조직의 일하는 방식에 따라 한계가 있을 수도 있다고 생각한다. 그럼에도 소극적이던, 적극적이던 어떤 방식으로도 이런 것을 명확히 하는 것은 중요할 것이다. 명확한 기획이 디자인을 넘어 더 빠르게 잘 일하는 것의 기본이라는 생각이 들기도 한다.
스케치의 중요성: 기획, 구조 설계 단계에서 디자인 구체화를 경계하는 것
스스로에게 있어 실수하기 쉬운 것이라고 생각한다. 기획을 하거나, wireframe을 짜기 전 구체적인 디자인을 생각하는 것을 항상 경계해야 한다. 기획이나 디자인을 시작할 때 바로 디자인 툴로 시작하는 경우가 있는데, 이는 빠르게 시작하는 것이라기보다는 섣불리 단계를 뛰어넘는 것이라는 생각이 든다. 스케치를 하지 않음으로써 지속적으로 세세히 잘 설계해야 하는 아주 중요한 부분들을 놓쳐왔던 것 같다. 그렇기 때문에 이런 부분에서 시간을 아끼기 위해서는 스케치 단계를 건너뛰기보다는 라이브러리를 잘 구축하고 활용하는 것이 UX를 잘 설계하는 것에서 더 현명하지 않을까 생각한다.
또한 가끔은 기획문서에서도 디자인이 이미 구체화되어 전달되는 경우가 있다. 어떤 정보를 어떤 컴포넌트를 이용해서 제작을 한다고 정리가 되는데, 기획서에는 어떠한 모습으로 보여야 하는가 보다는 어떤 것을 전달하려 하는가에 좀 더 초점을 맞추면 좋지 않을까 한다. 내용보다는 목표, 목적, 의도가 더 잘 전달되는 게 좋다고 생각한다.
프로토타입을 압축하기
프로토타입을 통해 얻을 수 있는 장점이라고 한다면 커뮤니케이션의 비용을 효과적으로 줄일 수 있는 것, 실수를 미리 방지할 수 있는 것, 또한 빠르게 실험해볼 수 있는 것이라고 생각한다. 지금까지는 프로토타입을 진행하지 않았는데, 어느 정도 Low-fi 프로토타이핑은 생략을 많이 하지만, 이런 장점 때문에 high-fi 프로토타이핑은 생략하지 않고, 전달력을 가질 만큼으로 압축해서(압축한다는 것은 앞서 pxd에서 정의한 '압축하기'를 한다는 의미다.) 진행하려고 노력하는 편이다.
low-fi prototype과 high-fi prototype의 이점은 조금 다른데, Invision에서 제시한 것에 따르면 low-fi의 장점은 디자인과 컨셉에 초점을 맞출 수 있는 것, 빠르게 실시간으로 인터렉션 하고 피드백을 수집할 수 있는 것, 누구에게나 접근할 수 있는 것이며, high-fi의 장점은 유저의 상황을 설계하여 정확히 살펴볼 수 있는 것, 세밀하게 컴포넌트의 사용에 대해 평가할 수 있는 것, 실제 구현된 것이 어떻게 보이게 될 것인지 소통할 수 있는 것이라고 한다. 그렇기 때문에 팀과의 '소통'에 초점을 맞추고 시행착오를 줄일 수 있는 것을 목적으로 한다면 high-fi prototype은 꽤나 중요하게 거치고 가야 하는 단계일 것이라고 생각한다.
사용자 데이터를 통한 유저 피드백
유저의 반응을 확인하는 것은 다양한 인터뷰, Usability test 등으로 확인할 수 있으나, 이보다 빠르게 유저의 반응을 즉각적으로 확인할 수 있는 것은 데이터라고 한다. 실험에 대한 결과를 판단하기 위한 필요한 데이터를 잘 설계하고, 이를 통해 개선해나가는 것은 중요할 텐데, 이런 데이터는 사용자가 남긴 흔적이고, 의도가 반영된 결과라고 할 수 있다. PXD에서는 사용자 가설에 대한 객관적 근거의 아쉬움을 들며, 데이터를 활용하여 사용자 모델링 프로세스를 설명하였다.
효과적으로 피드백을 받기 위해서 인터뷰나 테스트를 진행하는 것은 필수적이라고 할 수 있겠지만, 그전에 유저의 반응을 확인하기 위한 데이터를 수집하고 트래킹 하는 작업은 지속적으로 이루어져야 할 것이라고 생각된다. 데이터 분석에서 그 반응을 이해할 때는 PXD에서 제시한 바와 같이 5 W1 H(who, what, when, where, why, how)를 중심으로 생각하면, 데이터에서 공감의 요소를 찾을 수 있고, 이를 위한 필요한 인터뷰나 UT를 떠올릴 수 있을 것이다.
예측과 회고
지속적으로 작업물에 대한 데이터를 쌓으면 디자인을 개선할 때 쉽게 길을 찾을 수 있는 발판을 마련할 수 있다. 예측과 회고를 하는 것은 첫 번째로 위에서 말한 ‘라이브러리 구축’을 위해 필요하다. 이는 지속적으로 쌓여온 지식과 경험을 수집하는 ‘효율적인 작업을 위한 작업’이라고 생각한다. 이런 라이브러리를 얼마나 체계적으로 만드는지에 따라 다음 프로젝트를 얼마나 빠르고 완성도 있는 결과물로 보여줄 수 있는지가 달렸다고 할 수 있을 것이다.
이외에도 회고는 섣부름을 막는 책임의 영역이라고 생각한다. 결정을 내리는데 회고를 계획하고 어떤 가설과 어떤 예상에 따른 선택이었는지를 명확히 하는 것은 생각하지 않고 선택해버리는 오류를 어느 정도 막아내는 장치가 될 것이라고 생각한다. 앞서 말한 기획의 중요성과 같이 디자인에 관해서 예측과 회고를 제대로 하지 않고 진행하면, 프로젝트의 방향성을 잡지 못하고 시행착오를 지속할 위험이 있다.
더해서 예측을 통해 알아보고 싶은 것, 회고를 통해 확인하고 싶은 것을 쌓아가는 것은 본인의 성장을 위해서도 충분히 좋은 도구가 될 것이다. 이를 위해서 나는 브런치에 정리해놓은바와 같이 KPT의 방법을 가져와 사용하고 있다.
사실 빠르게 효율적으로 일을 잘하는 것의 처음은 경험을 쌓는 것이라고 생각한다. 다양한 아티클과 경험을 토대로 위와 같은 것을 지켜가려하고 있지만, 그렇기 하기까지의 실패의 경험과 시행착오를 통한 배움이 있었기 때문에 점점 더 효율적으로 일을 할 수 있게 되었다고 생각한다. 그렇기 때문에 앞으로 얼마나 더 효율성을 가지고 스스로의 성장을 이루어 낼 수 있을지는 결국 얼마나 많은 경험을 하고 이를 효율적으로 배움으로 가져오는지가 가장 중요할 것 같다.
