QA를 통과한 크로스 플랫폼 앱을 배포하고 스토어 리뷰를 통과했지만, 사용자에게는 첫 5분 동안 느끼는 불만이 있습니다. 로그인은 작동합니다. 네비게이션은 기술적으로 작동합니다. API은 데이터를 반환합니다. 그러나 리뷰에서는 앱이 느리고 어색하거나 불신스럽다고 말합니다.
그것은 앱 사용자 경험 lives.
Capacitor and Electron teams run into this all the time because feature delivery is visible inside the team, while friction shows up outside it. A WebView takes a beat too long to become interactive. A desktop window restores in an odd state. A form spinner doesn’t explain whether work is happening or frozen. An update fixes one bug but leaves half the user base on an older bundle for days. None of those issues look dramatic in a sprint demo. Together, they define whether people keep using the product.
Adjust는 사용자가 앱을 사용하지 않도록 된 이유로 90%가 성능이 좋지 않다고 말했습니다. __CAPGO_KEEP_0__ 모바일 앱의 사용자 경험에 대한 안내서에서 말하는 대로, 개발 팀에게는 이 대화가 바뀐다. UX는 앱이 작동하는 후에 추가하는 층이 아니다. 성능, 신뢰성, 명확성, 사용자가 가치에 도달하는 속도에 따라서 UX는 작동 결과이다.
크로스 플랫폼 팀에게는 이게 동시에 위험과 기회를 의미한다. 위험은 iOS, Android, 데스크톱에서 동일한 마찰을 퍼뜨리는 한 코드베이스다. 기회는, 올바른 순간을 측정하고 안전하게 업데이트를 배포하는 한, 한 번의 측정된 수정이 모든 곳에서 여행을 개선할 수 있기 때문이다.
내용목록
- 작동하는 앱은 충분하지 않다. 왜?
- 현대 앱 사용자 경험의 네 개 기둥
- 사용자 경험을 측정하는 방법: 실행 가능한 지표
- 다중 플랫폼 앱 UX를 개선하는 실용적인 전략
- 계속적인 UX 개선에서 신뢰할 수 있는 업데이트 역할
- 모든 것을 함께하는 첫 번째 UX 개선 주기
왜 '작동하는' 앱만큼은 충분하지 않은가?
작동하는 앱은 작업을 완료합니다. 좋은 앱은 사용자가 작업을 완료하는 것을 망설이지 않고 혼동하지 않고 두려움 없이 도와줍니다. 그것은 같은 것이 아닙니다.
많은 팀이 출시 후에 이것을 발견합니다. 내부 테스터들은 제품을 잘 알고 있기 때문에 흐름을 느리게하고 맥락을 가지고 움직입니다. 실제 사용자는 그렇지 않습니다. 그들은 차갑게, 작은 화면에서, 회의 사이에, 약한 네트워크에서, 또는 랩톱 배터리가 거의 죽은 상태에서 도착합니다. 그들은 아키텍처가 미학적이든지 아니면 첫 번째 유용한 액션을 너무 오래 걸리든지 아니면 사용자가 탭을 때 잠시 UI가 잠시 멈추는 경우에도 그들은 그것에 관심이 없습니다.
기술적으로 받아들여지는 UX의 숨겨진 비용
크로스 플랫폼 스택은 이 문제를 특정한 방식으로 증폭시킵니다. Capacitor 앱은 종종 웹 가정들이 모바일 네이티브 조건에서 유효하지 않게 상속됩니다. Electron 앱은 특히 팀이 데스크톱을 무제한 환경으로 간주하고 시작 작업, 배경 동기화, 그리고 oversized front-end bundles를 쌓을 때 무거워집니다.
결과는 항상 충돌이 아닙니다. 종종 그것은 quieter:
- 망설임: 사용자가 다음 단계가 명확하지 않아 멈추는 것입니다.
- 지연: 버튼이 늦게 응답하여 사용자가 다시 한번 클릭하는 것입니다.
- 신뢰 상실: 데이터가陈舊하여 사용자가 동기화가 성공했는지 의심하는 것입니다.
- 탈락: Onboarding은 완료되지만 사용자는 제품의 핵심 가치를 달성하지 못한다.
실용적인 규칙: 사용자가 앱을 "느슨한"이라고 말하는 경우, 일반적으로 작은 엔지니어링 및 제품 결정의 연쇄를 보고하는 것이 아니라 단일 시각 디자인 문제를 보고하는 경우이다.
기능 로드맵에 익숙한 팀에게는 UX feedback이 실패한 테스트 케이스보다 더 복잡한 것처럼 느껴질 수 있지만, UX를 시스템으로 다루면 여전히 관리할 수 있다. 첫 번째 세션의 행동, 오류 상태, 로딩 동작, 업데이트 수락, 작업 완료를 보는 것이 아니라 인터페이스가 "최신"인지 묻는 것이 아니라.
Why UX는 엔지니어링에 속하는가
다중 플랫폼 제품에서 가장 큰 영향을 미치는 UX 문제의 대부분은 구현 세부 사항에서 비롯된다. 캐시 무효화가 콘텐츠가 신뢰할 수 있는지 여부를 결정한다. 번들 크기가 상호 작용 시간에 영향을 미친다. 상태 지속성이 사용자가 앱을 다시 열 때 방향감을 느끼는지 여부를 결정한다. 업데이트 전송이 현장에서 마찰을 제거하는 속도에 영향을 미친다.
UX는 제품, 디자인, QA, 엔지니어링의 공유 작업이다. 디자이너는 흐름을 형성한다. 제품은 결과를 우선한다. 엔지니어는 경험을 실제 조건에서 빠르고 안정적이고 회복 가능한지 결정한다.
만약 앱이 모든 것이 잘못되지 않으면서만 작동한다면, 사용자는 앱이 깨진 것이라고 말할 것이다.
현대 앱 사용자 경험의 네 개柱
UX가 모호해지지 않도록 하려면 가장 단순한 방법은 UX를 네 개의柱로 나누는 것이다. 사용성, 성능, 신뢰성, 가치만약 하나가 약하다면 다른 것들은 강해도 사용자는 그것을 느끼게 된다.
사용성은 길이가 명확한 경로를 의미합니다.
사용성은 사용자가 다음 단계를 알 수 있고, 오류를 일으켰을 때 복구할 수 있는지 여부를 나타냅니다. 이에는 네비게이션 레이블, 컨트롤 배치, 폼 동작, 빈 상태, 앱이 플랫폼의 기대치를 존중하는지 여부가 포함됩니다.
Capacitor 앱에서, 사용성이 나쁜 경우 팀이 웹 인터랙션을 모바일로 복사했을 때 나타납니다. 마우스 오버 가정은 존재하지 않습니다. 밀집된 설정 페이지가 지치게 됩니다. 탭 대상이 좁아 보입니다. 데스크톱에서 모달 스택이 괜찮아 보이지만 모바일에서 혼란스럽게 보입니다.
좋은 사용성은 화려하지 않습니다. 그것은 마찰의 부재입니다.
성능과 신뢰성이 신뢰를 형성합니다.
성능은 앱이 반응이 빠른지 여부를 나타냅니다. 신뢰성은 앱이 예측 가능하게 행동하는지 여부를 나타냅니다. 사용자는 그 두 개념을 명확하게 구분하지 않습니다. 그들은 앱에 신뢰를 가지는지 여부를 알고 싶습니다.
화면이 즉시 나타나지만 동기화 중에 실패하는 화면은 여전히 나쁜 경험입니다. 반응이 느린 앱이 안정적이지만 반응이 느린 앱은 사람들을 잃습니다. 이 때문에 세션 수준 분석이 중요합니다. Dynatrace의 기사 UX 점수에서 Dynatrace는 각 세션을 분류하는 모델을 설명합니다. 성공적, 좌절적, 또는 수용 가능한 성능 분석과 오류 감지 기능을 하나의 지표로 combination하는
For Electron teams, this often means watching startup behavior, memory pressure, and renderer responsiveness. For Capacitor teams, it means paying attention to launch sequence, bridge calls, and whether network-dependent screens degrade gracefully.
사용자는 아키텍처 다이어그램을 경험하지 않습니다. 그들은 한 세션씩 경험합니다.
사용자는 아키텍처 다이어그램을 경험하지 않습니다. 그들은 하나의 세션을 경험합니다.
가치가 사용자가 돌아올 이유입니다.
앱은 사용 가능하고 빠르며 안정적이지만 여전히 사용자가 원하는 것을 받을 때까지 지연되는 경우에 성능이 좋지 않을 수 있습니다. 가치는 결과 layer입니다. 사용자가 작업을 완료했는지, 문제를 해결했는지, 또는 앱을 열기 위해 정당화된 이익을 달성했는지 여부를 묻는 것입니다.
많은 기능이 많은 제품은 흔히 실패합니다: 팀은 표면, 설정, 그리고 개인화 기능을 추가하기 전에 코어 journey를 강화하지 않습니다. 앱은 더 넓어지지만 더 나아지지 않습니다.
| Pillar | 기둥 | 주요 질문 |
|---|---|---|
| Usability | 사용자가 다음 단계를 알 수 있나요? | 웹 스타일의 흐름을 모바일 또는 데스크톱에 그대로 복사합니다. |
| 성능 | 앱이 빠르게 반응하여 살아있는 느낌을 주나요? | 중량 있는 패키지, 시작 시간을 차단하는 작업, 느린 전환 |
| 신뢰성 | 사용자가 앱을 신뢰하여 계속 작동할 수 있나요? | 추락, 동기화 중단, 고정된 UI, 불일치한 로컬 상태 |
| 가치 | 사용자가 설치한 이유에 도달할 수 있나요? | 온보딩이 길어지거나 지연되거나, 기능 경로가 소음이 나요. |
네 가지 기둥은 팀의 대화에 지지를 줍니다. "UX가 개선이 필요합니다."라고 말하는 대신, 온보딩 경로가 이해가 되지만 너무 느리거나, 기능이 가치가 있지만 약한 네트워크에서 불안정하다는 것을 말할 수 있습니다. 그 정도에서 팀은 앱 사용자 경험을 개선할 수 있습니다.
앱 사용자 경험을 측정하는 방법: 실행 가능한 지표
UX 문제를 피하기 가장 빠른 방법은 설치 횟수와 광범위한 참여 총계를 측정하지 않고 마찰을 측정하지 않는 것입니다. 다운로드는 사람들이 막혔는지, 지치지 않았는지, 또는 가치에 도달하기 전에 떠났는지 여부를 알려주지 않습니다.
크로스 플랫폼 앱의 경우, 기술 행동과 사용자 결과를 연결하는 유용한 지표가 가장 중요합니다. 사용자가 느끼는 불편한 경험은 충돌, 멈춰있는 인터페이스, 복잡한 온보딩, 또는 업데이트 간격이 사용자가 이전 버전의 빌드를 사용하게 만드는지 여부를 알고 싶습니다.
마찰을 측정하기 전에 규모를 측정하십시오.
실제 사용 중에 고통을 드러내는 신호를 시작하세요. 중요한 모바일 앱 분석 지표에 대한 UXCam은 일일 에 대한 UI 멈춤, 비응답 상태로 정의됩니다. non-응답 상태로 정의합니다. 2 초 이상, 그리고 rage 탭 정의는 1 초에 4 개 이상의 탭 같은 요소에. 같은 지침은 사용자가 첫 번째 세션의 60 초 이내에 활성화 이벤트에 도달하는 사용자들이 첫 번째 세션에서 첫 번째 세션에서
첫 번째 세션에서
- 첫 번째 세션에서 첫 번째 세션에서
- 첫 번째 세션에서 사용자가 앱이 더 이상 듣지 않는다고 생각하는 순간을 드러내세요.
- Rage 탭 반응이 명확하지 않지만 사용자에게 보이는 제어를 드러내세요.
- 첫 번째 실제 보상을 달성하는 데 걸리는 시간 첫 번째 실제 보상을 달성하는 데 걸리는 시간을 알려줍니다.
인스트루먼테이션을 구현하는 팀의 실용적인 시작점은 __CAPGO_KEEP_0__ 앱에서 성능 모니터링을 설정하고 첫 번째 세션 이벤트를 제품 및 엔지니어에게 모두 표시하는 것입니다. performance monitoring in Capacitor apps 모든 팀이 거대한 분석 분류 체계가 필요하지는 않습니다. 대부분의 팀은 신뢰할 수 있고 매 릴리즈마다 검토할 수 있는 작은 세트가 필요합니다.
측정 범주
중요한 측정치
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | 측정하는 것 | UX에 대한 중요성 |
|---|---|---|---|
| 기술적 건강 | 사용자 충돌률 | 사용자가 충돌 없이 세션을 완료하는 수 | 안정성은 기본적인 기대 |
| 기술적 건강 | 충돌 없는 세션 | 세션이 충돌 없이 끝나는 수 | 실패가 집중되거나 광범위한지 여부를 보여줍니다 |
| 기술적 건강 | UI 동결 | 인터페이스가 반응하지 않는 순간들 | 백엔드 타이밍만 아니라 느린 느낌을 포착한다 |
| 기술적 건강 | rage 탭 | 짧은 시간 동안 동일한 요소에 반복적으로 탭하는 것 | 혼란이나 피드백이 부족한 것을 시그널한다 |
| 활성화 | 첫 번째 유용한 이벤트에 도달하는 데 걸리는 시간 | 온보딩 지연이 가치가 있는지 보여준다 | 참여 |
| 세션 길이 | protectedTokens | 사용자 활동 시간 | 작업 맥락과 함께 사용하면 유용합니다. |
| 참여 | 활성 사용자 및 반복 방문 | 사람들이 반복적으로 돌아올지 여부 | 습관, 유용성 또는 둘 다를 나타냅니다. |
| 파이프 라인 | 단계 전환 | 키 흐름 단계별 완성 | 각 주요 흐름 단계에서 완료 |
| 정확한 탈락 지점을 찾습니다. | 여행 분석입니다. 스크린 흐름 및 경로를 찾습니다. | 사용자가 실제로 취하는 경로를 노출합니다. | 루프, 죽은 길, 그리고 분기점을 드러냅니다. |
몇 가지 주의 사항이 필요합니다.
첫 번째로, 더 긴 세션을 자동으로 좋은 것으로 간주하지 마세요. 지원 앱에서 긴 세션은 혼란을 의미할 수 있고, 콘텐츠 앱에서 만족을 의미할 수 있습니다. 상황은 중요합니다.
두 번째로, 단일 평균을 사용하여 사용자의 고통을 숨기지 마세요. 중간 로드 타임은 수용 가능한 것처럼 보일 수 있지만, 특정 온보딩 스크린은 이전 Android 기기에서 멈추거나 데스크톱 동기화 스크린은 잠자기 후 멈출 수 있습니다.
사용자가 자신감을 잃는 순간을 추적하십시오, 단지 대시보드가 건강한 것처럼 보이는 순간만 추적하지 마십시오.
목표는 모든 것을 수집하는 것이 아닙니다. 다음에 고치는 것을 결정하는 데 도움이 되는 측정层를 구축하는 것입니다.
모바일 앱 UX를 개선하는 실용적인 전략
팀들은 UX를 개선하기 위해 먼저 폴리시를 추가하려고 합니다. 새로운 애니메이션, 더 많은 빈 상태의 삽화, richer 설정, 추가적인 개인화. 이러한 변경 사항은 도움이 될 수 있지만, 약한 경험을 구원하는 데는 거의 도움이되지 않습니다.
크로스 플랫폼 제품의 경우 기본적인 것이 더 자주 승리합니다. 사용자가 느끼는 속도. 사용자가 무슨 일이 일어나고 있는지 설명하는 feedback. 네트워크가 좋지 않아도 살아남는 흐름. 기기에서 실행 중인 기기의 전통을 존중하는 인터페이스.
느껴지는 속도를 먼저 고치십시오.
실제 성능은 엔지니어링이 앱을 다시 작성하지 않고도 큰 UX 이익을 창출할 수 있는 곳입니다. 사용자는 모든 바이트가 즉시 로드되지 않아도 됩니다. 그들은 앱이 준비가 되었고, 반응적이고, 목표를 향해 움직이고 있는지 빠른 증거가 필요합니다.
그것은 일반적으로 다음과 같습니다:
- 즉시 피드백을 제공하세요: 버튼은 탭과 함께 상태를 변경해야합니다. 작업이 시작되면 이를 알려주세요.
- 스켈레톤을 신중하게 사용하세요: 그것은 최종 레이아웃이 예측 가능할 때만 작동합니다. 그것은 피할 수 있는 백엔드 지연을 숨기지 않으면 도움이되지 않습니다.
- 비중요한 작업을 지연하세요: 분석 초기화, 두 번째 요청 및 낮은 우선 순위 자산은 첫 번째 유용한 화면에 장애를 일으키지 않아야합니다.
- 자산 크기를 줄이세요: 크로스 플랫폼 팀은 종종 oversized 이미지를, 글꼴을, 프론트 엔드 의존성을 더 오래 동안 유지합니다.
의견을 주석하는 변경 사항을 설명하거나 앱 스토어 리뷰어에게 설명할 때 고품질의 제품 데모를 만들 때 UX 개선 사항을 스크린샷으로 표현하기 어려운 방식으로 시각화하는 데 도움이 됩니다.
A 더 깊은 시각적인_walkthrough는 팀이 "빠르면 충분하다"는 것이 실제로 어떤 방식으로 작동해야 하는지에 대해 일치하는 데 도움이 될 수 있습니다:
weak network와 uneven device를 위한 디자인
UX에 대한 많은 조언은 안정적인 연결성과 최신 하드웨어를 가정합니다. 그러나 실제 사용자는 그 세계에 살지 않습니다. Prototypr의 piece는 "잊혀진 모바일 사용성 문제"에 대해 말합니다. 모바일 사용성 문제 calls out a neglected question: how the app behaves with no network, poor network, or expensive data. That’s especially important for Capacitor teams shipping to broad mobile audiences.
Cache the last useful state:
- 새로운 데이터가 없으면, 마지막으로 알려진 좋은 데이터를 표시하고 명확한 상태를 표시합니다. Queue user intent:
- someone이 offline에서 drafts, submits, or changes a preference를 하면, 동작을 보존하고 나중에 적절한 곳에서 sync합니다. Sync 상태를 명확하게 설명합니다:
- ]} “로컬 저장”과 “sync를 기다리는 중”은 텍스트가 없는 스피너보다 사용자 불안을 줄이는 데 더 효과적입니다.
- 네트워크 트래픽을 줄이세요: 가능한 경우 요청을 Batch로 처리하고 작은 액션 후 전체 화면 리로드 패턴을 피하세요.
iOS, Android 및 공유 웹层에서 더 잘 번역되는 UI 세부 사항을 검토하는 것은 __CAPGO_KEEP_0__ 앱의 가치가 있습니다. __CAPGO_KEEP_1__의 신뢰성을 유지하는 것은 Capacitor 앱의 중요한 부분입니다..
상황에 맞게 상호 작용 패턴을 단조롭게 유지하세요.
이것은 반대편입니다. 훌륭한 앱 사용자 경험은 항상 새로운 것에서 오는 것이 아닙니다. 종종 제약에서 오는 것입니다.
네비게이션은 플랫폼에 맞춰야 합니다. 강력한 이유가 없다면 그렇지 않아야 합니다. 뒤로 가기 동작은 예측 가능해야 합니다. 데스크톱 창은 깨끗하게 복원되어야 합니다. 확인 패턴은 위험한 액션에만 마찰을 유발해야 합니다. 일상적인 액션에는 그렇지 않아야 합니다.
__CAPGO_KEEP_0__와 Electron은 __CAPGO_KEEP_1__을 공유하는 것을 쉽게 만듭니다. 그러나 __CAPGO_KEEP_0__ 앱의 신뢰성을 유지하는 것은 중요합니다. 사용자는 모바일과 데스크톱이 자신만의 플랫폼처럼 행동하는 것을 기대합니다. 중간 플랫폼의 조화된 것처럼 행동하지 않습니다.
Capacitor and Electron make it easy to share code. They don’t remove the need to honor context. Users still expect mobile and desktop to behave like themselves, not like one compromised median platform.
정신적인 UX 개선의 지속적인 역할은 신뢰할 수 있는 업데이트
__CAPGO_KEEP_0__ 앱의 UX를 개선하는 것은 지속적인 릴리스-discipline입니다.
크로스 플랫폼 작업에서 루프는 더 중요합니다. 많은 UX 문제는 작지만 급합니다. 로딩 상태가 깨진 경우, 버튼 피드백이 늦은 경우,陈腐한 복사본, 빈 상태가 나쁜 경우, 또는 어색한 온보딩 단계는 JavaScript, CSS, 구성, 또는 자산에서 고쳐질 수 있지만 전체 스토어 제출 주기와는 다릅니다. 그러나 현장에서 그것을 남겨두면 사용자에게 피해를 끼칩니다.
UX 고치는 사용자가 실제로 그것을 받았을 때만 중요합니다.
많은 팀이 내부 지표로 반복 속도에 대해 이야기합니다. 사용자들은 그것을 다르게 경험합니다. 그들에게는 단순한 질문이 있습니다. 앱이 빨리 개선되었는지, 아니면 같은 불편한 문제가 몇 주 동안 남아있었는지.
Glassbox의 개요에서 모바일 앱 메트릭스 가 설명하는 것처럼 현대 앱 UX는 반복 사용, 파이프라인 완료, 신뢰성과 함께 일일, 일주일, 일개월 보존 및 99.5% 이상의 충돌 없는 세션율 을 주요 성공 지표로 삼습니다. 그 프레임이 SHIPPING 볼륨에 대한 주목을 돌려서 사용자 여행에 개선이 도달하는지 여부에 주목을 돌립니다.
신뢰할 수 있는 업데이트는 그 중 하나입니다. 만약 당신의 반은 더 오래된 웹 번들을 사용하고 있다면, 그 메트릭스는 혼합됩니다. 제품은 혼합된 행동을 보입니다. 지원은 왜 일부 사용자가 해결된 문제를 여전히 만나는지 설명할 수 없습니다. 엔지니어링은 릴리스 영향에 대한 자신감을 잃습니다.
롤아웃 제어를 UX 워크플로우의 일부로 사용하십시오.
A 더 좋은 패턴은 앱 사용자 경험 자체에 배달 메커니즘을 포함하는 것입니다.
그것은 다음과 같은 것을 의미합니다.
- 좁은 범위로 배포하십시오: 내부 사용자, 베타 그룹, 또는 정의된 세그먼트에 UX 변경을 보내고 넓은 릴리스 전에 배포하십시오.
- 수용과 실패를 관찰하십시오: 업데이트된 장치, 실패한 장치, 롤백한 장치에 대한 시각성을 필요로합니다.
- 릴리스 그룹을 행동에 연결하십시오: 첫 번째 세션 활성화, 파이프라인 완료, 또는 좌절 신호를 이전과 이후에 비교하십시오.
- 빠른 롤백 경로를 보존하십시오: UX 실험은 여전히 프로덕션 변경입니다. 새로운 흐름이 사람들을 혼란스럽게 하면 그것을 швидко 되돌리십시오.
Capgo Capacitor 생태계에서 작업하는 팀에게, Capacitor의 라이브 업데이트 서비스에 대한 설명을 제공하는 서비스 라이브 업데이트 기능은 Capacitor에서 어떻게 작동하는지 이 릴리스를 운영하기 쉽게 만드는 데 도움이 될 수 있는 옵션입니다. CapgoCapacitor와 Electron 앱을 위한 서명된 웹 번들을 대상 채널로 전달하고 다음 런칭 시 업데이트를 적용하며 롤백 및 관찰 가능성 기능을 제공합니다. UX 변경이 웹层에 존재하고 완전한 스토어 사이클을 기다리지 않고 제어된 반복이 필요한 경우 유용합니다.
빠른 반복은 안전한 릴리스만큼만 도움이 됩니다. 팀이 실제로 픽스를 배포할 수 있는 정도의 릴리스 안전성이 충분해야 합니다.
강력한 관찰 가능성과 업데이트의 신뢰성이 만난다. 최고의 UX 팀은 단순히 마찰을 식별하는 것이 아니라, 그 차이를 명확하게 측정할 수 있는 동안 마찰을 제거합니다.
모든 것을 하나로 모으는 방법: 첫 번째 UX 개선 주기
많은 팀은 UX 개선이 필요하지 않습니다. 단 하나의 단단한 주기를 통해 프로세스가 작동하는지 증명하는 것이 필요합니다.
첫 번째 UX 개선 주기를 시작하는 방법
한 번의 여행으로 시작하세요, 전체 앱이 아닙니다.
하나의 여행만 선택하세요.
- 실용적인 첫 번째 단계는 다음과 같습니다. 하나의 결과 지표를 선택하세요:
- 이 흐름에서 마찰 신호를 검토하십시오: 고장, 멈춤, 반복적인 탭, 혼란스러운 루프, 그리고 포기 지점을 찾으십시오.
- 한 가지 좁은 개선책을 정의하십시오: 시작 시간을 줄이십시오, 한 화면을 명확하게 하십시오, 한 가지 막힌 단계를 제거하십시오, 또는 한 가지 동작을 위해 오프라인 처리를 개선하십시오.
- 작은 규모의 청중에게 배포하십시오: 폭파 범위가 작아서 안전하게 학습할 수 있도록 하십시오.
- 배포 후 행동을 비교하십시오: 더 깨끗한 경로 완료와 더 적은 좌절 지표를 찾으십시오.
이것은 discipline을 강요합니다. 팀은 추상적인 UX에 대해 토론하는 것을 중단하고 특정 구현이 특정 사용자 여행을 개선했는지 테스트합니다.
작은 사이클을 실행하고 빠르게 학습하십시오
주요 키는 사이클이 너무 재미없게 만들어서 반복할 수 있도록 하는 것입니다. 거대한 리디자인으로 시작하지 마십시오. 그들은 너무 많은 변수를 혼합하고 성공에 기여한 것을 알기 어렵습니다.
대신, 한 가지 경로씩 개선하고 증거에 대한 공통 습관을 구축하십시오. 제품은 중요한 지표를 알고 있어야 합니다. 엔지니어는 성공을 표시하는 이벤트를 알고 있어야 합니다. 지원은 변경된 것을 알고 있고 업데이트 불일치점을 식별할 수 있어야 합니다. 새로운 워크플로 또는 기능과 관련된 릴리스 커뮤니케이션을 조정하는 경우 구조화된 새로운 제품 소개 플레이북 팀이 메시징, 출시 예상, 내부 준비를 일치시킬 수 있도록 도와줍니다.
좋은 앱 사용자 경험은 일반적으로 이러한 방식으로 발생합니다. 단일 бли언트 리디자인에서 비롯되는 것이 아니라, 많은 측정된 수정이 의심을 제거하고 신뢰를 회복하고 사용자가 가치가 더 빠르게 얻을 수 있도록 도와줍니다.
If you’re shipping Capacitor or Electron apps and need a safer way to iterate on UX in production, Capgo 컨티뉴어스 UX 개선이 더 쉽게 관리될 수 있도록, 웹层 수정, 복사 변경, 구성 업데이트 및 자산을 빠르게 대상 롤아웃, 롤백 보호 및 릴리즈 시각화를 통해 제공합니다.
애플리케이션 사용자 경험: Capacitor & Electron 팀을 위한 안내서로 계속 진행하세요
Capgo를 사용하여 애플리케이션 사용자 경험: Capacitor & Electron 팀을 위한 안내서 Capgo를 사용하여 Capgo 플러그인 디렉토리 Capgo 플러그인 디렉토리 내의 제품 워크플로우를 위해 Capacitor 플러그인들에 의해 Capgo Capacitor 플러그인들에 의해 Capgo 플러그인 추가 또는 업데이트 플러그인 추가 또는 업데이트 아이오닉 엔터프라이즈 플러그인 대체 아이오닉 엔터프라이즈 플러그인 대체 Capgo 네이티브 빌드 Capgo 네이티브 빌드
