Mobil uygulama tasarımında en pahalı hatalar renk seçiminde değil, ekran akışında yapılıyor. Kod yazılmadan önce prototip üzerinde çözülmesi gereken şeyler ve iki platform arasındaki gerçek farklar.
Mobil uygulama tasarımı deyince akla ilk gelen şey görünüm oluyor: hangi mavi, hangi yazı tipi, ikonlar dolu mu çizgi mi. Bunlar da işin parçası ama projenin kaderini belirleyen yer burası değil.
Kaderi belirleyen soru şu: kullanıcı uygulamayı açtığında ne yapmak istiyor ve ona kaç dokunuşta ulaşıyor?
Tasarım, ekran resmi değil ekran akışıdır
Bir uygulamanın tasarımını kâğıda dökmek demek, ekranların resmini çizmek değil, ekranlar arasındaki geçişleri kurmak demek. Kullanıcı ana ekranda. Sipariş vermek istiyor. Kaç adım? Ürünü bulamazsa ne oluyor? Adresi yoksa hangi ekran açılıyor? Ödeme yarıda kalırsa geri döndüğünde sepet duruyor mu?
Bu soruların cevabı yazılmadan çizilen ekranlar güzel görünür ama kodlamaya başlandığında dağılır. Yazılımcı ilk boşluğu bulduğunda kendi kararını verir, sonra siz görürsünüz ve beğenmezsiniz. İkinci tur başlar, bütçe bir kez daha konuşulur.
Önce en sıkıcı ekranı çizin
Herkes ana ekranı çizmeye bayılıyor. Oysa uygulamayı yaşatan ekranlar başka: boş durum ekranı, hata ekranı, yükleniyor ekranı, izin isteme ekranı.
Yeni kullanıcı uygulamayı açtığında listede hiçbir şey olmayacak. O ekran ne diyecek? "Kayıt bulunamadı" yazan gri bir satır mı, yoksa ne yapması gerektiğini söyleyen bir yönlendirme mi? İnternet gittiğinde ne görecek? Konum izni reddedilirse uygulama çalışmaya devam edecek mi?
Tecrübemizde uygulamaların terk edilme anlarının çoğu bu ekranlarda oluyor, parlak ana ekranda değil.
Tıklanabilir prototip şart
Statik ekran görüntüleri üzerinden onay vermeyin. Telefondan açıp gerçekten dokunabildiğiniz bir prototip isteyin. Bugün bu, kod yazmadan birkaç günde hazırlanabiliyor.
Farkı şurada görüyorsunuz: resimde makul duran bir menü, telefonda parmağınızla denediğinizde üst köşeye uzanmanız gerektiğini fark ettiriyor. Alt kısımdaki düğme, klavye açıldığında kayboluyor. Bunlar resimde görünmez.
Prototipi patrona, bir müşteriye ve uygulamayı hiç görmemiş birine deneterek onaylayın. Üçüncü kişi en değerli olan; çünkü sizin bildiğiniz şeyleri bilmiyor.
Android ve iOS aynı tasarımı istemez
İki platformu aynı görünüme zorlamak yaygın bir istek ve genelde iyi bitmiyor. Birkaç somut fark:
Android'de donanımsal ya da jest tabanlı bir geri hareketi vardır, kullanıcı onu kullanır. iOS'ta geri hareketi ekranın sol kenarından kaydırmaktır ve ekranın sol kenarına bir şey koyarsanız çakışır.
Tarih seçici, liste kaydırma hissi, paylaşım penceresi, bildirim izni isteme zamanı — hepsi platforma göre farklı davranır. Kullanıcı kendi telefonunda alıştığı davranışı bekler. Markanızı taşıyacak yer renk, tipografi ve içeriktir; sistem davranışı değil.
Tek tasarımla iki platform çıkarmak istiyorsanız bu mümkün, ama farkların bilinçli bir kararla bırakıldığı bir tasarım isteyin; "fark etmez, aynı olsun" diyen bir tasarım değil.
Tasarım ne kadara mal olur?
Tasarım genelde toplam bütçenin dörtte biri civarında bir yer tutuyor, ekran sayısına ve akışın karmaşıklığına göre değişiyor. Bunu ayrı bir kalem olarak görmek yerine şöyle düşünün: tasarımda harcanan bir gün, kodlamada üç gün tasarruf ettiriyor. Çünkü tartışma prototip üzerinde bitiyor, yazılmış kodun üzerinde değil.
Tasarımı ayrı bir firmadan alıp kodu başkasına verecekseniz, iki tarafı aynı masaya oturtun. Kod yazacak ekibin göremediği bir tasarım, çoğu zaman uygulanabilirliği düşünülmemiş bir tasarımdır.
Sık sorulanlar
Tasarımcı olmadan uygulama yaptırabilir miyim?
Yaptırabilirsiniz, iç kullanıma yönelik bir araçsa mantıklı bile olabilir. Hazır bileşen setleriyle derli toplu bir sonuç çıkar. Ama kullanıcıya, müşteriye açılacak bir uygulamada tasarımsız gitmek, ilk kurulum sonrası silinme oranını yükseltiyor. Ekran akışını yine de birinin kâğıda dökmesi gerekir; bunu tasarımcı yapmazsa yazılımcı yapar.
Hazır şablonla mobil uygulama tasarımı olur mu?
Şablon, başlangıç noktası olarak işe yarar; iskelet hazır gelir, siz içeriğe odaklanırsınız. Sorun, işiniz şablonun varsaydığı akıştan farklıysa başlıyor: şablonu zorlamak sıfırdan çizmekten uzun sürüyor. Basit ve standart bir akışınız varsa şablon kullanın, kendinize özgü bir süreciniz varsa kullanmayın.
Tasarım onayından sonra değişiklik yapılabilir mi?
Prototip aşamasındaki değişiklik neredeyse bedava, kodlanmış ekrandaki değişiklik pahalı. Bu yüzden sözleşmede "tasarım onayı" diye net bir an olmalı ve o andan sonraki değişikliklerin nasıl fiyatlanacağı yazılmalı. Belirsiz bırakılırsa iki taraf da huzursuz oluyor.
Tasarım dosyaları benim mi olacak?
Olmalı. Kaynak tasarım dosyalarının teslim edilmesini sözleşmeye yazdırın. Sadece görsel çıktılar teslim edilirse, ileride başka bir ekiple çalışmak istediğinizde her şeyi baştan çizdirmek zorunda kalırsınız. Bu, kaynak kodun teslimi kadar önemli ama çok daha sık atlanıyor.
Uygulamanın teknik tarafını mobil uygulama geliştirme yazısında, Android'e özel mağaza konularını Android uygulama yaptırmak yazısında anlattık. Fikrinizi konuşmak için bize yazın.
