Kodsuz uygulamalarda kamera, GPS, biyometri ve çevrimdışı depolama için UX, izinler ve inceleme hazır kabul kriterleriyle kapsamı belirlemek için bir planlama matrisi kullanın.
Kamera, GPS, biyometri ve çevrimdışı mod basit eklentiler gibi görünür. Pratikte bunlar cihaz donanımına, gizlilik kurallarına ve uzun bir kenar durum listesine dokunur. Bu yüzden kodsuz uygulamalarda yerel mobil özellikler genellikle son dakika gecikmelerine yol açar.
Çoğu duraksama belirsiz kapsamla başlar. Bir tasarımcı temiz bir akış çizer, sonra QA gerçek davranışı test eder: zayıf sinyal, düşük ışık, izni reddeden bir kullanıcı veya arka planda uygulamayı kapatan bir telefon. Her sürpriz, sürüm incelemesinin zaten sıkı olduğu anda UX, iş mantığı ve test senaryolarında yeniden işe neden olur.
Zor olan mutlu yol değil. Zor olan, inşa etmeden önce kabul edilebilir minimum davranışta anlaşmaktır:
Basit bir planlama matrisi bu kararları erken almaya zorlar. Hız vs gizlilik, kolaylık vs güvenlik gibi ödünleşimleri görünür kılar, kenar durumları gereksinime dönüştürür ve belirsiz fikirleri test edilebilir ifadelere çevirir.
Örnek: bir saha teknisyeni uygulaması "GPS gerekli" diyebilir, ama gerçek soru sürekli takip mi yoksa iş tamamlandığında sadece bir konum damgası mı gerektiğidir. Bu tek seçim izinleri, pil etkisini ve inceleyicilerin beklentisini değiştirir.
Bir özellik planlama matrisi, kimse inşa etmeden önce kapsam üzerinde anlaşmanıza yardımcı olan tek sayfalık bir tablodur. Mobil yeteneklerde, özelliğin ne için olduğunu, kullanıcının ne gördüğünü ve inceleyicilerin neyi test edeceğini ekiplerin hizalanmasını sağlar.
Satırlara eklemeyi düşündüğünüz yetenekleri koyun: kamera, GPS, biyometri ve çevrimdışı depolama gibi. Sonra net kararlar almayı zorlayan sütunlar ekleyin. Henüz tam bir spes yazmıyorsunuz. Her özellik için aynı soruların cevaplandığından emin oluyorsunuz: kullanıcı hedefi, UX akışı, isteyeceğiniz izinler, toplanan veya saklanan veri, kenar durumlar ve kısa test notları.
Sahiplik önemlidir. Matrisi güncel tutacak bir kişiyi seçin (genellikle bir ürün sahibi veya baş tasarımcı) ve düzenli ritimde inceleyin: haftalık veya her sürüm incelemesinden önce. Matris kapsam değiştiğinde güncel kalmazsa işe yaramaz.
Çoğu son sürprizi engelleyen bir kural: her özelliğin bir yedek yolu olmalı. Kullanıcı hayır dediğinde, cihaz donanımı yoksa veya OS isteği engellediyse uygulama sınırlı ama dürüst bir şekilde çalışmaya devam etmelidir. Örneğin: kamera yoksa manuel giriş, GPS yoksa adres seçimi, biyometri başarısızsa PIN/parola ve çevrimdışı destek yoksa "çevrimdışı gerekir" mesajı (mümkünse taslaklarla) gibi.
AppMaster gibi bir platformla inşa ediyorsanız, matris aynı zamanda ekranları, mantığı ve veri modellerini birbirine bağlamadan önce kapsamı eşleştirmenize de yardımcı olur.
Matrise söz verilebilecek, sonra test edilebilecek bir vaad gibi davranın; dilek listesi gibi değil. Her yetenek için kullanıcı bakış açısından tek bir net "iş" yazın. Örnek: "Bir saha teknisyeni zayıf sinyal olsa bile bir sayaç fotoğrafı çekip bugünkü ziyaretle iliştirir." Bu özellikleri gerçek işe bağlı tutar.
Sonra özelliği kısa bir mutlu yola zorlayın. Akışı birkaç ekrandan daha fazla tarif edemiyorsanız, kapsam hazır değildir. Tasarım cilasına gerek yok; sadece aksiyonların sırası ve kullanıcının ne gördüğü yeterlidir.
İzinleri anlara eşleyin. "Çünkü daha sonra gerekebilir" diye uygulama açılışında sormaktan kaçının. İsteme tetikleyicisini ve sistem isteminden önce göstereceğiniz bir cümleyi belirleyin.
Matrisin her satırı için şunları yakalayın:
Gerçek testlere uyan kabul kriterleriyle bitirin, görüşler değil. Örnek: "Kamera izni reddedilirse, kullanıcı formu fotoğraf olmadan yine de gönderebilir ve daha sonra erişimi etkinleştirmek için net adımlar görür." veya: "Biyometrik giriş üç kez başarısız olursa uygulama hesabı engellemeden PIN/parolayı sunar."
AppMaster içinde inşa ediyorsanız, bu kararları ekranlar ve iş mantığını bağlamadan kilitlemek yeniden işi azaltır çünkü matris zaten UX, izinler ve geç ortaya çıkan kenar durumlarını kapsar.
Kamera özellikleri "basit" hissi verir ancak "bitti"nin ne olduğunu tanımlayana kadar karmaşıklaşır. Birincil kullanıcı eylemini seçin ve etrafında tasarlayın: kimlik tarama, iş yeri fotoğrafı çekme veya galeriden mevcut bir görüntü seçme. Her seçim ekranları, izinleri ve QA kapsamını değiştirir.
Yakalama sonrası kullanıcılara ne kadar kontrol vereceğinize karar verin. Sadece "fotoğraf" en kolay gönderimdir. Kırpma, döndürme, çoklu fotoğraf veya not ekleme eklediğiniz anda fazladan durumlar ortaya çıkar: yeniden çek, iptal, taslak kaydet ve ekran boyutları arası uyumluluk. Düzenleme gerekiyorsa minimumu belirleyin (ör. yeniden çek ve temel kırpma) ve diğerlerini atlayın.
Depolama kapsamın bir parçasıdır, uygulama detayı değil. Fotoğraf kanıt niteliğindeyse mümkünse hemen yükleyin ve ilerlemeyi gösterin. Daha sonra bir adımı destekliyorsa (form doldur, sonra gönder) cihazda geçici saklayın ve gönderimde yükleyin. Yükleme başarısız olursa ne olacağını tanımlayın: sonraya kuyrukla veya kullanıcıyı başarılı olana kadar engelle.
Genellikle bilet açtıran hata yollarını planlayın: düşük ışık veya bulanık çekim (ipuçları + yeniden çek), izin reddi (galeri yükleme gibi yedek ve net tekrar deneme yolu), çekim sırasında iptal (sil vs taslak), yavaş ağlarda büyük resimler (sıkıştır veya çözünürlüğü sınırla) ve yakalama sırasında uygulama/geçiş kesilmesi ile nazik bir kurtarma.
Gizlilik notlarını sade bir dille yazın: neyi yakalıyor, konum metadata'sı tutuluyor mu, görüntüler nerede saklanıyor (cihaz vs bulut) ve ne kadar süreyle saklanıyorlar.
GPS, "konum kullan" bütün gereksinim olduğunda karmaşıklaşır. Tek bir hedefle başlayın: anlık kontrol (şu an neredeyim), arka plan takibi (uygulama kapalıyken güncellemeler) veya rota kaydı (zaman içinde nokta izi). Her hedef izinleri, pil kullanımını ve inceleyicilerin isteyeceği gerekçeyi değiştirir.
Hassasiyet ve güncelleme sıklığını sade ifadelerle tanımlayın. "İşi 50 metre içinde işaretle" ve "ziyaret aktifken her 2 dakikada bir güncelle" gibi ifadeler "yüksek doğruluk, sık güncelleme"den daha kolay incelenir. Uygulama konum alamazsa ne olacağını belirleyin: bekle, yeniden dene veya kullanıcı konum olmadan devam etsin.
İzin zamanlaması özellik kadar önemlidir. Uygulama açılışında sormak genelde reddedilme ile sonuçlanır çünkü kullanıcı henüz değeri görmemiştir. Eylemden hemen önce sormak genelde daha iyi çalışır. Arka plan takibi farklıdır: açıkça gerekli bir özelliğe kullanıcı onay verdikten sonra isteyin.
Kenar durumları önceden planlayın: GPS kapalı veya uçak modu, zayıf sinyal/iç mekan çalışma, izin reddedildi, son bilinen konumun eski olması ve pil tasarrufu modunun arka plan güncellemelerini sınırlaması.
Konumun ne zaman kullanıldığını göstererek endişeyi azaltın. "Bu ziyaret için konum alındı" gibi küçük bir durum satırı veya izleme sırasında bir rozet güven oluşturur.
Örnek: saha servisi ekibi sadece teknisyen bir işi başlattığında bir check-in konumuna ihtiyaç duyuyorsa, bunu "dokununca bir kez yakala" olarak kapsamlandırın, iş emriyle saklayın ve GPS kapalıysa net bir mesaj gösterin. Rota kaydını gerçekten ihtiyacınız yoksa eklemeyin.
Biyometri uygulamayı hızlı ve güvenli hissettirebilir ama insanları takılmaya sokmanın yeni yollarını da yaratır. Bunu sadece bir kolaylık düğmesi değil, bir güvenlik özelliği gibi planlayın.
İlk olarak biyometrinin neyi koruyacağını kararlaştırın. Çoğu ekip için en iyi kullanım, kısa süreli zaman aşımından sonra uygulamayı yeniden açmak için hızlı yeniden doğrulama veya bir ödemeyi onaylama, veri dışa aktarma veya banka bilgilerini değiştirme gibi hassas işlemleri onaylamaktır. Biyometriyi tek giriş yöntemi yapmak kilitlenmeler ve destek taleplerinin başladığı yerdir.
Risk seviyenize uygun bir yedek seçin. Yaygın seçenekler: standart hesaplar için parola/parola kodu, daha güçlü kurtarma için tek kullanımlık kodlar (SMS/e-posta), daha az parola için sihirli bağlantılar (hesap kontrolüyle) veya yüksek riskli iş uygulamaları için yönetici destekli kurtarma.
Kaydı isteğe bağlı yapın. Başarılı oturum açmadan sonra sunun, faydayı bir cümleyle açıklayın ve insanların daha sonra kapatmasına izin verin.
Cihaz sınırları ve hatalar için tasarlayın: biyometri donanımı yok, biyometri ayarlı değil, sensör arızası (ıslak parmak/yüz tanıma başarısız), ve tekrarlı başarısızlıklarda OS kilitlenmeleri.
Korkuyu azaltan net metin kullanın. Ne depolandığını ve neyin depolanmadığını söyleyin: parmak izlerini veya yüz verilerini kaydetmiyoruz, telefonun kullanıcıyı doğrulamasını istiyoruz.
Çevrimdışı özellikler en sık ekipler "çevrimdışı çalışsın" diye uğraşırken başarısız olur çünkü "çalışmak" ne anlama geldiğini tanımlamazlar. Yardım eden en küçük hedefle başlayın: salt okunur erişim, taslak yakalama veya tamamlanmış bir iş akışı.
Kullanıcının 30 dakika sinyali olmadığını hayal edin. Görevlerini kaybetmeden bitirebilmesi için ne yapmalı? Bir saha teknisyeni için bugünün iş listesine erişim (salt okunur), not ve fotoğraf ekleme (taslak yakalama) ve tamamlanmış bir kontrol listesini daha sonra gönderebilme (kısmi iş akışı) gerekebilir.
Cihazda hangi verinin yaşadığını ve ne kadar süre kaldığını tam olarak seçin. Her şeyi önbelleğe almak depolama kullanımını ve gizlilik riskini artırır. Bunu kullanıcıların gerçekten ihtiyaç duyduğu ekranlarla sınırlayın.
Senkron davranışını ekranları inşa etmeden önce belirleyin: senkron ne zaman olur (açılışta, Wi-Fi'de, manuel dokunuşla), yeniden denemeler nasıl çalışır ve aynı kayıt sunucuda ve telefonda aynı anda değiştiğinde ne olur. Karmaşık çakışma yönetimi istemiyorsanız, çevrimdışıyken paylaşılan kayıtları düzenlemekten kaçının. Sunucunun sırayla uygulayabileceği kuyruklanmış eylemleri tercih edin.
Çevrimdışıyı görünür kılın. Kullanıcılar çevrimdışı banner'ı, "Son senkron" zamanı ve bekleyen eylemler sayısı gibi sinyallere ihtiyaç duyar. Bunları ayrı UI durumları (çevrimiçi, çevrimdışı, senkronize ediyor, hata) olarak planlayın ki QA bunları güvenilir şekilde test edebilsin.
Son olarak bir kurtarma hikayesi yazın. Kullanıcı yeniden yükleme yaparsa, depolama dolarsa veya oturum ortasında çıkış yaparsa kuyruktaki verilerle ne olacağını ve güvenli bir şekilde nasıl devam edileceğini uygulama açıklamalıdır.
İzinler rastgele hissettiğinde sorun olur. Her izni net, kullanıcı tarafından görülen bir ana bağlayın. Eğer uygulamanızın ilk yaptığı şey Camera, Location ve Notifications istemekse, birçok kişi "İzin Verme"ye dokunacak ve sonra geri dönmeyecek.
İzin isteklerini akışın bir parçası yapın. Kamerayı yalnızca kullanıcı "Barkod tara"ya dokunduğunda sorun ve kısa bir açıklama gösterin: "Kodu yazmak zorunda kalmayasınız diye kamerayı kodu taramak için kullanıyoruz." Dil basit ve spesifik olsun.
Ayrıca izin olmadan da çalışan bir yol tasarlayın. Paylaşılan bir cihazda GPS'i reddeden bir saha teknisyeni için manuel adres modu, sınırlı liste görünümü veya "daha sonra hatırlat" seçeneği sunun.
Bu kararları kapsamda tutun ki QA ve sürüm incelemeleri daha hızlı ilerlesin:
Ayrıca kimsenin iOS ve Android'in aynı davrandığını varsaymaması için küçük bir platform notları tablosu ekleyin:
| Capability | iOS notes | Android notes |
|---|---|---|
| Camera | Add clear purpose text | Handle permission + possible "Never ask again" |
| GPS | Prefer "only while using" when possible | Background tracking needs extra review |
| Biometrics | Always include passcode fallback | Allow device credential fallback |
| Offline storage | Define what’s cached and for how long | Plan for low-storage cleanup |
Eğer AppMaster ile inşa ediyorsanız, izinleri bir anahtar değil UX tasarımının parçası olarak ele alın. "Reddedildi" ekranlarını erken yazın. Destek taleplerinin çoğu genelde oradan gelir.
Çoğu gecikme özelliğiniz telefonunuzda çalışırken gerçek koşullarda bozulduğunda olur: zayıf sinyal, yorgun bir kullanıcı veya bir gizlilik inceleyicisinin "Bunu neden istiyorsunuz?" demesi. En hızlı düzeltme genellikle daha fazlasını inşa etmek değildir. Eksik kararları tanımlamaktır.
Yaygın bir engel, uygulama açılır açılmaz izin istemektir. İnceleyiciler eyleme bağlı bir gerekçe ister. Kullanıcı "Barkod tara"ya dokunmamışsa kamera istemi şüpheli görünür. Konum da benzer: sadece servis adresi bulunacaksa manuel giriş veya tek seferlik sorgu yeterli olabilir.
QA ayrıca bitmemiş akışlarda takılır. Kamera özellikleri genellikle yeniden çekme, net bir iptal yolu veya bağlantı koptuğunda yükleme yeniden denemesi olmadan gönderilir. Çevrimdışı çalışma başka bir tuzaktır: bir anahtar değildir. Hangi şeylerin çalıştığı, neyin kuyruğa alındığı, senkronun ne yaptığı ve çakışmalarda ne olacağı setidir.
Süre ekleyen yaygın kapsam eksikleri:
Kamera, GPS, biyometri veya çevrimdışı modu taahhüt etmeden önce bir mantık kontrolü yapın. Bu, izin reddi, belirsiz yedek yollar ve QA vakalarının planlanmaması gibi son sürprizleri önler.
Her özellik için bir cümleyle kullanıcı hedefini yazın. Kimin neden ihtiyaç duyduğunu söyleyemiyorsanız, sprint için hazır değildir.
Sonra mutlu yolu ve yedek yolu eşleştirin. Örnek: bir sürücü barkodu tarar (mutlu yol). Kamera izni reddedilirse kodu manuel girebilir veya son işlerden birini seçebilir (yedek). Yedek özellikten ayrı bir eklenti değil, özelliğin bir parçasıdır.
Kapsama karar vermek için bu kontrol listesini kullanın:
Küçük bir saha teknisyeni uygulaması matrisi nasıl çalıştırır gösterir. Amaç basittir: teknisyen bir işi açar, kontrol yapar, fotoğraf ve not ekler ve nihai raporu gönderir. Ofis ekibi bunu inceler ve takipler planlar.
İşte v1 için kapsamı net tutan ve izin sürprizlerinden kaçınan örnek bir matris:
| Capability | What we ship in v1 | Permission moment | UX decisions that prevent rework |
|---|---|---|---|
| Camera | Take 1+ photos per job, with retake. Compress before upload. Upload only on Wi-Fi by default (with an override). | Ask only when the user taps “Add photo”. | Show a preview, “Retake” and “Use photo”. Explain upload rules near the Save button. |
| GPS | Attach one location to a job when the tech taps “Set location”. No background tracking. | Ask only when the user taps “Set location”. | Provide “Use current location” and “Enter address instead”. Store accuracy (for review) but don’t block submission. |
| Biometrics | Re-authenticate with Face ID/Touch ID (or Android equivalent) right before “Submit final report”. | No extra OS permission prompt, but user must enable biometrics in the app settings. | Always offer a fallback (PIN/password). If biometrics fails, don’t lock the user out of the job. |
| Offline storage | Save drafts (notes + checklist state) and photos locally. Sync when online. | No permission prompt in most cases. | Show an “Offline” badge and a clear “Syncing…” status. Prevent duplicate submissions. |
Yapıma başlamadan önce, inceleme ve QA için birkaç geç/kal kontrolünde anlaşın:
AppMaster içinde bu matris ekranlara (iş detayları, fotoğraf çekimi, gönderme akışı), iş kurallarına (ne zaman sorulacağı, ne zaman senkronlanacağı) ve veri alanlarına (taslak durumu, konum, fotoğraf meta verisi) temiz şekilde eşlenir.
Matris doldurulduktan sonra, her hücreyi ekiplerin inşa edip test edebileceği öğelere dönüştürün. Anlaşmazlık çıkmaması için bunu kullanıcı hikayelerine ve kabul kriterlerine çevirin; böylece "çevrimdışı" veya "GPS"in ne anlama geldiği sonra tartışılmaz.
Hikayeleri sensörler yerine çıktılar etrafında yazın. Örnek: "Bir teknisyen olarak bir işe en fazla 3 fotoğraf ekleyebilmeliyim ve kamera erişimini reddedersem galeriden yükleyebilmeliyim." Sonra izinler, hata durumları ve yedek akış için kriterler ekleyin.
İnşa planını kasıtlı olarak küçük tutun. Tek bir ince özellik dilimini seçin (bir ekran, bir akış, bir yetenek), gerçek cihazlarda test edin ve öğrendiklerinize göre genişletin. Kamera + çevrimdışı + GPS'i aynı anda göndermek QA ve inceleme riskini çarpanlar.
Bu kararı AppMaster (appmaster.io) ile uygulamaya koymaya karar verirseniz, aynı matris veri model kararları için Data Designer'da, kenar durum mantığı için Business Process Editor'da ve açık UI durumları için mobil UI builder'da çift kullanım sunar. Bu, kapsam, UX ve testin gereksinimler değiştikçe hizalı kalmasını sağlar.
Mobil özellikler için feature planning matrix nedir ve neden kullanmalıyım?Bir feature planning matrix, inşa etmeden önce net kararlar almanızı sağlayan tek sayfalık bir tablodur. “GPS ekle” veya “çevrimdışı destekle” gibi talepleri, kullanıcı hedefi, mutlu yol (happy path), izin zamanlaması, hata yolları ve temel QA kontrolleriyle test edilebilir kapsama dönüştürür.
Tam bir spes yazmadan matrisi hızlıca doldurmanın en kolay yolu nedir?Kullanıcının işini bir cümleyle tanımlayarak başlayın, sonra tamamlayan en basit mutlu yolu yazın. İzni tam olarak ne zaman isteyeceğinizi, reddedilirse ne olacağını, cihazda hangi verinin saklanacağını ve QA'nın hızlıca yeniden üretebileceği 3–5 başarısızlık durumunu ekleyin.
Uygulama ne zaman kamera veya konum izni istemeli?Kullanıcının açıkça bunu gerektiren eylemi yapmadan hemen önce sorun — örneğin “Fotoğraf ekle”ye dokununca veya “Konumu ayarla”yı seçince. Kısa bir uygulama içi açıklama ile eşleştirin ki istem rastgele görünmesin ve kullanıcı reddederse kullanılabilir bir yol hep olsun.
İnceleme ve QA'nın kabul edeceği bir “fallback path” neye benzer?İyi bir fallback, kullanıcıya görevi yine de tamamlatan ama daha az konforlu bir yol sunar. Örneğin tarama yerine manuel giriş, GPS yerine adres seçimi veya biyometri yerine PIN/parola; ayrıca tekrar deneme yollarının açık olması gerekir.
Hangi kamera kararları genelde son dakika yeniden işe neden olur?“Bitti”nin ne olduğunu netleştirin: yeni fotoğraf çekmek mi, galeriden seçmek mi, belge taramak mı? V1'de amaçları karıştırmayın. Yeniden çekme/iptal davranışı, yükleme zamanlaması (hemen mi yoksa gönderim sırasında mı) ve yükleme başarısız olursa kullanıcı işinin kaybolmaması için ne yapılacağı belirleyin.
GPS'i fazla kapsamlandırmaktan nasıl kaçınırım ve incelemelerde takılmam?Tek seferlik bir konum damgası mı, arka plan takibi mi yoksa rota kaydı mı istediğinizi netleştirin. Çoğu iş uygulaması için “dokununca bir kez yakala” yeterlidir; bu izin yükünü, pil etkisini ve inceleme sorularını azaltır.
Kullanıcıları kilitlemeden Face ID/Touch ID eklemenin en güvenli yolu nedir?Biyometrik sadece kolaylık katmanı olsun, tek giriş yöntemi olmasın. Oturum açtıktan sonra isteğe bağlı sunun, hızlı yeniden doğrulama veya hassas işlemler için kullanın ve her zaman parola veya PIN gibi bir yedek bırakın.
Çevrimdışı modu faydalı ama büyük bir proje olmadan nasıl boyutlandırırız?Okuma erişimi veya taslak kaydetme gibi en küçük işe yarar çevrimdışı hedefi seçin. Lokalde hangi verinin kaldığını ve ne kadar süreyle saklandığını belirleyin. Senkron zamanlamasını, yeniden denemeleri ve ağ geri geldiğinde yinelenen gönderimleri nasıl engelleyeceğinizi önden tanımlayın.
Bu yerel yetenekler için kabul kriterleri nasıl görünmeli?Gözlemlenebilir davranışlar üzerinden kabul kriterleri yazın. En az bir pass/fail testi olarak; izin reddi, donanım eksikliği, zayıf bağlantı ve uygulama yeniden başlatıldıktan sonra kurtarma gibi durumları ekleyin ki QA her seferinde aynı kuralları doğrulayabilsin.
AppMaster bu matrisi uygulamaya geçirmede nasıl yardımcı olur ve teknik borç oluşturmaz?Her yeteneği ekranlara, veri alanlarına ve kenar durum mantığına haritalamak için matrisi kullanın. AppMaster (appmaster.io) içinde bu genellikle Veri Tasarımcısı'nda veriyi tanımlamak, İş Süreci Editörü'nde izin ve hata akışlarını ele almak ve mobil UI oluşturucuda açık UI durumları kurmak anlamına gelir; böylece kapsam değiştikçe teknik borç oluşmaz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
