brunch

매거진 실제적인 UX n Service

라이킷 26 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Creative Uxer Sep 12. 2020

Sketch / XD 는 만능 UX기획 툴이 아니다

UX 툴의 좋은 기능은 필요한 역할과 상황에 맞게 사용해야 합니다

2007년 처음 이 업계에 들어와서 기획을 배우던 시절부터,

화면설계 = PPT( 파워포인트 ) 라는 공식이 있을 정도로 당연한 이야기였습니다.

이 흐름이 급격하게 변했던 것은 4~5 년 정도 되었던 것 같은데요.

10년 전에도 발사믹 같은 axure rp 같은 툴이 간간이 있어 왔지만, 시장을 바꾸지는 못했습니다.

하지만 Sketch의 등장은 새로운 시대가 열렸음을 알려주는 계기가 되었죠.

( Sketch / Adobe xd / figma 등 UX툴의 공통적인 사항이나, 본 글에서는 Sketch중심으로 작성합니다.)

유명 UX에이젼시과 선도기업들이 바뀐 작업방식에 대해 어필하기 시작하면서 새로운 툴에 관심을 갖기 시작했습니다. 그리고는 상당히 빠른 시간에 많은 디자이너들이 사용하게 되었습니다.

더 이상 한땀 한땀 파워포인트로 UI를 설계하고, 그것을 포토샵으로 그리고 프로토타이핑을 위한 모션을 하나씩 만들지 않아도 한번에 스케치 툴에서 그럴듯한 결과물을 만들어 낼 수 있게 되었으며, Zeplin을 통해 퍼블리셔(또는 코더)에게 전달해야하는 디자인 가이드를 작업하지 않을 수 있게 되었습니다.

또 하나의 변화는 기획자와 디자이너의 경계가 무너지게 되는데요, 기획자가 스케치를 통해 한번에 디자인까지 작업하는 사례나, 별도의 기획없이 디자이너가 스케치로 기획문서를 겸한 산출물을 내기도 합니다.

여기까지는 사실 많은 사람들이 알고 있는 이 업의 변화 이기도 하고, 현재 많은 회사에서 채택하고 있는

방향이기도 합니다.

저도 최근에 다녔던 회사들에서 모두 이 방향으로 UX팀의 업무 방향과 프로세스를 잡아왔습니다.

어렵게 비용을 받아 회사에 받아 수십대의 아이맥을 구매하기도 하고, 정보보호와 논쟁끝에 정책을 바꾸기도 했죠. ( 이 부분은 앞서 발행한 글 https://brunch.co.kr/@creativeuxer/9 에 상세히 써두었습니다. ).

업무 환경을 바꾸기 위해 수십 대의 맥을 구매했을때, 옆 부서의 눈치도 감수해야했죠.

하지만 최근 드는 생각은 오히려 Sketch가 기획자의 성장을 방해하고, 편협하게 만들기도 한다는 점 입니다.

기획자들이 해야하는 역할은 단순하게 화면에만 그치지 않습니다.

기획자가 해야하는 일은 현업부서(요청부서)와 개발자와의 중간다리 역할을 해야하고,

요구사항에 대한 명확한 정의를 디스크립션을 통해 전달해야합니다.

또한 프로세스와 정책에 대한 설계를 하고 이에 대한 산출물 작성이 되어야 합니다.

sketch의 등장은 하나의 서비스 목업을 만든다고 가정할때

"요구사항 정의 > 프로세스/정책 설계 > 화면설계 > 디자인 > 퍼블리싱" 을 거치지 않고 바로 이 모든 단계를 하나의 툴에서 이뤄지게 만들어줍니다. 하지만 그런 변화속에서 실제 디자인적인 요소에 집중하는 기획자들을 많이 볼 수 있습니다.

이유는 명확합니다.

전에 없던 눈에 보이는 결과물이 기획에서 나오다보니, 의사결정권자(임원 등) 은 관심을 가지게 되고 기획자들도 더 잘하려고 애를 쓰게 되죠. 전에는 디자인에서 시안을 잡아줘야 보고 할 수 있던 일들이 자신의 손에서 해결이 되기 때문입니다.

하지만 이 과정에서 문제들이 생겨납니다.

누가 더 디자인처럼 아름답게 보이는 산출물을 내었는지는 기획자의 입장에서 중요한 요소가 아님에도, 눈에 보이는 결과물에 대한 크리에이티브를 높히는데 집중하거나, 반대로, 실제 UX기획이 해야하는 역할은 제대로 수행하지 못하고, 연차가 쌓임에도 성장하지 못하는 문제점이 있었습니다.

또한 기획자와 디자이너의 롤에 대한 애매한 문제들이 생겨납니다.

기획을 해야하는 시간(리소스)에 목업 작업을 요구받게 되고, 과거에는 화면설계로 가능한 협의를 목업을 선 진행하고 설계를 하면서 더 많은 리소스를 쓰게 됩니다.

실제 기획자가 작성한 산출물을 디자이너가 재사용할수 없어 폐기하고 재작업 한다거나, 디자인의 시안 발표/선정 기회가 사라지게 되면서 롤의 정체성이 흔들리게 되기도 합니다

가장 큰 문제는 정작 기획자가 배워야 하고 성장해야 하는 부분들을 지나치게 되어 반쪽짜리 기획자로 전락하게 되는 부분이 있습니다.

UX툴의 효율성은 써본사람은 돌아갈 수 없을 정도로 좋은 것은 분명합니다.

다만 그 적용 방법에 있어서는 상황과 그에 필요한 역할 자체를 충분한 고민과 논의 끝에 정해야 합니다.

UX기획과 UI디자인의 롤이 분리되어 있는 회사라면,

( 기획과 디자인을 병행하는 Uxer에는 해당이 되지 않을 수도 있음 )

1. 기획자가 Sketch 를 쓰는 것은 빠르게 목업이 필요한 경우 또는 효율적인 UI설게를 위해 필요한 경우에만 사용합니다. Sketch 툴은 서비스 플로우나 정책정의 및 개발 등 유관부서와의 커뮤니케이션에 필요한 디스크립션을 작성하기에 충분한 툴은 아닙니다. 이런 부분은 PPT나 다른 보조 수단을 통해 반드시 진행해야 합니다.

2. 기획에서 Sketch로 작업을 하게 된다면 이를 디자이너가 재사용 할 수 있는 형태로 제작이 되어야 합니다.

이 시점에서 필요한 것은 확실한 가이드라인입니다. 각자의 스타일로 그림을 그리는 것이 아니라 서로간에

약속된 규약에 따라 작업이 되어야 의미가 있습니다. 기획에서 작업하는 Sketch 따로 디자인에서 작업하는Sketch 따로 산출물이 나온다면 리소스의 낭비가 될 수 있습니다.

3. Sketch 만능주의를 버려야 합니다. 일부 기업에서는 오히려 UX 툴을 잘 모르는 임원들이 온라인 상의 정보를 바탕으로 UX툴을 써야만 좋은 것으로 오해하는 경우도 있습니다.

파워포인트는 아직도 충분히 화면을 설계하고, 커뮤니케이션하기 좋은 툴입니다. 파워포인트로 작성한 문서가 Sketch에 비해 비쥬얼이 떨어져 보이더라도, 문서의 비쥬얼이 아니라 필요성과 의미에 집중해야 합니다.

가장 중요한 것은 기획자와 디자이너간의 충분한 협의 입니다.

기획자와 디자이너는 오랜 세월 동안에도 끊임없이 서로의 결과물을 두고 논쟁하는 위치에 있는데요. 기획자의 입장에서는 자신이 설계한 문서를 디자이너가 작업하게 되는데, 자신의 눈높이나 방향성에 맞도록 끊임없이 요구하게 되고, 반대로 디자이너의 입장에서는 디자인을 할수 있는 재료(기획안)가 완전하지 않으면 좋은 산출물을 만들수 없기 때문에 좋은 기획서를 요구하게 됩니다. 서로가 서로의 결과물을 요구하는 입장에 있다보니 사이좋은 기획자-디자이너는 찾아보기 어렵습니다 ( 물론 좋은 문화일수록 다르긴 합니다. )

또한 기업의 애매한 KPI는 두 롤에 대한 경쟁심을 가지게 하죠. 아이러니한건 일반기업일수록 기획자에 대한 평가가 높고, 에이젼시로 갈수록 디자이너의 평가가 높다는 것입니다 ( 이 부분은 별도로 글을 쓸 예정입니다)

기획자와 디자이너가 UX 툴의 사용을 놓고 충분한 협의가 되지 않는다면 서로를 공격할 여지만 남긴채 좋은 팀웍을 가지기 어렵습니다. 기획자는 더이상 디자이너가 아니더라도 화면을 그릴수 있다는 오판을 하게 되고, 디자이너 입장에서는 기획자가 롤을 침범한다고 여기게 되며 기획자가 만든 UX산출물을 외면하게 됩니다. 적어도 UX 툴의 사용에 있어서는 충분한 협의를 통해 각 사와 서비스의 상황에 맞게 사용 범위와 방법을 정해야 합니다.