Lynnda!

[아티클 스터디] 기획자가 알아야 할 서비스 평가 지표

yj_lynn — Fri, 19 Jan 2024 12:45:28 +0900

아티클 출처

많은 기획자(PM/PO)가 ‘데이터 분석’ 역량에 대해 고민할 것 같습니다. 실제 현업에서는 데이터 분석을 위해 기획자가 봐야 할 지표도 다양합니다. 그러나 자주 사용하는 지표가 아닌 이상, 모

yozm.wishket.com

내용 정리

☝ ▪️ 기획자로서 데이터 기본 지표(Metric)을 안다는 것은 어떤 데이터를 살펴볼 것인가? 라는 질문의 첫 단추가 될 것이다. ▪️ 서비스 평가 지표는 제품을 올바른 길로 나아가게 하는 방향키와 같다. ▪️ 기획자는 지표를 활용해 서비스 성공 여부 점검 및 이에 맞는 전략을 세울 수 있어야 한다. ▪️ 어떤 지표를 어디에 활용지 알아야 원활한 커뮤니케이션이 가능하고, 데이터에 근거한 의사결정을 내릴 수 있다. ▪️ 또, 지표의 목적을 완벽히 이해하고 서비스에 맞게 적용시, 데이터를 통한 의사결정은 물론 제품의 성장으로도 이어질 것이다.

서비스를 평가하는 지표는?

1️⃣제품 관련 지표

1) DAU / WAU / MAU (Day/Week/Monthly Active Users)

각각 하루, 한 주, 한 달 동안 제품을 사용한 유저를 측정하는 지표
통상 서비스 내 트래픽과 영향력을 측정하는 지표
현재 우리 서비스를 얼마나 많은 사용자가 이용하고 있는지 측정하기 위해 사용

2) 리텐션(Retention)

고객 유지, 얼마나 많은 사용자가 우리 서비스를 계속해서 이용하는 지를 측정하는 지표
서비스마다 리텐션 정의가 달라질 수 있음
e.g. 인스타그램 → 고객이 서비스를 계속 이용하는 것 e.g. 넷플릭스 → 고객이 해지하지 않고 구독을 계속 유지하는 것
보편적인 분석 방법 : D+N일에 대한 리텐션을 측정하는 방식, 보톡 D+7, D+30, D+60, D+90을 살펴봄

3) NPS(Net Promoter Score)

고객 만족도와 로열티를 수치로 나타내는 지표
실제 서비스를 이용하는 고객이 얼마나 만족하고 있는지를 정량화하여 측정
고객이 우리 서비스에 전반적으로 만족하고 있는가?
측정 방법
- 고객에게 ‘이 서비스를 지인에게 얼마나 추천하고 싶나요?’ 라고 질문 → 0~10점으로 답변받음
- 각 점수에 따라 세 그룹으로 나눌 수 있다.
  - 9~10점: 우리 서비스를 추천할 확률이 높은 ‘추천 고객’
  - 7~8점: 언제든 서비스를 떠날 수 도 있는 ‘중립적인 고객’
  - 0~6점: 서비스에 불만족하는 ‘비추천 고객’
- NPS 계산법: 응답한 전체 고객 중 추천 고객 비율 - 비추천 고객 비율

4) CVR(Conversion Rate)

전환율 = 전환수/클릭수 * 100 %
특정 페이지에 진입하여 다음 Step으로 이동한 비율 지표
사용자가 목표 행위를 수행한 비율을 측정하는 목적으로 사용
특정 페이지에서 고객 액션 유도를 목표로 할 때 성공률 판단하는 지표
e.g. A 페이지에 진입한 100명의 고객 중 B 페이지로 이동한 고객이 30명 → CVR = 30%

5) 고착도

DAU/MAU
사용자가 우리 서비스를 얼마나 오래 혹은 자주 사용하는지 충성도를 판단하는 지표
보통 고착도 10%가 평균, 20~25% 이상이면 충성도가 매우 높은 서비스
서비스를 열성적으로 이용하는 고객이 얼마나 되는지, 우리 서비스의 아이템을 봤을 때 적절한 수치인지 평가 가능
e.g. 고착도가 20% → 우리 서비스에 월간 활성 사용자가 한 달에 6일 정보 방문한다는 뜻

6) 이탈률(Churn Rate)

제품 및 특정 영역 사용자 중 서비스를 중단하고 이탈한 비율을 측정하는 지표
우리 서비스에서 얼마나 많은 고객이 이탈하는지 알 수 있음
서비스 이탈률이 늘어났다면 어떤 문제가 있는 지 검토해야 함
서비스를 이용하는 유저가 어떤 목적을 가지고 있고, 어떤 행동을 취하고 싶은지 알아낼 수 있음
e.g. A 페이지에서 B 페이지로 이동시키는 것이 목적이었지만, 이 과정에서 이탈하는 유저가 있다 → 해당 유저 그룹의 형태와 특징을 분석할 수 있음 → 이탈 그룹이 이탈 후 어디로 이동하는지 추적하여 목적을 가늠해 볼 수 있음

2️⃣마케팅 관련 지표

1) ROAS(Return on Ad Spend) / ROI(Return on Investment)

투자 대비 성과를 측정하는 지표
ROAS(광고비 대비 매출액): 광고를 통해 얼마나 많은 매출을 올렸는지에 대한 지표
- ROAS = (해당 광고로부터의 매출 / 광고 비용) * 100
- e.g. 100만원의 광고 비용으로 200만원의 매출액 발생 → (200만원/100만원)*100% = 200%
- 광고 효율 측정 시 활용
ROI(투자 수익률): 투자한 비용 대비 이익금을 평가하는 지표
- ROI = 이익(매출 - 마케팅 비용) / 투자비용 * 100
- e.g. 50만원의 투자 비용으로 100만원의 이익 발생 → (100만원/50만원)*100% = 200%
- 모든 투자에 대해 전반적인 순수익 측정 시 활용

2) CAC(Customer Acquisition Cost)

고객 획득 비용: 한 명의 고객을 획득 또는 유치하는 데 든 비용
고객 1명을 우리 서비스로 데려오기 위해 비용이 얼마나 발생하는가?
신규 고객 획득과 관련된 전체 비용 / 신규 획득한 고객수
CAC 가 높다면 고객 1명을 데려오는 데 큰 비용을 지출하고 있다는 뜻
프로모션 진행 시, 지출할 비용 대비 이익에 CAC를 포함하면 손해 없이 적절한 프로모션 가격 계산 가능
e.g. 상품 구매를 목표로 광고를 집행하여 100만원의 비용을 지불, 구매한 고객은 10명인 경우 → CAC : 10만원

3) CAC Payback Period (CAC 회수까지 필요한 기간)

CAC를 회수하기 위해 평균적으로 필요한 시간을 측정하는 지표
비용을 통해 고객을 데려왔다면, 이 비용을 회수하기 위해 걸리는 시간을 측정
CAC Payback Period가 길어진다면, 서비스가 손익분기점을 넘지 못하고 있다는 의미

4) LTV(Life Time Value)

고객 생애 가치: 한 명을 획득 또는 유치한 시점에서, 자사 서비스나 제품 사용을 중단 또는 탈퇴하는 시점까지 얼마만큼의 이익을 가져다주는지에 대한 지표
1 / 이탈률 * 매출 (각 서비스마다 계산법은 달라질 수 있다)
만약 서비스의 LTV 지표가 높다면, 건강한 비즈니스 모델을 가지고 있는 것

3️⃣비즈니스 관련 지표

1) MRR(Monthly Recurring Revenue)

월간 반복 매출: 월간 구독 형태의 서비스를 제공하는 경우 비즈니스의 성장을 측정하는 기본 지표
주로 비즈니스 상태를 평가하는 지표로 활용됨

2) ARR(Annual Recurring Revenue)

연간 반복 매출: 월간 구독 매출을 12배로 산출하거나, 전년도 대비 비즈니스 성장을 측정하는 지표
MRR과 다르게 전년도 대비 서비스가 성장하고 있는지를 평가하는 것이 중요
현재 매출이 전년 대비 상승했는지 평가 → 서비스의 성장 가능성 도출

생각 정리

[아티클 스터디] 일상 속 휴리스틱, 어떻게 서비스로 연결할까?

yj_lynn — Thu, 18 Jan 2024 12:45:13 +0900

아티클 출처

일상 속 휴리스틱, 어떻게 서비스로 연결할까? | 요즘IT

디지털 제품이나 서비스를 만들 때, 휴리스틱을 고려하면 사용하기 쉽고 편한 제품을 만들 수 있습니다. 휴리스틱이란 사람들이 직관적인 판단을 내릴 수 있게 도와주는 의사결정의 지름길로

yozm.wishket.com

️ 선정 이유

❓ ▪️ 7주차 LMS 과제를 진행하면서 휴리스틱 및 사용자 심리를 반영한 기능 변경 사례를 확인하다 보니 조금 더 자세히 알고 싶다는 생각에 휴리스틱 관련 아티클을 찾아보게 되었다.

내용 정리

☝ ▪️ 디지털 제품/서비스 개발 시, 휴리스틱을 고려하면 사용하기 쉽고 편한 제품을 만들 수 있다. ▪️ 휴리스틱 : 사람들이 직관적인 판단을 내릴 수 있게 도와주는 의사결정의 지름길

휴리스틱 알아보기

심리학자 대니얼 카너먼에 의하면 사람이 정보를 처리하는 과정은 2가지로 나뉜다.
- 휴리스틱 사고 : 사람들이 문제에 대한 해결책을 더 빨리 찾을 수 있게 도와주는 어림짐작 기술
- 시스템 사고
시간이나 정보가 불충분한 상황에서 신속한 판단 필요 시 / 굳이 체계적이고 합리적인 판단을 할 필요가 없는 상황에서 휴리스틱을 사용한다.

휴리스틱 사용 장점

고객들이 서비스를 이용하는 과정에서 의사결정을 쉽게 할 수 있도록 한다.
고객들이 서비스를 구매하게 설득할 수 있다.

휴리스틱 사용 사례

넷플릭스는 고객들에게 최상의 인지적 편안함을 주기 위해 환경을 조성하여 서비스 사용 시간을 증가시켰다.

고객들이 쉽게 영화관을 떠올릴 수 있도록 검은색 배경을 제공한다.
세밀한 추천 시스템으로 개개인 선호 콘텐츠를 썸네일로 노출 → 고객들이 서비스를 오래 이용할 수 있게 한다.

휴리스틱과 설득의 법칙

휴리스틱은 특정 상황에서 더 잘 가동되는 경향이 있다.

1) 가용성 휴리스틱

사람들은 머리속에 쉽게 떠오르는 생각에 상대적으로 더 높은 평가를 하는 경향이 있다.
어떤 사건의 사례가 친숙하거나, 최근의 것일수록 떠올리기 쉽다 → 그 사건이 발생할 가능성이 높다고 믿는다.
e.g. 사람들이 한국인의 사망원인 2위를 떠올릴 때, 바로 떠올릴 수 있는 기억을 바탕으로 교통사고, 자살 등의 서로 다른 대답을 하는 것

2) 대표성 휴리스틱

대상이 가지고 있는 대표적인 특징이나 속성만을 가지고 판단한다.
e.g. 대통령 선거나 국회의원 선거에서 공약이나 도덕성 등 여러 내용을 비교/평가하는 대신, 후보의 출신지, 학력 등 대표적인 특징이나 과정을 바탕으로 판단하는 경우

3) 감정 휴리스틱

호불호같은 감정적인 요소로 의사결정을 하고, 부수적인 이익이나 리스크도 감정에 따라 판단하는 경향
e.g. 같은 토마토를 보더라도 평소 토마토를 좋아하는 사람은 거부감 없이 토마토를 먹는다. 반면 토마토를 먹고 탈이 났던 사람이라면 이를 떠올려 토마토를 먹지 않을 것이다. (이성적인 고려 < 감정적인 반응이 의사결정에 영향을 미친 것)

4) 맥락 효과

먼저 제시되는 정보가 그 이후 알게 된 새로운 정보들에 대한 판단기준으로 제공하고, 전체적인 맥락을 만드는 현상

휴리스틱을 어떻게 제품으로 연결할 수 있을까? : ***’설득’으로 연결한다.

설득이란 고객이 귀찮음을 감수해서라도 제품을 기획한 기획자의 의도대로 움직여주는 것이다.***

설득의 6법칙

상호성의 법칙
- 먼저 호의를 제공하고 보답을 요구한다.
- 사람들은 오래 신세를 지고 싶지 않은 마음에, 자신이 원치 않는 호의를 받았을 때도 훨씬 더 큰 호의를 요구하는 부탁을 쉽게 승인한다.
일관성의 법칙
- 일관성을 유지하기 위해 입장을 한 번 선택하면, 자신의 감정이나 행동을 그 결정에 대해 합리화하려는 방향으로 나아간다.
사회적 증거의 법칙
- 애매모호한 상황에서 어떤 행동이나 판단을 해야 할 때, 다른 사람들의 행동과 판단을 살펴 따라하게 되는 성향
호감의 법칙
- 자신이 잘 알고 좋아하는 사람의 부탁을 더 잘 들어주는 경향이 있다.
- 전반적인 호감도를 높이는 요인에는 외적 매력, 유사성, 칭찬, 반복 접근, 긍적적 연상 작용이 있다.
권위의 법칙
- 사람들은 믿을 만한 근거가 필요할 때, 권위에 쉽게 수긍하는 성향이 있다.
- 전문가의 권위뿐만 아니라, 단순히 믿고 따를 만한 모습을 보여주는 것 또한 권위의 형성에 영향을 준다.
희귀성의 법칙
- 한정 판매, 마감 시간 등 얻기 힘든 대상에 더 높은 가치를 부여하는 것이다.
- 특히 사람들은 원래 희귀했던 것보다 갑자기 희귀해진 것을 얻고자 할 때, 또는 희귀한 자원을 두고 다른 사람과 경쟁해야 할 때 그 대상을 더 간절히 원하게 되는 경향이 있다.

️ 휴리스틱을 활용한 일상 속 서비스

1) 배달의 민족

고객이 사용하기 편한 서비스를 지향한다.

매출 증가를 위해 설득의 법칙을 효과적으로 사용하고 있으며, 고객도 휴리스틱을 바탕으로 손쉬운 의사결정을 내림으로써 서비스 기획 의도를 잘 따라가는 편이다.

리뷰 시스템에는 사회적 증거의 원칙과 상호성의 원칙이 작용됨.
많은 업체들이 좋은 평점과 리뷰를 받기 위해 서비스 메뉴를 제공하고, 배민도 여러 업체의 쿠폰을 적극적으로 제공한다.
주문하는 음식점에서 이러한 쿠폰이나 이벤트를 제공하면, 사람들은 조금 귀찮음을 감수하더라고 리뷰를 남길 가능성이 커진다.
이 과정에서 등록된 리뷰는 해당 업체에서 주문하는 새로운 고객에게 영향을 주어 주문 수 자체를 늘리는 역할을 한다.
이러한 사회적 증거의 원칙은 휴리스틱 원칙 > 맥락 효과를 유도한다.
평점이 높고, 최근 리뷰가 좋다면 음식점에 대한 긍정적인 판단을 내린다.
꽤 예전에 올라왔던 낮은 평점의 리뷰를 보더라도 최근 평점이 좋다는 것에 대한 휴리스틱이 작동하여, 결정을 바꾸는 데 큰 영향을 주지 못한다.
리뷰에 포함된 사진들은 이전에 먹었던 음식의 맛을 떠올리도록 유도하려 새 고객들이 메뉴에 더 쉽게 접근하고 구매 결정하도록 돕는다.

B마트와 라이브 커머스에서는 ‘특가 한정판매’ 등의 문구를 사용해, 제품의 희귀성을 알려 고객의 구매 욕구를 자극한다.
배달 메뉴의 메인 화면에서는 ‘국물의 계절’, ‘집밥’, ‘축구엔 치킨’, ‘축구엔 피자’ 등 현재 상황에 맞는 키워드를 제공하고 있다.
따로 고민하지 않아도 서비스에서 먼저 추천해주는 선택지를 따라갈 수 있다는 장점이 있다.
이러한 장치들은 고객의 감정 반응과 연상 작용을 자극해 음식점에 대한 접근성을 높인다.

2) 밀리의 서재

밀리의 서재 서비스 목표는 사람들에게 친숙한 콘텐츠를 통해 독서에 대한 진입장벽을 낮추고, 긍정적인 독서 경험을 전달하는 것이다. 이 과정에서 설득의 법칙과 휴리스틱을 사용한다.

밀리의 서재 가입 시, 가장 먼저 일관성의 법칙을 활용한 습관 목표 설정 기능을 접하게 된다.
100일 100밀리 목표, 365일 365밀리 목표 라는 활동 목표를 설정할 수 있다.
독서 관련 활동을 할 때마다 ‘밀리’라는 활동 점수 단위가 부여되어, 고객이 목표를 달성할 수 있음을 확인할 수 있다.
고객이 꾸준히 독서하겠다는 다짐을 할 수 있게 하고, 이를 지속해서 인지하게끔 함으로써 고객이 더 꾸준히, 더 오래 독서하도록 돕는다.
책을 고르는 과정에서 호감의 원칙과 권위의 원칙을 사용한다.
책의 표지가 중요한 판단 기준이 되는 고객을 위해, 책 이미지 크기를 키워 시각적인 매력도를 높였다.
긴 텍스트를 읽는 것을 힘들어하는 고객을 위해 오디오북, 챗북, 스토리 형태로 책 내용을 요약해 제공하고 있다.
이러한 장치들은 고객이 책을 친숙하게 느끼게 한다.
유명인이나 북 큐레이터의 인터뷰, 책방 소개, 서점 베스트셀러 등 책을 잘 아는 사람들의 책 추천을 메인 화면에 적극 반영하여, 서비스의 컨텐츠를 풍부하게 만들어 고객의 흥미를 자극한다.

❗주의사항: 편향 경계하기

휴리스틱으로 인해 사람들은 편향이라는 체계적인 인지 오류에 빠지기도 한다.

매출을 올리기 위해 이러한 인지적 편향을 의도적으로 악용하는 경우도 있다.

다크패턴: 의도적으로 사용자를 속여 행동을 유도하는 정보나 인터페이스

구독해지버튼을 교묘하게 숨겨 고객이 찾기 어렵게 한다.
가입 과정에서 자연스럽게 광고 동의를 끼워 넣는다.
고객들은 유도된 패턴을 인지하지 못하고 넘어가는 경우가 빈번하지만, 이렇게 고객을 속인다면 단기적인 매출 상승은 있을 지 몰라도 결국 부정적인 서비스 사용 경험을 초래한다.
이는 브랜드에 대한 감정 휴리스틱에 부정적인 영향을 줄 수 있기에 지양해야 한다.

❕휴리스틱의 바람직한 활용

서비스를 만들 때는 여러 설득의 법칙이 복합적으로 활용된다.
휴리스틱을 유도하면, 고객이 제품을 제작자의 의도대로 사용할 수 있게 자연스러운 설득이 가능하다.
하지만 비합리적 결정을 초래할 수 있기에 이를 사전에 인지하고, 악용하지 않아야 한다.
기획자와 디자이너는 사용자 경험을 구성하는 요소들을 다크 패턴이 아니라 바람직한 방향으로 유도하는 넛지가 될 수 있도록 휴리스틱을 올바르게 활용해야 한다.

생각 정리

▪️ 휴리스틱이 서비스 기획에 어떻게 핵심적으로 작용하는지, 특히 배달의 민족과 밀리의 서재를 통한 사례를 통해 실제로 어떻게 적용되고 있는지 알게 되었다. ▪️ 배달의 민족을 이용하면서는 이러한 심리학전 원리들을 의식적으로 느끼지 못했었는데, 이처럼 알게 모르게 서비스 사용 경험에 스며들어있는 것이라는 인사이트도 얻은 것 같다. ▪️ 특히, 밀리의 서재는 아직 사용해보지 않은 서비스이지만, 목표 달성과 사용자의 심리에 맞춘 다양한 기능들이 흥미로워 보인다. ▪️ 기획자로서는 이러한 휴리스틱을 활용하면서 동시에 사용자 편의성과 윤리적 측면을 모두 고려해야 할 필요성을 느끼게 되었다.

[아티클 스터디] 백오피스 시스템 기획 시 TIPS

yj_lynn — Wed, 17 Jan 2024 12:40:15 +0900

아티클 출처

백오피스 시스템 기획 시 TIPS

과거 스타트업에 재직 중이었을 때, 이직 전 마지막으로 받은 마지막 미션은 서비스의 백오피스 시스템을 만드는 것이었습니다. 벤치마킹에 집착하는 기획자의 특성상 서비스의 프론트 기획의

brunch.co.kr

️ 선정 이유

❓ ▪️ 저자가 도입부에 언급한 것과 같이 백오피스 시스템은 참고할 수 있는 화면이 별로 없다. ▪️ 21년도부터 본부 내 백오피스 시스템 기획 담당을 하고 있는데, 처음 화면을 기획하면서 사용성에 대해 고민하며 리서치하는 과정에서 나의 결정이 올바른 방향인 것인지 항상 고민되었다. ▪️ 백오피스 시스템에 관련한 내용을 스스로도 한 번 정리해보고 싶어 이 아티클을 선정하였다.

내용 정리

☝ ▪️ 기획자 데이먼님의 백오피스 참고 사이트 모음 링크

▪️ 잘 만든 백오피스는 아래의 특징을 가진다. [이슈없이 서비스를 구동할 수 있는 안정성]

서비스 안정성은 하위 항목들이 추구를 통해 도달해야 할 최종 목표

모든 필요서비스(프론트운영, 정산, 홍보 등)를 지원할 수 있는 완전성
당장은 지원하지 않더라도 예상되는 기능을 쉽게 추가할 수 있는 확장 가능성
운영에서 휴먼 에러가 발생하지 않을 수 있도록 직관적인 페이지를 기획하는 운영 편의성
상대적으로 적은 개발 리소스 투입으로 추가 개발이 가능할 수 있는 개발 편의성

⛳TIPS

정석적으로 기획하고, 개발에 반영하자

백오피스 기능에 대한 전반적인 개선은 회사 내에서 가장 후순위로 생각되는 프로젝트이다.
- 이유: 백오피스 개선이 기업의 이윤 창출에 도움이 되는 것이 아니고, 과거 시스템에 적응한 운영자와 개발 결과물의 온보딩 실패 등으로 당장은 이슈가 늘어날 수 있다.
정석적으로 기획하지 않는다면 시간이 지나 더 큰 재앙으로 다가올 수 있다.

프론트에 대한 완벽한 이해를 전제로 백오피스를 기획하자

서비스의 주인공은 프론트이다.
- 프론트에서 조작 반영하고자 하는 사항을 완벽히 파악해야 한다.
- 개발없이 운영만으로도 서비스를 다룰 수 있게 백오피스를 기획해야 한다.

서버 구조에 대한 이해를 하자

서버 구조를 개발자 레벨까지는 아니더라도, 이 서버 내에 어떠한 데이터가 담겨 있고, 어떤 기능을 수행하는지는 숙지해야 한다.
- 어떤 서버에 대한 백오피스 기획인지, 한 페이지 내에 모두 조회할 수 있는 데이터인지, 조회만 가능한지 / 수정도 가능한 데이터 인지

제한 사항과 운영 숙련도를 생각하여 기능을 부여하자

대부분의 서비스는 전체적인 색깔톤과 룩앤필을 중시 여긴다.
운영자가 실수로 다른 색깔이나 폰트 등을 사용하여, 서비스 컨셉을 흔들면 안된다.
인력의 익숙함에 따라 상황이 달라질 수 있어, 에디터 없이 HTML만 지원하는 것은 되도록 지양해야 한다.
예시: 서비스 내에 공지사항 게시판을 출력해야 하는 상황
- 게시판 내 글을 쓰기 위해 백오피스 내 텍스트 입력 필드가 필요
- 텍스트 입력 필드는 아래 사항을 고민해야 한다.
  - 단순히 글씨만 쓸 수 있으면 되는지
  - 텍스트 에디터가 존재하여 글자색, 배경색, 볼드, 이텔릭, 밑줄 등을 설정할 수 있어야 하는지
  - HTML 태그를 지원할지

자동화와 운영 사이의 조율은 안정성을 기반으로 하자

서비스가 운영의 손을 많이 탈수록 휴먼 에러의 가능성 또한 높아진다.
데이터의 유무가 분명한 부분은 자동화로, 회색지대로 구분이 어려운 영역은 운영에 맡겨, 서비스의 이슈를 최소화해야 한다.

가이드없는 직관적인 백오피스 시스템을 목표로 하자

운영자의 눈높이에 맞춰 서비스를 기획해야 한다.
직관적인 백오피스 시스템을 만들기 어렵다면, 이해하기 쉬운 가이드를 만들어야 한다.
사용하기 쉬운 백오피스 시스템 기획을 위해 혼동을 유발하지 않을 정확한 용어를 사용해야 한다.

직관적인 버튼 및 아이콘 등을 사용하자

적재적소에 적절한 컴포넌트를 사용해야 한다.
- 예시
  - 단일 선택이 필요한 항목에서 체크박스를 사용하고 있진 않은지
  - 단순 텍스트 출력 자리에 버튼이 출력되어 클릭하도록 유도하지는 않는지
  - 1-10까지의 숫자만 선택하면 되는데 드롭다운 메뉴로 선택하는 대신 텍스트 박스를 넣어 불편함을 주는지

입력 및 표시 시 헷갈림이 없이 분명하게 기획하자

예시1
- 2022년 1월 1일부터 31일까지 노출시켜야 하는 배너가 있다.
- 개발자와의 협의 끝에 기획안은 연월일 시분까지 드롭다운으로 숫자를 선택하게 하고, 분은 5분 단위로 컨트롤하도록 했다.
- 종료시각은 2022년 1월 31일 23시 55분으로 해야할까? 2022년 2월 1일 0시 00분으로 해야 할까?
→ 방법 1) 뒤 시간을 이하가 아닌 미만으로 설정하여 개발 적용→ 방법 3) 시간을 시분초까지 디테일하게 표기하여, 1월 31일 23시 59분 59초에 종료
→ 방법 2) 별도의 순서 적용이 없는 배너나 요소라면, 2월 1일 0시 0분에 새로운 배너나 요소를 노출
예시2
- 메인에 노출하는 배너를 생성해야 한다.
- 암묵적으로 종료 날짜를 설정할 때 공란으로 설정하면, 배너 종료일 없이 별도 컨트롤이 없다면 무기한으로 배너를 노출하는 것으로 가정한다.
- 능숙한 운영자만 백오피스를 운영한다는 보장은 없기 때문에 헷갈리는 최소화하기 위한 방법은 아래와 같다.
→ ‘종료없음’ 버튼을 기간 옆에 두고, ‘종료없음’이 활성화되면 종료 날짜의 날짜 필드가 비활성화되도록 한다.

직관적으로 GNB 및 SNB 메뉴를 설정하자

변동이 있을 수 있는 R&R 대신, 프론트의 메뉴를 기준으로 직관적으로 백오피스의 GNB 및 SNB 메뉴를 설정한다.
프론트에 어떠한 부분을 변경하고자 할 때, 메뉴명만으로도 직관적으로 변경할 수 있게 메뉴명을 설정한다.
메뉴별 메뉴를 설정했다면, 기타 메뉴는 기능에 맞춰 직관적인 메뉴명으로 메뉴를 설정한다.
- 콘텐츠관리/고객관리/정산관리/백오피스관리 등의 이름으로 기능에 맞춰 누구나 알기 쉬운 이름으로 한다.
신규 기능 업데이트 시 기존 메뉴 안에서 구현 가능하다 생각하여 추가한다면, 이슈 처리비용과 QA, 실제 운영 비용이 더 증대될 수 있다.

저장과 배포 기능을 구분하자

저장은 변경사항을 백오피스 내에 저장하는 것이고, 배포는 서비스 출력을 위해 저장된 사항을 프론트에 출력하는 행위이다.
배포 기능을 별도로 가지고 있을 경우의 장점
- 예약 배포 기능 구현 가능
- 배포 후의 상용 리스트를 출력함으로써, 현재 프론트에 출력되는 요소(배너 등)에 대해 확인 가능

예약 배포 기능을 구현하자

예약 배포 기능 구현 시, 운영 직원이 밤새 서비스를 컨트롤할 필요가 없고, 그만큼 운영 비용이 감소된다.
또한 개별로 저장 버튼을 누른다면, 정확히 같은 시간에 프론트 서비스를 컨트롤할 수 없다.
예약 배포 기능이 있다면, 원하는 시간에 일괄적으로 서비스를 컨트롤할 수 있다.

운영자가 알아보기 쉽도록 에러 메세지를 분명하게 출력하자

하나의 백오피스 페이지에서 저장이나 배포 시 오류사항 시나리오를 모두 생각하여 팝업 스트링을 기획하는 것이 좋다.

오류코드가 출력되는 팝업의 텍스트 복사를 가능하게 하자

운영자의 휴먼에러가 아닌 상황에서도 오류는 발생할 수 있다.
구분되는 오류 상황에서 오류코드를 설정하고, 해당 오류코드의 텍스트 복사를 가능하게 하여, 빠른 이슈 해결에 도움을 주는 것이 좋다.

에러메세지가 출력되기 전에 인지하는 게 더 좋다

저장 버튼을 누르기 전에 에러 메세지를 출력하면, 운영 편의성을 더 줄 수 있다.

기획 전에 이해관계자와 충분히 대화를 나누자

실제 사용하는 운영자의 의견을 들어 백오피스 시스템을 기획해야 한다.
작은 불편함이지만, 운영 속도 저하 및 휴먼 에러 발생이라는 부작용을 초래하는 경우가 있다.

삭제 기능은 되도록 넣지 말고, 노출 불가로 처리하자

운영에서도 관리 이력을 쌓아 놓으면, 향후에 비슷한 요소를 프론트에 반영할 때 혹은 운영 이슈 사항이 발생했을 때 히스토리 파악에 더 유리할 수 있다.
삭제 버튼은 없거나, 고권한의 관리자에게만 부여되어야 한다.

과부하의 원인을 제고하고, 이슈를 컨트롤하자

과부하가 발생될 수 있는 기능의 경우, 개발자와 협의하여 일괄 처리의 양과 범위를 UI로 제한해야 한다.
예시
- 마케팅 이벤트를 통해 다수의 사용자에게 일괄적으로 캐시를 부여했다.
- 해당되는 사용자의 ID를 CSV 파일로 적용하는 작업에서 다수의 인원이 동시간대에 적용을 하다보니 버서의 과부하 상태를 체크해가며 작업을 진행해야 했다.
- 이러한 경우 아래의 방법으로 개발과의 적극적인 협의를 통해, 과부하 이슈를 컨트롤해야 한다.
  - CSV 파일 내의 고객 ID의 개수를 제한하는 방식으로 운영을 수행
  - 이미 개수가 제한된 CSV 파일이지만, 서비스 페이지에 적용시 적용된 고객의 ID 개수를 체크하고 페이지가 다운되었는지 확인할 수 있게 움직이는 프로그레스바로 상태를 확인

자주 쓰는 기능을 공통사항으로 기획하여 사용하자

미디어 서비스의 백오피스 시스템의 경우, 영화나 음악 같은 미디어를 호출하는 화면/고객조회 화면 등은 공통으로 사용할 수 있게 팝업으로 설정하면 손쉬운 기획 및 개발이 가능하다.

랜딩타입과 모듈타입을 공통사항으로 설정하자

기능을 랜딩타입으로 구현하여, 다른 백오피스 화면에서 공통으로 사용할 수 있게 관리한다면 효율적으로 기능 구현 및 개발이 가능하다.
서비스 내에서 일정한 모듈타입을 계획하고 팝업으로 관리한다면, 노출 관리의 효율성을 도모할 수 있다.

랜딩타입의 최선은 리스트 UI 구현, 차선은 ID 부여, API 주소 부여는 최후의 수단으로 고려하자

예시: 메인에 최신영화를 배너로 설정하는 상황
- 백오피스 내에서 배너를 설정하고 영화에 대한 링크 구현 시, 배너에 최신영화를 어떻게 선택하는 것이 좋을까?
- 최선의 방법은 영화를 조회하는 팝업을 출력하고, 그 창 내에서 조건대로 검색을 하여 영화를 선택하는 것이다.
- → 운영자가 별도의 화면에서 영화를 찾는 수고를 덜고, 여러 검색 조건에서 정확하게 원하는 컨텐츠를 선택할 수 있다.
- 최선의 상황을 구현하기 어려운 경우, 컨텐츠에 매겨진 별도의 ID를 입력한다.
  - 별도의 ID를 입력하는 기획을 해야하는 상황
    - 다수의 컨텐츠를 빠르게 입력하고 싶을 때
    - 이미 팝업이 하나 열려있는 상황이어서, 또 팝업을 열기가 어려운 경우
    - 리스트 팝업이 개발 되어있지 않은 경우
- API 주소를 입력하는 상황은 되도록 지양한다.

백오피스 로그인 후 백오피스를 위한 공지사항 란을 마련하자

여러 협업툴과 기업 홈페이지 내 소통 창구가 있지만, 백오피스를 사용하는 사람들에게 정확하게 닿을 수 있는 소통 창구는 백오피스 접속 후 게시판이다.
긴급한 서버 점검 등의 상황을 백오피스 메인 내 게시판에 게재한다면, 커뮤니케이션 부족으로 인한 이슈 또한 감소될 것이다.

개인정보 관련 기능은 되도록 몰아넣자

기업의 규모가 커진다면, 보안은 선택이 아닌 필수가 될 것이다.
개인정보를 다루는 메뉴를 별도로 생각해서 몰아넣는다면, 외부 감사나 ISMS 심사 시 개발 편의성을 도모할 수 있다.

순서 변경 기능은 보수적인 UI를 가져가자

다루는 백오피스 메뉴의 성질에 따라 노출 유무, 노출 기간 설정 등과 꼬여서 제대로 작동하지 않는 경우가 있다.
별도의 순서 팝업을 띄운 후, 각각 항목을 드롭다운 내 숫자로 선택해서 순서를 변경하거나, 항목을 체크박스로 선택한 후, 고정된 아래/위 버튼을 눌러 순서를 변경해서 이슈를 해결할 수 있다.

팝업은 한 개만 출력하자

팝업이 두 개가 열린 경우, UI 및 개발 상으로 이슈가 발생할 소지가 많다.

복사 기능을 넣자

예약 배포 기능이 활발하게 적용되는 서비스의 경우, 원래 있던 메뉴의 순서가 시간대에 다이나믹하게 변경될 수 있다.
기존에 배포된 요소를 그대로 복사하여, 운영의 편의성을 더해준다면 운영기획의 편의성을 증대할 수 있다.
- but, 계속해서 쌓이는 가비지 데이터를 주기적으로 정책을 잡아 제거하는 방법이 필요할 수 있다.

생각 정리

▪️ 내가 기획한 관리자페이지는 각 국가별 법인이 법인의 고객을 관리하고, 고객에게 공지를 하기 위한 ‘법인의 운영’ 용도였기에 본부 내 운영의 백오피스는 아니다. 본부 운영을 위한 백오피스 필요성이 가끔 언급되고 있는데, 기획을 담당하게 된다면 저자가 말하는 TIP을 기억하며 사용자가 사용하기 쉬운 백오피스를 기획하고 싶다. 기존 담당하고 있는 관리자 페이지는 언급된 TIP에 대해 어떤 대답을 하고 있나 생각해 보며 내용을 정리해보니, 개선 해야할 기능 및 화면이 떠오른다. 또 백오피스에만 한정된 TIP이 아닌 전반적인 기획에도 적용될 수 있는 내용이라는 생각이 들었다.

[아티클 스터디] 개발자에게 물어봤습니다. 함께 일하고 싶은 기획자/PM

yj_lynn — Tue, 16 Jan 2024 11:49:54 +0900

아티클 출처

개발자에게 물어봤습니다: ③ 함께 일하고 싶은 기획자 | 요즘IT

이번 시리즈를 통해 다양한 직무와 협업하는 IT 기업 직장인 중 개발자가 함께 일하고 싶어 하는 동료에 대해 다루고 있습니다. 오늘은 마지막으로 개발자가 생각하는 ‘함께 일하고 싶은 기획

yozm.wishket.com

내용 정리

기업이나 서비스는 한 명의 힘으로 운영되지 않는다. 다양한 직무의 사람들이 서로 협력하며 서비스를 발전해 나간다. 개발자가 생각하는 ‘함께 일하고 싶은 기획자’에 대해서 알아보자!

*저자가 ‘기획자’라는 단어에 PM도 포함하여 사용했다고 언급함

1️⃣ 개발자와 기획자의 협업

개발자와 기획자는 서비스의 큰 방향성은 함께 설정하더라도 구체적인 내용은 주로 기획자의 작업에 따라 결정되고, 개발자는 기획서를 토대로 개발을 진행한다. 기획자와 개발자의 잦은 협업 속에서 소통 오류가 생기는 경우가 있다.

레거시를 고려하지 않고 속도만을 요구하는 경우

“PM 입장에서는 정말 별거 아닌 기능이라고 생각될 수도 있지만, 기존 레거시 체계에서는 굉장히 무리한 요구가 될 수도 있어요. “

레거시란?
- 새로운 기능/정책 추가로 서비스 코드는 점차 복잡해진다. → 새로운 기능을 추가하는데 필요한 시간도 증가한다. : 레거시, 혹은 기술부채
- 기존 레거시에 따라 같은 기능이더라도 개발 소요 시간은 천차만별이다.
기획자가 단순한 예상이나 이전 회사의 경험으로 작업 기간을 산정하는 경우 개발자와 소통에 어려움이 생기고 협업이 어려워진다.
기획자는 개발자와 지속적으로 소통하면서 레거시를 파악하고, 기술 부채의 정도와 개발 속도를 이해해야 한다.

자신의 개발 경험만으로 판단하는 경우

“간혹 자신이 개발자 출신이라거나 개발을 해본 적이 있다거나 해봐서 안다는 등의 말을 하며 의견을 밀어붙이고, 특정 기능에 대해 기술적으로 구현하기 어려운 이유를 설명해도 납득하지 못하던 기획자들이 있었어요.”

점차 프로그래밍 교육이 대중화되면서, 개발자가 아니더라도 프로그래밍을 접하는 사람들이 많아지도 있다. → 기획자가 ‘이 정도 기능이면 내가 직접 개발할 수 있겠다’라는 생각을 하는 경우도 종종 생긴다.
어떤 직무든 자신의 경험을 지나치게 확신하지 않고 현재를 이해하려고 노력하는 자세가 필요하다.

다른 팀과의 조율이 원활하지 못한 경우

“한참 개발하다가 갑자기 다른 프로젝트가 검증 중인 기능을 건드리게 되는 상황이 발생할 때가 있있어요. 서로 일정 조율이 안되면 그 프로젝트가 끝날때까지 기다리거나 우리 기획을 우회해서 수정해야 하는데요. 그러면 일정 산정도 다시 해야하고, 세부 정책도 바뀌어야 해요.”

회사 내 여러팀이 존재하는 경우 보통 팀마다 서로 다른 기능을 담당한다.
간혹 작업 영역이 겹치는 상황이 생기는데, 팀 간 조율이 안되는 경우가 있다. → 개발 단계에서 작업 시간이 늘어나거나 예상치 못한 오류가 발생할 수 있다.

2️⃣ 함께 일하고 싶은 기획자

다른 직무와 프로세스 전반에 대한 이해도가 있는 사람

“개발적인 이해가 부족하면 성격의 차이보다도 소통에 어려움이 생기는 것 같아요. 개발 전반의 프로세스와 소프트웨어 프로덕트가 어떻게 나오는지 알고 있는 사람들이 아니면 같이 일하기 힘들어요. “ ****

기획자는 보통 전체적인 기획, 디자인, 개발의 과정을 조율하고 일정을 관리한다.
다른 직무의 업무를 이해하려고 하지 않는 경우 주로 마찰이 발생한다.
직무와 프로세스에 대한 이해도를 높이는 방법 중 하나는 ‘이것저것 관심을 두고 물어보는 것’이다.

가설의 근거가 명확하고 자신이 있는 사람

“’이대로 만들어줘’라고 강요하면 개발자 자신이 수동적인 구성원처럼 느껴질 수도 있어요. 자신이 있고 근거가 명확한 동료와 함께할 때 ‘다 같이 의미있는 일을 한다.’라는 느낌을 받고 확실히 더 열심히 일하게 되는 것 같아요.”

업무에 있어서 명확한 근거와 설득은 중요하다.
기획자는 기획에 대한 근거를 함께 설명하고, 그 근거가 명확해야 개발자 뿐만 아니라 여러 동료와 능동적으로 협업할 수 있다.

적절한 유저 니즈를 발굴할 수 있는 사람

“뛰어난 PM은 제품이 경시하고 있던 유저 니즈 중에서도 실행하기 값싸고 가져올 임팩트가 큰일들을 지속해서 찾아내고 성공시키는 사람이 나리까 싶어요.”

유저에게 어떤 영향을 미칠지는 기획자의 기획에 따라 결정되는 경우가 많다.
본인 뿐만 아니라, 팀원들과 원활하게 협업을 하기 위해서도 기획자 본연의 역량을 기르는 것이 중요하다.

팀 전체의 상황을 읽을 수 있는 사람

“프로덕트의 성공은 PM의 능력치와 열정에 의해 훨씬 더 많은 영향을 받는 것 같아요. “

디자이너나 개발자는 주로 특정 기능을 전담하여 작업한다. → 조금 더 세부적인 부분에 집중하게 되고, 큰 방향성에 대해 고민할 수 있는 시간이 부족하다.
기획자는 내부적으로 프로세스의 진행상황을 챙기고, 외부적으로 유저의 니즈를 파악하는 직무이기에 전체적인 상황을 파악하기 유리하다. → 기획자가 큰 그림을 보고 방향성을 제시할 수 있어야 프로덕트가 올바른 방향으로 나아갈 수 있다.

☝ 개발자는 프로세스를 이해하고 유저를 잘 아는 기획자를 원한다.

전반적인 프로세스와 팀을 잘 이해하고 있어야 여러 사람과 소통하며 기획안을 원활하게 진행할 수 있다.
유저를 잘 파악해야 임팩트있는 기획안을 만들 수 있다.

생각 정리

▪️ 저자가 마지막에 내용을 정리하며 ‘혼자만의 힘으로 원대한 서비스를 만들기는 불가능하다. 직무에 상관없이 자신이 더 성장하고 좋은 영향을 주고 싶다면 업무적 역량을 기르는 것뿐만 아니라 주변의 동료들과 함께 소통하는 자세가 중요하다는 걸 새삼 느끼게 됐다.” 라고 언급했다. 나는 개발자에게 소통이 잘 되는 기획자로 인식되고 있을까?를 고민할 수 있는 시간이었다. 그리고 그 답은 ‘(노력하고 있지만..)아직은 잘 모르겠다’ 인 것 같다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 바로 활용하는 12가지 AB테스트 사례

yj_lynn — Mon, 15 Jan 2024 08:10:18 +0900

아티클 출처

바로 활용하는 12가지 AB 테스트 사례 | 요즘IT

AB 테스트는 가설 수립, 실험 진행, 결과 분석의 3단계로 진행되는 그로스 해킹 방법론입니다. AB 테스트는 제품과 조직의 확실한 성장 엔진으로, 그랩(Grab), 넷플릭스(Netflix), 에어비앤비(Airbnb) 등

yozm.wishket.com

️ 선정 이유

❓ ▪️ AB 테스트를 직접 활용해 본 적이 없어 언젠가 활용해 보고 싶다는 생각을 항상 해왔던 것 같다.

▪️ 다양한 기업의 AB 테스트 사례를 다루고 있어 그 사례를 통해 실전을 익히고 싶어 아티클을 선정하였다.

내용 정리

☝ AB 테스트

가설 수립, 실험 진행, 결과 분석의 3단계로 진행되는 그로스 해킹 방법론
제품과 조직의 확실한 성장 엔진
큰 그로쓰 해킹 팀이나 테스트 문화, 맞춤 툴이 전혀 없는 상황이라도 적용 가능

1️⃣ 기능보다 가치 - Booking.com 온보딩 팝업 카피

연간 2만 5천 개가 넘는 AB 테스트를 실행하는 데이터 기업

문제점 발견 숙소 등록을 위해 가입한 숙박업소주가 첫 3개월 동안 크게 이탈

원인 분석	숙박업소주를 대상으로 한 온보딩 과정에서 제품 튜토리얼 단계에서 대부분 건너뛰는 선택지를 고른다는 것을 알아냄
기존 기능	둘러보기 단계를 시작하는 팝업은 둘러보기 계속, 건너뛰기, 닫기 의 3가지 기능으로 구성되어 있었음
실험 진행 1	처음에 건너뛰기 기능을 없애고 계속하기와 닫기 기능만 남김
→ 둘러보기를 진행하는 고객 13%
실험 진행 2	기능 변경없이 팝업의 문구를 수정 (고객은 제품이 어떤 일을 할 수 있는 지가 아니라, 나에게 어떤 도움이 되는지를 설명받음)
→ 둘러보기를 진행하는 고객 50%

제품이 고객에게 어떤 가치를 제공할지 설명하는 것이 제품을 설명하는 것보다 더 중요하다.

2️⃣ 입구는 단순하게 - 넷플릭스 랜딩 페이지

제품 개선의 방향 자체를 AB 테스트에 의존하고 있는 기업
재생, 대기열 추가 버튼과 같은 UI, 시청 데이터를 이용한 개인화 기능, 페이지 로드 시간, 인코딩 품질 등 제품의 대부분을 AB 테스트 한다.
CTA(Click to Action) 버튼 카피 수정 테스트
- TRY: JOIN이나 GET에 비해 시험 삼아 가볍게 눌러 볼만한 카피
- TRY IT NOW: 버튼을 누르는 고객의 심리적 허들을 최소화하는 가장 단순한 카피
- CTA 버튼은 1개일 때 가장 큰 영향력을 발휘한다. (특히, 고객을 제품 사용으로 인도해야 하는 랜딩 페이지에서는 더)
  - 가입 버튼 아래 로그인 옵션이나 ‘더 알아보기’에 해당하는 다른 버튼을 추가하는 대안은 모두 취소되었다.
  - 로그인 기능이나 넷플릭스에 대한 정보 제공이 고객 편의/전환에 도움 줄 수 있지만, 1순위 지표인 가입률을 해칠만큼 중요하지는 않기 때문

3️⃣ 100의 법칙 - 코드카데미(Codecademy) 플랜 가격 할인율

100의 법칙(Rule of 100): 고객의 처지에서 어떤 상품의 가격이 100달러 미만이라면 할인가가 얼마인지 표시하는 것보다 할인율이 몇 %인지 보여주는 게 할인 폭을 더 크게 실감한다는 이론
프로그래밍 학습 플랫폼 코드카데미는 이 이론을 플랜 선택 페이지에 적용했다.→ 전체적인 페이지 전환율도 개선됨
→ 연간 결제 플랜으로의 전환율 28%

4️⃣ CTA 버튼 추가 - OFLARA

리스트/그리드 UI는 거의 모든 디지털 프로덕트에서 활용되고 있다.→ 하지만, 이런 생략이 고객의 제품 사용을 불안하게 만든다.
→ 디자이너는 별도의 CTA 버튼 없이도 고객이 사용하는 데 무리가 없을 것으로 생각하는 경우가 있다.
온라인 주얼리 커머스 OFLARA는 상품을 보여주는 그리드 UI에 장바구니 추가 버튼을 추가했다.
→ 매출 60%

5️⃣ 인기 항목을 빠르게 필터링 - TELE2

필터: 고객이 원하는 조건에 맞는 항목만을 드러내 탐색에 드는 비용을 줄여주는 UI
필터에는 취급하는 항목이 가지고 있는 속성에 따라 세부항목의 수가 많아질 수 있다.e.g. 브랜드 필터링 옵션에 브랜드가 수십가지인 경우, 고객은 필터 목록에서 브랜드를 찾기 보다 검색 기능을 사용할 것이다.
→ 이러한 세부성이 탐색 비용을 줄인하는 필터의 본 목적을 해칠 수 있다.
유럽 통신사 TELE2는 휴대전화 목록에서 인기 브랜드를 바로 선택할 수 있는 빠른 필터를 추가했다.
→ 필터 클릭률 19%

6️⃣ 양날의 검, 무한 스크롤 - Etsy

콘텐츠가 많아 한 화면을 넘어가게 되는 리스트/그리드 UI를 처리하는 방법
- Pagination
- 무한 스크롤
  - 작은 노력으로 많은 항목을 탐색할 수 있다.
  - 그러나, 많은 탐색이 많은 전환으로 이어지는 것은 아니다. (제품에 따라 다를 수 있다.)
수공예 마켓플레이스 Etsy는 검색 결과 페이지의 그리드 UI를 무한 스크롤 방식으로 바꾸었다.
→ 조회율, 클릭률, 장바구니에 담는 비율, 구매율 모두

7️⃣ 콘텐츠 발행일 숨기기

사람들은 같은 주제여도 최신의 콘텐츠가 더 정확하고, 오늘날에 알맞다고 여긴다.
벨기에의 UX 디자이너 Paul Olyslager는 자신의 블로그에서 콘텐츠 발행일을 숨겼다.
→ 콘텐츠 이탈률 84% 에서 72%로 감소

☝ AB 테스트 사례로 얻을 수 있는 인사이트

기능보다 가치 전달에 초점을 맞춘 카피
랜딩 페이지에 심리적 허들을 낮추는 가벼운 카피 사용
랜딩 페이지에 제품 사용을 복잡하게 느끼는 카피 회피
랜딩 페이지를 비가입 고객 친화적으로 구성
CTA 버튼의 수 최소화하여 우선순위 높은 기능에 집중
전체 퍼널의 단계 수를 고려한 디자인
한 화면에 많지 않은 입력란
100의 법칙 - 액수가 낮다면 할인가 말고 할인율 노출
리스트/그리드 UI에 CTA 버튼 추가
인기 항목은 빠르게 필터링할 수 있도록 디자인
무한 스크롤은 양날의 검 - 많은 항목을 쉽게 탐색하는 것이 꼭 전환으로 이어지지 않음
이탈률 감소를 위한 콘텐츠 발행일 숨김

생각 정리

▪️ 기능 자체보다는 사용자에게 어떤 가치를 전달하는가가 더 중요하다는 포인트에 동의한다. 간결한 정보를 제공하고, 제품팀에서 사용자가 행하길 바라는 목표로 사용자를 이끄는 방안에 대한 고민이 중요하다. 또, 제품과 서비스의 개선은 실험과 데이터에 기반해 이루어져야하고, 그 과정에서 AB 테스트는 강력한 도구임을 알게 되었다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 프로젝트 매니저(PM)가 알아야할, 7가지 프로젝트 성공원칙

yj_lynn — Sun, 14 Jan 2024 08:30:07 +0900

아티클 출처

프로젝트 매니저(PM)가 알아야할, 7가지 프로젝트 성공원칙 | 요즘IT

프로젝트의 성공에 있어서는 능력이 뛰어난 개발자들과 날카로운 QA 엔지니어들을 확보하는 것만큼이나, '프로젝트매니저'의 역할도 필수적일 수 있다는 것을 이해해야 합니다. 오늘 위시켓은

yozm.wishket.com

️ 선정 이유

❓ ▪️ 하나의 프로젝트를 진행하는 팀의 일원으로서 프로젝트를 성공적으로 이끄는 방향은 언제나 고민하는 부분이 될 것이다. 프로젝트 관리의 핵심 원칙과 전략에 대한 이해를 하고자 이 아티클을 선정하였다.

내용 정리

프로젝트 매니저가 알아야 할 7가지 프로젝트 성공 원칙

▪️ 프로젝트 매니저는 개발 일정, 예산, 리스크를 관리하고 팀원들을 지원하는 역할을 한다. ▪️ 뛰어난 개발자와 QA 엔지니어를 확보하는 것 뿐만 아니라 프로젝트 매니저의 역할도 중요하다.

1️⃣ 리스크를 파악한다.

▪️ 사전부검(Pre-Mortem): 프로젝트를 본격적으로 시작하기 전에 가능한 최악의 시나리오를 모두 시각적으로 그려내는 작업

가장 중요한 항목의 목록을 만들 수 있다.
리스크를 피하거나 잘 대처할 수 있다.
사전부검이 잘 마무리 된다면, 복잡한 리스크 추적 도구나 프로세스가 필요하지 않다.

▪️ 무엇이 잘못될 수 있는지에 대해 처음부터 인지하고 있다면, 그 부분을 일상적으로 모니터링하고 이 활동을 프로젝트의 수명주기에서 기본적인 루틴(routine)으로 만들 수 있다.

▪️ 리스크 발생 시 언제든 대응할 수 있어야 한다.

2️⃣ 예산 추적의 중요성

▪️ 예산은 한정되어있는 프로젝트에서는 더욱이 예산에 대해 신중하게 생각해야 한다.

프로젝트의 목표 파악 후, 목표 달성을 위해 지출해야하는 예산을 계산할 수 있어야 한다.
작업 시 하루 통상적인 지출 비용을 기반으로, 프로젝트의 예산을 추적할 수 있는 스프레드시트를 만드는 것도 좋다.
예산에 맞게 우선순위를 쉽게 정할 수 있고, 최소기능제품(MVP)을 위해 필수적이지 않은 작업은 제외시킬 수 있다.

▪️ 한정된 예산만으로 폭넓은 범위의 기능을 구현할 수는 없다.

▪️ 매달 지출 가능한 비용의 범위와 최선의 지출 방안을 파악해야 한다.

3️⃣ 기술적인 어려움 - 개념증명(POC)를 갖고 작업한다.

▪️ 기술적인 개념증명(Proof of Concept, POC)를 준비할 시간을 가진다.

주어진 기능을 개발하기 위해 어떤 방향으로 나아가야 하는지, 어떻게 접근해야 하는지를 파악하기 위함이다.
프로젝트 내부의 미니 프로젝트에서도 사용할 수 있다.

▪️ 개념증명을 통해 결과를 도출했다면, 리스크를 측정한다.

▪️ 팀에서 해낼 수 있다는 확신이 든다면, 진행한다.

▪️ PoC는 불확실한 상황과 관련된 압박감을 해소시켜준다.

4️⃣ 일정 관리 - 사용자를 중심에 둔 스프린트(SPRINT) 목표에 의해서 진행과정을 추적한다.

▪️ PM은 프로젝트의 진행상황을 관리해야 하고, 문제가 생기는 경우 그에 대해 조치를 취해야 할 책임이 있다.

스프린트 완료 후 결과로 얻고자하는 목표를 기반하여 일정 계획을 준비한다. → 남은 시간과 그 시간 동안 얼마나 많은 목표를 달성할 수 있는 지 파악할 수 있다.
MVP 목표와 대상 사용자들에게 초점을 맞추어야 한다.
계획을 간단하게 유지하고, 관련자들이 지속적으로 업데이트 한다면, 관련된 모든 사람들이 프로젝트의 진행상황 및 정보를 모두 동일하게 공유할 수 있다.

→ 스프린트가 끝날 때마다 사용자들을 위한 새로운 가치가 만들어졌다는 확신을 가지게 된다.

▪️ 스프린트를 시작할 때 계획했던 기능들만 얻어내는 것이 아니라, 사용자들을 위해서 보이지 않았던 가치들도 만들어내게 된다.

5️⃣ 지속적인 재평가

▪️ 작업 환경 안에서 수많은 요소들이 끊임없이 변하고 있기 때문에, 이전에 맞았던 평가라고 하더라도 현재 시점과는 맞지 않은 것일 수도 있다.

재평가 작업을 매일 진행하는 아침회의, 진행상황 점검, 정례 미팅과 마찬가지로 일상적으로 따라야하는 일종의 의식으로 만든다.→ 제품 개발에 필요한 노력을 적극적으로 평가하도록 해야 한다.
→ 팀원들이 진행상황을 추적할 수 있게 한다.

6️⃣ 프로젝트의 명시적인 마감일이 없다 하더라도, 자신만의 마감일을 설정한다.

▪️ 전체 예산이 바닥나는 시점을 기준으로 계산한 것보다 더 앞선 시점으로 마감일을 앞당길 필요가 있는 경우가 있다. → 팀을 집중하게 만든다.

▪️ 남아있는 시간보다 마감일을 앞당기는 것은 어려운 일이지만, 시간과 돈에 여유분을 만들어 두는 것은 혹시라도 사전에 감지못한 리스크를 대비하는 면에서 좋은 태도이다.

▪️ 이러한 경우, 최악의 시나리오는 MVP를 만들어내기 위해 좀 더 많은 시간이 필요한 것이다.

▪️ 최상의 시나리오는 사용자들에게 MVP를 보다 빠른 일정에 전달할 수 있다는 것이다. → 절약한 예산을 다음 단계에 대한 계획에 착수할 수 있다.

7️⃣ 팀원들의 편에서 철저한 책임의식을 갖는다.

▪️ PM은 제품에 대해서, 그리고 자신의 팀에 대해서도 책임의식을 가져야 한다.

▪️ 적극적이며 투명한 커뮤니케이션을 해야 한다. 현재 작업이 어떻게 진행되고 있는지, 지금 당장 마주한 장애물이 무엇인지 일상적으로 투명하게 커뮤니케이션해야 한다.

▪️ 중요한 이슈 발생 시, 공식적인 논의 자리를 마련한다.

➡️ 프로젝트 관리를 더욱 훌륭히 수행해 나가기 위한 노력을 멈추거나 게을리 해서는 안된다.

생각 정리

▪️ 관리자의 입장에서는 어떠한 관점으로 프로젝트 관리를 해야 하는 지에 대해 알 수 있는 시간이었다. 또, 그 관리자가 관리하는 팀원으로서도 프로젝트 마감 기한 및 커뮤니케이션에 대해 관리자에게 투명하게 현 상황을 공유하고 커뮤니케이션해야겠다는 생각이 든다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 7년차 기획자의 커뮤니케이션 실제 사례

yj_lynn — Sat, 13 Jan 2024 08:20:40 +0900

아티클 출처

https://yozm.wishket.com/magazine/detail/2274/

7년차 기획자의 커뮤니케이션 실제 사례 | 요즘IT

이 글에서는 7년간 여러 서비스 도메인을 거치며 겪은 저의 경험담과 극복기를 공유하고자 합니다. 이 글은 ‘내가 열심히 했더니 모든 것이 잘 풀렸다’는 이상적인 이야기는 아닙니다. 하지만

yozm.wishket.com

️ 선정 이유

▪️ 기획 직무 공고를 보면 ‘원활한 커뮤니케이션’이 요구사항으로 주로 언급된다.

▪️ 개발/디자인/QA를 포함하여 다양한 유관부서와 협업하며 의견 조율을 하는 기획자에게 커뮤니케이션 능력은 중요하다.

▪️ 기획자로서 어떻게 효과적인 커뮤니케이션을 할 수 있는지에 관한 경력자의 의견을 살펴보고자 선정하였다.

내용 정리

커뮤니케이션도 기획의 영역이다

▪️ 서비스 기획자는 프로젝트를 관리하는 PM으로서 디자이너/개발자 등 실무자뿐 아니라 영업팀, 유관부서, 외부 협업사 등 내외부 소통 능력이 중요하다.

▪️ 소통 부재 → 큰 비용 손실로 이어질 수 있다.

▪️ 국내 유수 기업은 서비스 기획자에 대한 JD(Job Description)에 타 직군 대비 커뮤니케이션 역량을 특히 강조한다.

▪️ 서비스 기획자는 목표 달성을 위해 팀원의 불편 사항은 빠르게 이해하되, 업무 전달은 명확해야 한다.

1️⃣ 디자이너: 창의력의 방향성 제시하기

▪️ 발단

개발 명세에 집중하여 디자인 톤앤매너, 디테일, 기획의도에 대한 설명이 부족했음.

▪️ 이슈

기획 의도와는 다른 디자인이 나옴. (스토리보드와 다르게 중요도가 낮은 기능이 강조되는 등)

▪️ 해결

이를 해결하기 위해 디자인 방향성에 대한 사전 회의를 진행함.
기획서와는 별도로 디자인의 톤앤매너 레퍼런스를 정리함.
레퍼런스를 선택하는 기준은 경쟁사, 시장 점유율, 트렌드 등의 논리로 선별
레퍼런스 문서 바탕으로 디자이너와 회의 후, 경쟁사 UI/UX 및 프로젝트에서 중요한 정보의 강약을 설명

▪️ 결과

의도에 벗어난 디자인이 나오는 횟수가 줄고, 수정 방향이 명확해짐.
디자이너도 초기 컨셉에 대한 고민없이 필요한 디자인 구현에 집중할 수 있음

▪️ 의의

디자인은 창작의 영역으로 경우의 수가 무한함.
기획자는 경우의 수를 좁히는 노력을 해야함.

2️⃣ 프론트엔트 개발자/퍼블리셔: 시안과 기획서를 동시에 봐야 하는 고충 해결하기

▪️ 발단

프론트엔드/퍼블리셔는 시안과 기획서를 동시에 봐야 함.
기획자는 ‘기획서에 썼으니까’라고 생각하기 쉬움

▪️ 결과

외적으로는 시안처럼 구현했지만, 데이터의 노출 케이스나 동작 등 스크립트 누락이 빈번함.
작업자에 따라 디자인 시안을 기획서처럼 자세하게 요구하는 경우도 있음

▪️ 이유

시안에서는 데이터의 모든 노출 케이스와 동적 흐름을 보여주지 않음.
시안이 많은 경우 기획서와의 맵핑이 되지 않아 일일이 찾아보기 힘들어짐.

▪️ 해결

작업 범위가 큰 경우는 1차 시안 완성 후 개발에 넘기기 전 별도로 리뷰 회의를 진행했음.
전체 킥오프와 달리 시안의 수정사항과 프론트 구현 시 이슈에 대해 취합하는 ‘프론트엔드’만을 위한 회의.
- 시안 제작 시 기획서 페이지와 매칭될 수 있도록 대분류의 넘버링을 맞춤 → 시안 별 확인해야 하는 기획서 쉽게 찾을 수 있음.
- 기획서는 시안에 담기지 못한 데이터 노출에 대한 표현과 동작 시점을 정의해야 함 e.g. 몇 줄까지 노출, 절삭처리, 이미지 자름 기능 등)

▪️ 의의

해당 시안이 어느 기획서를 참고하고 있는지 제목 등에 넘버링을 잘 표기해줘야 함.
백엔드에 넘기기 전, 디자이너와 함께 구현 이슈는 없는지 체크해야 함.
리뷰 회의를 통해 디자인 가이드에 표기할 것, 기획서에서 확인해야 할 것을 구분해야 제 목적에 맞는 산출물이 나올 수 있음.

3️⃣ 백엔드 개발자: 요구는 명확하게, 일정 협의는 유연하게, 기획서는 읽기 쉽게

▪️ 발단

개발 중 기획서에 없던 스펙이 추가됨 → 공수 늘어남. (기획자의 누락 or 외부 요구사항)

▪️ 결과

개발자가 요구사항에 대해 방어적인 태도를 취함. → 서로 간의 소통이 경직됨.

▪️ 이유

개발자는 전체 모듈을 생각하여 코드를 짜야 함. → 개발자의 업무 특성을 이해해야 함.

▪️ 해결

기획자는 확장성을 고려하여 사전의 문서 작성과 방향성 회의를 진행해야 함.
추가되는 일정과 구현할 사항에 대해 유연한 협상 필요
- Case1. 사전 문서 작성 및 킥오프 회의
  - 개발자가 전체 코드 설계를 잘 할 수 있도록 ‘프로덕트의 목표와 쓰임새, 그리고 확장 가능성’을 기획하고 사전에 공유함 (폭포수 모델처럼 가능한 모든 케이스를 작성해주는 게 베스트이며, 애자일일 경우 MVP의 핵심 기능과 목표 명시)
  - 개발자는 확정 기능과 가변 기능을 따로 분리하여 아키텍쳐 설계와 모듈 단위 작업 시작 가능
- Case2. 개발 진행 도중 누락/추가 기능 요청
  - 개발자와 공감대를 형성할 수 있도록 요청 배경과 중요도를 먼저 설명해야 함
  - 기획자의 누락으로 발생한 경우에는 솔직하게 잘못을 인정하는 태도 중요
  - 누락된 개발 공수 파악 후 개발 일정 확보
  - 일정 확보가 불가한 경우, 핵심 기능만 구현하거나 우선순위 산정하여 후속개발로 산정해도 됨
  - 기획자가 조정할 수 있는 것은 일정과 스펙이기 때문에, 개발자와 원만한 협의를 도출해야 함.

▪️ 의의

기획자는 국어로 코딩하는 사람 → 개발자의 입장에서 기획 문서를 설계해야 함.
프로덕트의 핵심 기능, 부속 기능에 대해 정의하고 개발자와 공유해야 함.
개발자가 일하는 방식에 대해 끈임없이 탐구할 것

✔️ 커뮤니케이션도 프로덕트 기획처럼, ‘이해’가 먼저다

▪️ 프로덕트를 출시하기 전, 기획 대상인 사용자와 시장을 파악하듯 동료와의 협업에서도 그들의 특성을 이해하고, 업계의 언어로 이야기해야 한다.

▪️ 프로젝트의 리드는 기획의 영역이며, 커뮤니케이션은 문제 해결 역량이다.

생각 정리

▪️ 기존에는 커뮤니케이션을 통합적으로만 생각하고 있었던 것 같다. 함께 일하는 상대방의 직무를 고려하면 더 효과적으로 소통할 수 있음을 알게 되었다.
▪️ 저자는 함께 일하는 동료들의 특성을 이해하기 위해 피그마, XD 실습 및 HTML/CSS 강의를 듣고, SQL과 개발 언어들을 챗GPT나 블로그를 통해 꾸준히 학습하고 있다고 한다.
▪️ 소통이 잘 되는 기획자로 기억되고 싶다는 욕심이 생겼다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 카카오맵은 왜 상세화면을 탭으로 구분했을까?

yj_lynn — Fri, 12 Jan 2024 09:04:43 +0900

아티클 출처

https://maily.so/tipster/posts/643e5160?utm_source=oneoneone

카카오맵은 왜 상세화면을 탭으로 구분했을까?

번개장터, 카카오맵, 카카오T의 업데이트 소식 살펴보기!

maily.so

️ 선정 이유

▪️ 화면을 구성하면서 어떤 방식으로 페이지를 나누어 제공할 것인지 고민해야 했던 적이 많다. 페이지의 메인 기능이 무엇이냐에 따라 결정이 달라지겠지만, 무엇이 더 편리한지 논리적인 근거와 함께 이해하고 싶어서 선정했다.

내용 정리

1. 카카오맵 상세화면

✔️ 지도 서비스에서 상세화면은 특정 장소에 대한 여러 정보를 담는다.

✔️ 카카오맵의 상세화면은 스크롤하여 정보를 확인해야 하는 구조에서 탭 구분으로 변경되었다.

기존 카카오 맵 상세화면	변경된 탭 구조의 상세화면
• 주소, 영업여부와 시간, 웹사이트 주소, 전화번호 등의 기본 정보 및 리뷰 사진 출력
• 페이지 아래 어떤 정보가 이어지는 지 알 수 없으며 스크롤하여 화면을 내려야만 하는 구조
• 다양한 정보를 담고 있고 리뷰 등 사용자의 참여로 인해 정보의 양이 달라지는 경우 스크롤 구조는 불편할 수 있음	탭 선택 시 해당 정보만 모아볼 수 있음
원하는 정보를 바로 확인하기 어려움	어떤 정보가 담겨있는지 더 빠르게 확인 가능

탭 도입 시 고려해야할 점: 정보의 중요도

서비스의 성격에 따라 상세 화면에서 보여줄 수 있는 정보가 달라짐
정보의 중요도 및 순서 우선순위에 따라 기능의 편의가 달라질 수 있음

은 스크롤하여 정보를 확인해야 하는 구조에서 탭 구분으로 변경되었다.

1-1. 카카오맵, 네이버지도, 구글지도의 상세화면 구분

✔️ 상세화면에 포함된 정보가 비슷하더라도 어떤 정보를 먼저 보게 할 것이냐에 대한 구성은 달라질 수 있다.

카카오맵: 홈 - 사진 - 메뉴 - 랭킹 - 후기 - 리뷰
네이버지도: 홈 - 메뉴 - 리뷰 - 사진 - 지도 - 주변
구글지도: 개요 - 메뉴 - 리뷰 - 사진 - 업데이트 - 정보

1-2. 야놀자, 인터파크투어, 스카이스캐너의 상세화면 구분

✔️ 어떤 정보를 강조할 것인지에 따라 바로가기 역할을 하거나 특정 정보를 바로 확인할 수 있는 탭의 구성이 달라진다.

야놀자: 객실선택 - 위치/교통 - 안내/정책 - 시설/서비스 - 후기
인터파크투어: 객실선택 - 시설정보 - 리뷰
스카이스캐너: 특가 - 후기 - 세부정보

2. 번개장터 상품등록

✔️ 번개장터는 ‘상품상태’를 텍스트가 아닌 공통의 기준에 따라 직접 선택하도록 기능을 변경하였다.

생각 정리

▪️ 상세화면 구조는 사용자 경험을 개선하고 정보에 어떻게 빠르게 접근할 수 있게 할지 결정짓는 요소같다. 다양한 어플간의 비교를 통해 사용자 중심의 디자인은 다양할 수 있다는 것을 인식하게 되었다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 기능 출시 후, 우리가 챙겨야 할 것은?

yj_lynn — Thu, 11 Jan 2024 12:40:42 +0900

아티클 출처

기능 출시 후, 우리가 챙겨야 할 것은?

참고:

기능 출시 전, 우리가 챙겨야 할 것은?

️ 선정 이유

❓ ▪️ 출시 후 사용자의 피드백을 받는 방법을 다른 프로젝트에서는 어떻게 진행하고 있는 지 궁금했다.

내용 정리

1️⃣ 사용자 만족도를 고려해야 하는 이유

➕ 사용자 만족도는 사용자와의 ‘관계’를 구축하는 데 있어 중요한 역할을 한다

서비스들은 ‘고객문의’를 통해 VOC를 수집한다.
- 이는 보통 일방향으로 이뤄지며, 긍정이든 부정이든 사용자가 직접 행동을 해야 의견을 들을 수 있다는 한계가 존재한다.

사용자가 특정 행동을 한 직후, 행동에 대한 경험이 아직 남아있을 때 만족도에 해당하는 피드백을 요청하면 좋다.

→ 사용자가 즉시 응답할 수 있으며, → 사용자에 대한 관심을 기울이고 있다는 사실을 알리기에도 좋다. → 사용자가 고객문의를 직접 찾아 나서지 않아도, VOC를 낼 수 있는 환경을 제공할 수 있다.

➕ 발생하는 문제에 대한 빠른 파악이 가능하다.

개발 중 미처 고려하지 못한 상황과 발생한 문제를 빠르게 확인할 수 있다.
서비스를 사용자의 시각으로 살펴볼 수 있는 기회를 제공한다.

❗ 사용자 피드백을 받고, 이를 서비스 개발 과정에 어떤 식으로 활용할 것인지 정의되어 있어야 한다.

단편적 솔루션 도출 보다는 문제점을 찾기 위해 활용해야 한다.
e.g. 수집된 피드백의 다음 단계는? 함께 확인할 정보는?
학습이 충분하지 않은 기능이나 기존에 없었던 서비스라면 피드백이 단순 불만으로 채워질 가능성이 높아 피드백을 받지 않은 것도 방법이다.

우리가 사용자 피드백을 필요로 하는 이유를 함께 고민하기
사용자 만족도를 포함한 피드백을 받지 상황과 받지 않을 상황 구분하기
사용자 피드백을 제품 개발 과정에 어떻게 반영할 수 있을지 기준 마련하기

2️⃣ 만족도 조사에서 ‘타이밍’이 중요한 이유

➕ 로그 수집과 사용자에게 직접 피드백 듣기

두 가지 방법은 상호보완적인 역할을 한다. (행동 기반 데이터로 알 수 없는 내용을 사용자 조사를 통해 알 수 있기 때문)
- 로그수집: 사용자 행동 기반 데이터를 분석 → 서비스 개선에 활용
- 만족도 조사: 사용자의 생생한 의견 수집 → 특정 기능에 대한 피드백 수렴

특정 기능을 준비하는 데에 있어 로그를 어떻게 수집해 데이터를 볼 것인지 + 사용자 만족도 등의 피드백을 어떻게 확인할 것인지를 체크하면 좋다.

➕ 만족도 조사는 어떤 순간에 제공할 것인지가 중요하다.

보통 기능을 사용한 뒤에 만족도를 묻지만, 기능에 따라 시간차가 필요하거나 일정한 사용 흐름이 끝난 뒤에 묻는 고려가 필요할 수 있다.
e.g. 배달이 완료된 순간에 배달이나 주문한 메뉴에 대한 피드백을 요청하는 것보다 식사가 어느 정도 마무리 되었다고 판단하는 순간인 20-30분 뒤에 제공하는 것이 정확도와 응답률을 높일 수 있다.

➕ 동일한 방법의 만족도 조사를 상황에 따라 사용하는 것이 중요하다.

CSAT(Customer Satisfaction Score)
- A에 얼마나 만족하시나요? 라는 직접적인 질문으로 만족도 측정한다.
- 주로 기능을 경험한 직후에 진행한다.
- 기능을 경험한 지 오래된 경우에는 응답이 정확하지 않을 수 있어 일주일 이내 경험을 기준으로 한다.
- 5점 척도로 많이 진행하며, 선택한 항목에 따라 추가 질문을 하는 방식으로 더 자세한 피드백을 확인한다.
- e.g. 기능에 대해 사용자가 매우 불만족 선택 → 개선을 위해 필요한 내용이 무엇인지 추가 질문
- 빠른 확인이 필요한 경우, 2점 척도로 이모지 등을 활용해 만족도를 확인하는 경우도 있다.

CSAT 조사는 단순 만족도를 묻는 방법이기에 정량화가 쉽지 않다. but, 기능에 대한 대략적인 반응을 확인할 수 있으며, 특정 응답수가 감소하거나 부정적인 반응이 일어날 때를 빠르게 알 수 있다.

경험 직후, 어떤 순간에 만족도를 확인할 것인지 고려하기
경험 직후, 일주일 내 확인 등 만족도를 확인하는 기준 정하기
기능에 따라 공통적으로 만족도를 확인할 방법 살펴보기
만족도를 일정 주기에 따라 확인하고 정리하기

생각 정리

▪️ 사용자 만족도를 측정하는 체계적인 방식은 다양하다. 기존 출시했던 서비스에 대한 사용자 피드백은 VOC를 접수받거나, 시장조사를 통해 직접 설문을 하는 방식으로 진행했다. 현재 진행하고 있는 새로운 서비스는 출시를 내년 4월에 앞두고 있어, 출시 후 아티클에서 언급한 방법들로 만족도 조사를 해보고 싶다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com

[아티클 스터디] 실전 UI/UX - 다국어 서비스기획시 고려해야할것들 (feat. RTL)

yj_lynn — Wed, 10 Jan 2024 12:26:28 +0900

아티클 출처

https://brunch.co.kr/@fbrudtjr1/23

실전 UI/UX - 다국어 서비스기획시고려해야할것들

서점군은 가진 능력에 비해 운이 좋게도 다양한 다국어 웹서비스 구축&운영 경험을 가지고 있습니다. 처음 다국어 서비스 구축에 참여하게 되었을 때는 단순하게 생각했죠. 그래 나도 이 바닥

brunch.co.kr

️ 선정 이유

▪️ 현재 글로벌 시장을 대상으로 하는 웹 서비스 프로젝트에 참여하고 있으며, 현지 시장성을 고려한 localization을 담당하고 있다.

▪️ 우리 서비스는 멕시코, 이집트, 베트남, 러시아 등 글로벌 법인을 대상으로 각 국가의 언어 및 영어 서비스를 제공한다. 가장 어려웠던 부분은 오른쪽 → 왼쪽으로 쓰는 아랍어를 화면에 반영하는 것이었다.

▪️ 처음에는 다국어 서비스 기획에 대한 개념이 없어서 이를 이해하고 활용하기 위해 다양한 아티클을 찾아 읽었다.

▪️ 이 중에서 특히 도움이 많이 된 아티클에 대해 나 스스로도 다시 한 번 개념을 정리하고 내 것으로 만들기 위해 선정하였다.

내용 정리

다국어 서비스와 로컬 서비스는 큰 차이점을 가지고 있다. 글로벌 시대에서 많은 서비스들이 글로벌로 진출하고 있는데, 다국어 서비스 구축 경험이 있는 기획자는 많지 않다. 다국어 서비스를 기획할 때에는 아래와 같은 UI/UX 항목을 고민해야 한다.

1️⃣ 기능의 컴포넌트화

✔️ 서비스의 특성, 지역적 특성, 시장 환경 등 여러가지 요인으로 국가별 서비스 범위나 특성이 달라지기도 함.

✔️ 다국어 서비스 기획시에는 변화무쌍한 국가 특성을 고려해 기능을 넣고 빼기 쉽도록 단위별로 컴포넌트화하여 작업하는 것이 중요함.

예외사항 발생시
- 하나의 프레임: 해당 영역을 하드코딩으로 예외처리
- 컴포넌트 단위: 문제 발생 부분만 교체 또는 제외
다양한 국가에 서비스를 한다면, 가장 기능과 컨텐츠가 많은 국가를 우선하여 그 기점으로 다국어로 확산하는 것도 방법

2️⃣ 언어는 최우선 고려사항

✔️ 텍스트 길이에 주의할 것 : 텍스트 길이에 영향을 주는 케이스가 많다.

1) 문자의 압축률

문자의 압축률: 내가 어떤 표현을 할 때 몇 글자의 문자가 필요한가
e.g. 반갑습니다의 다국어 표현 (파파고 기준)
- 한글 : 반갑습니다(5글자)
- 영어 : Nice to meet you (13글자)
- 아랍어: سعيد بلقائك (11글자)
- 베트남어: hân hạnh. (7글자)
동일한 표현을 할 때 한자> 한글 > 영어 순으로 문자의 압축률이 높아지는 특성을 가짐
문자 길이 예상 시 가장 짧은 문자는 한자로, 가장 긴 문자는 영어로 가정하고 레이아웃을 설계할 것

2) CTA 설계 시

CTA: Call To Action 은 다국어 영향을 많이 받음 ← 글자수에 따라 버튼의 width가 달라질 수 있기 때문
해결방법
- 버튼의 가로폭을 글자수에 맞춰 가변적으로 조절
- 가장 긴 문자 기준으로 가로폭을 설계
- e.g. LG전자는 첫번째 방법을 택함
TIP) 레이아웃 설계시 MIN: 중국어, MAX: 영어로 설계하면 다국어의 오차를 줄일 수 있음

3)말줄임

말줄임은 영역이 정해져있고 글자 길이가 영역보다 길거나 예상할 수 없는 경우 사용함
다국어의 말줄임 이슈는 주로 카드형 list 페이지에서 많이 발생
e.g. 브런치 페이지

보통 말줄임을 할 때 글자의 Byte 수를 계산하여 글자를 자름
- e.g. “글자가 80 Byte 초과될 경우 말줄임을 한다”
언어마다 한글자가 차지하는 Byte에 차이가 있음 → Byte기준으로 말줄임 시 언어별 표현되는 단어의 수가 달라짐
- 1글자당 Byte 수
  - 영어: 1
  - 공백/특수문자: 1
  - 한글: 2
  - 중국어: 3
- 공백없이 80 Byte로 글자를 채운다면
  - 영어: 80자
  - 한글: 40자
  - 중국어: 26자
따라서 Byte가 아닌 Character(문자)로 말줄임 처리를 함
- 단점: 문자마다 1글자가 차지하는 영역이 다를 수 있음
- e.g.

4) 문자 코드

다국어 서비스에서 언어가 표시되는 영역과 문자열이 저장되는 위치
1. 퍼블로 입력하는 일반 문자열 (이용안내, 개인보호정책 등) → HTML
2. 관리자 페이지에서 입력하는 문자열 (공지사항, 팝업 등) → Data Base
3. 프로그램에서 표시하는 문자열 (게시판의 List 버튼 텍스트) → 프로그램 소스
1번과 2번은 관리와 수정이 용이하지만 3번은 국가별 페이지에 따라 문자열을 다르게 표현해야 하기 때문에 복잡함
→ 프로그램 소스 내 예외처리로 분기를 해서 해결
→ 단점: 새로운 국가나 언어 추가 시 문구가 표시되는 페이지의 소스에 대한 해당 언어 문구를 일일이 추가해야 함
→ 관리와 추가/수정이 용이하도록 프로그램 공통 문구 코드를 따고 해당 문자열을 DB에 저장해서 불러오는 식으로 관리함

5) 월드타임

시차!
시차는 주로 공지사항 관리, 팝업관리, 메인 배너를 하나의 관리자에서 등록/관리하는 경우 발생

☝ e.g. 전 세계 10개국에 진출해있는 (주)서점전자는 5월 1일 00시부터 각 국가 홈페이지에서 50% 세일 이벤트를 진행 예정.

이벤트로 갈 수 있는 배너와 링크는 5월 1일 00시에 노출되도록 예약 등록해둠

서점전자는 10개국 홈페이지를 하나의 관리자 페이지로 관리하고 있음

(주)서점전자의 매인 배너 관리 기능은 월드 타임이 적용되어 있지 않다. 이때 각 법인 홈페이지별 배너 노출 시간은 다움과 같다. (현지 시각 기준)

한국: 5월 1일 00시 (GMT +9)
미국: 4월 30일 11시 (GMT -5)
중국: 4월 30일 23시 (GMT +8)
프랑스: 4월 30일 17시 (GMT +1)
런던: 4월 30일 16시 (GMT +0)

→ 시차로 인해 한국 시간 기준으로 시차를 적용해 국가마다 다른 시간에 배너가 노출됨

시차 문제를 해결하려면 시차 보정 기능을 추가해야 함
시차 보정 기능 (e.g. 예약 노출 시간 기능)
1. 예약 노출 시간은 한국을 기준으로 하고, 각 국가별 시차 프로그램이 자동 보정(하드코딩)
2. 국가별로 배너 오픈 시간을 별도 설정할 수 있도록 등록 영역 개발 (국가 수만큼 시간을 입력할 수 있는 영역 필요)
3. 전부 한국 시간으로 보여줌
- 서버점검 시간은 시차를 보정하면 안됨 → 등록 옵션에 시차 보정 on/off를 설정할 수 있는 스위치나 라디오 버튼 추가

3️⃣ R to L

✔️ 아랍어의 고유한 특성 RTL

대부분의 국가들은 L to R (Left to Right) 순서로 글을 읽고 작성
아랍어는 R to L (Right to Left) 순서로 글을 읽고 작성
아랍어 선택 시 아랍어 이외의 외국어(영어)는 R To L 적용하지 않음
UI/UX: 레이아웃 설계 시 텍스트가 오른쪽에서 시작할 수 있다는 가정 하에 모든 레이아웃을 설계해야 함
아랍어 문구 변경 시 어순이 강제 변경되는 경우가 있어 검수에 신경써야 함
e.g. LG 전자 아랍어 사이트

4️⃣ 문화적 차이

✔️ 문화적 특성에 따라 콘텐츠 사용 제약사항이 있는 경우가 있음

e.g. 사진 :
- 인종차별이 어느정도 남아있는 국가의 경우 문화적 다양성 존중을 위해 특정 인종만으로 구성된 이미지를 경계하는 국가나 회사가 있음 (e.g. 미국)
- 인종 차별주의 마인드(백인 우월주의)를 가진 회사는 반대로 특정 인종만 구성된 사진을 사용했음 (e.g. 아베크롬비)
- 이슬람 국가의 경우 국가의 주적/원수 나라가 있는 경우가 있어 백인 이미지 사용을 지양하기도 함

생각 정리

▪️ 다국어 웹서비스 구축과 경험은 운이 좋아야 가질 수 있는 경험이라고 저자가 언급했듯이, 글로벌 서비스 출시 경험은 나에게 좋은 경험이라고 생각한다.

▪️ 초기에는 몇 가지 어려움이 있었다. 관련 문헌이나 자료가 제한적이어서 해외 웹사이트를 분석하여 정책을 세우기도 했었다. 그 때 저자의 글을 통해서 시작점을 찾았고, 이번 스터디를 통해 내용을 더 자세하게 정리할 수 있었다.

▪️ 다국어 서비스를 구축할 때 고려해야 하는 사항은 다양하다. 해당 국가의 개인 정보보호 정책 및 법률적인 측면을 법무실과 지속적으로 체크해야 하며, 통화의 종류/소수자릿수, 전화번호 digit, 일주일의 첫 요일 및 시간형식(12시간제 또는 24시간제) 및 국가의 time zone과 같이 국가별로 상이한 세부 정보를 고려해야 한다.

▪️ 또한 국가별 언어팩을 관리해줘야 하는데, 프로젝트 초반에는 그 과정에서 관련 경험자가 없어 시간이 많이 소요되는 비효율적 업무를 했던 적도 있다.

▪️ 특히 아랍어를 적용하는 경우에는 RTL에 따라 UI가 좌우 반전되어 그에 따라 사용성을 검토해야 하는 부분도 있다.

저요!!!! 저!!!! 저 해봤어요 !!!!!!!!! 흑흑

▪️ 글로벌 서비스 프로젝트에 참여하면서 얻은 경험을 정리하는 시간을 조만간 가져봐야겠다.

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그

틀을 잡아가고 있어요 조금만 기다려주세요 ❤️

blog.naver.com