프로덕트 디자이너
(이전 글: https://brunch.co.kr/@hvlog91/26)
피드백이 좋은 것들도 있겠지만 대부분이 어떻게 피드백해야 하는지 몰라 주관적이거나 디자인 외 피드백을 하는 경우가 많았다. 이런 경우 의도치 않게 마음이 상하거나 원치 않은 피드백으로 결과물에 악영향이 있는 경우가 종종 생기기도 한다.
내 경우 여러 회사를 다니며 결과물을 공유하기 전, 후 모든 상황에서 피드백을 받아보고 적용해봤을 때 좋은 피드백이 결국 좋은 결과물에 도움이 되는 것을 느꼈다. 이후 피드백을 받을 때 최대한 좋은 쪽으로 받기 위해 어떤 행동을 했고, 어떤 결과가 있었는지 공유해보려고 한다.
단, 누군가는 이 방법이 좋을 수 있지만 회사마다 상황이 다를 것이고 각자 잘 맞는 방법이 있을 것이라고 생각한다. 각자의 절망스러운 상황에 맞게 적절한 액션과 그나마 나은 결과를 얻기 바래본다.
- 도움이 되는 피드백을 받고 싶다
- 모든 사람들이 도움이 되는 피드백을 하지 않는다
- 피드백하는 방법을 모르는 사람들이 많다
- 도움 되는 피드백을 받는다
- 도움이 될만한 피드백을 사람들이 하게 한다
도움이 되는 피드백을 하는 사람들을 만나서 피드백을 받는 건 쉽지 않다. 유니콘을 만나야 하는 것이니. 그러면 차라리 유니콘을 만드는 게 빠르지 않을까 생각했다. 말에 뿔과 날개만 달면 되니까. 즉, 유니콘처럼 행동하도록 교육하는 것이다.
좋은 피드백은 현재 문제를 파악해 건설적으로 피드백하는 것이다. 대부분 사람들은 10~20년간 피드백에 대한 교육을 받아본 적이 없을 것이고, 이런 교육에 대해 불편함을 가질 수 도 있을 것이라 생각했다.
1. 우선 산발적으로 들어오는 피드백들을 한자리에서 들을 수 있도록 이해관계자들을 모아 회의를 잡는다.
2. 회의 시작 전 디자인 피드백을 하는 것임을 강조한다. 그리고 기능보단 시각적인 부분을 이야기해야 함을 알게 한다. 또한 피드백하기 전 솔루션보단 자신이 바라본 문제에 관해 이야기할 수 있도록 한다.
(최대한 질문 형태로 이야기해볼 것)
3. 설명이 끝났다면 디자인 작업물을 설명한다
4. 피드백을 하기 전 생각할 수 있는 시간을 준다
5. 피드백 형태는 질문식으로 진행하게 한다
참여 인원이 말하는 피드백이 어떤 문제로부터 온 것인지 파악한다
문제를 해결하게 되면 얻게 되는 예상 효과를 물어본다
이야기가 나온 문제를 해결할 더 나은 방법이 있는지 다른 사람들과 토론한다
실제 피드백 시간을 진행하다 보니 참여 인원이 생각보다 잘 따라와 주었고, 피드백 자체의 퀄리티도 많이 오르게 되었다. 물론 중간중간 디자인 외 기능 자체에 대한 기획이 변경되는 일이나 디자인 피드백 외의 이슈들도 생기기도 했지만 최대한 잘 마무리할 수 있게 되었다.
여러 사람들이 피드백하다 보니 의견이 맞지 않을 때 내가 굳이 설명할 필요가 사라졌다
해당 시간에 참여하는 인원이 함께 프로덕트를 만들고 있다는 느낌을 전달할 수 있다
너무 많은 의견들이 나오는 경우 몇몇 의견은 무시하게 된다
여러 화면들에 대한 피드백을 받게 된 경우 시간이 너무 지체되는 상황이 생긴다
피드백 시간에 참여하는 인원들이 최대한 좋은 피드백을 남기려고 노력했으며, 피드백을 받는 시간이 정해지다 보니 산발적으로 들어오는 피드백을 관리하기 편해졌다.
이전엔 피드백이 너무나 고통스럽고 괴로운 한마디였다면 이젠 한약 같은 느낌이 든다. 먹고 나면 묘하게 에너지가 생긴 것 같고, 도움이 되는 것 같은 느낌이 드는 한약. 실제로 도움이 많이 되고 있고!
물론 지금의 해결방법도 나중엔 바뀔 수도 있지만 그땐 또 다른 좋은 방법을 찾게 되지 않을까 생각한다.
다른 분들은 피드백을 어떻게 받고 해결한 지 너무 궁금합니다.
혹시, 더 좋은 방법이 있었다면 댓글 부탁드립니다.
그럼, 다음 만날 때까지 조금이라도 고생 안 하는 디자이너가 되길 바라며...