'프로덕트 원칙'을 차근 차근 만드는 4단계
프로덕트 원칙을 만든다고 생각하면 어떻게 시작할지 막막합니다. 자료를 찾아보면 '좋은 프로덕트를 만들기 위한 원칙'의 종류나 범주가 너무 다양하고 많기 때문입니다.
이러한 원칙의 바다에서 즐겁게 유영하고 학습하며, 우리 팀에 꼭 필요한 원칙을 4단계로 차근차근 만들어가 보아요.
프로덕트 원칙(Product Principles)이란?
원칙이란 일관되게 지켜야 하는 기본적인 법칙을 의미합니다. '프로덕트 원칙'이란, 이 프로덕트를 만드는 사람들이 '프로덕트를 만들 때 일관되게 지키겠다고 합의한 기본적인 법칙'을 말합니다. 프로덕트를 만들 때 일관되게 지킬 원칙이 필요한 이유는 두 가지입니다.
1. 사용성이 좋은 프로덕트를 만들기 위해서
2. 우리 프로덕트는 '어떻다'라는 경험을 사람들에게 알리기 위해서
사용성이 좋아야 AU 수, Stickiness, Retention이 올라갑니다. 우리 프로덕트는 '어떻다'가 일관되게 보여지면 Awareness, Loyalty에 긍정적인 영향을 줍니다.
프로덕트 원칙을 만들 때는 위 두 관점을 분리해서 생각해 보는 것이 좋습니다.
Step1. 인지 부하를 줄이는 원칙 선별하기
- 사용성이 좋은 프로덕트를 만들기 위해
프로덕트 사용성이 좋다는 말은 프로덕트를 사용하는 것이 쉽고 즐겁다는 것을 말합니다. 즉, 사람이 작업을 수행하는데 필요한 정신적 노력의 총량(Cognitive Load, 인지 부하)이 적다는 것을 말합니다.
인지 부하를 줄이는 방법은 검증된 방법은 이미 있습니다. 따라서 정보 인식 및 처리, 형태 인식과 관련된 원리를 학습하고 우리 프로덕트에 적합한 원칙을 선별합니다.
인지 부하를 줄이는 원칙의 예를 들어보겠습니다.
우리는, 사용자에게 필요한 최소한의 것만 제공합니다.
기능이나 설명을 많으면 더 전문적일 것 같지만, 정보를 너무 많이 주면 사람은 오히려 결정을 못 하는 분석 마비(Decision Analysis) 상태가 된다고 합니다. 선택지가 많으면 더 친절한 것 같지만, 사람이 한 번에 인지적으로 기억하고 처리할 수 있는 정보는 최대 7개라고 합니다.(Miller's law) 따라서 사용자에게는 해당 태스크를 수행하는 데 있어 필요한 최소한의 것만 제공해야 프로덕트가 쓰기 쉽다고 느낍니다.
정책은 적으면 적을수록 좋다(Less policy), 없으면 안 되는 피처만 남긴다(Minimum features), 메뉴 선택지는 적으면 적을수록 좋다(Present few choices)와 같은 원칙은 모두 사용자에게 필요한 최소한의 정보만 제공하는 계열의 원칙입니다.
우리는, 사용자가 다음에 일어날 일을 예상할 수 있게 합니다.
이 버튼을 누르면 어떤 일이 일어날지 알 수 없는 경우 사람들은 순간적으로 선택을 할 수 없어 인지 부하가 늘어납니다. 사용자가 당연히 알 것이라고 우리가 생각하는 대부분의 것을 사용자는 모릅니다.
이 행동을 하면 다음에 어떤 일이 일어나는지 알려준다(Predictability), 사용자가 실수하지 않도록 장치를 제공한다(Error prevention), 실수를 하면 돌이킬 수 있어야 한다(Recovery from errors)와 같은 원칙이 예측 가능성과 관련된 원칙입니다.
우리는, 사용자가 접하는 하나의 페이지에 핵심 기능을 한 개만 넣습니다.
프로덕트에 피처가 많아지면서, 나중에 추가한 피처를 강조하기 위해 색을 강하게 하거나 폰트 사이즈를 키우는 경우가 있습니다. 물론 나머지 피처가 시각적으로 돋보이지 않는다면 지표 상승효과를 가져올 수 있습니다. 하지만 어느 순간이 되면 모든 피처가 다 강조되어 아무것도 눈에 띄지 않는 부작용이 생기기도 합니다.
유저에게 가장 중요한 기능이 아닌 시각 요소는, UI적으로 정보를 묶고 분류하여 덩어리로 느낄 수 있게 합니다. 게슈탈트 법칙(Gestalt principles)을 이해하고 차용하면 좋습니다.
Step2. 우리 회사 다움을 보여주는 원칙 만들기
- 우리 프로덕트는 '어떻다'라는 경험을 사람들에게 알리기 위해
우리 회사에 맞는 원칙을 우리가 만드는 것입니다. 인지 부하를 줄이는 원칙과 달리, '우리 회사 다움을 보여주는 원칙'은 절대적으로 맞는 원칙이 있지 않습니다. 우리 회사에 맞게 프로덕트 경험을 구성하는 컬러, 형태, 글의 투 등을 정의하는 과정입니다. Brand visual language, Product design system, UX wirting guideline 등과 같이 독립적인 원칙이나 가이드라인으로 있는 경우가 많은데 이 또한 프로덕트 원칙의 한 계열입니다.
Step3. 프로덕트 개발 단계 중, 어떤 단계에서 어떤 원칙이 필요한지 매핑하기
위 그림에서처럼, 어떤 단계에서 어떤 원칙을 특히 더 지켜야 하는지를 할당합니다. 기획을 하며 혹은 디자인을 하며 모든 프로덕트 원칙을 다 지키려고 하면 오히려 하나도 지키지 못할 수 있습니다. (여기서도 인지 과부하가 일어났네요!)
PO는, 요구사항을 정의할 때 필요한 최소 정책/기능/설명만 제공하겠다는 것을 중점적으로 생각합니다. 프로덕트 디자이너는, 정보 구조를 정의할 때 다음 단계를 예상할 수 있게 하겠다는 것을 집중적으로 생각합니다. UI디자이너는, 화면을 구성할 때 시각 요소를 묶고 강약을 구분하겠다는 것에 집중합니다.
Step4. 우리 프로덕트에 필요한 원칙만 최소로 남기기
여기서도 인지 부하를 줄이는 원리가 적용됩니다. Step3까지 진행하고 나면 우리 회사에 필요할 것 같은 많은 원칙 리스트가 나왔을 것입니다. 그러면 이 중에서, 개념적으로 묶을 수 있는 것은 묶고 없어도 되는 것은 버리면서, 최대 7개(Miller's Law!)까지만 남겨 우리 팀이 외울 수 있게 합니다.
물론, 적으면 적을수록 좋습니다.
프로덕트 원칙은 정의하는 것보다, 정의한 후 지키는 것이 훨씬 중요합니다. 회사 상황에 따라 다음과 같은 장치를 적용해 볼 수 있습니다.
프로덕트 기획 문서에 체크리스트 형태로 넣기
프로덕트 리더들이 모여, 프로덕트 원칙 검수 위원회를 정기적으로 열어 점검하기
강력한 한 사람의 검수자가 주기적으로 리뷰하기
프로덕트 원칙은, 원칙을 위한 원칙이 되어서는 안 되며 회사나 프로덕트 발전 방향에 따라 유연하게 더해지거나 삭제할 수 있습니다. 궁극적으로 프로덕트를 만드는 모든 사람들이 사용성이 좋고 우리 회사 다운 프로덕트를 만드는 방법을 내재화하여 원칙이 필요없어지면 가장 좋습니다. :-)
