디자인과 피드백의 상관관계
디자이너는 왜 피드백을 받아야하는가?
디자인학부 1학년, 첫 전공 강의였습니다.
그 강의에서 교수님은 '예술과 디자인은 어떤 차이가 있느냐'라고 물어보셨고, 모두가 그렇듯, 저도 교수님의 시선을 피하기에 바빴죠. 결국, 그 날의 강의내용은 기억나지 않지만, 어째서인지 교수님의 그 첫 질문은 여전히 기억에 남아있습니다. (어쩌면 지목당할까 잔뜩 긴장했었기 때문인지도 모르겠습니다.)
예술과 디자인의 차이는 무엇일까요?
고유의 색과 아름다움을 추구한다든지, 새로운 것을 창조한다든지 등 예술과 디자인의 교집합은 쉽게 떠오르는데 그들의 여집합은 어쩐지 쉽게 생각나지 않습니다.
수업이 끝나고 꽤 많은 시간이 흐른 지금, 제가 찾은 여집합은 '대화의 대상이 누구인가'에 있었습니다.
예술은 예술가 자신과의 대화이지만 디자인은 '사용자와의 대화'입니다.
디자이너가 [디자이너]라는 이름으로 살아가기 위해서는 결국
'사용자와의 대화를 얼마나 잘 해내는가'에 달려있을지도 모릅니다.
사용자와 대화를 잘한다는 것은 사용자를 '이해하는 것'과 같습니다. 사용자들을 이해하는 과정에서 우리는 그들에게 '피드백'을 받게 됩니다. 매출이 떨어지거나, 앱 다운로드 수가 감소하거나, 웹 방문율이 줄어드는 등의 간접적인 피드백을 받고 사용자가 직접 보내는 CS 문의, 메일, 또는 대면 인터뷰를 통해 직접적인 피드백도 받게 되죠.
실제로 제품을 디자인하는 디자이너와 기획자들은 다양한 내용과 형태의 피드백을 받고, 이를 통해 제품을 개발하고 개선합니다. 여러분은 얼마나 많은 피드백을 받고, 또 그것을 제품에 녹여내기 위해 얼마나 노력하고 계신가요? 혹시, 그 과정에서 어려움을 겪고 있진 않으신가요? 디자이너가 제대로 흡수하지 못한 채, 쏟아지는 피드백은 사용자를 이해하는 기회를 주기는커녕 오히려 길을 잃게 하기도 하고, 어떤 디자이너는 피드백 과정 자체를 놓치거나 크게 중요하지 않다고 생각하기도 합니다.
레이니스트의 디자인팀은 피드백의 중요성을 깨닫고 이를 제품에 성공적으로 녹여낼 방법을 항상 고민하는 팀입니다.
오늘 저는 피드백을 수용하고 반영하는 그 지난한 고민들과 시행착오, 또 작은 결실들을 이야기하려 합니다.
저희의 경험이 제품을 디자인하는 분들에게, 그 과정에서 피드백 받는 것이 두렵고 어려운 분들에게 조금이나마 도움이 되길 바랍니다.
1. 피드백을 받아야 하는 이유
제품을 앞으로 사용할 잠재 사용자, 현재 사용하고 있는 실사용자, 제품을 함께 만드는 팀원 모두 디자이너에게 피드백을 줄 수 있습니다. 피드백은 개개인의 취향에 따른 색감이나 조형에 대한 다소 사소한 피드백부터, 사용에 큰 불편함을 호소하는 제법 크리티컬한 피드백까지 아주 광범위하죠. 그리고 그 내용은 대체로 부정적인 의견일 겁니다.
피드백 폭격을 맞은 디자이너는 '제품'과 '나 자신'을 동일시함에서 비롯되는 자괴감으로 멘붕상태가 되어버릴지도 모릅니다. 레이니스트 디자인팀도 처음부터 피드백 폭격 속에서 태연했던 것은 아니었습니다. 그런데도 우리는 사용자에게, 그리고 팀원들에게 늘 피드백을 요청합니다. 지금의 디자인팀 정신승리(?)가 가능했던 이유는 무엇이었을까요?
피드백을 올바르게 받는 것은 피드백을 받는 이유를 깨닫는 것에서 출발합니다.
레이니스트 디자인팀은 '내'가 아닌 '타인'의 관점을 이해하는 과정이 좋은 제품을 만드는 데 매우 중요하다는 것을 깨달았습니다. 그래서 피드백을 단순한 불만 또는 비난이라는 관점이 아닌, 사용자를 이해하는 데 필요한 절차라는 관점으로도 받아들일 수 있는 것입니다. 컬러가 마음에 들지 않는 이유가 무엇이었는지, 사용하기 어려웠던 이유는 무엇이었는지, 제품을 더 사용하지 않는 이유가 무엇인지를 이해한 디자이너는 제품의 다음 STEP을 진행할 준비가 된 것입니다.
사용자는 내가 아닌 다른 사람, 결국 '진짜 제품을 사용할 사람'입니다.
제품을 소비할 사람의 관점을 이해하는 것은 어쩌면 너무나 당연한 이야기이겠지요.
그래서 피드백을 주는 팀원들 역시 '내'가 아닌 '사용자'의 관점으로서 피드백을 주어야 합니다. (이 부분은 아주 중요하기에 2번째 주제에서 자세히 이야기해보겠습니다)
(왼쪽 뱅크샐러드 1.0 / 오른쪽 뱅크샐러드 3.0)
뱅크샐러드 앱은 현재 3.0입니다.
현재 버전이 나오기까지 수많은 시행착오가 겪었고 성장했으며, 여전히 그 과정을 반복하고 있습니다.
그리고 레이니스트는 뱅크샐러드 최초의 앱 1.0은 실패한 앱이었다는 결론을 내렸습니다. 뱅샐 1.0은 지속적으로 사용자를 끌어들이지 못했고, 다운받은 사용자의 잔존율은 크게 떨어졌습니다. 1.0의 실패는 현재의 레이니스트 디자인팀의 '피드백 문화'를 발전시켜야 했던 계기가 되었습니다. 당시 뱅샐 1.0이 실패한 원인은 앱을 사용할 사용자, 앱을 사용할 사용자, 즉 '가계부 앱 사용자'에 대한 고민이 부족했기 때문입니다.
최초 런칭한 앱의 큰 실패 이후 2.0을 개발하는 과정은 수많은 가계부 사용자를 이해하는 것에서 시작해야 했습니다. 가계부 앱을 대학 시절부터 꾸준히 써 온 어느 직장인부터, 복식 가계부를 사용하는 사업가까지….
그들을 이해하는 과정은 쉽지 않았지만, 그들을 이해한 내용을 토대로 앱을 설계하는 과정은 3.0을 출시하는 모든 과정에서 큰 자산이 되었습니다. 그리고 뱅크샐러드 2.0은 레이니스트에서 작은 성공을 거둔 첫 번째 앱이 되었습니다.
2. 양질의 피드백을 받기 위한 준비
그럼 피드백은 어떻게 받는 것이 좋을까요?
첫 번째 주제에서 잠깐 언급하였듯이 피드백은 '어떻게' 주고받느냐가 아주 중요합니다. 이를 위해서는 디자이너가 피드백을 받을 준비를 철저히 하는 것이 좋습니다. 피드백을 왜 받아야 하는지, 전달받은 피드백은 제품의 어떤 부분을 개선하기 위해서인지 기준을 확실하게 세웁니다.
뱅샐 앱에 새로운 지출 내역을 추가하는 화면을 디자인한다고 가정해봅시다.
가계부 사용자들은 지출 내역을 어떻게 추가하기를 원하는지에 대한 리서치가 먼저 선행되어 있어야 합니다.
그 리서치를 토대로 화면을 설계한 뒤 '가계부 사용자에게 용이한 구조로 설계되어있는지' 검증하기 위하여 피드백을 받는 것입니다. 사용자에 대한 리서치없이 설계된 화면을 팀원 또는 사용자들에게 피드백을 요청하게 되면, 광범위한 피드백 속에서 디자이너는 어떤 판단을 내려야 할지 길을 잃을 수 있습니다.
자, 그럼 검증을 받을 화면을 사용자에게 피드백을 받아봅시다. 그 사용자는 가계부 앱을 사용하고 있거나, 앞으로 사용할 사용자이어야 합니다. 사용자에게 피드백을 받을 때는 그들의 목소리를 직접 듣고, 프로토타입을 어떻게 사용하는지 직접 관찰할 수 있는 환경이 가장 좋습니다. 직접 만나는 것이 어렵다면 최대한 구체적이고 쉽게 응답할 수 있도록 설문지를 작성하거나, 전화 통화 등으로 진행할 수 있겠습니다.
그렇다면, 팀원들에게도 똑같은 화면에 대한 피드백을 요청해봅시다. 사용자에 대한 피드백과 달리, 팀원들은 가계부 사용자일 수도 있고, 아닐 수도 있습니다.
그래서 디자이너는 가계부 사용자에 대한 리서치를 상세히 공유하여 피드백을 사용자 관점에서 줄 수 있도록 도와주어야 합니다. 또 팀원들이 양질의 피드백을 줄 수 있도록 충분한 시간을 제공해야 합니다. 이 과정에서, 제품의 개선 방향까지 팀원 모두가 자연스럽게 합의될 수 있다면 가장 완벽한 모습이겠지요.
이렇게 글로 쓰고 보니, 디자이너가 해야 할 일이 아주 많군요.
3. 피드백을 받아들이는 디자이너의 자세
그렇다면 넘쳐나는 피드백 폭격 속에서 디자이너는 어떤 자세를 취해야 할까요?
모든 피드백을 반영해야 할까요? 당연히 그렇지 않을 겁니다. 오히려, 모-든 피드백을 반영한 제품이 있다면 그것이 좋은 제품이 아닐 가능성이 높습니다. 예를 들면, 텔레비전 리모컨을 디자인하기 위해서는 전원 버튼, 채널/볼륨조절, 채널 번호 기능을 편리하게 사용할 수 있느냐가 핵심일 겁니다. 그런데 여기에 집 안에 있는 모든 가전제품을 컨트롤 할 수도 있고, 심지어 집 형광등을 조절하거나 커튼을 조정할 수 있는 등 다양한 기능을 모두 담아내려고 한다면 만인의 염원(?)을 담은 리모컨일지는 모르겠지만, 결론적으로 비행기 조종석 같은 TV 리모컨을 사용할 수 사람은 실제로 거의 없을 겁니다. 이런 비행기 조종석 같은 TV 리모컨을 레이니스트에서는 '키메라'라고 표현하기도 합니다.
(비행기조종석과 TV리모콘)
소프트웨어 제품에서도 마찬가지겠지요.
각각의 화면은 '모든 이가 바라는 모든 것이 가능한 곳'이 아니라 '제품 속에서 적합한 때에 적합한 기능을 제공하는 곳'이어야 합니다.
그럼 우리는 제품의 다음 단계를 밟기 위해 최대한 많은 이들에게 받은 피드백을 어떻게 처리(?)해 볼까요?
우리 제품의 사용자는 Early Adopter, Majority 등의 세그먼트로 나뉘거나, 20~30대 또는 남/녀의 프로필 유형으로 나뉠 겁니다.
제품의 특징에 따라 이 세그먼트와 유형별로 피드백을 정리하면 각각의 공통점과 차이점을 발견하게 됩니다.
그리고 모든 세그먼트와 유형을 관통하는 하나(또는 그 이상)의 인사이트로 귀결되는데, 그것이 제품을 개설시킬 핵심 이정표입니다. 그러나 이때 정립한 이정표를 맹신할 수는 없습니다. 세상의 모든 제품 사용자를 만나보지 못했기 때문에, 이는 어디까지나 검증이 필요한 '가설'입니다.
첫 번째 피드백으로부터 정리된 가설은 여러 차례 검증 과정을 거치며 제품은 성장합니다.
핵심 인사이트를 제외한 나머지 자잘한 NEEDS와 PROBLEMS들은 인사이트에 포함되는 내용일 수 있고, 포함되지 않는 내용일 겁니다. 포함되지 않는 내용은 어느 정도 수준으로 제품에 녹이는 것이 좋을지, 혹은 아예 BACKLOG로 남길지 판단합니다. 그 판단은 결국 디자이너의 손에 쥐어지게 되는데, 여러 가지 복잡한 상황에 얽히게 되면 그 결정이 쉽지 않은 경우도 많습니다. 하지만 피드백을 통한 제품 개선이 습관화되기 시작하면 디자인된 화면은 내가 내린 정답이 아니라, 제품의 최선을 찾기 위한 '검증 도구'라는 것을 알게 될 것입니다.
나의 판단이 확신이 서지 않을 때도, 제품 개선이 계속되어야 하므로 피드백을 토대로 가설을 세우고 스스로 판단하고 다시 한번 검증하는 것을 습관화하는 훈련이 필요합니다.
그 훈련 과정을 처음 시작할 경우 쉽지 않을 수 있습니다.
뱅크샐러드 웹의 카드정보 상세페이지는 1년 전 리디자인되어 지금의 모습이 되었습니다. 당시 카드 전문가 팀원들의 날카롭고 아주 꼼꼼한 피드백들에 어떠한 '판단 기준'을 가지지 않은 채 피드백에 휩쓸렸던 당시 디자이너는 수많은 스케치 파일들이 만들어야만 했습니다. 그 과정은 지금 생각해보면, 불필요한 고민과 불필요한 스케치 파일들이 난무하였는데요. 피드백을 주는 팀원들은 어떤 피드백을 주는 것이 제품 개선에 도움이 되는지 몰라 자신을 기준으로 의견을 줄 수밖에 없었고 디자이너 역시 어떤 피드백을 어떻게 받아들여야 하는지 몰랐기에 지금의 정답을 찾을 때까지 많은 시행착오를 겪었던 것이지요.
만약 지금 그 일을 진행한다면 웹을 방문하는 과반수의 대부분의 일반 사용자(Majority)사용자가 해당 화면에서 무엇을 원하는지, 우리는 어떤 행동을 유도해야 하는지에 대한 기준을 세웠을 겁니다. 그렇게 되면 아주 꼼꼼한 정보를 원하는 일부 사용자(Early Adopter)의 NEEDS를 위해 과반수의 대부분의 일반 사용자(Majority)에게는 어려운 정보를 전면에 배치하는 의사결정을 하진 않았을 것입니다
팀원과 디자이너 모두 카드 전문가 팀원의 피드백은 그러한 일부 사용자(Early Adopter)를 위한 것임을 이해했어야 합니다. 대부분의 일반 사용자(Majority)들을 고려하여 최대한 이해하기 쉽게 제공하되, 복잡한 정보는 DEPTH를 주어 원하는 이는 확인해 볼 수 있도록 디자인을 진행했어야 했던 것이죠. 그렇게 되었다면 좀 더 효율적인 판단이 가능하였을 것이고, 적어도 디자이너의 정신적/육체적 체력을 보호할 수 있지 않았을까 하는 생각이 듭니다. :)
피드백과 관련하여 제법 전문가의 모습을 갖춰나가는 레이니스트 디자인팀 역시 여전히 시행착오를 겪으며 제품을 개선해나가고 있습니다. 팀원 모두가 제품을 성장시키고 결국 성공시키겠다는 하나의 마음으로 앞으로도 열심히 피드백을 주고, 받을 것입니다.
이 글을 통해 제품을 기획/개발하는 분들이 피드백과 관련한 여러 의문과 어려움을 해소하시는데 조금이나마 도움이 되었기를 바랍니다.
