안녕하세요, 에블린입니다! 지난 글에서 디자이너의 역할과 가져야하는 마음가짐에 대해 살펴보았습니다. 실천편에서는 이를 활용하는 실질적인 이야기를 할 것입니다. 발표에서 못다한 이야기를 자세히 풀고자 아예 새로 쓰여졌습니다. 본문에 제공하는 디자인 가이드는 팔라에서 쓰는 것은 아닙니다. 여러 자료를 참고하여 제가 생각하는 방향으로 새로 정리했습니다. 발표에 쓰였던 팔라 디자인가이드는 굉장히 축약한 내용이었는데 글의 맨 하단에 달아두었습니다.
지난 글 요약
- 프로덕트 :
사용자의 문제 해결과 새로운 가치 창출을 위해 존재, 팀이 모여있는 이유이자 팀의 염원 O / 디자이너의 작품 X
- 프로덕트 디자이너 역할 :
사용자의 문제를 깊이 이해하여 구성원들과 함께 고민하고 이를 설계하는 것 → 새로운 가치 창출. 미적인 작업을 하는 그 이상 O / 개인의 창작 욕구 실현 X
- 평가의 대상 :
프로덕트 O / 프로덕트 디자이너 X
- 생각의 전환 :
내부 의견 수집 반영 → 다수에게 유용하고 견고한 프로덕트 설계한다는 개념으로 접근 O (능동적) / 디자이너가 작업한 디자인을 비디자이너에게 평가받는다는 생각 X (수동적)
성공하는 기버로 ‘지속적인 조언과 도움을 요청’하는 것은 내적에너지를 빠르게 회복시키는 방법입니다. 디자인 작업물에 대해 ‘나의 업무를 평가 받는다’라고 생각지 마시고 ‘내부 구성원으로부터 필요한 데이터를 얻는다’라고 생각하시면 좋겠습니다. 그러기 위해서는 먼저 디자이너가 질문을 해야합니다.
전체 디자인 프로세스에서 스프린트를 시작하면 PM은 PRD(Product Requirements Document)를 팀에게 제공합니다. 이때 PRD는 구체적이기보다 방향성에 초점이 맞추어져 있습니다. 초기에 작성되고 요약되어 있기 때문에 구성원들은 이 자료만으로 구체적인 화면을 구상하기 어렵습니다. 이를 가시화하고 구체화하는 역할을 프로덕트 디자이너가 하는 것입니다.
PRD는 해당 스쿼드의 PM이 주도하여 진행하는데 상황에 따라 리드 미팅에서 탑다운으로 정해져 올 수도 있고 스쿼드 조직에서 바텀업으로 결정할 수도 있습니다. 구성원은 이 기능이 어떤 비즈니스 목표와 가치를 지니는지 또는 사용자는 어떤 의도를 가지고 진입하여 어떤 목적을 달성할지와 같은 제품의 목적과 방향에 대해 모두가 명확히 인지해야합니다. 일관된 내용으로 합의하고 함께 고민하기 위함인데, ‘PRD 질문 사항 가이드’를 참조하시면 PRD를 검토할 때 도움이 될 것 같습니다.
디자이너는 스프린트가 시작됨과 동시에 디자인 작업이 들어갑니다. 구체적이기보다 방향성에 초점을 맞춘 PRD를 토대로 화면 설계를 진행하다 보니, 작업 중 논의해야 할 상황이 빈번히 발생합니다. 스프린트가 진행됨에 따라 기능이 더욱 발전되거나 예상치 못한 변수에 따라서 기능의 변경사항이 생길 수 있습니다. 그래서 이때 디자이너가 가장 바쁜 시기임에도 구성원들과의 난이도 높은 커뮤니케이션 능력이 요구되는 것입니다.
이는 가급적 디자인이 초기에 진행될 때 많은 논의를 거치는 것이 좋습니다. 아래의 장표를 보시면 스프린트의 끝으로 갈수록 디자인 개선은 여러 리스크가 발생하게 됩니다. 스프린트가 끝나면 다음은 다른 기능이 기다리고 있기 때문에 한번 진행할 때 최대한 잘 만들어 놓아야 합니다.
디자인이 진행됨에 따라 내부 구성원을 단계별로 참여시키기 위한 방법들을 설명드리겠습니다. 최종적으로 모든 화면의 작업이 완료될 때까지 크게 작게 4–5번의 디자인 리뷰를 거치게 됩니다. 마지막 디자인리뷰를 제외하고 거창하게 하지 않아도 됩니다. 매일 진행하는 스크럼이나 위클리 미팅에서 단계별로 공유해야하는 상황에 유기적으로 논의하면 됩니다.
여기서 무작정 구성원의 의견을 수용하는 것이 아니라 이기심도 가진 이타심으로 유효한 피드백은 얻되 내적에너지를 덜 소모시키는 방법으로 디자이너가 먼저 질문을 던져야 합니다. 구성원들에게 과제를 내주어 디자인 리뷰에 구조 설계 검토, 시각 요인 검토, 사용성/인터렉션 검토를 요청할 것입니다.
디자인리뷰 시간에는 꼭 확인해야하는 요소를 먼저 검토해야 합니다. 이 기능이 비즈니스 의도와 맞게 유용하게 설계되었는지, 사용자는 학습없이 이 기능을 원활히 사용할 수 있는지, 중요한 메시지 전달에 가독성은 괜찮은지, 플로우를 더 단순화할 수 있는지 등에 대한 리뷰를 통하여 충돌하는 사용성을 미연에 방지하고 더욱 견고한 제품을 만들 수 있습니다.
이에 따른 기대 이익 효과는 구성원과 디자이너 모두에게 있습니다. 구성원들은 자신의 의견을 디자이너가 수용한다는 점과 프로덕트에 반영이 되어 좋고 디자이너는 능동적으로 제품에 필요한 사용성을 평가를 해서 이득입니다. 디자이너는 능동적으로 팀 모두가 함께 참여하도록 만들어야 합니다.
디자인리뷰에 가이드를 제공하지 않으면 간혹 일부 구성원이 자신의 의견이 모든 사용자를 대변하는 것으로 생각해 사용자의 관점이나 디자이너의 의도를 고려하지 않고 주관적인 개인의 생각이나 취향이 담긴 저마다의 의견을 내는 경우가 있습니다. 좁혀지지 않는 의견에 누군가는 쉽게 피로함을 느끼기도 하고 조용한 구성원은 자신의 개인 의견을 내는 것에 불편함을 느낄 수 있으며 또 특정 목소리 큰 사람의 의견에 휩쓸릴 수도 있습니다.
이는 조직 모두의 내적 에너지를 손상시키고 사용자와 조직을 위한 옳은 선택에 혼란을 야기하게 됩니다. 개인적인 의견은 따로 작성하는 칸을 제공하거나 별도의 시간에 의견을 제시하도록 합니다. 실제로 유용하고 꼭 필요한 의견이 나오면 백로그로 남겨두어 다음 스프린트에 적용하도록 하고 새로운 스프린트가 시작되기 전에 다시 논의되는 것이 좋을 것 같습니다.
1. 평가 기준을 놓고 항목을 평가하는 사용자 평가는 정보가 쌓이면 데이터가 됨 -> 추가 질문과 의견은 따로 받으면 됨
2. 타 직무의 구성원은 의견을 화면으로 시각화 하는 것에 익숙치 않음 -> 사용성에 대한 가이드가 필요함
3. 규칙이 없으면 소리 큰 사람이 기준이 될 수 있음. 조용한 사람은 의견을 내기 불편해함 -> 모두의 생각을 수집해야 함
4. 모두가 다른 영역을 이야기하면 각 내용에 객관화가 어렵고 정작 평가해야할 내용을 놓칠 수 있음 + 개인의 생각을 사용자의 생각으로 일반화 할 수 있음
5. 디자이너의 내적에너지를 지키면서 유효한 피드백을 얻기 위함
6. 효율적인 시간 활용 등등
디자인 리뷰를 무섭고 에너지 소모가 큰 피곤한 시간이라 생각할 것이 아니라 프로덕트 디자인에 유용한 정보를 얻는 효율적인 시간이라고 생각하시면 좋겠습니다. 아무리 뛰어난 디자이너도 한 두명이 객관성을 갖춘 프로덕트는 만들기 어렵습니다. 고객데이터가 충분하지 않은 Web3 환경에서 내부 구성원을 적극 활용하셔서 Web3.0의 표준이 되시길 바랍니다!
지난 글 작성할 무렵에 이미 크립토 겨울이 왔었는데,, 더 추운 윈터가 있었습니다. 엉엉. 세계 경제 시장이 매우 불안정한 상황에서 감히 Web3의 미래를 재단할 순 없지만. 창작자 중심의 소유의 인터넷은 점점 확장되고 가까운 미래에 새로운 형태의 서비스가 많이 생길 것 같습니다. 딱히 표준이 없는 Web3의 표준이 될 수 있는 절호의 기회.. 당신이 할 수 있습니다…!
+ ‘뜻깊은시월드:실천편’의 내용으로 밋업 당시 발표때는 아래의 두 장표로 축약해서 들어갔습니다.
그럼 다음에 또 도움되는 내용으로 찾아오겠습니다.
글이 괜찮으셨다면 라이킷버튼 부탁드립니다!