figma·2026년 8월 11일·3분 읽기큐레이션 요약

Figma Make를 통한 시간 절약 측정 | Figma 블로그

Figma 데이터 과학팀은 Figma Make가 디자인 작업을 얼마나 단축하는지 측정하기 위해 100명 대상의 무작위 대조 실험(RCT)을 설계했다. 그 결과 전체 디자인 작업은 20% 빨라지고 16% 쉬워졌으며, 특히 PM은 작업 시간이 23% 단축되고 난이도가 37% 낮아지는 가장 큰 효과를 보였다. 기존 A/B 테스트나 로그 기반 인과 추론만으로는 작업 복잡도와 사용자 경험 같은 교란 요인을 충분히 통제하기 어려워 RCT가 선택됐다. ## AI 시간 절감 측정의 어려움 - AI가 반복적·기계적인 업무를 대신하면 팀이 더 중요한 작업에 집중할 수 있지만, 실제 절감 시간과 효율 개선 지점을 정량화하기는 어렵다. - 작업 완료 시간에는 AI 사용 여부 외에도 다음과 같은 교란 요인이 영향을 준다. - 근속 기간 - 경력과 숙련도 - 작업의 복잡성 - 개인의 주관적인 디자인 경험 - 이런 요인을 통제하지 않으면 생산성 향상이 AI 때문인지, 다른 조건 때문인지 구분하기 어렵다. ## 기존 방법의 한계 ### 온라인 A/B 테스트 - 한 그룹에는 Figma Make를 제공하고 다른 그룹에는 제공하지 않는 방식이다. - 무작위 배정으로 사용자 특성의 차이는 어느 정도 줄일 수 있다. - 그러나 사용자마다 수행하는 작업이 달라 작업 난이도와 유형을 동일하게 맞추기 어렵다. - 따라서 두 그룹의 완료 시간 차이가 AI 효과인지, 과제 차이 때문인지 판단하기 어렵다. ### 로그 데이터 기반 인과 추론 - AI 기능을 사용한 작업과 사용하지 않은 작업의 평균 소요 시간을 비교하는 방식이다. - **성향 점수 매칭(PSM)**은 각 작업이 AI 사용 조건에 속할 확률을 계산해 비교하지만, 모든 교란 요인이 로그에 기록되어 있어야 한다. - 익명화된 사용자 ID만으로는 사용자의 주관적인 디자인 숙련도나 경험을 알 수 없어 PSM 적용에 한계가 있다. - **도구 변수(IV)** 방법은 AI 사용 여부에 영향을 주면서 작업 속도에는 다른 방식으로 영향을 주지 않는 변수가 필요하다. - 하지만 Figma 로그에는 이러한 조건을 만족하는 유효한 도구 변수가 없었다. ## 무작위 대조 실험을 선택한 이유 - RCT는 인과적 효과를 측정하는 표준적인 방법으로, 데이터 수집 단계에서 교란 요인을 직접 통제할 수 있다. - 연구에서는 다음 세 가지 요소를 결합했다. - **무작위 배정:** 참가자를 실험군과 대조군에 나누어 개인별 차이를 양쪽에 대체로 균등하게 분산 - **동일한 과제:** 모든 참가자가 같은 작업을 수행하게 해 과제 속성의 영향을 제거 - **실험 진행 관리:** 숙련된 연구팀이 실험을 감독해 수행 과정의 변동과 통계적 오류를 줄임 - 제품 디자이너와 PM이 일상적인 디자인 업무에서 Figma Make를 사용할 때 얻는 시간 절감 효과를 측정하기 위해 Figma 안팎의 사용자 연구팀과 협력했다. ## 연구 대상과 실험 도구 - 여러 AI 도구를 동시에 허용하면 어떤 도구가 시간 절감에 기여했는지 구분하기 어려워, 연구 대상 AI를 Figma Make 하나로 제한했다. - Figma Make는 사용자 기반이 크고 다양한 디자인 작업에 활용될 수 있어 연구 도구로 선정됐다. - 참가자는 총 100명으로 구성됐다. - 제품 디자이너 50명 - 제품 관리자 50명 - 표본 수는 GitHub Copilot 무작위 대조 실험 등 기존 연구에서 관찰된 효과 크기를 참고해 산출했다. - 이후 통계적으로 유의미한 효과를 탐지할 수 있도록 검정력 분석(power analysis)을 수행해 최종 표본 규모를 결정했다. ## 관찰된 효과 - 전체적으로 Figma Make 사용 시: - 디자인 작업이 **20% 더 빨라짐** - 작업이 **16% 더 쉬워짐** - 직군별로는 PM의 효과가 가장 컸다. - 작업 시간 **23% 단축** - 작업 난이도 **37% 감소** 실무에서 AI의 생산성 효과를 검증하려면 단순한 사용 로그 비교보다, 동일한 과제와 무작위 배정을 포함한 통제된 실험이 더 신뢰할 만하다. 특히 AI 도입 효과를 직군별로 비교하려면 사용자 특성뿐 아니라 과제 복잡도와 실험 진행 방식까지 함께 표준화하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

a-b-testingAIfigma-make데이터 사이언스+2

discord·2026년 4월 24일·3분 읽기큐레이션 요약

적게 측정하고 더 많이 배우기: 중요한 것을 포착하는 더 적고 질 높은 지표 활용

Discord는 실험에서 측정 지표를 많이 포함할수록 계산·해석 비용뿐 아니라 통계적 오류도 커진다고 설명합니다. 다중 가설 검정 보정은 거짓 양성을 줄이지만 실제 변화를 놓칠 가능성, 즉 재현율을 낮출 수 있습니다. 따라서 가장 효과적인 해결책은 모든 지표를 넣는 대신, 서로 다른 개념을 대표하는 소수의 고품질 지표를 선택하는 것입니다. ## 지표가 많아질수록 커지는 문제 - Discord의 실험에는 모든 실험에 자동으로 포함되는 “Default Metric List”가 있었음. - 각 팀이 중요하다고 생각하는 지표를 계속 추가했지만, 기존 지표는 거의 제거되지 않아 목록이 비대해짐. - 지표가 100개이고 각 지표의 유의수준을 5%로 두면, 실제 효과가 없어도 평균적으로 약 5개가 우연히 유의미하게 나타날 수 있음. - 지표가 많아질수록: - 실험 결과를 읽고 해석하기 어려워짐 - 계산 비용이 증가함 - 하나 이상의 거짓 양성이 발생할 확률이 높아짐 - 다중 검정 보정을 적용할 경우 실제 효과를 발견하는 재현율이 낮아짐 ## 다중 비교 문제와 Benjamini-Hochberg 보정 - Discord는 여러 지표를 동시에 검정할 때 Benjamini-Hochberg(BH) 보정을 사용함. - BH는 전체 지표 중 거짓 발견의 비율인 FDR(False Discovery Rate)을 일반적으로 5% 이하로 유지하도록 설계됨. - 지표를 p-value 오름차순으로 정렬한 뒤, 각 지표의 순위에 따라 다음 임계값과 비교함: - `i × α / n` - `i`: p-value 순위 - `α`: 유의수준(예: 0.05) - `n`: 전체 지표 수 - 예를 들어 보정 전 p-value가 0.038인 지표는 일반적인 0.05 기준에서는 유의하지만, BH 보정 후에는 유의하지 않을 수 있음. - BH는 거짓 양성을 줄이는 대신 유의미한 실제 변화를 탐지하는 재현율을 떨어뜨림. - BH는 각 지표가 실제로 변할 가능성에 대한 사전 정보를 활용하지 않으므로 모든 지표를 동일하게 취급함. ## 시뮬레이션으로 확인한 거짓 양성과 재현율의 균형 - Discord는 통계적 공식만 따르지 않고 50,000회의 실험을 시뮬레이션해 지표 수의 영향을 확인함. - 기본 실험 조건: - 효과가 없는 지표 20개는 평균 0, 표준편차 1인 정규분포에서 생성 - 한 지표에는 실제 효과 `z = 2.8`을 부여 - 지표 개수를 바꿔가며 일반 p-value 기준과 BH 보정 결과를 비교 - 시뮬레이션 결과: - 보정하지 않으면 지표 수가 늘어날수록 실험 전체에서 거짓 양성이 발생할 확률이 급격히 증가함. - 5개 지표에서는 거짓 양성률이 약 23%였지만, 50개에서는 약 93%까지 상승함. - BH 보정은 거짓 양성률을 약 5% 수준으로 유지함. - 그러나 지표 수가 5개에서 50개로 늘어나면 BH 적용 시 재현율이 약 60%에서 30%로 하락함. - 보정하지 않은 경우 재현율은 약 80%로 유지되지만, 거짓 양성이 지나치게 많아짐. ## 더 나은 실험 지표를 선택하는 방법 - 다중 검정 보정은 문제를 해결하는 만능 통계 기법이 아님. - 많은 지표를 넣은 뒤 보정으로 처리하는 방식은: - 거짓 경보는 줄이지만 - 실제 제품 변화를 놓칠 가능성을 높임 - 자동으로 모든 실험에 포함할 지표는 수를 줄여야 함. - 서로 중복되는 지표보다 사용자 행동, 품질, 안정성 등 서로 다른 개념을 대표하는 지표를 우선해야 함. - 지표의 개수뿐 아니라 각 지표가 실제 의사결정에 얼마나 유용한지도 정기적으로 검토해야 함. 실무적으로는 실험 기본 지표 목록을 작게 유지하고, 추가 지표는 명확한 가설이나 의사결정 목적이 있을 때만 포함하는 것이 좋습니다. BH 같은 보정 기법을 사용하더라도 지표 선택의 품질과 중복 제거가 통계적 보정보다 우선입니다.

원문 읽기(새 탭에서 열림)

a-b-testingstatistical-analysisexperiment-designbenjamini-hochberg-correction+3

spotify·2026년 4월 22일·4분 읽기큐레이션 요약

LLM 평가로 더 나은 실험하기 — 포크가 아닌 퍼널 | Spotify Engineering

LLM 평가(evals)는 실험을 대체하는 도구가 아니라, 실험 전에 유망한 후보를 걸러내고 실험 후 판단 기준을 보정하는 퍼널의 일부다. Evals는 출력의 품질과 의도 부합 여부를 검증하지만, 실제 사용자의 행동과 사업 성과까지 검증하지는 못한다. 따라서 오프라인 평가와 온라인 A/B 테스트를 반복적으로 연결해야 실험 성공률과 평가 모델의 신뢰도를 함께 높일 수 있다. ## Evals와 실험의 역할 차이 - **Evals는 검증(verification)**을 담당한다. - 출력이 관련성, 일관성, 어조, 의도 부합성 등 정해진 품질 기준을 만족하는지 평가한다. - 대규모 데이터에서 사람의 수작업 평가보다 빠르고 저렴하게 후보를 비교할 수 있다. - **실험은 검증(validation)**을 담당한다. - 실제 사용자가 변경된 결과에 어떻게 반응하는지 확인한다. - 개선된 출력이 참여도, 유지율, 매출 등 실제 사업 성과로 이어지는지 측정한다. - 따라서 관계는 “eval 또는 실험”이라는 분기가 아니라, **eval로 후보를 좁힌 뒤 실험으로 사업 효과를 확인하는 퍼널**이어야 한다. - Spotify의 사례에서도 A/B 테스트 중 긍정적인 결과로 출시되는 비율은 약 12%지만, 약 64%는 회귀를 발견하거나 가설을 수정하는 등 유효한 학습을 제공한다. ## Evals가 제공하지만 제공하지 못하는 것 - LLM judge는 다음과 같은 품질 문제를 대규모로 탐지할 수 있다. - 사용자 의도와 맞지 않는 추천 - 신뢰를 훼손하는 콘텐츠 - 응답의 관련성, coherence, 어조 문제 - 평가 과정에서 팀이 예상하지 못한 문제 패턴을 발견할 수 있다. - 예를 들어 부적절한 추천이 특정 사용자군이나 상황에서 반복된다는 사실을 찾아낼 수 있다. - 발견된 패턴은 제품 개선 가설이 된다. - 같은 judge를 수정 후에도 사용하면 문제가 실제로 줄었는지 확인할 수 있다. - 문제가 되는 평가 항목의 발생 빈도가 감소하면 구현 품질이 개선된 것으로 볼 수 있다. - 그러나 eval만으로는 다음을 알 수 없다. - 사용자의 장기 참여도가 높아졌는지 - 이탈이나 churn이 줄었는지 - 시스템 전체에서 예상치 못한 부작용이 발생했는지 - Spotify에서는 출시된 실험의 약 42%가 세션 길이, 충돌률, 유지율 등 **최적화 대상이 아니었던 보조 지표의 회귀** 때문에 되돌려졌다. 이런 문제는 오프라인 eval에서 포착되지 않을 수 있으므로 온라인 실험과 가드레일 지표가 필요하다. ## 두 단계의 보정과 평가 드리프트 - Evals는 실제 성과를 직접 측정하는 것이 아니라, 성과를 대신하는 **프록시 점수**다. - 기존의 정량 지표(랭킹 점수, precision, recall) 위에 LLM judge라는 또 하나의 보정 계층이 추가된다. - 두 계층 모두 실제 온라인 결과와 비교해 보정해야 한다. - judge가 더 높은 점수를 준 변형이 실제로 더 나은 사용자 경험을 제공하는가? - judge가 실질적 가치가 아닌 표면적 문체나 특정 패턴을 보상하고 있지는 않은가? - 평가 기준은 시간이 지나면서 드리프트할 수 있다. - 모델, 사용자 행동, 콘텐츠 유형, 제품 목표가 바뀌면 기존 judge의 점수와 실제 성과의 관계가 약해질 수 있다. - Qodo의 코딩 eval에서는 Anthropic의 Opus 4.5가 개선되지 않은 것처럼 보였지만, 실제로는 긴 작업에서 성능이 크게 향상된 사례가 있었다. - 반대로 eval 점수는 좋아졌지만 실제 사용자 성과가 개선되지 않는 경우도 가능하다. - 따라서 오프라인 점수와 온라인 결과를 지속적으로 비교해야 eval이 단순한 의견이 아니라 신뢰할 수 있는 증거가 된다. ## 실험 전후를 연결하는 피드백 루프 - **실험 전** - 여러 후보를 LLM eval로 평가한다. - 품질 기준을 충족하지 못하는 후보를 제거한다. - 남은 후보에 실험 리소스를 집중해 실험의 적중률을 높인다. - **실험 중** - 주요 사업 지표뿐 아니라 최적화하지 않은 가드레일 지표도 관찰한다. - 세션 길이, 오류율, 충돌률, 유지율처럼 회귀 가능성이 있는 지표를 함께 확인한다. - **실험 후** - A/B 테스트에 사용된 실제 데이터에 eval을 다시 적용한다. - judge가 선호한 변형이 실제 사용자 성과도 개선했는지 비교한다. - eval 점수와 실험 결과 사이의 차이를 다음 평가 기준을 개선하는 신호로 활용한다. - 결과가 어느 쪽이든 학습이 발생한다. - eval과 사용자 성과가 함께 개선되면 judge가 가치 있는 품질 요소를 측정하고 있다는 뜻이다. - eval만 개선되고 사용자 성과가 그대로라면 judge가 사업 성과와 무관한 요소를 측정하고 있다는 뜻이다. ## 상황에 따른 실험 강도 - 모든 변경에 동일한 수준의 증거를 요구할 필요는 없다. - 빠른 반복 단계에서는 방향성을 파악하기 위한 간단한 테스트를 사용할 수 있다. - 출시 결정이나 영향 범위가 큰 변경에는 충분한 표본, 장기 지표, 가드레일을 포함한 엄격한 실험이 필요하다. - 시스템이 복잡할수록 실험을 생략해 발생하는 대규모 회귀 위험이 커진다. 실무적으로는 LLM eval을 **후보 선별과 품질 진단**에 사용하고, 최종 출시는 반드시 사용자 대상 실험과 가드레일 지표로 판단하는 방식이 권장된다. 실험 결과를 다시 eval 보정에 반영하면 시간이 지날수록 더 정확한 평가 체계를 구축할 수 있다.

원문 읽기(새 탭에서 열림)

a-b-testing머신러닝llm-evalsonline-experiments+3

toss·2026년 2월 27일원문

인턴에서 1인 디자이너로: 뾰족한 가설이 만든 성장 (새 탭에서 열림)

토스뱅크의 신입 디자이너가 비회원 가입 전환율을 높이기 위해 수행한 실험 설계 과정은 데이터 분석과 가설 검증의 유기적인 반복을 통해 정교해집니다. 실험의 성공 여부보다 중요한 것은 '왜'라는 질문을 바탕으로 선명한 가설을 세우는 것이며, 과거의 실험 데이터를 구조적으로 분석하여 승패의 패턴을 학습하는 것이 성장의 핵심입니다. 결국 명확한 문제 정의와 사용자 맥락을 반영한 작은 개선들이 모여 제품의 유의미한 비즈니스 임팩트를 만들어냅니다. **속도와 임팩트 중심의 우선순위 설정** * 비회원 가입 퍼널 중 이탈이 발생하는 인트로, 동의 화면, 신분증 인증 단계를 데이터로 분석했습니다. * 리걸(Legal) 및 컴플라이언스 검토가 필요한 공통 모듈 영역보다는, 수정이 자유롭고 첫 유입에 직접적인 영향을 주는 '인트로 화면'을 실험 대상으로 선정했습니다. * 즉각적인 반복 실험이 가능한 '속도'와 전체 전환율에 기여하는 '임팩트'를 기준으로 리소스를 배분하는 효율적인 접근 방식을 택했습니다. **과거 실험 데이터를 통한 위닝 패턴 학습** * 단순히 새로운 시안을 만드는 데 집중하기보다, 기존에 진행된 수많은 실험의 가설 구조와 문제 정의 방식을 먼저 분석했습니다. * 특정 시안의 승패 결과 자체보다는 어떤 맥락에서 해당 가설이 세워졌는지 '이유'에 집중하여 실패와 성공의 패턴을 흡수했습니다. * 실험 경험이 부족할수록 아이디어를 내는 시간보다 기존의 러닝(Learning)을 구조적으로 읽고 현재 맥락에 적용할 지점을 찾는 시간이 중요함을 확인했습니다. **명확한 가설 수립과 기술적 최적화** * 첫 실험의 실패를 통해 가설이 모호하거나 사용자 맥락을 놓치면 결과 분석이 어렵다는 점을 깨닫고, 한 번에 하나의 변수만 검증하는 원칙을 세웠습니다. * 사용자 반응이 좋았던 '고금리', '매일 이자 받기' 등의 키워드를 문구에 반영하고, 저사양 기기에서도 원활하도록 이미지 로딩 속도를 최적화(저용량 확장자 사용 등)하여 실제 전환율 상승을 이끌어냈습니다. * 기능 설명 중심의 문구에서 벗어나 유저가 혜택을 체감하는 장면을 상상하게 만드는 구체적인 표현으로 개선하여 CTR(클릭률)과 CVR(전환율)을 동시에 높였습니다. **신입 디자이너를 위한 실험 설계 제언** * 실험은 단순히 성공을 확인하는 도구가 아니라 다음 선택을 더 명확하게 하기 위한 과정임을 인지해야 합니다. * 거창한 해답을 찾으려 하기보다 퍼널을 세분화하고, 핵심 문제를 정의한 뒤 가설이 선명하게 드러나는 실험안을 설계하는 것이 중요합니다. * 실패한 실험에서도 다음 가설을 위한 힌트를 얻을 수 있도록 가설과 성공 지표를 사전에 정교하게 설정할 것을 권장합니다.

a-b-testing프로덕트 디자인data-driven-designux-writing+3

figma·2026년 1월 12일·4분 읽기큐레이션 요약

디자인 시스템을 위한 새로운

디자인 시스템은 더 이상 단순한 UI 컴포넌트 라이브러리가 아니라 매출 성장, 고객 충성도, 글로벌 확장, 제품 전략을 지원하는 비즈니스 자산이다. DXC 연구에 따르면 그 가치는 작업 효율뿐 아니라 고객 만족도·유지율·브랜드 경험·시장 확장성과 같은 경영 지표로도 측정할 수 있다. 따라서 디자인 시스템 팀은 재작업 감소보다 고객과 사업에 미친 구체적인 영향을 중심으로 투자 가치를 설명해야 한다. ## 생산성 중심에서 사업 성과 중심으로 - 기존에는 디자인 시스템의 ROI를 다음과 같은 운영 효율로 설명하는 경우가 많았다. - 재작업 감소 - 디자인·개발 핸드오프 단축 - 제품 제작 속도 향상 - 여러 팀 간 일관성 유지 - 그러나 현재 기업들은 디자인 시스템을 다음과 같은 전략적 목표에 활용한다. - 제품 포트폴리오 확장 - 고객 유지율과 충성도 개선 - 글로벌 시장 진출 - 제품 완성도와 브랜드 경험 향상 - 경우에 따라 매출 성장 측정 - 핵심은 디자인 시스템의 활동 자체가 아니라, 그 결과가 사업 지표에 어떤 변화를 만들었는지 연결하는 것이다. ## 고객 성과와 디자인 시스템의 연결 - 기업이 이미 관리하는 고객 지표를 디자인 시스템의 성과 측정 기준으로 활용할 수 있다. - 제품 도입률 - 유지율 - 참여도 - 고객 만족도 - 작업 완료율과 문제 해결 시간 - Freshworks는 새로운 디자인 시스템 도입 이후 고객 서비스 비용을 28% 줄이고 지원 티켓의 해결 시간을 개선했다고 설명한다. - SAP는 앱 내 설문을 통해 사용자 데이터 100만 건 이상을 수집하고, 이를 디자인 시스템 개선에 반영한다. - Freshworks는 온보딩 과정에서 사용자가 어디서 시작해야 할지 어려워한다는 피드백을 바탕으로 새로운 개선 작업을 추진했다. - 고객 경험 개선을 위해 다음 데이터를 활용한다. - CSAT 점수 - A/B 테스트 - 전환 퍼널 분석 - 온보딩 과정의 마찰 지점 - 이런 방식은 디자인 시스템이 단순히 컴포넌트를 제공하는 조직이 아니라, 고객의 불편을 발견하고 제품 경험을 개선하는 체계가 되도록 한다. ## 기업 가치와 제품 품질의 확장 - 디자인 시스템은 기업이 만든 브랜드와 제품 원칙을 여러 팀과 제품에 확산하는 수단이다. - Linear는 디자인 시스템을 통해 ‘완성도 높은 제품을 만든다’는 기업 가치를 규모가 커진 조직에서도 유지하고 있다. - Linear의 접근 방식은 엄격한 규칙과 수치만을 따르기보다 제품이 의도적으로 설계된 것처럼 느껴지는지를 중요하게 본다. - 이를 위해 디자인 시스템을 고정된 규격집이 아닌 살아 있는 시스템으로 운영한다. - 필요에 따라 컴포넌트를 업데이트 - 다양한 상황에 대응할 수 있도록 유연성 확보 - 품질 기준은 유지하되 제품 맥락에 따른 예외 허용 - 결과적으로 높은 제품 완성도는 사용자 경험을 차별화하고, 고객 충성도와 순매출 유지율에 영향을 줄 수 있다. ## 글로벌 확장을 지원하는 설계 기반 - 글로벌 확장에서 디자인 시스템의 역할은 제작 속도를 높이는 것에 그치지 않는다. - 여러 지역에서 일관된 브랜드 경험 제공 - 각 시장의 문화와 언어에 맞는 인터페이스 구현 - 다양한 하드웨어와 화면 크기 지원 - 브랜드별 고유성 유지 - 현대자동차그룹은 현대·기아·제네시스 3개 브랜드의 30개 이상 차량 모델을 하나의 일관된 기반으로 확장하면서도 각 브랜드의 정체성을 유지하려 한다. - Grammarly는 초기부터 현지화를 디자인 시스템 전략에 포함했다. - 사내 언어 전문가를 채용해 문화적 뉘앙스 반영 - 오른쪽에서 왼쪽으로 읽는 언어의 가독성 고려 - 언어별 레이아웃과 표현 차이를 시스템 입력값으로 관리 - 북미, 한국, 폴란드에 분산된 팀은 공통 디자인 시스템을 기반으로 지역별 차이를 조정한다. - 현대자동차그룹의 42dot은 다국어 UX를 검증하기 위해 맞춤형 Figma 플러그인도 활용한다. ## 디자인 시스템의 성과를 입증하는 방법 - 경영진이 중요하게 여기는 기존 비즈니스 지표와 디자인 시스템의 활동을 직접 연결해야 한다. - 예를 들어 다음과 같이 측정할 수 있다. - 디자인 변경 후 고객 만족도 변화 - 온보딩 퍼널의 이탈률 감소 - 지원 문의와 고객 서비스 비용 감소 - 기능 출시 기간 단축 - 글로벌 출시 시 지역별 일관성 및 현지화 품질 - 고객 유지율과 순매출 유지율 변화 - 정성적 사례와 정량적 데이터를 함께 제시하면 디자인 시스템의 기여도를 더 설득력 있게 설명할 수 있다. - 단순히 “컴포넌트를 몇 개 만들었는가”보다 “고객의 문제를 얼마나 줄였고 사업 결과를 어떻게 개선했는가”가 중요한 평가 기준이다. 디자인 시스템 팀은 운영 효율을 기본 성과로 제시하되, 고객 만족도·유지율·비용·매출·글로벌 확장성과 연결된 지표를 함께 관리하는 것이 좋다. 또한 시스템을 경직된 규칙 모음이 아니라 브랜드 가치와 사용자 피드백을 지속적으로 반영하는 살아 있는 제품으로 운영해야 한다.

원문 읽기(새 탭에서 열림)

a-b-testingFigma디자인 시스템사용자 경험+2

toss·2025년 11월 6일원문

토스에서 가장 안 좋은 경험 만들기 (새 탭에서 열림)

토스에서 광고와 혜택 서비스를 담당하는 디자이너는 비즈니스 목표 달성과 사용자 경험(UX) 개선이 상충하는 과제가 아니라, 치열한 고민을 통해 찾아내야 할 ‘교집합’이라고 주장합니다. 필자는 광고라는 피할 수 없는 비즈니스 조건을 수용하되, 사용자가 느끼는 불쾌함을 최소화하고 오히려 가치 있는 경험으로 전환하는 전략을 통해 실질적인 성과를 이끌어냈습니다. 결과적으로 사용자의 신뢰를 지키는 방식이 비즈니스 임팩트를 극대화하는 가장 확실한 길임을 증명하며, 서비스의 수익성과 활성도를 동시에 잡는 결론에 도달했습니다. **사용자의 불쾌감을 줄이는 예측 가능성과 배치** * **예측 가능한 광고 경험:** 광고가 예고 없이 튀어나올 때 발생하는 사용자의 거부감을 줄이기 위해 '광고 보고'라는 문구나 광고 길이를 미리 명시했습니다. 이는 클릭률 저하 우려와 달리 부정적인 피드백을 유의미하게 감소시켰고, 광고를 수용할 사용자만 선택하게 함으로써 광고 효율을 유지했습니다. * **동선을 방해하지 않는 위치 선정:** 계좌 내역 등 사용자의 핵심 정보 탐색 동선에 광고를 배치해 혼란을 주던 방식을 폐기했습니다. 정보를 오인하지 않도록 광고 영역을 분리 배치한 결과, 매출 타격 없이 사용자의 신뢰와 지표를 동시에 회복할 수 있었습니다. **광고를 혜택과 재미로 인식하게 만드는 전략** * **맥락에 맞는 광고 제공:** 광고주가 직접 집행할 수 있는 B2B 광고 플랫폼을 구축하여 광고의 양을 늘리고, 유저 개개인에게 필요한 순간(예: 자동차 보험 만료 시점)에 맞춰 광고를 노출해 광고가 '혜택'처럼 느껴지게 설계했습니다. * **인터랙티브한 재미 요소 도입:** 광고를 단순 이미지 노출이 아닌 퀴즈, 게임, 휴대폰 움직임에 반응하는 인터랙션 등 재미있는 콘텐츠로 변모시키기 위해 팀 내부에서 정기적인 아이데이션을 진행하고 이를 실제 제품에 반영했습니다. **적절한 보상 설계를 통한 비즈니스 모델 전환** * **사용자가 체감하는 보상의 가치 탐색:** 1년 이상의 실험을 통해 현금, 기프티콘, 일확천금형 복권 등 다양한 보상 체계를 테스트하며 사용자가 광고 시청의 '노동 강도'를 기꺼이 수용할 만한 지점을 찾아냈습니다. * **만보기 복권의 성공 사례:** 광고 시청 시 100만 원 당첨 기회를 주는 '복권' 형태의 보상을 만보기 서비스에 도입하여, 적자 서비스를 수익 창출 서비스로 전환했습니다. 이는 유저 활동성과 만족도를 동시에 높여 구글로부터 게임 외 서비스 중 광고 임팩트가 가장 큰 사례로 인정받기도 했습니다. 비즈니스와 사용자 경험 사이에서 고민하는 조직이라면, 단순히 광고를 숨기거나 강요하기보다 사용자의 신뢰를 지키는 '투명성'과 적절한 '보상'의 지점을 찾는 실험을 반복해야 합니다. 광고가 사용자의 목적을 방해하는 요소가 아니라, 그 자체로 재미나 이득을 줄 수 있는 보완재로 기능하게 할 때 비즈니스는 지속 가능한 성장을 이룰 수 있습니다.

a-b-testing사용자 경험프로덕트 디자인gamification+3

figma·2023년 8월 9일·3분 읽기큐레이션 요약

디자인과 비즈니스의 접점 탐색하기: 에어비앤비 브라이언 체스키와의 대담 | 피그마 블로그

Airbnb의 브라이언 체스키는 디자인을 단순한 시각 작업이 아니라 사업 전략과 의사결정의 중심에 두어야 한다고 주장합니다. 그러나 회사가 성장하면서 Airbnb는 제품 관리자, 조직 분화, A/B 테스트 중심의 관습적인 운영 방식에 묻혀 초기의 창의성과 고객 중심성을 잃어갔습니다. 체스키는 2019년 위기를 자각한 뒤 애플의 디자인 중심 경영에서 회복의 실마리를 찾기 시작했습니다. ### 디자인을 기반으로 시작한 Airbnb - 체스키와 공동창업자 조 게비아는 RISD에서 만난 디자이너였고, 엔지니어 네이선 블레차르지크와 함께 회사를 세웠습니다. - “낯선 사람끼리 서로의 집에 머물 리 없다”는 통념과 “디자이너는 회사를 창업하지 않는다”는 편견을 동시에 깨야 했습니다. - Airbnb의 출발점은 디자인을 회사의 의사결정 테이블로 가져오는 것이었습니다. - 고객이 사랑하는 특별하고 매력적인 제품을 만드는 것이 회사의 핵심 철학이었습니다. ### 성장 과정에서 사라진 창의성 - 2019년 체스키는 회사가 처음의 비전과 달라지고 있다는 위기감을 느꼈습니다. - 회사는 약 10개의 큰 부문과 각 부문별 세부 조직으로 복잡하게 나뉘었습니다. - 제품 관리자 중심으로 운영되며 프로젝트가 지나치게 많아졌고, A/B 테스트가 풍부하게 실행됐습니다. - 인력이 늘고 프로젝트가 증가했지만 오히려 앱의 변화는 줄어들고 비용은 커졌습니다. - 체스키는 디자인의 창의적 과정에는 용기와 직관이 필요한데, 과학적 방법론과 효율 중심의 조직 구조 속에서 자신 역시 그 용기를 잃었다고 회고합니다. ### 디자이너가 경영에서 소외되는 이유 - 체스키는 엔지니어, 마케터, 재무·운영 전문가에 비해 디자이너가 CEO가 되는 경우가 드물다고 지적합니다. - 기업은 대체로 측정과 검증을 중시하는 과학적 방법론에 맞춰 조직됩니다. - 반면 디자인은 불확실성을 감수하고 새로운 방향을 선택해야 하므로 더 취약하고 용기가 필요한 영역입니다. - 디자인 리더가 경영에 참여하지 않으면 회사는 점차 기존 업계의 업무 방식과 조직 관행을 답습하게 될 수 있습니다. ### IPO를 앞둔 조직 개편의 딜레마 - 체스키가 문제를 인식한 시점은 Airbnb가 기업공개를 준비하던 2019년 말이었습니다. - 상장을 앞두고 회사를 근본적으로 재편하는 것은 위험했기 때문에, 문제를 알면서도 즉시 해결하기 어려웠습니다. - 그는 공동창업자들과 상황을 논의했지만 구체적으로 무엇을 바꿔야 할지 알지 못했습니다. - 이 시기에 애플 출신 크리에이티브 디렉터 히로키 아사이와 애플 디자인을 이끌었던 조너선 아이브를 만나며 새로운 전환점을 맞게 됩니다. ### 애플의 디자인 중심 경영에서 얻은 자극 - 체스키는 스티브 잡스가 애플에서 만들어낸 디자인 르네상스를 잊고 있었다고 말합니다. - 아사이와 아이브는 디자인을 제품의 한 기능이 아니라 회사를 운영하는 방식으로 설명했습니다. - 이 만남은 Airbnb가 다시 초기의 “마법”과 디자인 중심 철학을 회복하는 계기가 되었습니다. - 글의 핵심 문제의식은 디자인이 사업 실행 이후의 장식이 아니라, 제품 방향과 조직 운영을 함께 결정해야 한다는 데 있습니다. 회사가 커질수록 조직 세분화와 실험 지표만으로는 고객이 느끼는 제품의 가치와 독창성을 지키기 어렵습니다. 따라서 창업자와 경영진은 디자이너를 실행 조직의 구성원이 아니라 사업 전략을 함께 만드는 의사결정자로 참여시키고, 필요할 때는 성장 과정에서 굳어진 관행을 과감히 재검토해야 합니다.

원문 읽기(새 탭에서 열림)

a-b-testingFigma사용자 경험design-thinking+2

figma·2022년 10월 12일·3분 읽기큐레이션 요약

데이터를 활용하는 방법 | 피그

Figma는 서비스를 제공하는 데 필요한 **기능 데이터**와 제품 개선에 활용하는 **분석 데이터**를 구분해 수집·활용한다. 분석 데이터는 기능 개발, 성능 개선, 커뮤니티 보호를 위한 의사결정을 지원하며, A/B 테스트와 데이터 분석을 통해 사용자 경험을 정량적으로 검증한다. 글은 데이터 활용이 제품을 발전시키는 동시에 고객에게 수집 목적과 책임을 투명하게 설명해야 한다고 강조한다. ## 기능 데이터: 서비스 제공에 필요한 최소 정보 - 이메일 주소는 사용자 이름 부여와 비밀번호 재설정 등 중요한 안내에 사용된다. - 가입 시 이름과 역할을 추가로 수집하며, 이 정도의 기본 정보만으로 파일 생성과 협업을 시작할 수 있다. - 다른 클라우드 서비스와 달리 신원 확인 서류나 문서 등 민감한 정보를 일반적으로 요구하지 않는다. - 유료 플랜의 결제 정보는 Figma가 직접 처리하지 않고 결제 인프라 제공업체인 Stripe가 수집·처리한다. ## 분석 데이터: 제품 개선을 위한 사용 정보 - 사용자가 어떤 기능을 사용하는지, 사용하지 않는지, 이용 과정에서 어려움을 겪는지를 파악한다. - 플랫폼에 접근하는 방식과 같은 메타데이터도 분석 대상에 포함된다. - 사용자 의견이나 소셜미디어 반응만으로는 전체 사용 패턴을 파악하기 어렵기 때문에 정량적 데이터가 필요하다. - 데이터 과학팀이 수집된 정보를 처리·분석해 제품 개발 방향을 세운다. - 주요 활용 목적은 기능 개선, 애플리케이션 성능 최적화, Figma 커뮤니티 보호다. ## A/B 테스트를 통한 기능 개선 - Figma는 UX 리서치, 데이터 분석, 제품 직관에서 세운 가설을 실험으로 검증한다. - 새로운 기능이나 UI 변경이 사용자 행동에 미치는 영향을 정량적으로 비교해 출시 여부를 판단한다. - 공유 모달 개선 사례에서는 가입 후 첫 달에 공유 모달을 여는 사용자가 20%에 불과했고, 그중 실제 파일 공유에 성공하는 비율도 절반이었다. - Figma는 UI를 단순화하고 부차적인 기능을 별도 탭으로 옮겨 공유 과정을 쉽게 만들었다. - 실험 결과: - 초대장을 보내는 사용자 비율이 2% 증가했다. - 파일마다 초대되는 사용자 수가 2% 증가했다. - Figma Community에 작업물을 게시하려는 성향에는 부정적인 변화가 없었다. - 이 결과는 이후 공유 경험을 개선하는 작업의 방향을 설정하는 근거가 됐다. ## 성능 문제와 장애 원인 분석 - Figma의 여러 팀은 플랫폼별 애플리케이션 성능 데이터를 지속적으로 분석한다. - 분석 결과는 성능 개선 과제와 전반적인 사용자 경험 향상에 활용된다. - iOS 앱 베타 출시 후에는 충돌 발생 빈도, 충돌 상황, 영향을 받는 플랫폼을 조사했다. - 분석 결과 프로토타입이 iOS 충돌의 주요 원인 중 하나였으며, 프로토타입 관련 충돌의 25%가 로딩 시작 후 10초 이내에 발생했다. - 이처럼 단순히 충돌 횟수만 보는 것이 아니라, 특정 기능·플랫폼·사용 시점과 연결해 문제의 우선순위를 정한다. Figma의 사례는 필요한 기능 데이터는 최소한으로 수집하고, 분석 데이터는 구체적인 제품 문제를 해결하는 데 사용해야 한다는 점을 보여준다. 데이터 기반 의사결정은 사용자 행동을 더 정확히 이해하게 하지만, 실험 결과를 사용자 경험과 개인정보 보호라는 관점에서 함께 검토하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

a-b-testingiOS데이터 사이언스data-analytics+2

figma·2022년 1월 19일·3분 읽기큐레이션 요약

Draft 3 (Standard blog style):

Figma는 댓글이 팀 협업과 사용자 유지에 중요한 기능이라는 데이터를 확인했지만, 실제 사용률이 낮은 원인을 실험으로 검증했다. 댓글 진입점을 더 쉽게 노출하자 댓글 작성이 45% 증가했지만, 위치를 단순히 왼쪽에서 오른쪽으로 옮긴 실험은 발견 가능성을 20% 낮췄다. 이 과정은 제품 가설을 직관이 아니라 데이터로 검증하고, 작은 실험을 반복해 전면적인 댓글 경험 개편으로 발전시킨 사례다. ## 댓글과 팀 성장의 관계 - 첫 달에 협업한 팀은 그렇지 않은 팀보다: - 유지될 가능성이 1.75배 높았다. - 유료 고객이 될 가능성이 6.5배 높았다. - Figma는 편집자뿐 아니라 보기 전용 사용자도 디자인 과정에 참여해야 팀 전체의 협업이 성장한다고 판단했다. - 댓글은 파일에 대한 피드백을 주고받는 기능이므로, 팀 협업을 시작하게 하는 ‘마법 같은 순간’이 될 수 있다고 가설을 세웠다. - 그러나 댓글이 팀 성장과 참여도의 강한 지표임에도 실제 사용률은 높지 않아, 데이터와 사용자 행동 사이의 차이를 실험으로 조사했다. ## 댓글 발견 가능성 가설 - 기존에는 Figma 편집기 왼쪽 상단의 아이콘을 눌러 댓글 모드에 진입해야 했다. - 사용자 조사에서 댓글의 가치는 인정했지만, 기능 자체를 찾기 어렵다는 문제가 확인됐다. - 첫 번째 실험은 보기 전용 개발자를 대상으로 진행했다. - 이 사용자들은 디자이너와 긴밀히 협업하지만, 기존에는 댓글을 가장 적게 사용하는 집단이었다. - 실험군과 대조군을 50 대 50으로 나누고 2주간 관찰했다. - 댓글 작성을 유도해 기능을 노출한 결과: - 실험군의 댓글 작성이 45% 증가했다. - 다음 주 댓글로 다시 돌아오는 비율에는 부정적인 영향이 없었다. - 즉, 댓글 자체의 가치가 부족한 것이 아니라 사용자가 기능을 발견하지 못한 것이 주요 장벽이었다. ## 댓글 진입점 이동 실험의 반전 - 두 번째 실험에서는 댓글 진입점을 메뉴 바 왼쪽에서 오른쪽으로 옮겼다. - 왼쪽은 디자인 도구와 캔버스 기능이 모여 있고, 오른쪽에는 협업·보기 기능이 많으므로 댓글도 오른쪽이 더 적합할 것이라고 예상했다. - 신규 가입자를 대상으로 50 대 50 실험을 진행하고, 가입 후 7일 안에 댓글을 발견한 비율을 측정했다. - 예상과 달리 댓글 발견 가능성이 전체적으로 20% 감소했다. - 기능의 의미와 무관하게 위치, 주변 UI, 사용자의 기존 탐색 습관 같은 작은 변화가 발견성과 사용률에 큰 영향을 줄 수 있음을 보여줬다. ## 데이터 기반 제품 개발의 교훈 - 제품 가설은 대부분 맞지 않을 수 있으므로, 직관만으로 전면 출시하지 않고 실험으로 검증해야 한다. - 첫 번째 실험은 ‘노출을 높이면 사용이 늘어난다’는 가설을 입증했다. - 두 번째 실험은 ‘오른쪽이 협업 기능에 적합하므로 댓글도 더 잘 발견될 것’이라는 가설을 반박했다. - 실패한 실험도 사용자의 행동 패턴과 제품 구조를 이해하는 데 중요한 정보를 제공한다. - 여러 차례의 작은 실험과 사용자 조사 결과가 쌓이면서 댓글 기능의 재설계와 전체 사용자 대상 출시로 이어졌다. 댓글 같은 협업 기능은 기능을 추가하는 것보다 사용자가 자연스럽게 발견하고 진입하도록 만드는 일이 중요하다. 따라서 UI 위치를 변경할 때는 직관에 의존하지 말고, 대상 사용자와 명확한 지표를 정한 뒤 통제 실험으로 효과와 부작용을 함께 측정하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

a-b-testingFigmacollaborationuser-research+2

figma·2020년 1월 29일·3분 읽기큐레이션 요약

새로운 Maze 연동

Figma와 Maze의 통합으로 개발 단계까지 기다리지 않고 Figma 프로토타입을 초기부터 사용자 테스트할 수 있게 되었다. Figma 프로토타입 링크를 Maze에 복사해 가져오면 실제 사용자 행동을 정량적으로 측정하고, 제품팀이 연구 결과를 공유하며 개선 방향을 논의할 수 있다. 글은 효과적인 사용자 테스트를 위해 명확한 목표 설정, 사전 검증, 다양한 사용자 모집, 중립적인 과제 설계, 공동 분석을 권장한다. ## Figma와 Maze의 통합 - Figma 프로토타입 링크를 Maze에 복사·붙여넣기만 하면 테스트를 시작할 수 있다. - 개발 환경에서 A/B 테스트를 진행할 때까지 기다리지 않고, 디자인 초기 단계에서 사용성 문제를 발견할 수 있다. - Maze는 여러 사용자 흐름에서 경험을 정량적으로 측정한다. - 소규모 1:1 인터뷰부터 최대 5만 명 규모의 테스트까지 지원한다. - Maze는 Ring, Revolut, IBM 등 기업의 사용자 리서치에 활용되고 있다. ## 테스트 전에 성공 기준 정의 - 프로토타입을 만들기 전에 테스트의 목표와 성공 조건을 정해야 한다. - 목표는 구체적이고 측정 가능해야 한다. - 예를 들어 다음과 같이 기준을 수치로 정의할 수 있다. - 참가자의 80% 이상이 과제를 성공적으로 완료 - 오클릭 비율 2% 미만 - 테스트마다 검증하려는 목표와 평가 지표가 달라질 수 있으므로, 목적에 맞는 기준을 설정해야 한다. ## 실제 테스트 전 파일럿 진행 - 대규모 사용자 테스트 전에 내부 팀원, 친구, 가족 등을 대상으로 시험 운영을 한다. - 파일럿을 통해 다음 사항을 점검할 수 있다. - 과제 설명이 명확한지 - Figma 프로토타입의 인터랙션이 정상 작동하는지 - 테스트 목표가 실제로 의미 있는지 - 예상치 못한 오류나 혼란이 발생하는지 - 제품의 베타 테스트나 점진적 출시처럼 사용자 테스트도 사전 검증 단계가 필요하다. ## 기존 사용자와 비사용자 모두 모집 - 기존 사용자는 제품에 익숙하고 새로운 기능을 적극적으로 사용해볼 가능성이 높다. - 새로운 기능을 가장 많이 채택할 고객 세그먼트를 우선적으로 테스트하면 유용한 피드백을 얻을 수 있다. - 다만 기존 사용자만 조사하면 제품 구조에 익숙한 사람에게 편향될 수 있다. - 비사용자도 함께 테스트해 처음 접하는 사람의 관점과 직관성을 확인해야 한다. ## 유도하지 않는 과제와 질문 작성 - 사용자가 특정 답이나 경로를 따라가도록 지시하는 표현을 피해야 한다. - “여기를 클릭하세요”, “Signup 버튼으로 이동하세요”, “Feed 페이지로 가세요” 같은 표현은 사용자의 자연스러운 탐색 능력을 검증하지 못하게 한다. - 과제는 내부 기능명이나 구체적인 조작법보다 사용자가 달성해야 할 최종 목표 중심으로 작성해야 한다. - 이를 통해 인터페이스가 실제로 직관적인지 확인할 수 있다. ## 팀 전체가 참여하는 결과 분석 - 사용자 테스트의 어려움은 데이터를 얻는 것뿐 아니라, 결과에 대한 조직의 공감대를 형성하고 다음 행동을 결정하는 데 있다. - 제품팀 전체가 분석 과정에 참여하면 각자 결과를 해석하고 개선 방향을 논의할 수 있다. - Maze는 즉시 생성할 수 있는 리포트와 공유용 사용자 지정 URL을 제공한다. - 연구 결과를 팀원과 쉽게 공유해 발견 사항을 실제 제품 개선으로 연결할 수 있다. 실용적으로는 작은 파일럿 테스트부터 시작해 성공 지표를 검증한 뒤, 기존 사용자와 신규 사용자를 포함한 규모 있는 테스트로 확장하는 방식이 적절하다. 테스트 과제는 조작법이 아닌 사용자의 목표를 중심으로 작성하고, 결과 분석에는 디자이너·개발자·제품 담당자가 함께 참여하는 것이 좋다.

원문 읽기(새 탭에서 열림)

a-b-testingFigma사용자 경험프로토타이핑+3

figma·2019년 12월 15일·3분 읽기큐레이션 요약

More natural/engaging

2010년대 모바일 혁명은 기술 기업에서 디자인의 역할을 주변 업무에서 핵심 경쟁력으로 끌어올렸다. 스마트폰은 더 복잡한 사용 환경과 방대한 사용자 데이터를 만들어냈고, 디자이너는 기능 우선순위 설정과 지속적인 UI 실험을 주도하게 됐다. 특히 아이폰은 소비자가 기대하는 제품의 미적·사용성 기준을 높이며 기업 전반의 디자인 투자를 촉진했다. ## 모바일 물결이 디자인의 위상을 높이다 - 아이폰은 2007년에 출시됐지만, 2009년 인앱 결제와 2010년 아이패드 등장 이후 2010년대에 본격적으로 산업 전반을 변화시켰다. - 스마트폰 보급으로 제품이 일상생활의 중심이 되면서, 복잡한 기술 시스템을 간단한 상호작용으로 바꾸는 디자이너의 역량이 중요해졌다. - 과거 엔지니어 중심이었던 실리콘밸리 기업들은 디자인 인력을 대규모로 채용하기 시작했다. - IBM 같은 기업은 2년 동안 35개 이상의 디자인 에이전시를 인수할 정도로 디자인 역량 확보에 적극적으로 나섰다. ## 모바일 환경이 만든 복잡성 - 모바일 화면은 데스크톱보다 작고 기기별 크기도 다양해졌다. - 사용자는 마우스 클릭 대신 손가락으로 탭, 스와이프, 길게 누르기 등의 동작을 수행했다. - 사용 상황도 책상 앞에 한정되지 않고 걷거나 이동하는 중으로 확장됐다. - 기업은 제한된 화면과 사용자의 주의력 안에서 어떤 기능을 우선 제공할지 결정해야 했고, 이 과정에서 디자이너의 문제 정의와 우선순위 판단이 중요해졌다. - 컴퓨팅이 화면 안에만 머무르지 않고 사용자의 주변 환경과 일상 행동 속으로 확장됐다. ## 데이터 기반 디자인과 A/B 테스트 - 스마트폰은 카메라, 마이크, 위치 정보 등을 통해 과거보다 훨씬 많은 사용자 데이터를 만들어냈다. - 모바일 사용이 일상화되면서 제품팀은 버튼 색상, 문구, 화면 구성 같은 UI 변형을 지속적으로 실험했다. - 실험 결과는 가입, 구매, 공유 등 사용자의 실제 행동 변화로 평가됐다. - 페이스북을 비롯한 기업들은 이러한 실험을 수행할 디자이너를 적극 채용했다. - 디자인은 시각적 완성도를 만드는 일을 넘어, 성장 지표를 개선하는 데이터 기반 업무로 확장됐다. - 2011년부터 2019년 사이 미국 성인의 스마트폰 보유율은 35%에서 81%로 증가했다. ## 아이폰이 세운 디자인 기준 - 아이폰은 기술 제품이 단순히 기능적이기만 해서는 안 된다는 인식을 널리 퍼뜨렸다. - 과거의 소프트웨어가 투박하고 실무적인 도구로 여겨졌다면, 아이폰은 제품의 외관과 사용 경험 자체를 경쟁 요소로 만들었다. - 아이폰은 맥보다 더 넓은 대중에게 디자인 중심의 제품 경험을 보여주며 소비자의 기대치를 높였다. - 기업들은 애플처럼 보이고 작동하는 제품을 만들려 했고, 소비자 역시 애플 수준의 완성도를 기대하게 됐다. - 이런 영향은 아이폰뿐 아니라 안드로이드와 틴더 같은 모바일 중심 서비스의 디자인 방향에도 나타났다. - 애플의 영향은 긍정적인 디자인 혁신을 이끌었지만, 모든 제품이 애플의 미학을 모방하려는 결과도 낳았다. ## 실무적 시사점 모바일 제품을 설계할 때는 기능을 많이 넣는 것보다 사용자의 상황과 제약을 먼저 이해하고 핵심 상호작용을 선별해야 한다. 또한 정성적 사용자 이해와 A/B 테스트 같은 정량적 검증을 함께 활용하되, 단기 성장 지표뿐 아니라 전체 사용자 경험과 제품의 일관성까지 고려하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

a-b-testing사용자 경험mobile-designux-ui-design+2