Design Critique Guide
Google Ventures의 Critique 방법
일하면서 언제가 가장 긴장되느냐라고 누군가가 물어본다면,
1) 첫 디자인 시안을 가지고 사용자를 만나러 갔을 때.
2) 관리자분들을 상대로 기획안 리뷰받을 때.
가 아닐까 한다. 특히 2)의 경우 많은 상실감과 좌절감을 동반하는 일이기에 대부분의 디자이너들이 별로 좋아하지는 않는 것 같다. 동료들에게 "요즘 뭐가 제일 힘들어?"라고 물었을 때도 같은 대답이 나오는 걸 보면..
하지만 디자인 작업을 하다 보면 필연적으로 크리틱(하거나 받거나) 발생한다. 또 그것이 가진 나름의 장점도 분명히 있다. 그렇다면 우리는 어떻게 조금 더 크리틱 작업을 의미 있게 할 수 있을까?
아래 내용은 Google Ventures의 Design Critique Guide의 요약과 개인적인 경험으로부터 우러나온 사족들이 포함된 내용입니다. (오역/의역 다수)
1. 디자인 크리틱 세션을 구성하라.
어떤 리뷰 회의는 분명 처음에는 UI 리뷰로 시작했는데 진행하다 보니 사용자 이야기가 나왔다가, 다시 Stakeholder 이야기로 넘어가고, 결국 기존 UI는 전혀 정리되지 못한 상태로 끝마치는 기가 막힌 경험을 할 때가 있다. 이런 현상을 방지하기 위하여 GV에서는 어느 정도 구조화된(Scheduled) 디자인 크리틱 세션을 구성할 것을 조언한다. 이렇게 함으로써 리뷰 시간에는 적절한 사람(고객 서비스 담당자, 영업사원 등)들을 참여시킬 수 있게 되며 그라운드 룰을 정하여 회의 전체적인 목적과 방향을 명확하게 할 수 있게 된다. 유연한 회의 진행을 위하여 퍼실리테이터를 참여시킬 수 있다면 더욱 좋다.
2. 디자인 크리틱 가이드라인을 준수하라.
기본적으로 사람들은 어떤 대상에 대해 칭찬하는 사람보다 비판하는 사람을 더 전문적이라고 느낀다고 한다. 긍정적인 기억보다 부정적인 것을 더 강하게 기억하는 경향에서 기인한다. 우리는 크리틱 할 때 서로에게 너무 기억되려고 하는 것은 아닐까. 크리틱이라는 단어가 자체가 가지는 비평이라는 의미 때문일지도 모르겠다. 지나치게 비판적인 성향으로 흐르는 것을 방지하기 위해 GV에서는 크리틱 가이드라인을 만들어 일종의 그라운드 룰로 삼으라고 한다. 가이드라인은 다음과 같다.
1) 솔직하게 까라(Be candid)
이런 사람 꼭 있다. 의견 교환할 때는 가만히 있다가 뭔가 잘못되면 '거봐 내가 그럴 줄 알았다니까' 하는 사람(...) 크리틱 시간에는 참석자의 역할과 관계없이 본인이 의심 가는 부분과 솔직한 의견을 투명하게 교환하는 것이 중요하다. 크리틱 받는 사람의 입장에서도 듣는 사람이 뭔가 꿍꿍이가 있다고 생각하면 그 시간이 끝나도 찜찜하다.
2) 구체적으로 까라(Be specific)
이런 사람도 꼭 있다. "이건 좀 별론데..?"라고 말하고서는 왜냐고 물으면 딱히 이유를 대지 못한다. 보통 지위가 높고 제품에 대한 지식이 부족하면 이런 식으로 말하는 경우가 많은데 그럼 그 아래 관리자들이 그것에 대해 적당한 이유를 만들어주려는 경향도 있다. 누군가를 비판하기 위해서는 본인도 그만큼 준비되어 있어야 한다.
3) 목표지향적으로 까라(Tie everything to goals)
디자인 크리틱 자리는 누가누가 더 잘 까나를 보기 위한 자리가 아니다. 그 팀에 도움이 주기 위한 건전한 비평 자리다. 따라서 그 팀과 프로젝트 목표를 기준으로 비평해야 한다. 예컨대, 첫 번째 UI 스케치를 마친 팀에게 '버튼 색상이 더 눈에 띄어야 하지 않을까?', '가독성이 좀 별론데?'라고 하는 것은 그 팀에 별로 도움이 되지 못한다는 이야기이다.
4) 칭찬도 곁들이면서 까라(Affirm what's working)
크리틱 중에도 정말 제대로 되고 있는 것들은 확실하게 좋다고 말해줘야 한다. 그렇지 않으면 다음 이터레이션에서 그 아이디어는 소리 소문 없이 사라져버릴지도 모른다.
5) 해결책보다 문제를 찾아줘라(Problems first, then solutions)
몇몇 잘난 체하기 좋아하는 사람들은 문제보다는 본인의 아이디어를 말하는데 열을 올리는 경우가 있다. 문제를 우선 찾고 다 함께 솔루션을 찾는 것이 바람직하다.
6) 지시하지 말고 제안하라(Suggestions, not mandates)
실제로 우리 팀에서 하는 디자인 리뷰는 누가 이야기 하든 '제안'이다. 그 아이디어를 받아들일지 말지는 디자이너가 결정한다. 몇몇 추상적이고 상징적인 아이디어는 구체적인 아이디어보다 좋아 보이기 마련이다. 디자이너에게 새로운 아이디어를 찾을 수 있는 영감을 주는 코멘트면 충분하다.
7) 즐겁게 까라! (Have fun!)
무겁지 않은, 유머가 함께하는 크리틱 자리는 더 많은 인사이트를 발견하고 디자이너 스스로 아이디어를 찾을 수 있게 자극을 준다고 생각한다. 까도 즐겁게 웃으면서 깝시다!
3. 크리틱 환경을 조성하라.
디자인 크리틱 자리를 마련한 사람이라면 다짜고짜 화면 결과물부터 보여주어서는 안된다. 왜 이런 결과물이 나왔는지에 대해 참여한 사람들이 충분히 이해할 수 있는 환경을 만들어라. 그렇게 모든 참여자들이 프로젝트나 결과물에 대한 컨텍스트를 명확히 이해할 때, 건강한 크리틱을 할 수 있다. 이때 준비해야 하는 내용들은 비즈니스/고객의 목표, 프로젝트 일정 및 제약사항, 이전에 합의된 내용 등이다.
4. 고객 경험을 재현하라.
GV에서는 단순히 한 화면을 놓고 넘겨가며 크리틱 하는 것이 아니라 간단한 프로토타이핑 툴(Keynote, Flinto 등)을 이용하여 실제 화면을 만들고, 사용자의 스토리에 맞춰 참석자들이 그 컨텍스트 흐름에 따라 크리틱 할 수 있게 유도하라고 충고한다. 여기에서 가장 공감 가는 항목은 Don't pitch hard인데, 설명이 많이 필요한 UI는 대부분 좋은 UI가 아니기 때문이다.
처음 봤을 때는 그런가 보다 했는데, 진짜 그렇다. 설명에 많은 시간을 투자해야하는 디자인은 대부분 나중에 더 나은 아이디어로 변경되는 일이 잦았다.우리는 모든 UI에 대해 의도를 가지고 있지만 일일이 모두에게 설명할 수는 없다. 그저 그 화면에서 사용자가 어떤 과업을 수행하게 될 것인지만 간단히 설명하자
5. 피드백을 수집하고 토론하라.
이제 남은 일은 디자인에 대해 참여자들의 생각을 묻는 일이다. 디자인된 화면을 회의실 내에 붙여놓고 참여자들 각각의 의견을 자유롭게 이야기할 수 있게 해야 한다. 실제로 우리 팀에서는 디자인 리뷰 시, 먼저 디자이너가 빔프로젝트에 프로토타입(Invisionapp)을 띄워서 모든 팀원(PM, DEV)들에게 사용 시나리오를 설명한다. 그다음 누구든(심지어 디자이너라고 하더라도) 특정 화면에 대해 질문이 있다면 포스트잇에 작성하여 붙인다. 디자이너는 그 질문에 대해 응답하거나 / 무시하거나 / 반영하거나 할 수 있다. 그것은 전적으로 디자이너의 판단에 맡긴다.
우리팀 디자인 리뷰사진, 특정 화면에 저렇게 많은 포스트잇이 붙어있으면 더 고민이 필요하다는 의미이다. 이러한 방식은 굉장히 효율적이다. 작은 문제를 토론하느라 시간을 허비하는 현상을 막아준다. 또한 전체 팀원들이 지금 이터레이션 내 이슈가 무엇이고 어떻게 풀어갈 것인지 준비할 수 있는 시간을 준다.
마치며
빡센(?) 크리틱 하는 것으로 유명한 픽사에서는 '브레인 트러스트'라는 회의를 통해 신작 스토리에 대한 크리틱을 진행하는데, 그들이 가장 중요하게 생각하는 가치는 솔직함이라고 한다. 그 솔직한 피드백이 나오는 원천은 우리 모두 한 배를 탄 처지라는 생각, 그리고 우리 모두 같은 일을 경험한 적 있기 때문에 당신의 고통을 이해한다는 공감과 신뢰를 기반으로 한다.
GV에서도 몇 번의 반복을 통해 팀원들이 방법에 숙달되고 나니 가이드에 구애받지 않고도 더 빠르고 생산적인 크리틱을 할 수 있었다고 한다. 결국 정말 중요한 것은 크리틱 하는 사람과 받는 사람의 자세일 것이다. (조금은 뻔한 결론이긴 하다.) 그럼에도 불구하고 수많은 리뷰 때문에 고통받고 있는 디자이너들이 좀 더 생산적인 크리틱 회의가 되는데 이 글이 조금이나마 보탬이 됐으면 좋겠다.
