Fratres

Dijital Ürün ve Mühendislik

UI/UX

Kullanıcılarınızın ürününüzde nerede takıldığını doğrudan gözlemliyor, bulguları geliştiricilerinizin kodlayabileceği ekranlara ve tutarlı bir tasarım sistemine çeviriyoruz.

Problem

Ürünümüz şık görünüyor ama kullanıcılar basit işleri tamamlayamıyor ve destek ekibi hep aynı soruları cevaplıyor.

Elde kanıt olmayınca tasarım toplantıları zevk tartışmasına döner, en kıdemli kişinin görüşü karar olur. Kullanıcının o anda ne yapmaya çalıştığı masaya hiç gelmez.

Görsel sorun sanılan şeylerin önemli bir kısmı yapısaldır. Aradığını bulamayan kullanıcı, büyük ihtimalle şirket içi terimlerle yazılmış bir menüyle uğraşıyordur. Formu yarıda bırakıyorsa neden istendiğini anlamadığı bir alan vardır. Yeni renk paleti bunlara dokunmaz.

Ürün büyüdükçe tutarsızlık da büyür. Tasarım sistemi olmayan ekipler aynı kalıpları tekrar tekrar çizer, her yeni özellik daha uzun sürer.

Bunu yaşıyorsanız

  • Destek talepleri aynı birkaç ekranda toplanıyor.
  • Her demoda ürünü adım adım göstermek zorunda kalıyorsunuz.
  • Boş ve hata ekranları tasarlanmadığı için geliştiriciler kendi çözümünü üretiyor.
  • Aynı düğme ekrandan ekrana farklı davranıyor.

Nasıl çalışıyoruz

  1. Görev analizi

    İş açısından önemli görevleri listeliyor, sürtünme noktalarını analitik verilerden ve destek kayıtlarından çıkarıyoruz.

  2. Moderatörlü test

    Gerçek kullanıcılarınıza benzeyen kişilere görev veriyor, sesli düşünerek ilerlemelerini izliyoruz. Segment başına birkaç oturum tekrar eden engelleri ortaya çıkarır.

  3. Yapı ve akışlar

    Kart sıralama ve tree test ile menüyü doğruluyoruz. Akışlara olumsuz senaryoları da katıyoruz: doğrulama hataları, boş ekranlar, zaman aşımları.

  4. Tasarım sistemi

    Renk, tipografi ve boşluk kararları design token'a dönüşür, bileşenler tüm durumlarıyla Figma'da belgelenip koda eşlenir. WCAG 2.2 AA kriterlerini, uzun Türkçe metinleri ve i/İ dönüşümlerini de sınıyoruz.

Ne teslim ederiz

  • Görev haritası ve öncelikli sorun listesi
  • Kullanılabilirlik testi raporu
  • Bilgi mimarisi ve kullanıcı akışları
  • Tıklanabilir prototip
  • Design token seti ve bileşen kütüphanesi
  • Geliştirici devir notları

Nasıl ölçeriz

  • Görev tamamlama oranı: tasarımın işini yapıp yapmadığının en yalın testidir.
  • Ekran başına destek talebi: tasarım sorununu operasyon maliyetine bağlar.
  • Tasarım sisteminin kodda kullanımı: tutarlılığın korunup korunmadığını izler.

Çok şubeli bir kliniğin randevu akışı

Örnek senaryo: Çok şubeli bir diş kliniğinde hastalar saatleri görmeden önce doktor seçmek zorunda, oysa çoğu kişi en yakın şubedeki en erken randevuyu arıyor. Test oturumları bu uyumsuzluğu gösterir. Akış şube ve tarihle başlayacak biçimde yeniden kurulur, doktor seçimi isteğe bağlı olur.

Sık sorulanlar

Kaç kullanıcıyla test yapmamız gerekir?

Sorun bulmak için segment başına birkaç kişi genellikle yeter, çünkü aynı engeller hızla tekrar eder. Bir sürümün diğerinden iyi olduğunu kanıtlamak ise daha geniş örneklem veya A/B testi ister.

Her şeyi baştan mı tasarlamamız gerekiyor?

Nadiren. Size en pahalıya mal olan akışlardan başlıyor, tasarım sistemini mevcut ekranlara kademeli olarak sokuyoruz. Böylece ürünü yeniden yazma riskine girmeden tutarlılık sağlanır.

Tasarımları kendi geliştiricilerimiz kodlayabilir mi?

Evet. Bileşenleri, token'ları ve davranış notlarını geliştiricilerinizle birlikte gözden geçiriyoruz. Gerçek veri arayüze girince küçük kararlar mutlaka çıkar, bu yüzden geliştirme sırasında da ulaşılabilir kalıyoruz.

Birlikte çalışmadan önce, birlikte düşünelim.

Görüşme talepleri kurucu tarafından yanıtlanır.