Capacitor & Electron 팀을 위한 앱 사용자 경험 가이드: 앱 사용자 경험을 위한 핵심 구성 요소, 주요 지표 및 Capacitor & Electron을 위한 신뢰할 수 있는 업데이트 방법을 학습하세요.

사용자가 첫 다섯 분 동안 사용하는 앱을 배포할 수 있습니다. 로그인은 작동합니다. 네비게이션은 기술적으로 작동합니다. API은 데이터를 반환합니다. 그러나 리뷰에서는 앱이 느려서 느려 보이거나 불편하거나 불신스럽다고 말합니다.

그것은 앱 사용자 경험 의 장소입니다.

Capacitor와 Electron 팀은 항상 이 문제를 겪습니다. 왜냐하면 기능 배달은 팀 내에서 보이기 때문입니다. 반면摩擦는 팀 외부에서 나타납니다. WebView가 반응하기까지 1초가 걸리거나 데스크톱 창이 이상한 상태로 복원되거나 스피너가 사용자가 작업이 진행 중인지 또는 멈췄는지 설명하지 않습니다. 업데이트 하나가 버그를 고치지만 사용자 베이스의 절반만 업데이트를 받는 데 며칠이 걸립니다. 그 중 하나의 문제는 스프린트 데모에서 드라마틱하게 보이지 않습니다. 그러나 그들은 사용자가 제품을 계속 사용하는지 여부를 정의합니다.

잘못된 UX는 더 이상 외관 문제가 아닙니다. Adjust는 사용자가 앱의 성능이 좋지 않다고 말한 90%가 사용자가 앱을 중단한 이유라고 말했습니다. 사용자 경험에 대한 모바일 앱 가이드에서 말합니다. 엔지니어링 팀에게는 이게 대화의 변화를 의미합니다. UX는 앱이 작동하는 후에 추가하는 층이 아닙니다. 그것은 성능, 신뢰성, 명확성, 사용자가 가치에 도달하는 속도에 의한 기능적 결과입니다.

다양한 플랫폼을 지원하는 팀에게는 위험과 기회가 함께 존재합니다. 위험은 iOS, Android, 데스크톱에서 동일한 마찰을 전달하는 하나의 코드베이스가 될 수 있기 때문입니다. 기회는 하나의 측정된 수정이 모든 곳에서 여행을 개선할 수 있기 때문입니다. 만약에 올바른 순간을 측정하고 업데이트를 안전하게 배포한다면.

목차

• 소개
  • ‘작동하는’ 앱은 충분하지 않다. 왜냐하면?
  • 기술적으로 받아들여질 수 있는 UX의 숨겨진 비용
• 이것은 엔지니어링뿐만 아니라 디자인에도 관련이 있습니다.
  • 모던 앱 사용자 경험의 네 개柱
  • 사용성은 경로가 명확해야 합니다.
  • 성능과 신뢰성이 신뢰를 형성합니다.
• 가치가 사람들이 돌아오게 하는 이유입니다.
  • 액션 가능한 지표를 사용하여 앱 사용자 경험을 측정하는 방법
  • 마찰을 측정하기 전에 규모를 측정하지 마십시오.
• 실용적인 전략을 사용하여 다중 플랫폼 앱 UX를 개선하십시오.
  • 속도 느려 보이게 하는 문제를 먼저 해결하십시오.
  • 약한 네트워크와 불균형한 장치에 대비하여 디자인하십시오.
  • 정확한 위치에서 상호 작용 패턴을 재미없게 유지하십시오.
• 신뢰할 수 있는 업데이트의 역할을 통한 지속적인 UX 개선
  • UX 수정이 실제로 사용자가 받을 때만 의미가 있습니다.
  • 롤아웃 제어를 UX 워크플로우의 일부로 사용하십시오.
• 모든 것을 함께 연결하는 방법 - 첫 번째 UX 개선 주기
  • 하나의 여행에서 시작하십시오. 앱 전체가 아닙니다.
  • 작은 주기를 실행하고 빠르게 학습하십시오.

소개 - '작동하는' 앱은 충분하지 않습니다.

작동하는 앱은 작업을 완료합니다. 좋은 앱은 사용자가 작업을 완료하는 것을 방해하지 않으며, 혼란이나 두 번 생각하는 것을 피합니다. 그것은 같은 것이 아닙니다.

많은 팀이 런칭 후에 이 사실을 발견합니다. 내부 테스터들은 제품을 잘 알고 있기 때문에 흐름을 서서히 진행하며 맥락을 이해합니다. 실제 사용자들은 그렇지 않습니다. 그들은 차갑게, 작은 화면에서, 회의 사이에, 약한 네트워크 연결에서, 또는 랩톱 배터리가 거의 죽은 상태에서 도착합니다. 그들은 아키텍처가 아름답다는 것을 신경 쓰지 않습니다. 만약 첫 번째 유용한 액션의 시간이 너무 오래 걸리거나, 사용자가 탭을 누를 때 UI가 잠시 잠금 상태가 된다면.

기술적으로 받아들여지는 UX의 숨겨진 비용

플랫폼 스택은 이 문제를 특정한 방식으로 증폭시킵니다. Capacitor 앱은 종종 웹에 대한 가정들을 상속받는데, 그것들은 모바일 네이티브 환경에서 유효하지 않습니다. Electron 앱은 특히 팀이 데스크톱을 무제한 환경으로 간주하고 시작 작업, 배경 동기화, 그리고 oversized front-end bundles를 쌓을 때 무거워집니다.

결과는 항상 충돌이 아닙니다. 종종 quieter:

• 의심: Users pause because the next step isn’t obvious.
• 사용자가 다음 단계가 명확하지 않아 멈춥니다. 지연:
• 버튼이 늦게 반응하여 사용자가 다시 한번 클릭합니다. 신뢰 상실:
• 데이터가陈舊해 보이기 때문에 사용자가 sync가 작동했는지 의심합니다. 탈락:

실용적인 규칙: 사용자가 앱을 "부실"이라고 묘사할 때, 그들은 일반적으로 작은 엔지니어링 및 제품 결정의 연쇄를 보고하는 것이 아니라 단일 시각 디자인 문제를 보고한다.

기능 로드맵을 사용하는 팀에게는 frustrate 할 수 있지만, UX feedback를 시스템으로 다루면 여전히 관리할 수 있다. 첫 번째 세션의 행동, 오류 상태, 로딩 동작, 업데이트 수용, 작업 완료를 보는 대신 인터페이스가 "최신"하게 보이는지 묻지 말아라.

Why UX는 엔지니어링에 속하는가

다중 플랫폼 제품에서 가장 높은 영향력의 UX 문제는 구현 세부 사항에서 오는 경우가 많다. 캐시 무효화는 콘텐츠가 신뢰할 수 있는지 여부를 결정한다. 번들 크기는 상호 작용 시간에 영향을 미친다. 상태 지속성은 사용자가 앱을 다시 열 때 방향감을 느끼는지 여부를 결정한다. 업데이트 전달은 현장에서 마찰이 사라지는 속도에 영향을 미친다.

따라서 성숙한 팀은 UX를 제품, 디자인, QA, 엔지니어링의 공유 작업으로 다루게 된다. 디자이너는 흐름을 형성한다. 제품은 결과를 우선한다. 엔지니어는 실제 조건에서 경험을 빠르다, 안정적이고 회복할 수 있는지 여부를 결정한다.

만약 앱이 모든 것이 잘못되지 않으면서만 작동한다면, 사용자는 여전히 그것을 고장난 것으로 부르게 된다.

현대 앱 사용자 경험의 네 개의 기둥

UX가 모호해지지 않도록 하려면 가장 단순한 방법은 UX를 네 개의 기둥으로 나누는 것이다. 사용성, 성능, 신뢰성, 가치. 만약 하나가 약하다면, 사용자는 다른 것들이 강해도 그것을 느끼게 된다.

사용성은 길이는 명확한지 여부를 의미한다.

사용성은 사용자가 다음 단계를 알 수 있고, 오류를 일으켰을 때 복구할 수 있는지 여부를 말한다. 이에는 네비게이션 레이블, 컨트롤 배치, 폼 동작, 빈 상태, 앱이 플랫폼 기대치를 존중하는지 여부가 포함된다.

Capacitor 앱에서, 나쁜 사용성은 팀이 웹 인터랙션을 모바일로 복사했을 때 나타난다. 마우스 오버 가정은 존재하지 않는다. 밀집된 설정 페이지가 지치게 된다. 탭 대상이 좁아 보인다. 데스크톱에서 모달 스택이 괜찮아 보인다면, 모바일에서는 혼란스럽다.

좋은 사용성은 화려하지 않다. 그것은 마찰의 부재이다.

성능과 신뢰성은 신뢰를 형성한다.

성능은 앱이 반응적인지 여부를 말한다. 신뢰성은 앱이 예측 가능한지 여부를 말한다. 사용자는 그 두 개념을 명확하게 구분하지 않는다. 그들은 앱에 신뢰를 가지는지 여부를 알 뿐이다.

화면이 즉시 나타나지만 Sync 중에 실패하는 화면도 여전히 나쁜 경험이다. 반응 속도가 느린 앱이도 사용자들을 잃는다. 따라서 세션 수준 분석이 중요하다. Dynatrace의 기사 "UX score"에서, 각 세션을 "만족스럽다", "불편하다", "tolerable하다"로 분류하는 모델을 설명하고 있다. UX scoreDynatrace는 성능 분석과 오류 감지를 하나의 지표로 combination하는 모델을 설명하고 있다. 그것은 개발자에게 유용한 마음션이다. 평균 페이지 속도만으로는 어떤 여행이 깨진지 알 수 없다. Dynatrace는 성능 분석과 오류 감지를 하나의 지표로 combination하는 모델을 설명하고 있다. 그것은 개발자에게 유용한 마음션이다. 평균 페이지 속도만으로는 어떤 여행이 깨진지 알 수 없다. Dynatrace는 성능 분석과 오류 감지를 하나의 지표로 combination하는 모델을 설명하고 있다. 그것은 개발자에게 유용한 마음션이다. 평균 페이지 속도만으로는 어떤 여행이 깨진지 알 수 없다.

Electron 팀의 경우, 이 경우는 시작 시 동작, 메모리 압박 및 렌더러 반응성에 대한 관찰을 의미합니다. Capacitor 팀의 경우, 이는 런치 시퀀스, 브리지 호출 및 네트워크에 의존하는 화면이 부드럽게 감소하는지에 대한 주의를 기울이는 것을 의미합니다.

사용자는 아키텍처 다이어그램을 경험하지 않습니다. 그들은 하나의 세션씩 경험합니다.

가치가 사용자가 돌아올 이유입니다.

앱은 사용 가능하고 빠르며 안정적일 수 있지만 여전히 사용자가 원하는 것을 얻을 때까지 지연되는 경우에 성능이 좋지 않을 수 있습니다. 가치는 결과层입니다. 사용자가 작업을 완료했는지, 문제를 해결했는지, 앱을 열기 위해 이익을 얻었는지 여부를 묻는 것입니다.

많은 기능이 많은 제품은 다음과 같은 문제를 겪습니다: 팀은 코어 여행을 강화하기 전에 표면, 설정 및 개인화 옵션을 추가합니다. 앱은 더 넓어지지만 더 좋지 않습니다.

사용성 평가를 위해 네 개의 기둥을 평가하는 유용한 방법은 다음과 같습니다.

__CAPGO_KEEP_1__

__CAPGO_KEEP_2__

__CAPGO_KEEP_3__

다양한 플랫폼을 지원하는 앱의 경우, 기술적 행동과 사용자 결과를 연결하는 가장 유용한 지표가 필요합니다. 사용자 경험의 저하가 충돌, 멈춰있는 인터페이스, 복잡한 온보딩, 또는 업데이트 간격으로 인해 사용자가 이전 버전의 빌드에 남아있는지 여부를 알고 싶습니다.

규모를 측정하기 전에 마찰을 측정하십시오.

실제 사용 중에서 고통을 드러내는 신호를 시작하세요. UXCam은 '중요한 모바일 앱 분석 지표'에 대한 가이드에서 crash-free user rate99% 이상의 일일 목표와 함께 추적하는 것을 권장합니다. UI 멈춤 2초 이상 응답하지 않는 경우로 정의됩니다. Capacitor, Capacitor Capacitor CapacitorCapacitor rage taps 정의는 1초에 4개 이상의 클릭 같은 요소에 클릭합니다. 같은 지침은 사용자가 첫 번째 세션의 60초 이내에 활성화 이벤트에 도달하는 사용자들은 첫 번째 세션에서

보다 훨씬 더 높은 비율로 유지됩니다.

• 이러한 지표는 사용자가 느끼는 것과 직접 연결되기 때문에 비정상적인 사용자 비율
• 불안정성이 광범위한지 고립된지 여부를 알려줍니다. UI 동결
• 사용자가 앱이 더 이상 듣지 않는다고 생각하는 순간을 드러냅니다. 사용자가 실제로 사용할 수 있는 컨트롤이 보이지만 명확하게 반응하지 않는다.
• 첫 번째 실제 결과에 도달하는 데 걸리는 시간 사용자가 첫 번째 실제 결과에 도달하는 속도에 대한 정보를 제공한다.

인스트루먼테이션을 구현하는 팀에게는 __CAPGO_KEEP_0__ 앱에서 성능 모니터링을 설정하고 첫 번째 세션 이벤트를 제품 및 엔지니어링 모두에게 표시하는 것이 실용적인 시작점이다. performance monitoring in Capacitor apps 대부분의 팀은 큰 분석 분류 체계가 필요하지 않다. 대부분은 신뢰할 수 있고 매번 릴리스마다 검토할 수 있는 작은 세트가 필요하다.

매트릭스 카테고리

주요 매트릭스

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

그것은 일반적으로 다음과 같은 것을 의미합니다:

• 즉시 피드백을 제공하십시오: 버튼은 탭하는 즉시 상태를 변경해야 합니다. 작업이 시작되면 이를 알려주십시오.
• 스켈레톤을 신중하게 사용하십시오: 그것은 최종 레이아웃이 예측 가능한 경우에만 작동합니다. 그것은 백엔드 지연을 숨기는 것을 피할 수 있는 경우에만 도움이 됩니다.
• 비상요구 작업을 미루십시오: 분석 초기화, 두 번째 요청 및 우선 순위가 낮은 자산은 첫 번째 유용한 화면을 차단하지 않아야 합니다.
• 자산 크기를 줄이십시오: 크로스 플랫폼 팀은 종종 oversized 이미지를, 글꼴 및 프론트 엔드 의존성을 더 오래 동안 유지합니다.

앱 스토어 리뷰어 또는 스테이크 홀더에게 변경 사항을 설명할 때, 품질 높은 제품 데모를 만들면 UX 개선 사항을 스크린샷으로는 표현할 수 없는 방식으로 시각화할 수 있습니다. 품질 높은 제품 데모를 만들면 UX 개선 사항을 스크린샷으로는 표현할 수 없는 방식으로 시각화할 수 있습니다.

__CAPGO_KEEP_0__의 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있지 않습니다. 실제 사용자들은 그 세계에 살지 않습니다. Prototypr의 "잊혀진 모바일 사용성 문제"에 대한 기사에서

__CAPGO_KEEP_0__가 널리 사용되는 모바일 사용자에게 배포하는 팀은 특히 이러한 네트워크 상황을 고려해야 합니다.

실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있지 않습니다. 실제 사용자들은 그 세계에 살지 않습니다. Prototypr의 "잊혀진 모바일 사용성 문제"에 대한 기사에서 __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__가 널리 사용되는 모바일 사용자에게 배포하는 팀은 특히 이러한 네트워크 상황을 고려해야 합니다.

• 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있지 않습니다. 실제 사용자들은 그 세계에 살지 않습니다. Prototypr의 "잊혀진 모바일 사용성 문제"에 대한 기사에서 __CAPGO_KEEP_0__가 널리 사용되는 모바일 사용자에게 배포하는 팀은 특히 이러한 네트워크 상황을 고려해야 합니다.
• 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있지 않습니다. 실제 사용자들은 그 세계에 살지 않습니다. Prototypr의 "잊혀진 모바일 사용성 문제"에 대한 기사에서 __CAPGO_KEEP_0__가 널리 사용되는 모바일 사용자에게 배포하는 팀은 특히 이러한 네트워크 상황을 고려해야 합니다.
• 실제 사용자들은 안정적인 연결성과 최신 하드웨어를 갖고 있지 않습니다. 실제 사용자들은 그 세계에 살지 않습니다. Prototypr의 "잊혀진 모바일 사용성 문제"에 대한 기사에서 __CAPGO_KEEP_0__가 널리 사용되는 모바일 사용자에게 배포하는 팀은 특히 이러한 네트워크 상황을 고려해야 합니다.
• 네트워크 트래픽을 줄이기 위해: 가능한 경우 요청을_batch_하고, 작은 액션 후 전체 화면 다시 로드 패턴을 피하십시오.

iOS, Android 및 공유 웹层에서 더 잘 번역되는 UI 세부 사항을 검토하는 것은 __CAPGO_KEEP_0__ 앱의 크로스 플랫폼 UI 및 UX 관행을 검토하는 것과 같습니다. cross-platform UI and UX practices for Capacitor apps.

정해진 장소에서 사용자 경험을 개선하는 데에는 반드시 새로운 요소가 필요하지 않습니다. 종종 제약이 필요합니다.

네비게이션은 플랫폼에 맞춰야 하며, 강력한 이유가 없다면 예상할 수 있는 백 버튼을 사용해야 합니다. 데스크톱 창은 깨끗하게 복원되어야 하며, 위험한 액션에만 마찰을 유발하는 확인 패턴을 사용해야 합니다.

__CAPGO_KEEP_0__와 Electron은 __CAPGO_KEEP_1__을 쉽게 공유할 수 있지만, 컨텍스트를 존중하는 필요는 여전히 존재합니다. 사용자는 모바일과 데스크톱이 자신만의 행동을 보이도록 기대합니다.

신뢰할 수 있는 업데이트의 역할은 지속적인 UX 개선에 있습니다.

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.

__CAPGO_KEEP_0__

__CAPGO_KEEP_1__

그 루프는 크로스 플랫폼 작업에서 더 중요합니다. UX 문제는 대부분 작지만 긴급합니다. 로딩 상태가 깨진 경우, 버튼 피드백이 늦은 경우,陈舊한 복사본, 빈 상태가 나쁜 경우, 또는 어색한 온보딩 단계는 JavaScript, CSS, 설정, 또는 자산에서 수정이 가능하다면 전체 스토어 제출 주기와 같은 이유로 정당화되지 않습니다. 그러나 field에서 남겨두면 여전히 사용자에게 피해를 줍니다.

UX 수정은 사용자가 실제로 그것을 받았을 때만 중요합니다.

많은 팀이 내부 지표로 반복 속도에 대해 이야기합니다. 사용자들은 그 질문을 다르게 경험합니다. 앱이 빨리 개선되었는지, 아니면 같은 불편한 문제가 몇 주 동안 남아있었는지에 대한 질문입니다.

Glassbox는 모바일 앱 메트릭스 에서 overview에서 언급했듯이 modern 앱 UX는 반복 사용, funnel 완료, 그리고 신뢰성에 의해 판단됩니다. 1일, 7일, 30일 보존과 99.5% 이상의 충돌 없는 세션율

이 성공의 주요 지표입니다. 그 프레임이 shipping 볼륨에 대한 주목을 돌려서 사용자 여행에 개선이 시간에 따라 중요성을 가지는지 여부에 주목합니다.

신뢰할 수 있는 업데이트 는 그 부분입니다. 만약 당신의 반은 더 오래된 웹 번들을 사용하고 있다면, 당신의 메트릭스는 흐려집니다. 제품은 혼합된 행동을 보입니다. 지원은 왜 여전히 해결된 문제를 만나는 사용자가 있는지 설명할 수 없습니다. 엔지니어링은 릴리스 영향에 대한 자신감을 잃습니다. 사용할 수 있는 롤아웃 제어를 UX 워크플로우의 일부로 사용하십시오.

__CAPGO_KEEP_0__의 배포 메커니즘을 앱 사용자 경험 자체로 다루는 패턴이 더 좋습니다.

__CAPGO_KEEP_0__의 배포 메커니즘을 앱 사용자 경험 자체로 다루는 패턴이 더 좋습니다.

• 배포를 좁게 먼저 출시하세요. 내부 사용자, 베타 그룹 또는 정의된 세그먼트에 UX 변경 사항을 전달하여 광범위한 릴리스 전에 먼저 출시하세요.
• 수용과 실패를 감시하세요. __CAPGO_KEEP_0__의 업데이트, 실패, 롤백된 장치에 대한 시각성을 필요로합니다.
• 릴리스 그룹을 행동에 연결하세요. 첫 번째 세션 활성화, 파이프라인 완료, 또는 좌절 신호를 변경 전과 후에 비교하세요.
• 빠른 롤백 경로를 보존하세요. UX 실험은 여전히 프로덕션 변경입니다. 새로운 흐름이 사람들을 혼란스럽게 하면 그것을 швидко 되돌리세요.

Capacitor 생태계에서 작업하는 팀에게는 Capacitor의 실시간 업데이트가 어떻게 작동하는지 설명하는 서비스가 필요합니다. Capacitor의 실시간 업데이트가 어떻게 작동하는지 설명하는 서비스가 필요합니다. 이 릴리스 루프를 운영하기 쉽게 만드는 것을 목표로 합니다. 하나의 옵션은 Capgo입니다. 이 기능은 signed web bundles를 대상 채널로 전달하고 Capacitor 및 Electron 앱에 업데이트를 적용하며 다음 런칭 시 업데이트를 제공하고 롤백 및 관찰 가능성 기능을 제공합니다. UX 변경이 웹层에 존재할 때 이 기능은 유용합니다. 또한 전체 스토어 사이클을 기다리지 않고 제어된 반복이 필요합니다.

빠른 반복은 안전한 릴리스만큼이면 팀이 실제로 픽스를 배포할 수 있는 경우에만 도움이 됩니다.

강력한 관찰 가능성 및 업데이트의 신뢰성은 만나는 곳입니다. 최고의 UX 팀은 단순히 마찰을 식별하는 것이 아니라, 그 차이를 명확하게 측정할 수 있는 동안 마찰을 제거합니다.

모든 것을 합치다. 첫 번째 UX 개선 주기

많은 팀은 UX 개선이 필요하지 않습니다. 그들은 하나의 단단한 주기를 증명하기 위해 프로세스가 작동하는지 확인하기 위해 필요합니다.

사용자가 가치에 도달하기 전에 가장 먼저 만나는 여행을 시작하세요. 첫 번째 런칭, 온보딩, 로그인, 검색, 체크아웃, 양식 완료, 또는 진행 중인 작업으로 돌아가는 것은 모두 좋은 후보입니다. 가장 직접적으로 사용자가 가치에 도달하는지 여부에 영향을 미치는 것을 선택하세요.

하나의 여행을 시작하세요, 전체 앱이 아닙니다.

실용적인 첫 번째 패스는 다음과 같습니다:

1. 하나의 결과 지표를 선택하세요: 첫 번째 의미 있는 액션까지의 시간이 많은 앱에 대해 강력한 후보입니다.
2. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
3. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
4. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
5. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ 새로운 제품 소개 매뉴얼 팀이 메시징, 출시 예상, 내부 준비를 일치시킬 수 있는 도움이 될 수 있습니다.

좋은 앱 사용자 경험은 일반적으로 이러한 방식으로 발생합니다. 단일 бли언트 리디자인에서 비롯되는 것이 아니라, 많은 측정된 수정이 주저함을 제거하고 신뢰를 회복하고 사용자가 가치가 더 빠르게 얻을 수 있도록 도와줍니다.

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

App User Experience: Capacitor 및 Electron 팀을 위한 안내서 App User Experience: A Guide for Capacitor & Electron Teams App User Experience: Capacitor 및 Electron 팀을 위한 안내서 Capgo Plugin Directory for the product workflow in Capgo Plugin Directory, Capacitor 플러그인들에 의해 Capgo Capacitor 플러그인들에 의해 Capgo의 구현 세부 정보를 위해 플러그인 추가 또는 업데이트 플러그인 추가 또는 업데이트의 구현 세부 정보를 위해 Ionic Enterprise 플러그인 대체 Ionic Enterprise 플러그인 대체의 제품 워크플로에 대해 Capgo 네이티브 빌드 Capgo 네이티브 빌드의 제품 워크플로에 대해