Take feedback only if it makes sense
10월이 되고 나서,
지난 분기에 다른 팀으로 이적을 요청한 팀원 A를 계획대로 떠나보냈다.
워낙 부지런한 성격의 팀원이라 대부분의 할당된 업무들은 잘 마무리하고,
마무리 안된 나머지 일들은 나와 다른 팀원 B에게 인수인계를 했다.
그 뒤에도 일주일에 한 번 있는 디자인 리뷰하는 시간마다 마주치는데,
새롭게 맡은 프로젝트들을 재미있어하고, 그 프로젝트가 풀려고 하는
사용자 문제에 접근을 잘하고 있는 것 같아서 새삼 뿌듯했다.
사실, 그 팀원 덕분에 아직까지도 직접 그 친구의 디자인 QA를 하고 있다는 건 덤이다.
타이밍이라는 게 언제나 완벽하지 않아서,
내부적 사정으로 채용공고를 통해 새로운 사람을 뽑을 수 없었고
이가 없으면 잇몸이라고 현재 다른 프로젝트를 하는 팀원 B가
하던 프로젝트가 마무리되는 대로 떠난 그 팀원의 빈자리를 채우기로 했다.
2주 정도 시간을 두고 지금 진행하고 있는 프로젝트를 마무리를 짓기로
팀원 B와 진행하고 있는 프로젝트의 개발자 리드,
그리고 떠난 팀원의 팀의 PM, 개발자 팀장과 입을 맞추었다.
3주가 지나서도,
어느 정도 마무리되었다고 생각했던 프로젝트를 붙들고 있는 팀원 B를 발견했다.
'뭐지... 결정한 디자인을 왜 다시 Iteration을 하지?'라는 궁금증과 함께, 디자인을 변경하는 이유에 대해 물어보았다. 처음에는 그럴듯한 이유를 대더니, 조금 더 구체적으로 물어보자 "개발자 팀장이 마음에 안 든다고 했어 (Engineering manager wasn't a fan of the original design)."라고 대답했다. 그러면서 내가 피드백 준거는 다시 원래대로 가는 거라며 나와 그 개발자 팀장 사이의 의견 조율을 교통정리를 요청했다.
바로 그 개발자 팀장에게 따로 1:1 메시지를 보냈다. 팀원 B에게 기존의 디자인이 마음에 안 든다고 이야기한 이유가 내가 모르는 개발 상의 어려움 때문에 그런 건지, 아니면 단순히 개인적인 견해인 건지 물어보았다. 그러자 바로 개인적인 견해라고 전하며, 기존의 디자인으로 진행해도 괜찮다는 답변을 받았다.
이 이야기를 팀원 B에게 전달하면서 다음과 같은 이야기를 곁들였다.
1) 다른 사람들의 피드백은 경청하되,
2) 디자인에 반영할지 말지의 최종 결정권자는 팀원 B 자신이라는 말과
3) 피드백을 반영하여 기존 디자인을 변경할 시, 그 이유에 대해 기술해 달라고 부탁했다.
그랬더니, 팀원 B가 고맙다며
지난 회사에서 자아(ego)가 너무 강하다는 피드백이 있었어서,
이번에는 팀 사람들의 이야기를 최대한 수용하고 싶었다고 이야기했다.
피드백 관련된 내용을 찾아보니, 공감이 가는 글이 있어 소개하고자 한다.
디자이너는 뒷받침하는 다음과 같은 강력한 이유들 없이 단순히 "이 옵션이 더 나아"라고 말해선 안된다.
- UX logic에서 파생되었거나,
- Industry 경험을 통해 나왔거나,
- 사용자 리서치를 통해 알아낸 내용이거나,
- 다른 출처들에서 나온 사실 데이터 (hard data)이거나
- Industry best practices에서 나왔거나
You’re not allowed to say “I like this option better” without backing that up with a strong mixture of:
- UX logic
- Industry experience
- User testing
- Hard data from other sources
- Industry best-practices
Source: How to give and receive great design feedback