사용자가 첫 다섯 분 동안 느끼는 불만을 피할 수 있는 플랫폼 앱을 배포할 수 있습니다. 로그인은 작동합니다. 네비게이션은 기술적으로 작동합니다. API은 데이터를 반환합니다. 그러나 리뷰에서는 앱이 느려서 사용하기 어렵거나 불신스럽다고 말합니다.
그것은 앱 사용자 경험 의 장소입니다.
Capacitor과 Electron 팀은 이러한 문제를 자주 겪습니다. 왜냐하면 기능 배달은 팀 내에서 보이지만, 마찰은 팀 외부에서 나타나기 때문입니다. WebView는 반응이 느려서 사용자가 기다리게 됩니다. 데스크톱 창이 이상한 상태로 복원됩니다. 양식 스피너는 작업이 진행 중인지 또는 멈췄는지 설명하지 않습니다. 업데이트는 하나의 버그를 고치지만, 사용자 베이스의 절반은 오래된 배포본에 몇 일 동안 남아 있습니다. 이러한 문제는 스프린트 데모에서 드라마틱하게 보이지 않습니다. 그러나 사용자가 제품을 계속 사용하는지 여부를 결정합니다.
잘못된 UX는 더 이상 외관 문제가 아닙니다. Adjust는 사용자가 앱의 성능이 좋지 않다고 말한 90%가 사용자가 앱을 중단한 이유라고 말했습니다. 개발 팀에게는 이게 대화의 방향을 바꿉니다. UX는 앱이 작동하는 후에 추가하는 층이 아닙니다. 그것은 성능, 신뢰성, 명확성, 사용자가 가치에 도달하는 속도에 따른 운영 결과입니다.
다양한 플랫폼을 지원하는 팀에게는 위험과 기회가 함께 존재합니다. 위험은 하나의 코드베이스가 iOS, Android, 데스크톱에서 동일한 마찰을 전달할 수 있기 때문입니다. 기회는 하나의 측정된 수정이 모든 곳에서 여행을 개선할 수 있기 때문입니다. 만약에 올바른 순간을 측정하고 업데이트를 안전하게 배포한다면.
목차
- 소개
- 이것은 엔지니어링만 아니라 디자인에도 관련이 있다.
- 가치가 사람들이 돌아오게 하는 이유다.
- 다양한 플랫폼 앱 UX를 개선하는 실제 전략
- 정확한 업데이트 역할에 대한 UX 지속적인 개선
- 모든 것을 함께하는 첫 번째 UX 개선 주기
소개 '작동하는' 앱은 충분하지 않다
작동하는 앱은 작업을 완료합니다. 좋은 앱은 사용자가 작업을 완료하는 것을 방해하지 않고 혼동이나 두려움 없이 작업을 완료할 수 있도록 도와줍니다. 그것은 같은 것입니다.
많은 팀이 런칭 후에 이 사실을 발견합니다. 내부 테스터들은 제품에 대해 잘 알고 있기 때문에 흐름을 느리게 진행하며 맥락을 이해합니다. 실제 사용자는 그렇지 않습니다. 그들은 차갑게, 작은 화면에서, 회의 사이에, 약한 네트워크에서, 또는 랩톱 배터리가 거의 죽은 상태에서 도착합니다. 그들은 아키텍처가 미학적이든지 아니면 첫 번째 유용한 액션을 너무 오래 걸리든지 아니면 사용자가 탭을 누를 때 UI가 잠시 잠금 상태가 되든지 상관하지 않습니다.
기술적으로 받아들여지는 UX의 숨겨진 비용
플랫폼 스택은 이 문제를 특정한 방식으로 증폭합니다. Capacitor 앱은 종종 웹에 대한 가정으로부터 상속됩니다. 이 가정은 모바일 네이티브 환경에서 유효하지 않습니다. Electron 앱은 특히 팀이 데스크톱을 무제한 환경으로 간주하고 시작 작업, 배경 동기화, oversized front-end bundles를 쌓을 때 무거워집니다.
결과는 항상 충돌이 아닙니다. 종종 quieter:
- 의심: 사용자가 다음 단계가 명확하지 않아 멈춥니다.
- 지연: 버튼이 늦게 응답하여 사용자가 다시 한번 클릭합니다.
- 신뢰 상실: 데이터가陈舊해 보이기 때문에 사용자가 동기화가 성공했는지 의심합니다.
- 탈락: 온보딩이 기술적으로 완료되지만 사용자가 제품의 핵심 가치에 도달하지 못합니다.
실용적인 규칙: 사용자가 앱을 "부실"이라고 말할 때, 그들은 일반적으로 작은 엔지니어링 및 제품 결정의 연쇄를 보고하는 것이 아니라 단일 시각 디자인 문제를 보고한다.
기능 로드맵을 사용하는 팀에게는 frustrate 할 수 있지만, UX feedback를 시스템으로 다루면 여전히 관리할 수 있다. 첫 번째 세션의 행동, 오류 상태, 로딩 동작, 업데이트 수용, 작업 완료를 보는 대신, 인터페이스가 "최신"인지 묻지 말고.
UX는 왜 엔지니어링에 속하는가
크로스 플랫폼 제품에서 가장 높은 영향력의 UX 문제는 구현 세부 사항에서 오는 경우가 많다. 캐시 무효화가 콘텐츠가 신뢰할 수 있는지 여부를 결정한다. 번들 사이즈가 상호 작용 시간에 영향을 미친다. 상태 지속성이 사용자가 앱을 다시 열 때 방향감을 느끼는지 여부를 결정한다. 업데이트 전달이 현장에서 마찰이 사라지는 속도에 영향을 미친다.
따라서 성숙한 팀은 UX를 제품, 디자인, QA, 엔지니어링의 공유 작업으로 다루게 된다. 디자이너는 흐름을 형성한다. 제품은 결과를 우선한다. 엔지니어는 실제 조건에서 경험을 빠르게, 안정적으로, 회복 가능하게 유지하는지 결정한다.
만약 앱이 모든 것이 잘못되지 않으면서만 작동한다면, 사용자는 그것이 깨진 것이라고 말할 것이다.
현대 앱 사용자 경험의 네 개柱
UX가 모호해지지 않도록 하려면 가장 단순한 방법은 UX를 네 개의柱로 나누는 것이다. 사용성, 성능, 신뢰성, 가치하나가 약하면, 사용자는 다른 것들이 강해도 그것을 느끼게 된다.
사용성은 경로가 명확한 것을 의미한다.
사용성은 사용자가 다음 단계를 알 수 있고, 오류를 일으켰을 때 복구할 수 있는지 여부를 나타낸다. 이에는 네비게이션 레이블, 컨트롤 배치, 폼 동작, 빈 상태, 앱이 플랫폼 기대치를 존중하는지 여부가 포함된다.
Capacitor 앱에서, 팀이 웹 상호 작용을 모바일로 복사했을 때 사용성의 문제가 자주 나타난다. 마우스 오버 가정은 존재하지 않는다. 밀집된 설정 페이지가 지치게 된다. 탭 대상이 좁아 보인다. 데스크톱에서 모달 스택이 괜찮아 보인다면, 모바일에서 혼란스럽게 보인다.
좋은 사용성은 화려하지 않다. 그것은 마찰의 부재이다.
성능과 신뢰성은 신뢰를 형성한다.
성능은 앱이 반응적인지 여부를 나타낸다. 신뢰성은 앱이 예측 가능한지 여부를 나타낸다. 사용자는 그 두 개념을 명확하게 구분하지 않는다. 그들은 앱에 신뢰를 가지고 있는지 여부를 알고 있다.
화면이 즉시 나타나지만 동기화 중에 실패하는 화면도 여전히 나쁜 경험이다. 반응성이 느린지만 안정적인 앱도 사람들을 잃는다. 이 때문에 세션 수준 분석이 중요하다. Dynatrace의 기사인 "UX score"에서, Dynatrace는 성능 분석과 오류 감지를 하나의 지표로结合한 모델을 설명한다. 그 모델은 각 세션을 "만족스럽다", "불편하다", "tolerable하다"로 분류한다. 개발자에게 유용한 마음가짐이다. 평균 페이지 로딩 속도만으로는 어떤 여행이 깨진 것인지 알 수 없다. 사용성은 사용자가 다음 단계를 알 수 있고, 오류를 일으켰을 때 복구할 수 있는지 여부를 나타낸다.사용성은 네비게이션 레이블, 컨트롤 배치, 폼 동작, 빈 상태, 앱이 플랫폼 기대치를 존중하는지 여부를 포함한다. __CAPGO_KEEP_0__ 앱에서, 팀이 웹 상호 작용을 모바일로 복사했을 때 사용성의 문제가 자주 나타난다. 좋은 사용성은 화려하지 않다.
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.
A user doesn’t experience your architecture diagram. They experience one session at a time.
가치가 있는 이유로 사람들이 돌아오는 이유
앱이 사용할 수 있고 빠르며 안정적이지만 여전히 사용자가 원하는 것을 얻을 때까지 지연되는 경우에 성능이 좋지 않다. 가치는 결과层이다. 사용자가 작업을 완료했는지, 문제를 해결했는지, 앱을 열기 위해 얻은 이익을 달성했는지 여부를 묻는 것이다.
많은 기능이 많은 제품은 흔히 다음과 같은 문제를 겪는다: 팀은 코어 여행을 강화하기 전에 사용자 인터페이스, 설정, 개인화 옵션을 추가한다. 앱은 더 넓어지지만 더 좋지 않다.
사용성, 성능, 안정성, 가치 4대 기둥을 평가하는 유용한 방법은 다음과 같은 질문을 묻는 것이다.
| 기둥 | 핵심 질문 | 일반적인 크로스 플랫폼 실패 모드 |
|---|---|---|
| 사용성 | 사용자가 다음 단계를 알 수 있나요? | 웹 스타일의 흐름을 모바일이나 데스크톱에 그대로 복사하는 것 |
| 성능 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__, __CAPGO_KEEP_0__ 작업, 느린 전환 |
| 신뢰성 | __CAPGO_KEEP_0__, 동기화 중단, UI 동결, 지역 상태 불일치 | 가치 |
| __CAPGO_KEEP_0__ 온보딩, 활성화 지연, 노이즈 있는 기능 경로 | 팀 대화는 네 가지 기둥에 의해 지중화됩니다. "UX가 개선이 필요합니다."라고 말하기보다 온보딩 경로가 이해가 가지만 너무 느리거나 기능이 가치가 있지만 약한 네트워크에서 불안정하다는 것을 말할 수 있습니다. 팀은 앱 사용자 경험을 개선할 수 있는 수준입니다. | 액션 가능한 지표를 사용하여 앱 사용자 경험을 측정하는 방법 |
UX 문제를 피하기 가장 빠른 방법은 설치 횟수와 광범위한 참여 총계를 측정하지 않고 마찰을 측정하지 않는 것입니다. 다운로드는 사람들이 막혔는지, 지루해졌는지, 가치에 도달하기 전에 떠났는지 알려주지 않습니다.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
다양한 플랫폼을 지원하는 앱의 경우, 기술적 행동과 사용자 결과를 연결하는 유용한 지표가 가장 중요합니다. 앱 사용자 경험의 저하가 충돌, 멈춰있는 인터페이스, 복잡한 온보딩, 또는 업데이트 간격으로 인해 사용자가 이전 버전의 빌드로 남아 있는지 여부를 알고 싶습니다.
규모를 측정하기 전에 마찰을 측정하십시오
실제 사용 중에서 고통을 드러내는 신호를 시작하세요. UXCam은 '중요한 모바일 앱 분석 지표'에 대한 가이드에서 crash-free 사용자 비율99% 이상의 일일 목표 UI 멈춤 2초 이상 응답하지 않는 경우 ]을 추천합니다., crash-free 사용자 비율 99% 이상의 일일 목표 UI 멈춤2초 이상 응답하지 않는 경우 rage taps __CAPGO_KEEP_0__ 1초에 4개 이상의 탭 같은 요소에. 첫 번째 세션의 60초 이내에 활성화 이벤트에 도달하는 사용자들은 훨씬 더 높은 비율로 유지됩니다. 사용자가 느끼는 것과 직접 연결된다는 점에서 그들은 일반적으로 유용한 지표입니다.
안정성이 광범위하거나 고립된지 여부를 알려주는 것입니다.
- 사용자가 앱이 더 이상 듣지 않는다고 생각하는 순간을 드러냅니다. 사용자가 앱에 화가 나서 강하게 탭하는 횟수
- UI 멈춤 사용자가 앱에 화가 나서 강하게 탭하는 횟수
- 사용자가 앱에 화가 나서 강하게 탭하는 횟수 노출되는 컨트롤이 보이지만 명확하게 반응하지 않는다.
- 첫 번째 실제 결과에 도달하는 데 걸리는 시간 사용자가 첫 번째 실제 결과에 도달하는 속도
인스트루먼테이션을 구현하는 팀에게는 __CAPGO_KEEP_0__ 앱에서 성능 모니터링을 설정하고 첫 번째 세션 이벤트를 제품 및 엔지니어링 모두에게 표시하는 것이 실용적인 시작점이다. performance monitoring in Capacitor apps 대부분의 팀은 신뢰하고 매 릴리스마다 검토하는 작은 세트가 필요하다.
메트릭 카테고리
주요 메트릭
| 측정하는 내용 | UX에 대한 중요성 | 팀이 거대한 분석 분류 체계가 필요하지 않다. 대부분의 팀은 신뢰하고 매 릴리스마다 검토하는 작은 세트가 필요하다. | 팀이 거대한 분석 분류 체계가 필요하지 않다. 대부분의 팀은 신뢰하고 매 릴리스마다 검토하는 작은 세트가 필요하다. |
|---|---|---|---|
| 기술적 건강 | 사고 없는 사용자 비율 | 사용자가 사고 없이 세션을 완료하는 비율 | 안정성은 기본적인 기대 |
| 기술적 건강 | 사고 없는 세션 | 사고 없이 끝난 세션의 비율 | 실패가 집중되거나 광범위한지 보여줌 |
| 기술적 건강 | UI 동결 | 인터페이스가 반응하지 않는 순간 | 사용자가 느끼는 느려짐, 백엔드 타이밍만 아니라 |
| 기술적 건강 | 화난 탭 | 짧은 시간에 동일한 요소에 반복적으로 클릭하는 것 | 혼란이나 피드백 누락을 나타냄 |
| 활성화 | 첫 번째 유용한 이벤트에 도달하는 데 걸리는 시간 | 사용자가 온보딩 지연이 가치 있는지 여부를 보여줌 | 참여 |
| 세션 길이 | 사용자가 활성화 상태를 유지하는 시간 | 작업 맥락과 pair할 때 유용함. | 사용자가 첫 번째 유용한 이벤트에 도달하는 속도 |
| 참여도 | 활성 사용자 및 반환 행동 | 사람들이 반복적으로 돌아오는가 | 습관, 유용성 또는 둘 다를 나타낸다 |
| 파이프라인 | 단계 전환 | 각 키 플로우 단계에서 완료 | 정확한 드롭 오프 지점을 찾는다 |
| 여행 분석 | 스크린 플로우 및 경로 | 사용자가 실제로 따라가는 경로 | 루프, 죽은 길, 그리고 분기점을 드러낸다 |
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__
__CAPGO_KEEP_4__
__CAPGO_KEEP_5__
__CAPGO_KEEP_6__
__CAPGO_KEEP_7__
__CAPGO_KEEP_9__
__CAPGO_KEEP_10__
__CAPGO_KEEP_0__는 일반적으로 의미하는 바입니다.
- 즉시 피드백을 제공하십시오: 버튼은 탭하는 즉시 상태를 변경해야 합니다. 작업이 시작되면 이를 알려주십시오.
- 스켈레톤을 신중하게 사용하십시오. 스켈레톤은 레이아웃이 예측 가능한 경우에만 효과가 있습니다. 스크린을 숨기는 백엔드 지연을 피할 수 있는 경우에는 도움이 되지 않습니다.
- 비중이 낮은 작업을 미루십시오. 분석 초기화, 두 번째 요청, 및 낮은 우선 순위 자산은 첫 번째 유용한 화면을 막지 않아야 합니다.
- 자산 크기를 줄이십시오. 플랫폼을跨하는 팀은 종종 이미지, 글꼴, 및 프론트 엔드 의존성을 더 오래 동안 유지합니다.
앱 스토어 리뷰어 또는 스테이크 홀더에게 변경 사항을 설명할 때 품질 높은 제품 데모를 만들면 UX 개선 사항을 스크린샷으로는 표현할 수 없는 방식으로 시각화할 수 있습니다. __CAPGO_KEEP_1__
__CAPGO_KEEP_0__의 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있는 세계에 살지 않는다.
__CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다.
실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있는 세계에 살지 않는다. __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다. 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.
__CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다.
- __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다. __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다.
- __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다. __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다.
- 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있는 세계에 살지 않는다. __CAPGO_KEEP_0__ 팀은 광범위한 모바일 사용자에게 배포하는 경우 특히 중요하다.
- 네트워크 소통을 줄이기: 가능한 경우 요청을_batch_하고, 작은 액션 후 전체 화면 다시 로드 패턴을 피하십시오.
iOS, Android, 및 공유 웹层에서 더 잘 번역되는 UI 세부 사항을 검토하는 것은 가치가 있습니다. Capacitor 앱을위한 플랫폼 간 UI 및 UX 관행을 검토하십시오..
악조건 하에서 신뢰성을 더 중요한 것보다 기능 탭을 추가하는 것보다 종종 더 중요합니다.
필요한 곳에서 상호 작용 패턴을 단조로 하십시오.
이것은 반대되는 부분입니다. 훌륭한 앱 사용자 경험은 항상 새로운 것에서 오는 것이 아닙니다. 종종 단조로움에서 오는 것입니다.
네비게이션은 플랫폼에 맞춰야 합니다. 강력한 이유가 없다면. 뒤로 가기 동작은 예측 가능해야 합니다. 데스크톱 창은 깨끗하게 복원해야 합니다. 확인 패턴은 위험한 액션에만 마찰을 남기고, 일상적인 액션에는 남기지 않아야 합니다.
Capacitor 및 Electron은 code을 쉽게 공유하도록 해줍니다. 그러나 컨텍스트를 존중하는 필요는 없습니다. 사용자는 여전히 모바일 및 데스크톱이 자신만의 것처럼 행동하는 것을 기대합니다. 하나의 중간 플랫폼을 희생하지 않고.
정직한 업데이트의 역할은 지속적인 UX 개선
UX를 개선하는 것은 디자인 프로젝트가 끝나는 줄 알기 때문에 아니다. 반복적인 릴리스-discipline입니다. 마찰을 측정하고, 수정을 배포하고, 변경된 것을 관찰하고, 반복합니다.
그 반복은 크로스 플랫폼 작업에서 더 중요합니다. 많은 UX 문제는 작지만 긴급합니다. 로딩 상태가 깨진 경우, 버튼 피드백이 늦은 경우,陈舊한 복사본, 빈 상태가 나쁜 경우, 또는 어색한 온보딩 단계는 JavaScript, CSS, config, 또는 자산에서 수정이 가능하다면 전체 스토어 제출 주기와도 같은 이유로 정당화되지 않습니다. 그러나 field에서 남겨두면 여전히 사용자에게 피해를 줍니다.
UX 수정은 사용자가 실제로 이를 받았을 때만 중요합니다.
많은 팀이 내부 지표로 반복 속도에 대해 이야기합니다. 사용자들은 그 질문을 다르게 합니다. 앱이 빨리 개선되었는지, 아니면 같은 불편한 문제가 몇 주 동안 남아있었는지.
Glassbox의 개요에서 모바일 앱 지표 최신 앱 UX는 반복 사용, 채널 완료, 신뢰성과 함께 일일, 일주일, 일개월 보존 및 99.5% 이상의 충돌 없는 세션율 성공의 주요 지표입니다. 그 프레임은 배송량에 대한 주목을 돌려서 사용자 경험에 개선이 시간 내에 도달하는지 여부에 초점을 맞추게 합니다.
신뢰할 수 있는 업데이트는 그 부분입니다. 만약 당신의 반은 더 오래된 웹 번들을 유지한다면, 당신의 지표는 혼란스럽게 됩니다. 제품은 혼합된 행동을 보입니다. 지원은 왜 여전히 해결된 문제를 만나는 사용자가 있는지 설명할 수 없습니다. 엔지니어링은 릴리스 영향에 대한 자신감을 잃습니다.
롤아웃 제어를 UX 워크플로우의 일부로 사용하세요.
보다 나은 패턴은 앱 사용자 경험 자체에 배포 메커니즘을 포함하는 것입니다.
그것은 다음과 같은 것을 의미합니다.
- 좁은 범위로 배포하십시오: 내부 사용자, 베타 그룹 또는 정의된 세그먼트에 UX 변경을 보내기 전에 넓은 릴리스를 기다리지 마십시오.
- 수용과 실패를 관찰하십시오: 업데이트된 장치, 실패한 장치 및 롤백한 장치에 대한 시각성을 필요로 합니다.
- 릴리스 그룹을 행동에 연결하십시오: 첫 번째 세션 활성화, 파이프라인 완료 또는 좌절 신호를 변경 전과 후에 비교하십시오.
- 빠른 롤백 경로를 보존하십시오: UX 실험은 여전히 프로덕션 변경입니다. 새로운 흐름이 사람들을 혼란스럽게 하면 그것을 швидко 되돌리십시오.
Capgo 생태계에서 작업하는 팀에게, Capacitor의 live 업데이트가 어떻게 작동하는지 설명하는 서비스 Capacitor live 업데이트에 대한 설명 이 릴리스 루프를 더 쉽게 운영화 하기 위해. 하나의 옵션은 Capgo, 이 웹 번들을 Capacitor 및 Electron 앱에 대한 대상 채널로 전달하고, 다음 런칭 시 업데이트를 적용하고, 롤백 및 관찰 가능성 기능을 제공합니다. UX 변경이 웹层에 존재할 때 이 기능은 제어된 반복을 위해 스토어 전체 사이클을 기다리지 않고 필요한 경우 유용합니다.
빠른 반복은 안전한 릴리스만 제공되면 팀이 실제로 픽스를 배포할 때만 도움이 됩니다.
강력한 관찰 가능성과 업데이트의 신뢰성은 만나는 곳입니다. 최고의 UX 팀은 단순히 마찰을 식별하는 것이 아니라, 그 차이를 명확하게 측정할 수 있는 동안 마찰을 제거합니다.
모든 것을 함께하는 방법: 첫 번째 UX 개선 주기
많은 팀은 UX 개선이 필요하지 않습니다. 그들은 단일 주기를 증명하기 위해 프로세스가 작동하는지 증명하기 위해 하나의 단단한 주기를 필요로합니다.
사용자가 가치에 도달하기 전에 가장 먼저 사용하는 여행을 시작하세요. 첫 번째 런칭, 온보딩, 로그인, 검색, 체크아웃, 양식 완료, 또는 진행 중인 작업으로 돌아가는 것은 모두 좋은 후보입니다. 사용자가 가치에 도달하는지 여부에 가장 직접적으로 영향을 미치는 것을 선택하세요.
하나의 여행에서 시작하세요, 전체 앱이 아닙니다.
실용적인 첫 번째 패스는 다음과 같습니다.
- 하나의 결과 지표를 선택하세요. 시간을 의미 있는 첫 번째 액션으로부터 첫 번째 액션까지의 시간은 많은 앱에 대한 강력한 후보입니다.
- __CAPGO_KEEP_0__ 흐름을 둘러싼 마찰 신호를 검토하십시오.
- 추락, 멈춤, 반복적인 탭, 혼란스러운 루프, 그리고 포기하는 지점을 찾으십시오. 한 가지 좁은 개선책을 정의하십시오.
- 시작 시간을 줄이거나, 한 화면을 명확하게 하거나, 한 개의 차단 단계를 제거하거나, 한 가지 동작을 위해 오프라인 처리를 개선하십시오. 한정된 대상자에게 배포하십시오.
- 폭파 범위가 작아서 안전하게 학습할 수 있는 정도로 작게 유지하십시오. 배포 후 행동을 비교하십시오.
더 깨끗한 경로 완료와 더 적은 좌절 지표를 찾으십시오.
이것은 discipline을 강요합니다. 팀은 추상적인 UX에 대해 토론하는 대신, 특정 IMPLEMENTATION이 특정 사용자 여행을 개선했는지 테스트합니다.
작은 사이클을 실행하고 빠르게 학습하십시오.
주요 키는 사이클이 너무 재미없게 만들어서 반복할 수 있는 정도로 만들 것입니다. 거대한 리디자인으로 시작하지 마십시오. 그들은 너무 많은 변수를 혼합하고, 무엇이 도움이 되었는지 알기 어렵습니다. 대신, 한 가지 경로씩 개선하고, 증거에 대한 공통 습관을 만들고, 제품은 중요한 지표를 알고, 엔지니어는 성공을 표시하는 이벤트를 알고, 지원은 변경된 내용과 업데이트 불일치의 특징을 알 수 있도록 하십시오. 새로운 워크플로우 또는 기능을 위한 릴리즈 커뮤니케이션을 조정할 때, 구조화된 새로운 제품 소개 매뉴얼 팀이 메시지, 출시 예상, 내부 준비를 일치시킬 수 있는 도움이 될 수 있습니다.
좋은 앱 사용자 경험은 일반적으로 이러한 방식으로 발생합니다. 단일 бли언트 리디자인에서 비롯되는 것이 아니라, 많은 측정된 수정이 주저함을 제거하고 신뢰를 회복하고 사용자가 가치가 더 빠르게 얻을 수 있도록 도와주는 것입니다.
If you’re shipping Capacitor or Electron apps and need a safer way to iterate on UX in production, Capgo Capacitor
Keep going from App User Experience: A Guide for Capacitor & Electron Teams
앱 사용자 경험: Capacitor 및 Electron 팀을 위한 안내서 App User Experience: A Guide for Capacitor & Electron Teams Capacitor Capgo Plugin Directory for the product workflow in Capgo Plugin Directory, Capacitor 플러그인들에 의해 Capgo Capacitor 플러그인들에 의해 Capgo의 구현 세부 사항에 대해 플러그인 추가 또는 업데이트 플러그인 추가 또는 업데이트의 구현 세부 사항에 대해 아이온틱 엔터프라이즈 플러그인 대안 아이온틱 엔터프라이즈 플러그인 대안의 제품 워크플로에 대해, 그리고 Capgo 네이티브 빌드 Capgo 네이티브 빌드의 제품 워크플로에 대해.
