Kullanılan, güvenilen ve gerektiğinde güncellenebilen bir araç.

Bazı soruların yanıtı kullanıcının kendi verisine bağlı. Hesaplayıcıyı, testi ya da yapılandırıcıyı açık bir mantıkla tasarlıyoruz. Hangi girdiyi neden istediğimiz, sonucu nasıl hesapladığımız ve aracın neyi bilemeyeceği görünür kalıyor. Sonuç anlaşılır, girdi az, veri kullanımı açık. Elinizde baştan sona yalnızca klavyeyle tamamlanabilen bir araç, dayanağı sağlam bir sonuç ve sayılar değiştiğinde neye bakacağını bilen bir bakım sorumlusu kalıyor.

Hesaplayıcı arayüzündeki kaydırıcıları değiştirirken sonuç kartını karşılaştıran kullanıcı

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Watsons
  • GAP
  • English Home
  • Joker
  • Axa Hayat Emeklilik
  • Elle
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • MediaMarkt
  • Decathlon
  • Trendyol
  • Hepsiburada
  • Sahibinden.com
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • DenizBank
  • Acıbadem Sağlık Grubu
  • Abdi İbrahim

Arayüzden önce soruyu ve mantığı netleştiriyoruz. Görsel tasarım belirsiz bir hesabı çekici göstermeye çalışmıyor, açıkça tanımlanmış bir kararı destekliyor.

  1. Asıl soruyu belirliyoruz

    Tasarım başlamadan önce aracın hangi kararı kolaylaştıracağını yazıyoruz. Kullanıcının sonuçtan sonra neyi anlayacağı ya da yapacağı açık değilse etkileşim biçimini seçmiyoruz. Ekipten biri, arayüz tasarlanmadan önce tek cümlelik soruyu onaylıyor.

    Aracın yanıtladığı soruyu, hedef kullanıcıyı ve beklenen sonraki adımı açıklayan tek cümle.

  2. Mantığı görünür biçimde kuruyoruz

    Formülleri, aralıkları ve uç durumları önce kâğıt üzerinde sınıyoruz. Her sonucun hangi girdiden doğduğunu izliyoruz. Sadece çalışan değil açıklanabilen bir model kuruyoruz. Formülü ve varsayımları bir kişi elle kontrol ediyor. Agent uç durumları tarayabiliyor ama matematiğin sorumluluğunu almıyor.

    Formülleri, varsayımları, aralıkları ve sıra dışı durumları içeren belgelenmiş karar modeli.

  3. Gerekli girdileri seçiyoruz

    Her alanın sonuca katkısını sorguluyoruz. Yanıt için gerekmeyen veriyi istemiyoruz. Girdinin amacını kullanıcıya anlatamıyorsak o alanı kaldırıyoruz. Aracın sahibi, sonuçta yeri olmayan her alanı kaldırıyor.

    Her alanın amacı, veri türü ve sonuçla ilişkisi belirtilmiş asgari girdi listesi.

  4. Tüm durumları yazıyoruz

    Yükleme, hata, boş ekran ve sıra dışı sonuçları birlikte tasarlıyoruz. Geçersiz girişte ne olacağını, kullanıcının nasıl düzelteceğini ve sonucun hangi sınırla sunulacağını yazıyoruz. Bir kişi, durum listesini tamamlanmış saymadan önce her hatayı ve uç durumu tek tek deniyor.

    Kullanıcının görebileceği her ekranı, mesajı ve kurtarma yolunu kapsayan içerik matrisi.

  5. Gerçek değerlerle deniyoruz

    Prototipi gerçekçi senaryolarla, sınır değerlerle ve beklenmedik girdilerle test ediyoruz. Akışın yalnızca klavyeyle tamamlandığını, hata mesajlarının anlaşıldığını ve sonucun formülle örtüştüğünü kontrol ediyoruz. Biri prototipi gerçek sayılarla ve yalnızca klavyeyle denemeden işi bitmiş saymıyor.

    Senaryoları, bulguları ve çözülen sorunları eklenmiş çalışan prototip.

  6. Bakım bilgisiyle teslim ediyoruz

    Formülü, varsayımları ve değişiklik olduğunda kontrol edilecek noktaları bakım sorumlusuna bırakıyoruz. Fiyat, aralık ya da kaynak veri değiştiğinde hangi testlerin tekrarlanacağını da belgeliyoruz. Devralan kişi formülü ve neyin yeniden kontrolü tetiklediğini anladığını teyit ettikten sonra aktarımı kapatıyoruz.

    Tamamlanmış araç, mantık açıklaması ve sorumlusu belirlenmiş bakım notu.

Çok sayıda senaryo denemek formülü onaylamaya yetmiyor

Agent'larla sıra dışı girdi birleşimlerini tarıyor, farklı sonuç aralıkları için ilk metinleri hazırlıyoruz. Böylece kırılan akışları daha erken görüyoruz. Formülün doğruluğu, varsayımları ve sonucunun sınırları uzman incelemesinde kalıyor. Para, sağlık ya da önemli bir karar söz konusu olduğunda bu sorumluluk daha da belirginleşiyor.

Araç görünür çıktı. Güveni sürdüren şey ise arkasındaki belgelenmiş mantık. Ekibiniz yalnızca arayüzü değil, sonucun nereden geldiğini ve hangi değişiklikte hangi testi tekrarlayacağını da teslim alıyor.

  • bir açılış sayfası taslağı

    Çalışan etkileşimli araç

    Gerçek girdiler ve uç durumlarla sınanmış hesaplayıcı, test veya yapılandırıcı.

  • kuralları işaretlenmiş bir stil kılavuzu

    Belgelenmiş karar mantığı

    Her sonucu üreten formül ya da kurallar, geliştirici olmayan birinin de izleyebileceği açıklıkta.

  • küçük bir eğilim çizgisi içeren ölçüm notu

    Bakım notu

    Fiyat, varsayım ya da aralık değiştiğinde hangi parçanın nasıl güncelleneceğini gösteren kısa rehber.

Şu olduğunda tamam sayarız: araç baştan sona yalnızca klavyeyle tamamlanabiliyorsa, alan etiketleri ve hata mesajları anlaşılıyorsa, sonuç belgelenmiş mantığa dayanıyorsa ve ekibiniz varsayımlar değiştiğinde nereyi güncelleyeceğini biliyorsa iş tamamlanmış sayılıyor.

Yanıt gerçekten kişiye göre değişiyorsa etkileşim anlamlı. Araç, kullanıcının kendi durumunu anlamasına yardım etmeli. Sadece dikkat çekmek için soru sormamalı. Herkes aynı sonuca ulaşıyorsa iyi bir sayfa yeterli.

Şu durumlarda iyi bir seçim

  • Hesaplayıcının yanıtı bütçe, ekip büyüklüğü veya kuruluma göre değişiyor, ama sabit bir sayfa bu girdilerin sonucunu açıkça gösteremiyor.
  • Satış ve destek görüşmelerinde aynı duruma özel soru tekrar tekrar geliyor, bu yüzden insanların cevabı kendi girdileriyle bulacağı bir araç gerekiyor.
  • Formül ile varsayımlar geliştirici olmayan biri tarafından incelenebiliyor, çünkü sonucu kara kutu gibi sunmak aracın güvenilirliğini zedeliyor.

Şu durumlarda başka bir çalışma daha doğru

  • Dürüst yanıt neredeyse herkes için aynıysa. Birkaç soru eklemek içeriği kendiliğinden yararlı bir araca dönüştürmüyor.
  • Araç hesap için gereksiz kişisel veri istiyor ve bu verinin nasıl kullanılacağı açıklanamıyorsa, önce girdi kapsamını ve veri kullanımını daraltmak gerekiyor.
  • Fiyatlar ya da varsayımlar zamanla değişiyor, ama mantığı güncelleyip gerçek girdilerle yeniden sınayacak adı belli bir sorumlu bulunmuyor.
  • Whimsical

    Geliştirme başlamadan önce aracın mantığındaki her dalı haritalıyor

  • Outgrow

    Onaylanmış mantıktan çalışan hesaplayıcıyı ya da testi bizzat kuruyor

  • Airtable

    Denenmiş her girdi kombinasyonunu kaydeden, durum durum test günlüğü

  • axe DevTools

    Klavye ve odak davranışını aracın gerçek etkileşimli durumları boyunca test ediyor

  • Notion

    Sorumluluk devri: mantık, test kaydı ve sahiplik tek bir yerde

Önce kullanıcının vermeye çalıştığı kararı dinliyoruz. Girdiler sonucu yeterince değiştiriyorsa aracın mantığını kurmaya geçiyoruz.
İçerik Pazarlaması uzmanıyla görüşün
İşe başlarken el sıkışan iki kişi

Aracın yazılımını da geliştiriyor musunuz?

Karar mantığını, içerik durumlarını ve geliştirici spesifikasyonunu hazırlıyoruz. Hafif araçları uygun teknolojiyle doğrudan geliştirmemiz de mümkün olabilir.

Hesaplama sağlık veya finansla ilgiliyse ne olur?

Riski baştan işaretliyoruz, formülü ve açıklamaları ek uzman incelemesine açıyoruz. Yüksek etkili sonuçlarda hata payını gizlemiyoruz.

Yayından sonra bakım kime ait?

Fiyatlar, aralıklar ve varsayımlar zamanla değişiyor. Bu yüzden müşteri tarafında bir sorumlu belirliyoruz, kontrol edeceği noktaları aktarıyoruz.

Kişisel veri toplamadan çalışabilir mi?

Çoğu durumda evet. Mantığın ihtiyaç duyduğu en küçük girdi setini seçiyoruz, pazarlama için gereksiz alan eklemiyoruz.

Erişilebilirliği nasıl ele alıyorsunuz?

Klavye akışını, alan etiketlerini ve hata durumlarını test ediyoruz. Araç fare olmadan tamamlanamıyorsa iş bitmiş sayılmıyor.