Mobil uygulama tasarımı için “kaç ekran?” sorusu tek başına yeterli değildir. Aynı randevu ekranı; uygun saatleri gösterirken, veri yüklenirken, uygun saat kalmadığında ve bağlantı kesildiğinde farklı kararlar gerektirir. Teklifin kapsamı yalnız ana ekranların adlarını içeriyorsa bu durumların kim tarafından çözüleceği belirsiz kalır.
Bu rehber, ilk uygulamasını hazırlayan ekipler ve mevcut ürününün arayüzünü yenilemek isteyen markalar için bir brief hazırlama yoludur. Önce kullanıcının tamamlayacağı işi, ardından ekranları, durumları ve teslim sorumluluklarını tanımlar. Buradaki örnek envanter varsayımsaldır; sabit ekran paketi, fiyat listesi veya bir müşteri projesinin sonucu değildir.
Önce ilk sürümün görevini tanımlayın
“Üyelik, profil ve ana sayfa olsun” bir ekran listesi verir; kullanıcının uygulamayı neden açacağını açıklamaz. “Kullanıcı aracına uygun hizmeti seçip randevu talebi oluştursun” daha değerlendirilebilir bir başlangıçtır. Hedef görev belli olduğunda hangi bilginin önce gerektiği, hangi adımın ertelenebileceği ve işlemin ne zaman tamamlanmış sayılacağı konuşulabilir.
İlk brief'e birincil kullanıcıyı, onun uygulamayı açma nedenini ve tamamlamasını beklediğiniz görevi yazın. Ardından mevcut bir ürün varsa ekran görüntülerini ve bilinen sorunları ekleyin. Kullanıcı araştırması veya destek talepleri bulunuyorsa paylaşın; bulunmuyorsa tahminleri araştırma sonucu gibi sunmayın. Araştırma, mevcut arayüz değerlendirmesi ve yeni ekran tasarımı ayrı kapsamlandırılabilir.
Ekran ve durum envanterini birlikte çıkarın
Aşağıdaki örnek bir randevu akışının nasıl kapsamlandırılabileceğini gösterir. Her satırın tamamını her projede üretmek gerekmez; ürünün gerçek davranışına göre gereken durumlar seçilir. “Aynı ekranın bir durumu” ifadesi o işin otomatik olarak ücretsiz veya sınırsız olduğu anlamına da gelmez; teslim listesi teklif aşamasında belirlenir.
| Kullanıcı adımı | Ana ekran veya bileşen | Kararlaştırılacak durumlar | Marka/ürün ekibinden gereken |
|---|---|---|---|
| Hizmet seçimi | Hizmet listesi ve detay | Yükleniyor, sonuç yok, hizmet geçici olarak kapalı | Hizmet adları, uygunluk koşulları ve içerik |
| Tarih ve saat | Takvim ve saat seçenekleri | Saat dolu, gün kapalı, seçim değişti, ağ hatası | Randevu kuralları ve gerçek sistem sınırları |
| Bilgi girişi | Form alanları | Boş, odakta, hatalı, gönderiliyor | Gerekli alanlar ve doğrulama kuralları |
| Sonucu görme | Onay ve hata geri bildirimi | Talep alındı, işlem başarısız, yeniden dene | İşlemin hangi noktada kesinleştiği ve sonraki adım |
| Geri dönüş | Önceki adıma dönme veya iptal | Girilen bilgiyi koruma, vazgeçme onayı | Veri koruma ve iptal davranışına ilişkin ürün kararı |
Bu listeyi tasarımcıyla geliştiricinin birlikte okuması yararlıdır. Örneğin sistem uygun saatleri anlık veremiyorsa, arayüzde kesin müsaitlik vaadi gösterilmemelidir. Tasarımın anlatacağı durum ile yazılımın sağlayabildiği veri aynı olmalıdır. İlgili ayrıntıları mobil form UX rehberinde daha yakından inceleyebilirsiniz.
Prototipten ne beklediğinizi belirtin
Etkileşimli prototip, tasarlanan akışın ekranlar arasında nasıl ilerlediğini değerlendirmek için hazırlanır. Çalışan hesap sistemi, canlı ödeme veya uygulama mağazasında yayınlanmış ürünle aynı teslim değildir. Prototipte gerçek veri bağlantısı ya da ileri etkileşim bekliyorsanız bunu ayrıca belirtin.
Teklifte hangi görevlerin prototipte tamamlanabildiğini yazın. Örneğin hizmet seçimi ve başarılı randevu akışının yanında bir hata senaryosunun da incelenmesini isteyebilirsiniz. Her ekrana rastgele bağlantı eklemek yerine değerlendirmek istediğiniz soruyu tarif edin: Kullanıcı sonraki adımı bulabiliyor mu, hata mesajı ne yapacağını anlatıyor mu, geri döndüğünde seçimlerini anlayabiliyor mu?
Kullanılabilirlik testi isteniyorsa katılımcıları kimin bulacağı, hangi görevlerin deneneceği ve bulguların nasıl raporlanacağı ayrıca kararlaştırılır. Bir tasarımcının uzman incelemesi ile hedef kullanıcılarla yapılan test aynı kanıtı üretmez. Prototipin bulunması da test yapıldığını kendiliğinden göstermez.
Platform, içerik ve erişilebilirlik beklentilerini konuşun
Uygulamanın iOS, Android veya her ikisi için mi hazırlandığını belirtin. Ortak marka dili kurulabilir; gezinme, geri dönüş, klavye ve izin akışları platform bağlamında değerlendirilir. Tablet veya farklı dil desteği varsa bunların ilk sürüme mi sonraki aşamaya mı ait olduğunu yazın.
Gerçek içerikler tasarım kararını değiştirir. Uzun hizmet adları, kullanıcı tarafından girilen metinler ve eksik görseller için örnekler sağlayın. Okunabilirlik, büyüyen metin, dokunma alanı ve yalnız renge dayanmayan durum açıklamaları hangi ekranlarda kontrol edilecek, başlangıçta belirleyin. Bu beklentiler, uygulanan yazılım üzerinde yapılacak erişilebilirlik kontrolünden ayrı bir tasarım sorumluluğudur.
Geliştiriciye teslim dosyasında ne bulunmalı?
Teslim yalnız ekran görüntülerinden oluşuyorsa geliştirme ekibi birçok kararı yeniden vermek zorunda kalabilir. İhtiyacınıza göre düzenlenmiş Figma dosyası, yeniden kullanılan bileşenler ve davranış açıklamaları istenebilir. Kapsamı, geliştiricinin gerçekten kullanacağı teslimler üzerinden tanımlayın.
- Onaylı akışlar ve ekranlar: hangi sürümün geliştirileceği ve hangi işlerin sonraya bırakıldığı.
- Bileşenler ve durumlar: buton, alan, kart veya gezinme öğesinin gereken varyasyonları.
- Tasarım değerleri: renk, tipografi, aralık ve ölçü kararları; varsa mevcut sistemle ilişkisi.
- Etkileşim notları: açılma/kapanma, geri dönüş, hata ve yükleme davranışı.
- Görsel varlıklar: dışa aktarılacak ikon/görseller, gerekli formatlar ve kullanım kaynakları.
- Devir görüşmesi: geliştiricinin sorularının nasıl toplanacağı ve geliştirme sırasındaki tasarım desteğinin kapsamı.
Yeni bir tasarım sistemi kurulması ile mevcut bileşenlerin birkaç ekranda kullanılması farklı işlerdir. Ayrıca her UI/UX projesine mobil yazılım geliştirme, sunucu, API bağlantısı veya mağaza yayını dahil değildir. Bu sorumlulukları mobil uygulama tasarımı hizmeti için hazırlanan teklifinizde ayrı ayrı netleştirin.
Fiyatı ve takvimi etkileyen kararlar
Özgün akış sayısı, ekranların karmaşıklığı, gereken durumlar, platformlar, mevcut tasarım altyapısı ve prototipin ayrıntı düzeyi iş yükünü değiştirir. Aynı bileşenin benzer ekranlarda kullanılmasıyla tamamen yeni bir görevin tasarlanması aynı kapsam değildir. Araştırma, içerik hazırlığı, test ve geliştirme desteği de ayrıca ele alınmalıdır.
Revizyon sürecini yön onayı, akış onayı ve final teslim gibi aşamalara bağlayın. Bir buton metninin düzeltilmesi ile onaylı randevu akışına yeni ödeme adımı eklenmesi farklı taleplerdir. Kaç geri bildirim turu bulunduğu ve kapsam değişikliğinin nasıl ele alınacağı teklifte yazılmalıdır; bu rehber sabit revizyon sayısı vaat etmez.
Portfolyoda rolü ve teslimi okuyun
OtoKonfor mobil uygulama projesi ve MoodVerse vaka çalışması, farklı ürün bağlamlarında arayüz ve görsel sistem kararlarını incelemek için başlangıçtır. Beğendiğiniz ekranın yanında akışın hangi ihtiyacı karşıladığını ve tasarımcının projede üstlendiği rolü okuyun. Bir portfolyo ekranından yazılımın tamamını kimin geliştirdiği veya uygulamanın ticari sonucu çıkarılamaz.
Kendi brief'inize bu örneklerden yalnız ihtiyacınızla ilgili soruları taşıyın. Bir randevu uygulamasının akışını, farklı amaçla kullanılan bir ürüne aynen uygulamak zorunda değilsiniz. Referansın hangi kararını yararlı bulduğunuzu açıklamak, yalnız “bunun gibi olsun” demekten daha somut bir başlangıç sağlar.
Teklif istemek için kısa brief
- Ürün kim için var ve ilk sürümde hangi görev tamamlanacak?
- Mevcut uygulama, araştırma, ekran listesi veya teknik ekip var mı?
- Hangi platform, dil ve cihazlar ilk kapsamda?
- Öncelikli ekranlar ve bilinmesi gereken boş/hata/yükleme durumları neler?
- Metin, marka dosyaları ve ürün kuralları hazır mı; kim onaylayacak?
- Prototip hangi görevleri gösterecek; kullanıcı testi ayrıca isteniyor mu?
- Geliştirici hangi dosyalara ve ne kadar devir desteğine ihtiyaç duyuyor?
- Hedef tarih, bütçe çerçevesi ve sonraki sürüme bırakılabilecek işler neler?
Bilmediğiniz alanları boş bırakmak yerine “birlikte netleştirilecek” diye işaretleyebilirsiniz. Uygulama fikrinizi veya mevcut ekranlarınızı paylaşın; ekran sayısını, gerekli durumları ve teslim sorumluluklarını aynı kapsamda konuşarak başlayalım.
Teslimi ne zaman tamamlanmış sayacaksınız?
Onaylı ekran/durum listesini dosyayla karşılaştırın, kararlaştırılan prototip görevlerini baştan sona deneyin ve geliştiricinin açık sorularını kapatın. Eksik durumlar, yanlış içerikler ve yeni özellik talepleri ayrı kaydedilsin. Tasarım tesliminin kabulü ile çalışan uygulamanın test edilip mağazada yayınlanması farklı aşamalardır; her birinin sorumlusu açık olmalıdır.