파워포인트로 UX디자인하며 얻은
3가지 교훈
디자이너에게 에자일 회고가 주는 의미
회고를 통해야 비로소 실패는 성공의 어머니가 된다.
Agile 방법론의 회고(Restrospective)는 마무리된(또는 필요에 따라 진행 중인) 프로젝트를 돌이켜 보며 잘한 것과 잘못한 것, 풀리지 않은 문제점 등을 함께 공유하고, 이를 통해 앞으로의 진행 방향을 수립하는 활동을 의미한다. 회고의 개념을 접하게 된 후부터, UX 디자인 결과물을 스스로 돌이켜보고, 친한 개발자나 GUI 디자이너에게 피드백을 받는 '나 좋으라고 하는 회고'의 시간을 가졌다. 프로젝트를 진행하는 동안에는 그 속에 갇혀서 보지 못했던 아쉬운 부분들이 보였고, 다음 프로젝트에서는 그 부분을 개선하려고 노력했다. 그 결과 디자인 생산성은 올랐고 유관부서와의 협업은 보다 원만해졌다.
내가 진행했던 회고의 과정 중 가장 오랜 기간 고민한 것이 디자인 툴에 대한 것이다. 내가 속한 기업은 UX 디자이너들이 파워포인트로 디자인을 진행해 UX 시나리오를 만들고 있다. 다들 아시다시피 파워포인트는 디자이너를 위한 툴이 아니다 보니 사용하면서 아쉬움과 불만이 생겼다. 그리고 이 아쉬움과 불만에 대한 회고를 통해 내 나름의 디자인 방향성을 어렴풋이나마 잡을 수 있었다. 그 경험을 공유하려 한다.
1. 쓸데없는 반복 작업은 이제 그만
UX 시나리오는 상품이 아니다. UX 시나리오는 엄밀히 말해 디자이너와 개발자의 소통을 위해 존재하는 매체 일 뿐, 사용자와의 접점은 전무하다. 냉정하게 말하면 UX 시나리오 개발에 소요되는 시간과 노력은 고스란히 프로젝트 전체의 손실이다. 하지만 좋은 상품(서비스)의 개발을 위해서는 심도 있는 고민이 녹아든 UX 시나리오가 필요하다. 그리고 이 고민의 과정에는 시간이 소요된다. 그렇다면 결론은 하나다. 불필요하게 소요되는 시간을 줄여나가야 한다.
디자인 과정을 돌이켜 보며 가장 쓸데없이 소요된 시간이 무엇인지 고민해 봤다. 여러 가지가 있겠지만 가장 지독한 녀석은 무의미한 반복 작업이었다. 가장 빈번히 발생하는 반복 작업은 시나리오 여러 곳에 적용된 동일한 컴포넌트를 수정하는 것이다. 파워포인트로 만든 UX 시나리오에서 글로벌 탭 메뉴의 구성을 변경해야 하는 사태가 발생했을 때를 상상해보라. 생각만 해도 끔찍하지 않은가. 그런데 시나리오 Revision History를 살펴보면 이런 일들은 매우 빈번하게 일어난다. 나도 수백 장의 UX 시나리오에 별 고민 없이 복붙(Copy & Paste)한 글로벌 UI를 모든 페이지에서 수정한 경험이 몇 번 있다.
위의 예시는 Sketch의 Symbol 같은 기능을 사용하면 깔끔하게 해결된다. 파워포인트를 써야 하는 상황이라면 UI 컴포넌트(위의 예시로 보면 글로벌 탭 메뉴)의 상세 정의 페이지를 별도로 구성하고, 나머지 페이지는 컴포넌트 이름과 상태(글로벌 탭의 어떤 메뉴가 선택된)로 표기하는 등의 노력으로 어느 정도 해결할 수 있다.
다시 한번 말하지만 UX 디자인 과정의 시간 소요는 프로젝트 전체의 손실이다. 불필요한 반복을 줄이고 작업의 효율을 높이는 방법에 대해 지속적으로 고민해야 한다.
2. UX 시나리오는 읽힐 때 의미가 있다.
유관부서 담당자와 통화로 의견을 한참 주고받다가 뭔가 이상한 느낌이 들 때가 있다. 서로 다른 것을 보면서 이야기하는 것 같은 위화감, 십중팔구 다른 버전의 시나리오를 보고 있거나 다른 페이지를 보고 있었다. 어느 순간부터 논의전에 시나리오 버전과 페이지를 확인하는 버릇이 생긴 것도 이 때문이다.
한 번은 웃지 못할 해프닝이 있었다. 버전, 페이지를 재차 확인했는데 자꾸 다른 페이지를 보는 듯 한 이상한 느낌이 들었다. 내가 속한 기업은 ppt로 작성된 UX 시나리오를 pdf로 변환하여 배포하는데, 나는 시나리오에 명시된 페이지 번호를, 개발자는 pdf 문서상의 페이지 번호를 보고 있었다. 이 해프닝 이후 나는 파워포인트의 페이지 넘버링을 한 장씩 밀어서 pdf 페이지 번호와 맞췄다.
이 외에도 오해를 만드는 부분들은 생각보다 많았다. 용어에 대한 생각의 차이도 많았고, 표현 방식에 대한 선호도도 달랐다. 개발자들의 의식의 흐름과 니즈에 대해 고민하기 시작한 때가 이때부터다. UX 시나리오를 통해 표현하는 디자이너의 의도가 개발자에게 잘 전달되어야만 디자인 행위의 의미가 생기기 때문이다. UX 디자인은 사용자를 위해, UX 시나리오는 개발자를 위해 진행되어야 한다.
3. 신은 디테일에 깃든다.
UX 시나리오는 얼마나 디테일해야 하는가? 이 주제로 동료 디자이너들과 술 한잔하며 이야기를 나눈 적이 있다. 여러 의견이 있었고 크게 두 갈래로 나뉘었다. 레이아웃과 인터랙션 디자인 같은 UX 디자인의 본질에 집중하고 나머지는 제외해야 한다는 의견과 UX 시나리오 자체로 완결성이 있도록 최대한 디테일해야 한다는 의견이 팽팽했다. 이 부분에 대해 정답은 없다고 생각한다. 프로젝트의 성격이나 규모에 따라도 달라질 수 있고, 디자이너의 성향에 따라갈 수 있는 부분이라고 여긴다. 다만 내가 선호하는 쪽은 후자에 가깝다.
내가 UX 시나리오는 디테일을 지향해야 한다고 생각하는 이유는 크게 2가지다. 첫 째는 UX 시나리오가 프로젝트의 지표로 활용되기 때문이다. 개발자는 순전히 UX 시나리오에 의존해서 개발을 진행하게 되는데, 지도가 목적지를 정확하게 표시하지 않는다면 항해는 난항에 이르게 될 것이다. 또한 품질 검증의 단계에서 UX 시나리오는 기준으로 사용되기 때문에 엉성한 UX 시나리오는 상품의 품질 저하로 직결된다.
두 번째는 UX 시나리오가 디자이너의 유산이기 때문이다. UX 시나리오는 개발자에게 공유됨과 동시에, UX 팀 내에 공유된다. 이런저런 이유로 담당자가 변경되면서 내 시나리오를 후임자에게 넘겨준 거나 다른 사람의 시나리오를 물려받아야 하는 경우도 많다. 이 과정에서 정교하게 작성된 UX 시나리오는 큰 도움이 된다. 동료와 후배들에게 '시나리오만 보내고 한마디도 안 해도, 개발이 가능하게 해야 진정한 UX 시나리오다.'라고 자주 말하는 것도 이런 맥락에서 나에게 스스로 하는 말이다.
효율적인 작업, 심도 있는 표현, 정확한 전달
'작업은 효율적으로, 표현은 심도 있게, 전달은 정확하게'
회고의 과정을 겪으며 얻은, 나만의 디자인 방향성이다. 책상 한편에 늘 적어두고 까먹지 않으려고 자주 들여다본다. 이 글을 읽는 분들도 이렇게 작업을 진행하라고 말하고 싶지 않다. 만약 그런 의도로 이 글이 읽혔다면 그것은 전적으로 글쓴이의 표현이 열악했기 때문일 것이다. 그저 본인의 디자인 작업물을 돌이켜 보는 회고의 시간을 가져보시기를 권하고 싶다. 그 과정은 아마도 여러분에게 생각보다 많은 선물을 가져다줄 것이다.
