문제정의에 집중하는 팀의 디자이너는 어떻게 일할까?
국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
이번 글은 전 세계 6,000만 명의 아침을 깨우는 앱 '알라미'를 서비스하는 딜라이트룸 디자인팀의 이야기입니다. 딜라이트룸 디자이너로서 문제를 정의하고, 해결 방법을 도출해 나가는 과정에 관해 설명했습니다.
딜라이트룸에 입사한 후로 가장 많이 쓰고 듣는 단어는 WHAT, WHY, HOW(WWH)이었던 것 같습니다. 현재도 알라미팀은 직군을 가리지 않고 일하기 전에 가장 먼저 문제의 본질을 싱크하고 일을 진행합니다. 알라미 디자이너로 성장하면서 문제를 정의하고 해결 방법을 도출해 나가는 과정을 정리 겸 글을 작성해 봅니다.
일단 피그마는 닫아두세요
시각화보다 더 중요한 단계부터 집중하세요!
디자이너에게 시각적 이미지는 무언가를 구체적으로 생각하게 만드는 큰 힘이 되는데요. 그 힘은 가끔 반대로 생각을 틀에 가둬버리는 역할을 하게 되기도 합니다.
우리가 이루려고 하는 목적이나 문제가 싱크 되기 전에 시각 결과물을 공유하게 될 때 작업자들이 다 같이 시각 결과물이라는 제한적인 생각에 갇혀 버릴 때가 많습니다. 초기 싱크부터 시각 결과물에만 초점이 맞춰질 때, 팀은 무엇을 하려고 했는지조차 모를 정도로 프로젝트 방향성을 잃기 쉬워집니다. 작업자 자신들이 방향을 잃게 되면 다른 팀원들이 보기에도, 사용자들이 보기에도 공감하지 못하는 작업 결과물이 나오기 쉽습니다.
이런 이유로 초기에 결과물에 대한 이야기보다 목적과 문제를 팀원 간 싱크 하는 문제는 정말 중요합니다. 또한 초기 싱크가 잘된 후 결과물에 대해 논의하게 되면 또 쉬워지는 것이 있습니다. 결과물인 디자인이 좋은 디자인인지 아닌지 팀 내에서 판단하기 수월해지는 것인데요. ‘목적을 이루고 문제를 잘 해결하는 디자인인가’, ‘우리가 초기에 싱크 한 문제를 해결하는 방법이 잘 적용되어 있는가’ 기준으로 디자인으로 보게 되면 결과물에 대한 판단 기준이 작업자마다 상이하지 않고 효율적으로 논의될 수 있습니다.
그러니 프로젝트가 시작될 때 일단 피그마는 닫고 시각화를 멈추세요. 우리가 하려는 일의 목적과 문제를 찾고 그 문제를 어떤 방법으로 해결한 것인지 모두가 싱크 하는 단계가 시각화보다 더 중요하니까요!
목적을 이루고자 할 때 무엇이 문제가 되나요?
목적에 따라 문제 찾기
알라미 디자이너는 스스로 WWH를 정의하여 일하기도 하지만, PM이 들고 온 WWH를 함께 싱크하고 발전시키는 일도 많이 하게 됩니다. PM이 생각한 WWH를 완벽히 이해하기 위해서는 디자이너 스스로 WWH를 다시 그려볼 줄 아는 것이 중요합니다.
목적과 문제가 정해지는 방법은 여러 가지가 있지만, 보통 회사가 성장하려는 바가 분명할 때는 비즈니스적으로 팀에서 이루려는 목적이 명확하게 전달될 때가 종종 있습니다. 이럴 때 우리는 분명한 목적을 이루고자 할 때 무엇이 문제가 되는지에 집중합니다.
비즈니스적으로 특정 기능이 개선되어야 할 때, 혹은 새로운 기능이 만들어져야 할 때, 명확한 목적을 이루는 데에 방해물이 되는 문제를 더 날카롭게 찾아가고 그에 맞는 해결 방법을 도출하는 방식으로 작업을 진행합니다.
알라미의 ‘오늘의 패널’ 개편을 예를 들어 보겠습니다. 알리미의 ‘오늘의 패널’은 사용자에게 아침을 제공하는 주요 페이지이기도 하지만 동시에 주요 광고 수익 포인트입니다.
오늘의 패널에서 이루려는 목적은 명확합니다. 최대한 많은 사용자가 더 오래 머무는 것이죠. 비즈니스적으로도 명확한 목적을 가진 이 프로젝트를 방해하는 문제를 찾고, 그에 따른 해결 방법을 아래와 같이 도출했습니다.
해결 방법을 다시 디자이너의 골로 만들어봐요
How를 사용자의 행동별로 쪼개서 디자인 골로!
위에서 예시로 든 오늘의 패널 작업에서,
[What] 체류시간을 늘리기 위해
[Why] 사용자가 원하는 정보를 보지 못하는 문제를
[How] 사용자가 선정한 정보로 오늘의 패널을 볼 수 있게 재구성하자
도출했습니다.
여기까지 잘 싱크 한 디자이너는 디자이너만의 작업으로 넘어가고, 해결 방법을 디자인 목표로 다시 한번 쪼갭니다. 디자인 목표는 해결 방법을 구현하기 위해 사용자에게 요구할 주요 행동 단위를 쪼개서 목표로 설정합니다.
아래 이미지와 같이 오늘의 패널 해결 방법을 다시 쪼개 볼 수 있을 거 같은데요. 디자인 목표는 예시보다 더 쪼개고 구체화할수록 방향성도 더 명확히 싱크 되지만, 작업에 따라 어느 정도로 쪼갤지는 매번 다를 수 있습니다. 디자인 목표가 행동 단위로 잘 쪼개졌다면 이제 디자이너는 목표를 달성하기 위해 최적의 UX/UI를 설계해야 합니다.
디자인 목표를 어떻게 하면 더 잘 달성할 수 있을지에 대한 고민을 시작하고, 리서치했으면, 이제 드디어 피그마를 열고 시각적으로 구현해 나갈 차례입니다.
하나 더, 디자이너가 문제 정의하는 법 추가요
현상을 보고 문제를 정의하고 결과(목적) 이루기
위에서는 목적이 분명한 작업에 대해서는 What → Why → How 순으로 작업하는 방법에 관해 이야기했습니다. 하지만 가끔 눈에 보이는 현상에서 문제를 찾아 개선하는 경우도 디자이너에게는 많이 일어납니다.
이런 경우 목적을 통해 문제를 정의하는 것이 아닌, 현상을 통해 문제를 정의하는 방법으로도 작업을 진행하게 됩니다. 현상을 문제로 받아들이는 것이 아닌 현상과 문제를 분리하여 좀 더 근본적인 문제를 정의하고 어떻게 해결할지를 고민하는 식으로 작업을 진행하곤 합니다.
우리가 보는 현상을 바로 해결 방법으로 매칭하려고 하면 작업이 날카로워지지 않게 됩니다. 예를 들어 ‘구독 사용자가 프리미엄 기능을 모두 사용하지 않는다’라는 현상을 목격했습니다. 바로 해결 방법으로 가게 되면 ‘구독 사용자에게 프리미엄 기능을 사용하게 하자’로 매칭이 됩니다. 어떤 작업을 해야 할지 상상이 잘 안 갑니다. 너무 많은 방법이 있을 거 같습니다. 방법을 찾는다 해도 어떤 기준으로 이 작업이 성공적이었는지 판단하는 것이 날카롭지 않을 거 같습니다.
그렇기 때문에 현상 속에서 진짜 문제를 찾아 구체화해야 합니다.
현상 속에서는 여러 가지 문제가 있을 수 있겠지만 아래 예시에서는 ‘사용자가 어떤 기능을 사용했고, 어떤 기능을 사용하지 않았는지조차 모른다’를 문제로 정의했습니다. 그렇다면 아까와 조금 더 구체적인 해결 방법이 나오게 됩니다.
이렇게 현상부터 찾아 문제를 정의할 때, 알람 디자인그룹 내에서는 더 명확한 싱크를 위해 문제 정의 테이블을 아래와 같이 만들어 사용하고 있습니다. 디자이너가 직접 백로그를 만들 때, 문서만으로도 서로 명확하게 싱크 하기 위해서는 최대한 구체화한 간결한 문장으로 표현합니다. 하고자 하는 작업이 무엇인지 누구나 알기 쉽게 적는 것을 기본으로 하고 있습니다.
마무리
모든 팀에서 그렇듯이 왜 그 일을 하는지가 싱크 되지 않으면 일이 시작조차 되기 힘듭니다. 우리가 왜 그 일을 해야 하는지, 왜 이게 문제인지를 싱크 하는 일은 가장 먼저 필수적으로 많은 시간을 들여 모두가 완벽히 이해해야 하는 첫 단계라고 생각합니다.
앞단에서 시간을 많이 할애하는 일이 처음에는 비효율적으로 보일 수 있지만 결과적으로 많은 부분에서 비효율을 줄일 수 있는 경험을 하실 수 있을 거로 생각합니다.
<원문>
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
