Bir ürün eskidiğinde ilk akla gelen şey görünüşünü değiştirmektir: yeni renkler, yeni yazı tipi, yuvarlatılmış köşeler. Bu iş hızlı biter ve sonucu hemen görünür. Ama kullanıcı aynı yerde takılmaya, aynı formu yarıda bırakmaya, aynı bilgiyi arayıp bulamamaya devam eder. Çünkü sorun çoğu zaman yüzeyde değildir.
Boyamak ile yenilemek arasındaki fark #
Boyamak, mevcut ekranların aynı yapıyla yeniden çizilmesidir. Menü aynı, adımlar aynı, içerik aynı kalır; yalnız görünüm değişir. Marka yenilendiğinde ya da görsel dil dağıldığında bu yeterli ve doğru bir iştir.
Yenilemek ise kullanıcının işini nasıl yaptığını değiştirir. Bir işlemin adım sayısı azalır, bilgi başka bir yerde ve başka bir sırayla sunulur, bazı ekranlar tamamen kalkar. Karar vermek için sorulacak soru şudur: kullanıcının şikâyeti görünüşle mi ilgili, yoksa işini bitirememekle mi? İkincisiyse boya çözüm olmaz.
Yenilemenin dört katmanı #
Kökten yenileme tek bir karar değil, dört katmanda verilen kararların toplamıdır. Katmanlar alttan üste doğru birbirini belirler.
- Amaç: ürün bugün kimin hangi işini çözüyor? Yıllar içinde eklenen işlevler asıl amacı gölgelemiş olabilir.
- Akış ve bilgi mimarisi: kullanıcı bir işi başlatıp bitirirken hangi yoldan geçiyor, bilgi hangi başlık altında duruyor?
- İçerik ve veri: ekranlardaki metinler, etiketler, tablolar ve durum mesajları kullanıcının dilinde mi?
- Arayüz ve teknik yapı: bileşenler, tasarım sistemi ve bunları taşıyan kod.
Boyama yalnız en üst katmanda çalışır. Alt katmanlardaki bir sorun, üst katmandaki hiçbir değişiklikle çözülmez. Menüsü organizasyon şemasına göre kurulmuş bir üründe en iyi görsel tasarım bile kullanıcının aradığını bulmasını kolaylaştırmaz.
Önce neyin korunacağına karar verin #
Kökten yenileme her şeyi atmak demek değildir. Mevcut kullanıcılar ürünü belirli bir düzenle öğrenmiştir ve o düzenin çalışan parçaları değerlidir. Kullanıcılar alıştıkları kalıpları bekler; bildik bir akışı sebepsiz değiştirmek, çözdüğünden fazla sorun çıkarabilir.
Bu yüzden değişimden önce bir envanter çıkarılır: hangi akışlar sorunsuz tamamlanıyor, hangi ekranlar sık kullanılıyor, kullanıcılar hangi alışkanlıkları edinmiş? Çalışan parçalar korunur, sorunlu olanlar yeniden kurulur. Bu envanterin nasıl çıkarıldığını yenilemeden önce neyi denetlediğimiz yazısında anlattık.
Mevcut işlevleri ayrıştırıp görevlere göre yeniden kurmak #
Türk Kızılay'ın kart tabanlı destek programı QRed için yaptığımız çalışma bu yaklaşımın bir örneği. Sistemin temel işlevleri çalışıyordu ama farklı ekiplerin ihtiyaçlarıyla şekillenen arayüz, dolambaçlı akışlara ve tutarsız ekranlara sahipti.
Önce mevcut işlevleri, kullanıcı rollerini ve birbirine bağlı operasyonları ayrıştırdık. Ardından modülleri görev odaklı bir bilgi mimarisi altında yeniden düzenledik ve web ile mobil deneyimi ortak bir tasarım sistemiyle birleştirdik. Değişen şey ekranların rengi değil, bilginin düzeni ve kullanıcının görevine ulaşma yoluydu.
Tek seferde mi, aşamalı mı? #
Büyük bir yenilemeyi tek bir yayın gününe bağlamak risklidir: mevcut kullanıcı bir sabah tanımadığı bir ürünle karşılaşır ve geri bildirim, düzeltmek için çok geç gelir. Aşamalı ilerlemek çoğu zaman daha güvenlidir.
- En kritik akıştan başlayın: en çok kullanılan ya da en çok terk edilen akış ilk adaydır.
- Yeni yapıyı eski yapının yanında bir süre çalıştırın; kullanıcıya geçiş için zaman verin.
- Her aşamada neyin değişmesini beklediğinizi yazın ve yayından sonra bakın.
- Tasarım sistemini ilk aşamada kurun ki sonraki ekranlar aynı dili izlesin.
Tek seferlik geçiş, yalnız eski yapının korunmasının yenisini engellediği durumlarda anlamlıdır. Örneğin veri modeli değişiyorsa iki yapıyı yan yana yaşatmak mümkün olmayabilir.
Tasarım ve yazılım kararı birlikte verilir #
Kökten yenilemede sık yapılan bir hata, tasarımı bitirip sonra teknik tarafa götürmektir. Bir akışın kısaltılması veri yapısına, bir ekranın birleştirilmesi yetki sistemine, bir aramanın hızlanması altyapıya bağlı olabilir. Bu sınırlar baştan bilinmezse tasarım ya uygulanamaz ya da yarım uygulanır.
Yenileme kararlarını bu yüzden tasarım ve yazılım tarafıyla aynı masada veriyoruz. Hangi değişikliğin yalnız arayüzde kalacağı, hangisinin altyapıya dokunacağı baştan ayrılır ve aşamalar buna göre sıralanır. Yayındaki ürünler için bu çalışma UI/UX tasarım hizmetimizin yenileme tarafını oluşturur. Sorunun nerede olduğu henüz net değilse başlangıç noktası Denetim ve Dönüşüm çalışmasıdır.
Ne zaman gerçekten her şeyi değiştirmek gerekir #
Bazen ürünün dayandığı varsayım değişmiştir: kullanıcı başka bir cihaza geçmiş, iş modeli dönmüş ya da yeni bir teknoloji aynı işi çok daha basit bir yoldan çözer hâle gelmiştir. Bu durumda mevcut yapıyı iyileştirmek yerine ürünü baştan düşünmek gerekir.
Bu karar nadiren ve kanıtla verilmelidir. "Rakip yeniledi" ya da "tasarım eskidi" tek başına gerekçe değildir. Gerekçe, kullanıcının işinin mevcut yapıyla artık çözülemediğini gösteren bulgulardır.
Kaynaklar #
- Jakob's Law, Laws of UX; kullanıcıların alıştıkları düzeni beklemesi
- Disruptive Innovation Theory, Christensen Institute; köklü değişimin hangi koşulda anlamlı olduğu
