Mobil uygulama tasarımı nasıl yapılır?

Kısaca

Mobil uygulama tasarımı, masaüstü ekranın küçültülmüş hali değildir. Telefonda fare yoktur, bu yüzden üzerine gelince açılan menü de yoktur. Kullanıcı parmağıyla dokunur ve parmak, imleçten çok daha kaba bir araçtır.

Ben bir mobil ekrana bakarken dört soru sorarım. Hedefler parmağa yetecek kadar büyük mü? Ana işler başparmağın ulaştığı yerde mi? İş yarıda kesilince ne oluyor? Ağ yavaşlayınca ekran ne gösteriyor?

Bunların üstüne platform kuralları gelir. Apple ve Google kendi tasarım rehberlerini yayımlıyor. Kullanıcı da telefonundaki diğer uygulamalardan bir alışkanlık getiriyor. Bu alışkanlığa uyan bir uygulamayı öğrenmeye gerek kalmaz.

• Dokunma hedefleri: iOS'ta 44 × 44 pt, Android'de 48 × 48 dp. Web'de en az 24 × 24 CSS piksel.
• Gezinme: az sayıda ana bölüm, altta ve hep görünür.

Mobilde ne farklı

Masaüstünde kullanıcı genelde oturur ve iki elini kullanır. Telefonda bunların hiçbiri garanti değildir. Tasarım kararlarımın çoğu bu farktan çıkar.

Dokunma

Parmak ekranın bir bölümünü kapatır ve dokunduğu noktayı kullanıcı göremez. Bu yüzden küçük ve sık dizilmiş hedefler yanlış dokunuşa yol açar. Hover, yani imleci bir öğenin üzerine getirme durumu da yoktur. Masaüstünde fareyle görünen bir ipucu, telefonda hiç görünmez.

Audit'lerde en sık gördüğüm örnek, liste satırındaki küçük bir çöp kutusu ikonudur. İkon küçüktür ve satırın kendisine dokununca detay açılır. Kullanıcı silmek isterken detaya girer ya da tersi olur.

Tek el

Otobüste ayakta duran biri telefonu tek eliyle tutar ve başparmağıyla kullanır. Ekranın üst köşeleri bu durumda en zor ulaşılan yerlerdir. Ben sık kullanılan eylemleri ekranın alt yarısına koyarım.

Ödeme onayı gibi ana bir butonu sağ üst köşeye koymak, kullanıcıyı telefonu ikinci eline almaya zorlar. Aynı buton ekranın altında, tam genişlikte durduğunda tek elle basılır.

Kesinti

Mobil kullanım parça parçadır. Bir bildirim gelir ya da kullanıcı durağında iner. Uygulamaya döndüğünde form boşalmışsa iş baştan başlar.

Bu yüzden uzun formları adımlara bölerim ve girilen bilgiyi cihazda saklarım. Kullanıcı geri döndüğünde kaldığı adımı görür. Kredi başvurusu ya da bir e-Devlet işlemi gibi uzun işlerde bu fark hemen hissedilir.

Klavye ve form

Telefon klavyesi açıldığında ekranın büyük bir kısmını kaplar. Altta duran "Devam" butonu klavyenin arkasında kalabilir. Ben formu çizerken klavye açık halini de ayrı bir ekran olarak çizerim.

Doğru klavyeyi açmak da tasarımın işidir. Telefon numarası alanında rakam klavyesi, e-posta alanında @ işaretli klavye çıkmalı. Yanlış klavye, her alanda birkaç fazladan dokunuş demektir.

Otomatik doldurmayı da açık tutarım. Adres ya da tek kullanımlık doğrulama kodu gibi alanlarda telefon bilgiyi kendisi önerebilir. Bu alanları özel bileşenlerle bozmamak gerekir.

Ağ

Telefon asansörde ya da metroda bağlantıyı kaybeder. Tasarım bu anı da kapsamalıdır. Ben "yükleniyor" ve "bağlantı yok" durumlarını ayrı ekranlar olarak çizerim, ikincisine bir "Tekrar dene" butonu koyarım.

En tehlikeli an, para gönderme gibi bir işlemin ortasında bağlantının kopmasıdır. Kullanıcı işlemin gidip gitmediğini bilmezse butona yeniden basar. Ekran, işlemin durumunu açıkça söylemeli ve ikinci basışı engellemelidir.

Dokunma hedefi boyutları

Dokunma hedefi, kullanıcının parmağıyla basabildiği alandır. Görünen ikon küçük olabilir ama basılabilen alan ondan büyük tutulur. Üç kaynak bu alan için üç ayrı ölçü verir.

• 24 × 24 CSS piksel. WCAG 2.2, 2.5.8 (AA)
• 44 × 44 pt. Apple, iOS varsayılanı
• 48 × 48 dp. Android ve Material

Şekil: Kareler bu sayfada CSS piksel olarak çizildi. pt ve dp farklı birimlerdir, onları yan yana koymamın tek amacı fikir vermek.

Apple: 44 × 44 pt

Apple'ın Human Interface Guidelines erişilebilirlik bölümünde bir tablo var. Tabloya göre iOS ve iPadOS için varsayılan kontrol boyutu 44 × 44 pt, en küçük boyut 28 × 28 pt. Apple, her platformda önerilen en küçük boyuta ulaşmaya çalışın der.

Aynı bölüm kontroller arasındaki boşluk için de ölçü verir. Çerçeveli öğelerin çevresinde yaklaşık 12 pt, çerçevesiz öğelerin görünen kenarı çevresinde yaklaşık 24 pt boşluk önerir. Amaç, kullanıcının yanlış kontrole dokunma ihtimalini azaltmaktır.

Android ve Material: 48 × 48 dp

Android Developers belgeleri, dokunmatik arayüzde her etkileşimli öğenin en az 48 × 48 dp dokunma alanı olmasını önerir. Daha büyüğünün daha iyi olduğunu da ekler. Compose belgesi, bu 48 dp sınırını Material Design erişilebilirlik kurallarına bağlar.

Hazır Material bileşenleri bu boyutu kendiliğinden sağlar. Örneğin etkileşimli bir onay kutusu, çevresine eklenen boşlukla en az 48 dp'ye çıkar. Kendi özel bileşeninizi yaptığınızda ise bu boyutu sizin vermeniz gerekir.

WCAG 2.2: 24 × 24 CSS piksel

Web ve web görünümü kullanan uygulamalar için ölçüt W3C'nin WCAG 2.2 standardıdır. 2.5.8 Hedef Boyutu (En Az) ölçütü AA düzeyindedir. Bu ölçüt hedefin en az 24 × 24 CSS piksel olmasını ister.

Ölçütün beş istisnası var. Küçük hedefler yeterli aralıkla yerleştirilmişse, aynı işi yapan başka bir uygun kontrol varsa ya da hedef bir cümlenin içindeki bağlantıysa ölçüt aranmaz. Boyutu tarayıcının belirlediği kontroller ile sunumun zorunlu olduğu durumlar da istisnadır.

Daha sıkı bir ölçüt de var: 2.5.5 Hedef Boyutu (Gelişmiş). AAA düzeyindeki bu ölçüt 44 × 44 CSS piksel ister. W3C, önemli bağlantı ve kontroller için bu sıkı ölçütü hedeflemeyi düşünmenizi önerir.

Hangisini kullanmalı?

Ben 24 pikseli taban, 44 ve 48'i hedef olarak görürüm. Yerel bir iOS uygulamasında 44 pt, Android'de 48 dp kullanırım. Web tabanlı ya da çapraz platform bir uygulamada 48'i seçerim, çünkü iki platformun da üstünde kalır.

Ekran kalabalıksa ikonu küçültmeden önce ekrandaki işi azaltmayı denerim. Hedefleri küçültmek çoğu zaman yanlış soruya verilmiş bir cevaptır.

iOS ve Android farkı

İki platformun kuralları birbirine benzer ama aynı değildir. Kullanıcı iPhone'dan Android'e her gün geçmez. O yüzden kendi telefonunun alışkanlığını bekler.

Konu	iOS	Android
Dokunma hedefi.	44 × 44 pt varsayılan.	En az 48 × 48 dp.
Alt gezinme.	Sekme çubuğu, içeriğin üstünde yüzer.	Gezinme çubuğu, üç ila beş eşit önemde hedef.
Geri.	Standart geri butonu, üstte.	Sistem geri hareketi ya da tuşu.
Başlık.	Büyük başlık, kaydırınca küçülür.	Üst çubukta başlık.

Geri nasıl çalışır

En büyük fark geri davranışında. Apple, standart geri butonunu kullanmayı ve üstüne "Geri" yazmamayı önerir. Kullanıcı bu butonun bilgi hiyerarşisinde bir adım geri götürdüğünü bilir.

Android'de geri sistemin işidir. Android Developers belgelerine göre çoğu cihazda fiziksel, yazılımsal ya da hareketle çalışan bir geri tuşu vardır. Bu yüzden belge, uygulamaya genelde ayrı bir geri butonu eklememenizi söyler.

Android 13 ile tahmine dayalı geri hareketi geldi. Kullanıcı geri kaydırırken nereye döneceğinin önizlemesini görür. Android 15'ten itibaren bu sistem animasyonları, desteği açan uygulamalarda varsayılan olarak çalışır.

Başlıklar

Apple'a göre başlık, kullanıcının uygulamada nerede olduğunu doğrulamasına yardım eder. Başlığı 15 karakterin altında tutmayı önerir, böylece diğer kontrollere yer kalır. Büyük başlık, kullanıcı kaydırmaya başlayınca standart başlığa döner.

Android'de başlığın yeri üst uygulama çubuğudur. Android Developers'a göre bu çubuk genelde bir başlık taşır.

Bu kural Türkçede beni sık sık zorlar. "Hesap hareketlerim" 18 karakterdir, "Hareketler" ise 10. Türkçe kelimeler eklerle uzadığı için başlıkları ilk taslakta kısa yazarım.

Ortak tasarım mı, ayrı tasarım mı?

Bütçesi sınırlı ekiplerde tek bir tasarımla iki platforma çıkmak isterim. Marka ve içerik ortak kalır. Gezinme ve geri davranışı ise her platformda o platformun diliyle çalışır.

Gezinme kalıpları

Gezinme, kullanıcının uygulamada nerede olduğunu ve nereye gidebileceğini söyler. Mobilde en çok kullandığım üç kalıp var: alt sekme çubuğu, yığın gezinme ve menü.

Alt sekme çubuğu

Uygulamanın ana bölümleri ekranın altında, hep görünür durur. Apple sekme çubuğunu eylem için değil gezinme için kullanmayı önerir. Ekrandaki bir işlem için araç çubuğunu önerir.

Apple ayrıca sekme sayısını az tutmayı ve "Daha fazla" sekmesine düşen taşmalardan kaçınmayı önerir. Gizli sekmelerdeki içeriğe ulaşmak zorlaşır. Android'de gezinme çubuğu, dar ekranlarda eşit önemdeki üç ila beş hedef için önerilir.

Bir de görünürlük kuralı var. Apple'a göre sekme çubuğu gizlenirse kullanıcı hangi bölümde olduğunu unutabilir. Tek istisna, sekme çubuğunu geçici olarak kapatan bir modal görünümdür.

Yığın gezinme

Kullanıcı listeden detaya, oradan bir alt detaya iner ve geri ile döner. Banka uygulamasında hesap listesinden tek bir işlemin dekontuna inmek bu kalıba örnektir.

Burada dikkat ettiğim şey derinliktir. Kullanıcı dört beş ekran içeri girdiyse ana bölüme tek dokunuşla dönebilmelidir. Alttaki sekmeye basmak bu işi görür.

Hamburger menü

Üç çizgili ikonun arkasına saklanan menü yer kazandırır ama bir bedeli var. NN/g'nin 2016 çalışmasında mobil kullanıcılar gizli gezinmeyi vakaların %57'sinde kullandı. Görünür ve gizli gezinmeyi birleştiren tasarımda bu oran %86 oldu.

Aynı makale, dört ya da daha az ana bağlantı varsa bunları görünür göstermeyi önerir. Ben de ana bölümleri hamburgerin arkasına saklamam. Menüye yalnızca ayarlar ya da yasal metinler gibi seyrek kullanılan sayfaları koyarım.

Aşağıdaki örnekte aynı ekranı iki platformda görebilirsiniz.

Aynı ekran, iki platform

iOS

‹Geri

Kartlarım

• Banka kartı•••• 4821
• Kredi kartı•••• 0937
• Sanal kart•••• 5512

ÖzetKartlarÖdeProfil

Android

Kartlarım

• Banka kartı•••• 4821
• Kredi kartı•••• 0937
• Sanal kart•••• 5512

ÖzetKartlarÖdeProfil

◁ Geri: sistem hareketi ya da tuşu

Aynı banka ekranı iki platformda. iOS ya da Android'i seçin: sekme çubuğu, geri ve başlık değişir. Ekranlar örnek, gerçek bir uygulamadan alınmadı.

İki ekranda içerik ve renk aynı kaldı. Değişen parçalar sekme çubuğunun biçimi, geri davranışı ve başlığın yeri oldu. Kullanıcı kendi telefonundaki biçimi görünce ne yapacağını düşünmez.

Mobil uygulama tasarımı nasıl yapılır

1. 1. GörevKullanıcının telefonda bitireceği iş
2. 2. AkışEkran sırası, kâğıtta
3. 3. WireframeTek elle, gerçek boyutta
4. 4. PrototipTelefonda, parmakla
5. 5. TestAğ ve kesinti dahil

Şekil: Benim mobil tasarım sürecimin özeti. Aşağıdaki yedi adım aynı süreci daha ayrıntılı anlatır.

1. Görevi yazın. Kullanıcı bu uygulamayı açtığında hangi işi bitirmek istiyor? "Faturamı öderim" bir görevdir, "finans uygulaması" bir görev değildir. Ben en önemli üç görevi birer cümleyle yazarım.

2. Akışı kâğıtta çizin. Her görev için ekran sırasını kutularla çizerim. Burada bilgi mimarisi kararları verilir: hangi bölüm sekme olacak, hangisi bir alt ekran?

3. Wireframe'i gerçek boyutta yapın. Wireframe çizerken çerçeveyi bir telefon genişliğinde tutarım. Hedefleri en baştan 44 ya da 48 birim çizerim. Sonradan büyütmek düzeni bozar.

4. Prototipi telefonda deneyin. Bilgisayar ekranında güzel görünen bir prototip, elde bambaşka hissettirir. Prototipi telefona açar, tek elle ve ayaktayken kullanırım.

5. Zor durumları çizin. Boş liste, yükleniyor, bağlantı yok, hata. Her biri ayrı bir ekran durumudur ve geliştiriciye ayrı çizilmiş olarak gider.

6. Kullanıcıyla test edin. Birkaç kişiye görevi verir ve telefonda yapmalarını izlerim. Nerede durduklarını, nereye yanlış dokunduklarını not ederim.

7. Platforma uyarlayın. Ortak tasarımı iOS ve Android için ayrı ayrı gözden geçiririm. Geri davranışı ve gezinme çubuğu bu adımda ayrışır.

Mobil uygulama tasarımı yapmaya yeni başlıyorsanız ilk iki adımı atlamayın. Ekran çizmeye hemen başlamak caziptir. Ama görev ve akış net değilse güzel ekranlar yanlış işe hizmet eder.

Sık hatalar

Masaüstü tasarımı küçültmek. Üç sütunlu bir paneli tek sütuna dizmek mobil tasarım değildir. Telefonda hangi işin önce geleceğine yeniden karar vermek gerekir.

Ana eylemi üst köşeye koymak. Kaydet ya da gönder gibi butonlar üst köşede kalırsa tek elle ulaşmak zorlaşır. Ana eylem başparmağın yakınında durmalıdır.

Yalnızca ikonla gezinmek. Etiketsiz bir ikonun ne yaptığını herkes bilmez, bu yüzden alt sekmelerde ikonun altına kısa bir yazı eklerim.

Boş ve hatalı durumları unutmak. Tasarım dosyasında her liste dolu görünür. Gerçek hayatta yeni bir kullanıcının listesi boştur ve bu ekran ilk izlenimi belirler.

Platformun geri davranışını bozmak. Android'de sistem geri hareketi uygulamadan beklenmedik biçimde çıkarsa kullanıcı işini kaybeder. Bir formdan çıkarken kaydedilmemiş bilgi varsa önce sormak gerekir.

Yalnızca yeni telefonlarda test etmek. Ekip genelde yeni ve hızlı cihazlar kullanır. Kullanıcıların bir kısmı küçük ekranlı, eski bir telefonla ve zayıf bağlantıyla gelir.

Benim notum

Mobil audit'lerde en sık bulduğum sorun kesintiyle ilgili. Kullanıcı uygulamadan çıkıp dönünce baştan başlıyor. Ekip bunu masada, kesintisiz bir testte hiç görmüyor.

İkinci sırada bağlantı durumları geliyor. Yükleniyor ikonu sonsuza kadar dönüyor ya da hata mesajı hiç çıkmıyor. Ben bu ekranları tasarımın asıl parçası sayar ve ilk taslakta çizerim.

Bir de şunu öneririm: tasarımı her hafta bir kez telefonda, metroda ya da yürürken kullanın. Masada fark etmediğiniz sorunların çoğu orada kendini gösterir.