Birçok uygulama fikri hazır bir çözümle başlar: “bir platforma ihtiyacımız var” veya “bu adım otomatikleştirilmeli”. Bu cümleler yön gösterebilir, ancak henüz bir ürün tanımlamaz. İlginç bir fikir ile bakımı kolay bir uygulama arasında insanlar, durumlar, veriler, sınırlar ve sonraki işletim hakkında kararlar vardır.
En önemli çalışma ilk ekrandan önce başlar. Gerçek sorun nedir, bugün nasıl çözülüyor ve hangi gözlenebilir sonuç iyileşmeyi gösterecek? Bakımı kolay bir uygulama açık amacı, tutarlı veri modelini ve ekibin ilk sürümden sonra da taşıyabileceği kapsamı birleştirir.
Kısaca
- Somut bir sorunu, hedef kitleyi ve en küçük eksiksiz süreci tanımlayın.
- Veri modelini, gizliliği, testleri ve işletimi en baştan ele alın.
- Yalnızca her sürüm eksiksiz ve yararlı bir sonuç sunduğunda aşamalı yayın yapın.
Sorunu gözlemlenebilir bir durumda tanımlayın
“Mülk yönetimi kafa karıştırıcıdır” ifadesi çok geniştir. Kimlerin etkilendiğini veya kafa karışıklığının tam olarak ne olduğunu açıklamaz. Buna karşılık “Özel mülk sahipleri, evden uzaktayken son kaydedilen sayaç okumasını ve ilgili fotoğrafı güvenilir biçimde bulamıyor” somuttur: kişiyi, durumu, bilgiyi ve istenen sonucu adlandırır.
İyi problem tanımları başlangıçta çözümden bağımsız kalır. Belki mevcut depolamayı iyileştirmek, süreci değiştirmek veya küçük bir web arayüzü yeterlidir. Belirli bir teknolojiyi hemen şart koşan kişi daha basit yolları kolayca gözden kaçırır. Erken analizin amacı bir uygulamayı haklı çıkarmak değil, uygulamanın yararlı olup olmayacağını ve nerede yarar sağlayacağını anlamaktır.
İnsanlar bugün hangi adımları atıyor? Hangi araçları kullanıyor? Kâğıt, elektronik tablolar, mesajlar ve fotoğraflar arasında nerede geçiş yapıyor? İstisnalar neler? Yalnızca istenen işlevleri sormak yeterli değildir. İnsanlar çözümleri önceki deneyimlerinden yola çıkarak anlatır; gözlemlenen zorluklarsa ürünün ne yapması gerektiğini daha iyi açıklar.
Hedef grup aynı zamanda şu anlama da gelir: bilinçli olarak herkes için değil
“Özel şahıslara ve her büyüklükteki şirketlere” yönelik bir ürünün muhtemelen henüz net bir hedef kitlesi yoktur. Farklı grupların farklı terimleri, riskleri ve iş akışları vardır. Tek bir kişinin rol yönetimine ihtiyacı yoktur. Bir ekip, roller ve ortak veriler olmadan güvenilir bir şekilde çalışamaz.
Yararlı bir hedef kitle açıklaması kullanım bağlamını, deneyimi, sıklığı ve sınırları kapsar. Kişi tek başına mı, başkalarıyla mı çalışıyor? Akıllı telefonda mı, birkaç iş istasyonunda mı? Uygulama her gün mü, yalnızca belirli bir olayda mı açılıyor? Ağ olmadan çalışması gerekiyor mu? Hangi hatalar yalnızca can sıkıcı olur, hangileri ciddi sonuçlar doğurur?
Bu sorular daha sonra hemen hemen her şeyi etkiler: navigasyonu, veri depolamayı, güvenlik modelini, yardım metinlerini ve iş modelini. Hedef kitleyi sınırlandırmak yalnızca pazarlama amacıyla persona çalışması yapmak değildir; teknik şartnamenin de bir parçasıdır.
En küçük tam süreci bulma
İlk ürün sürümü küçük olmalı, ancak eksik kalmamalıdır. Örneğin bir sayaç okumasını belgelemek için mülkü seçmek, tarih ve değeri girmek, gerekirse fotoğraf eklemek, kaydı kaydetmek, daha sonra bulmak ve düzeltebilmek gerekir. Geçmişi veya hata düzeltmesi olmayan tek bir form daha az emek ister, ancak eksiksiz fayda sağlamaz.
En küçük eksiksiz akışın bir başlangıcı, ortası ve sonu vardır; ayrıca önemli sapmaları da kapsar. Kamera izni yoksa ne olur? Kayıt fotoğrafsız kaydedilebilir mi? Boş durum nasıl görünür? Değer geçersizse veya kullanıcı işlemi iptal ederse ne olur? Kesintiden sonra girilen bilgiler korunur mu?
İşlevler ancak bu temel yol netleştiğinde gerekli ve isteğe bağlı olarak anlamlı biçimde ayrılabilir. Gerekli olan, sonucu mümkün kılan veya kabul edilemez bir hataya karşı koruyandır. İsteğe bağlı olan ise konforu, seçenekleri ya da gelecekteki hedef kitleleri genişletir. Görünüşte küçük bir seçenek yeni veriler ve durumlar üretebileceğinden bu ayrım düzenli olarak gözden geçirilmelidir.
Kararları görünür kılacak prototipler
Bir prototip, soruları açıklığa kavuşturduğunda özellikle değerlidir. İnsanlar kullanılan terimleri anlıyor mu? Bir sonraki adımı buluyorlar mı? Karar vermek için gerekli bilgiler eksik mi? Süreç, akıllı telefonun gerçekte kullanıldığı duruma uyuyor mu?
Prototipin görsel olarak kusursuz olması gerekmez. Gerçekçi içeriğe sahip basit, tıklanabilir bir model çoğu zaman yer tutucu metinlerle dolu gösterişli bir sunumdan daha fazlasını ortaya çıkarır. Gerçek adlar, uzun metinler, eksik görseller ve çok sayıda kayıt, düzenin ve bilgi mimarisinin bunlara dayanıp dayanmadığını gösterir.
Prototipler kritik durumları da içermelidir: veri olmaması, yükleme veya kaydetme hataları, iznin reddedilmesi, çevrimdışı kullanım, çok büyük yazı ve geri alınamayan eylemler. Yalnızca ideal akışı gösteren kişi ürün yerine bir hikâyeyi test eder.
Apple, İnsan Arayüzü Yönergelerinde hiyerarşiyi, tutarlılığı ve farklı ekranlara uyumu vurgular. Bu ilkeler sürecin sonuna dekorasyon olarak eklenemez. Prototipin yapısını en baştan etkiler: İçerik nedir, eylem nedir, hangi bilgiler ön planda kalır ve ilgili platformda hangi etkileşim tanıdıktır?
Veri modeli uzun vadeli bir ürün kararıdır
Arayüzler önemli ölçüde değişebilir; saklanan verilerin anlamı ise çoğu zaman yıllarca önemini korur. Bu nedenle üründe hangi varlıkların bulunduğunu ve bunların nasıl ilişkili olduğunu erken açıklığa kavuşturmak gerekir. Bir “oda” her zaman bir birimin parçası mıdır? Bir belge birden fazla sürece atanabilir mi? Bir nesne arşivlendiğinde görevlere ne olur? Parasal tutarlar ve ölçümler gereken hassasiyetle mi saklanır?
Tutarlı bir veri modeli, aynı bilginin farklı yerlerde birbiriyle çelişmesini önler. Android Developers, uygulama mimarisi için tek bir doğruluk kaynağı ve net sorumluluk sınırları önerir. Bu teknik ilkeler önemli bir ürün kuralını destekler: bilgi değiştiğinde hangi gösterimin geçerli kaynak olduğu açık olmalıdır.
Veri geçişleri de bu kararın parçasıdır. Gerçek veriler oluştuğunda yeni sürüm alanları keyfî biçimde yeniden adlandıramaz veya silemez. Ürünün eski durumların yeni yapıya nasıl aktarılacağını belirleyen kurallara ihtiyacı vardır. İyi bir ilk model gelecekteki her gelişmeyi tahmin etmeye çalışmaz; ancak istikrarlı alan kavramlarını arayüzün kısa ömürlü mantığından ayırır.
Veri koruması hangi verinin gerekli olduğu sorusuyla başlar
Veri koruması ancak uygulama geliştirildikten sonra incelenirse pahalı hâle gelir. O noktada izinler, harici hizmetler ve veri modelleri zaten birbirine bağlanmıştır. Konuyu erken ele almak ürün kapsamını sadeleştirebilir.
Uygulamanın hesaba ihtiyacı var mı? Kişi kaydının tamamı mı içe aktarılmalı, yoksa elle girilen bir kişi yeterli mi? Konum erişimi sürekli mi, yalnızca tek bir işlem için mi gerekli, yoksa hiç mi gerekmiyor? Bir belgenin cihazdan çıkması gerekiyor mu? Toplanmayan her veri öğesi saldırı yüzeyini, hata durumlarını, güvenlik çalışmalarını ve sonraki silme süreçlerini azaltır.
Android, izin isteklerini en aza indirmeyi ve mümkünse işlevleri gereksiz erişim olmadan çalışacak şekilde tasarlamayı önerir. İzin gerekiyorsa somut eylem bağlamında istenmelidir. Makul bir alternatif yol varsa reddedilen izin tüm uygulamayı otomatik olarak kullanılamaz hâle getirmemelidir.
Veri koruması tüm yaşam döngüsünü kapsar: kaydetme, görüntüleme, paylaşma, dışa aktarma, yedekleme ve silme. Yerel depolama bir yedekleme stratejisi gerektirir. Bulut verileri için hesap koruması, erişim kuralları ve anlaşılır bir silme süreci gerekir. Üçüncü taraf sağlayıcıların hangi bilgileri neden aldığı açık olmalıdır.
Bakımı kolaylaştıran şey açık sınırlar ve sorumluluklardır
Bakımı kolay bir kod tabanında görevleri net biçimde ayrılmış modüller bulunur. Arayüz etkileşimleri koordine eder, alan mantığı kuralları uygular, veri katmanı ise kaynakları ve kalıcı depolamayı yönetir. Ağ erişimi, sunum ve iş kuralları aynı bileşenlerde karıştığında değişiklikler ve testler zorlaşır.
Teknik ayrım tek başına yeterli değildir. Ürünün sorumluluk sınırlarına da ihtiyacı vardır. Terimleri kim belirler? Bir veri kümesi için ürünün hangi bölümü geçerli kaynaktır? Harici bir hizmet başarısız olduğunda ürün neyi garanti eder? Manuel bir alternatif var mıdır? Açıkça desteklenmeyen nedir?
Her bağımlılığın tanınabilir bir amacı olmalıdır. Bir kitaplık geliştirmeyi hızlandırabilir ancak güncellemeler ve güvenlik izlemesi gerektirir. Bir bulut hizmeti karmaşık işleri üstlenebilir ancak maliyetlere ve bir arıza noktasına neden olur. Kurum içi bir sistem kontrol sağlar ancak kalıcı bakım gerektirir. Bakım kolaylığı, bu yükümlülükleri bilinçli olarak seçmek anlamına gelir.
Dokümantasyon kararları açıkladığında bu netliği destekler. Her dosyayı sıralayan uzun bir liste hızla eskir. Sistem sınırlarını, veri akışlarını, geçiş kurallarını ve açık olmayan kararların gerekçelerini kısaca anlatmak daha değerlidir. Hem yeni ekip üyeleri hem de ileride bu kararlara dönecek kişiler bir parçanın neden böyle tasarlandığını anlayabilmelidir.
Testler riskleri ve gerçek kullanıcı yolculuklarını izler
Otomatik testlerin çokluğu tek başına ürün kalitesini kanıtlamaz. Önemli olan ilgili riskleri kapsayıp kapsamadıklarıdır. Birim testleri alan kuralları ve hesaplamalar için uygundur. Entegrasyon testleri veritabanı, hizmetler ve geçişlerin etkileşimini denetler. Uçtan uca testler temel kullanıcı yollarını güvence altına alabilir. Manuel testler dil, görsel hiyerarşi, odak davranışı ve tamamen otomatikleştirilmesi zor durumlar için önemini korur.
Testler gerçekçi verilerle çalışmalıdır: uzun adlar, boş listeler, eski kayıtlar, alışılmadık ondalık değerler, birden fazla ek ve kesintiye uğrayan bağlantılar. Farklı ekran boyutları ve büyük yazı boyutları, bir düzenin gerçekten uyarlanabilir olup olmadığını gösterir. Ekran okuyucular ve klavyeler, ekran görüntüsünün göstermediği anlamsal zayıflıkları görünür hale getirir.
W3C WAI, erişilebilirliğin erken ve düzenli olarak değerlendirilmesini ve engelli bireylerin uygun bir biçimde dahil edilmesini önermektedir. Bu iyi bir genel kalite ilkesidir: yalnızca bitmiş sürümü bir kontrol listesiyle incelemek yerine, kararlar hâlâ değiştirilebilirken geri bildirimi sürece katmak gerekir.
Özellikle riskli eylemler hedefli kontroller gerektirir. Silme, geri yükleme, satın alma durumu, dışa aktarma ve izinler, yalnızca görsel nitelikteki durumlardan daha derin testleri hak eder. Etki ve olasılığa göre önceliklendirme, her yerde aynı miktarda test istemekten daha yararlıdır.
Adım adım yayınlamak, yayınlamanın yarım kaldığı anlamına gelmez
İlk versiyonun her uzun vadeli planı içermesi gerekmez. Ancak vaat edilen temel yolların eksiksiz, anlaşılır ve dayanıklı olması gerekir. “Adım adım” kapsamın gelişimini anlatır; eksik hata işleme veya belirsiz veri sorumluluğu için mazeret değildir.
Ürünün piyasaya sürülmesinden önce doğrulanabilir kriterlere ihtiyacı vardır: desteklenen cihazlar ve sürümler, test edilmiş temel süreçler, anlaşılır ürün sınırları, doğru mağaza ve yasal metinler, ulaşılabilir destek, yedekleme veya silme davranışı ve kritik hatalar için bir plan. Kontrollü bir test grubu, ürün geniş çapta kullanıma sunulmadan önce gerçek kullanımı gösterebilir.
Yayınlandıktan sonra geri bildirim otomatik olarak yol haritası girişlerine dönüşmez. Geri bildirim gerçek durumlar hakkında kanıt sağlar. Aynı işleve yönelik birden fazla istek, ortak bir örüntüyü gösterebilir veya kimsenin bulamadığı mevcut bir sürece işaret edebilir. Ürün ekipleri bir çözüm seçmeden önce sorunu, sıklığı, hedef grubu ve riski anlamalıdır.
Daha sonraki bir sürüm yeni yetenekler ekleyebilir. Ancak ürünün çekirdeğini gölgelememeli ve mevcut verilere saygı göstermelidir. Veri geçişi, geriye dönük uyumluluk ve güncellenmiş açıklamalar sonradan yapılacak temizlik değil, özelliğin bir parçasıdır.
Ortak nokta somut sonuçtur
İlk gözlemden günlük işletime kadar tek bir soru yönü korur: bu karar hedef kitle için somut sonucu iyileştiriyor mu? Şık bir prototip, modern mimari veya uzun özellik listesi yanlış sorunu optimize ediyorsa az değer taşır.
Bakımı kolay bir uygulama gerçek sorun, sınırlı kitle, eksiksiz temel süreçler, tutarlı veri modeli, anlaşılır veri akışları ve test edilebilir sorumlulukları bir araya getirir. Bu temel, ürünün sonraki sürümlerde tutarlı biçimde gelişmeye devam edip edemeyeceğini belirler.
Kaynaklar ve daha fazla okuma
- Android Geliştiriciler: Uygulama mimarisi kılavuzu – veri modelleri, tek bir doğruluk kaynağı, test edilebilirlik ve sorumluluk sınırları.
- Android Geliştiriciler: Veri katmanı – veri katmanının sorumlulukları ve sınırları.
- Android Geliştiriciler: İzin isteklerini en aza indirin – veri minimizasyonu ve bağlamsal izinler.
- Apple İnsan Arayüzü Yönergeleri – hiyerarşi, tutarlılık, düzen ve platforma uygun etkileşimler.
- W3C WAI: Web Erişilebilirliğini Planlama ve Yönetme – erişilebilirlik ve değerlendirmenin erken ve sürekli olarak dahil edilmesi.
