2021. 4. 9. 07:50ㆍUI 가벼운 이야기
들어가며
최근 제조업에서 디지털 트랜스포메이션(Digital Transformation) 프로젝트를 컨설팅부터, 양산 그리고 운영 및 개선까지 1년 6개월 동안 프로덕트를 리딩하면서의 경험을 정리해보고자 합니다.
UX, 서비스 컨설팅
저는 '서비스 디자이너'로 활동하고 있습니다. 서비스디자이너는 사용자 경험뿐만 아니라 서비스 및 프로덕트가 가지는 전체적인 가치를 고려하는 부분이 필요합니다. (많은 회사가 이런 부분을 프로덕트 오너가 가져가고 프로덕트 디자이너는 더 디자인과 사용성에 전문화하는 방향으로 나아가는 것 같습니다).
"어떻게 프로젝트를 시작하나요?"
UX, 서비스 컨설팅은 사람 혹은 사용자를 분석하여 어떤 것들을 개선할 수 있는 Intervention Point를 찾고 Oppirtunity를 발견하여 서비스 혹은 프로덕트를 만들 수 있는 가치를 제안하는 과정을 말합니다. (최근에 컨설팅의 많은 부분이 사람을 중심으로 진행되면서 이러한 과정을 하는 디자이너를 Business Designer라고 명시하기도 합니다). 이를 위해서는 기존의 전통적인 컨설팅 방법과는 달리 실질적인 사용자 조사가 필요합니다 (이 부분이 오늘날 말하는 UX Researcher가 주도해나가는 부분이 아닐까 싶습니다). B2B 프로젝트의 경우 프로젝트의 목적성을 구체적으로 가지고 시작하는 경우가 많기 때문에 사용자의 세그먼트가 쉽습니다. 사용자의 범위를 좁히고 실질적인 사용자를 리서치하는 것을 통해 전체적인 서비스, 프로덕트의 전략적 방향성이 설정되어야 합니다.
이러한 과정을 통해 전반적인 프로젝트의 방향성 및 컨셉을 도출하여 실질적인 프로덕트를 디자인하고 설계하는 양산 과정을 진행할 수 있습니다.
양산
컨설팅 단계에서 전체적인 서비스, 프로덕트의 방향성 및 콘셉트가 정해졌다면, 실질적인 프로덕트의 설계를 시작할 단계입니다(여기서부터 프로덕트 디자이너가 주도해 나가는 부분이 아닐까 싶습니다). 프로덕트를 설계 및 개발하는 데에 있어서 여러 분야의 전문가들이 협동하는 것이 필요하기 때문에 협력의 효율이 가장 중요한 요소중 하나가 될 수 있습니다.
"어떻게 효율을 극대화 하나요?"
양산과정에서 1+1 = 2+@가 되거나 2-@가 될 수 있기 때문에 협업의 방법과 과정이 아주 중요하다고 생각되며 디자이너가 이의 핵심이 될 수 있다고 생각합니다. 왜냐하면
프로덕트가 양산 프로세스의 커뮤니케이션에 중심에 있기 때문이고, 둘째는 프로덕트 디자이너가 프로덕트에 대해서 모든 것을 알고 있기 때문이며, 셋째는 디자이너가 여러 가지 생각을 효과적으로 전달하는 도구를 가지고 있기 때문입니다.
- 커뮤니케이션 : 함께 일하는 개발자뿐만 아니라 클라이언트(여기서는 PO, Product Owner라고 볼 수 있습니다)까지 함께 의사 결정을 하는 팀으로 생각하고 커뮤니케이션을 진행하면 의사결정의 시간이 조금이나마 줄어듭니다.
- 미팅 : Scrum은 개발회의라고 생각하지 마시고 함께 참여하면 개발자들의 속도가 확실히 빠릅니다. 아무리 설명회를 가지고 가이드 문서를 친절히 작성하였어도 직접 개발자들이 고민하는 부분에 대해서 듣고 답해주는 것만 못합니다. 따라서 여건이 된다면 Scrum에 참여하시는 것이 좋은 것 같습니다. 또한 개발자 설명회 미팅을 통해 서비스 초기 혹은 새로 설계되는 플로우에 대해서 개발자 전원에게 소개하는 자리로 이를 통해 전체적인 프로세스의 병목현상을 최소화할 수 있었습니다.
- 디자인 시스템 : 디자인 시스템은 프로젝트 내에서의 병목현상을 최소화합니다. 잘 설계된 디자인 시스템은 비주얼 디자이너와의 의사소통 그리고 나아가 퍼블리셔, 개발자들과의 커뮤니케이션에서 소비되는 시간을 줄일 수 있었습니다.
운영 및 개선
프로덕트를 개발하였다면 QC(Quality Control), QA(Quality Assurance)가 필요합니다. QC과정은 프로덕트의 기능을 설계한 프로덕트 디자이너가 참여하여 함께 사용자 테스트를 진행하면 효율성 및 진행속도가 높은 경향이 있습니다. QA는 궁극적으로 이를 기반으로 프로덕트의 품질을 확인하는 단계로 프로덕트 오너의 결정이 중요합니다 (QC와 QA를 잘 비교한 사이트). 이 과정에서도 프로덕트 디자이너가 함께 참여하여 프로덕트 오너의 의사결정을 함께 하는 것이 필요합니다.
프로덕트를 릴리즈하였다면 그동안 쌓아온 실질적인 팀워크가 요구됩니다. 쏟아지는 VoC 및 오류를 해결하기 위해서 프로덕트 오너와 프로덕트 디자이너 그리고 개발 리더가 함께 우선순위를 선정하여 어떤 항목부터 해결을 할지를 설정하고 스케줄에 맞게 프로덕트의 완성도를 올려가는 것이 필요합니다. 이를 위해서 전체적인 팀원의 스케줄의 고려가 필수적으로 요구됩니다. 또한 개선이 필요한 사항들은 따로 정리하여 이후에 다음 버전 배포 시 활용할 수 있어야 하겠습니다.
"언제 다음 버전을 어떻게 올릴까요?"
"우리는 흔히 데이터가 먼저 있어야 의사결정도 있다고 생각하기 쉽지만, 실은 의사결정 프로세스에 데이터가 가미되는 것이다."(데이터 리터러시 p55)
프로덕트의 개선을 위해서는 개발팀에게 정확하게 어떤 것들을 파악하기 위해 데이터가 필요한지 정확히 전달하여 의미 있는 데이터(Actionable Data)를 전달받아 프로덕트를 개선할 수 있습니다. 백앤드 개발자들이 DB의 구조를 설계하여 데이터를 쌓고 있는데, 프로덕트 디자이너의 이러한 고려사항이 전달되지 않는다면 DB구조는 프런트(화면)를 위해서만 고려되어 실질적으로 개선을 위한 데이터를 획득하는 것이 어려워질 수 있습니다. 디자인을 하면서 어떤 부분에 대해서 이후에 개선이 필요할 것 같다는 부분이 있다면 정확하게 개발자들에게 요청하시는 것이 필요합니다.
마치며
최근 디지털 트랜스포메이션이 실질적인 프로덕트나 서비스에 영향을 미칠 뿐만 아니라 일하는 방식에서도 여러 가지 변화를 일으키고 있는 것 같습니다. 프로세스가 빠르게 진행됨에 따라 각각의 인원들은 더욱 전문성(프로덕트 오너, 프로덕트 디자이너, UX 리서처 등)을 가지게 될 뿐만 아니라 각 단계에서 어떤 인원이 리드해서 진행해야 할지가 더욱 뚜렷해지는 것 같습니다. 또한, 이에 따른 의사결정의 방식을 더욱 효율적이고 논리적으로 하는 방식(데이터를 활용하는 등)에 초점이 맞춰지고 있는 것 같습니다. 따라서, 여러 협업 방식이나 커뮤니케이션 방법(조금 더 린하고 애자일 하게)에 대한 고민도 함께 고민되고 있는 것 같습니다.
이 글을 통해 다시 한번 1년 반 동안 많은 가르침을 주신 동료분들께 감사드리며, 이번 글도 읽어주셔서 고맙습니다.
이 글은 Minwoo Kim의 브런치에서도 보실 수 있습니다.