Prototip, çözümün nasıl görünebileceğini ve bir görevin nasıl yapılacağını sınamak için yararlıdır. Fakat problem gerçekten önemli mi, doğru kişiyle mi konuşuyoruz, gerekli veri mevcut mu gibi soruların hepsini tek başına cevaplamaz. Bazen prototipten önce eksik olan şey ekran değil, problem kanıtıdır.
Bu rehber, tasarım çalışmasını geciktirmek için uzun bir araştırma zorunluluğu önermiyor. Amaç, prototipin hangi soruya cevap vereceğini netleştirmek ve daha temel bir belirsizliği güzel bir arayüzle örtmemektir.
Gerçek bir işin izini bulmak
Önce kullanıcının yapmak zorunda olduğu işi ve bu işin gerçekleştiği bağlamı tanımla. Son örnek, kullanılan belge, mevcut araç veya gözlenen adımlar soyut beğeniden daha güçlü başlangıç noktalarıdır.
Kişinin problem yaşadığını söylemesi önemlidir; yine de hangi sıklıkta, hangi sonuçla ve hangi geçici çözümle karşılaştığını öğren. “Böyle bir araç olsa güzel olur” ifadesiyle her hafta emek harcanan iş aynı kanıt düzeyinde değildir.
Birden fazla kaynaktan benzer örnek aramak yararlı olabilir. Ancak görüşme sayısını büyütmek tek başına doğruluk sağlamaz. Aynı dar çevreden gelen cevapların sınırını kaydet.
Kullanıcı, karar verici ve ödeme yapanı ayırmak
Özellikle işletmelere yönelik ürünlerde işi yapan kişiyle satın alma kararını veren kişi farklı olabilir. Kullanıcı için zaman kazandıran çözüm, yöneticinin veri veya güvenlik beklentisini karşılamıyorsa benimsenmeyebilir.
Bu rollerin hangi soruyu cevapladığını ayrı tut. Kullanıcı görev ayrıntısını, yönetici iş önceliğini, ilgili teknik veya operasyon sorumlusu entegrasyon sınırını açıklayabilir. Bir rolün onayı diğerinin ihtiyacını otomatik olarak doğrulamaz.
Prototip görüşmesinde kimin geri bildirim verdiğini yaz. Sonuçlar “müşteriler istedi” gibi tek bir gruba indirgenmemelidir.
Veri ve işleyiş uygunluğunu erkenden kontrol etmek
Önerilen çözüm hangi bilgiye ihtiyaç duyuyor? Bu bilgi gerçekten mevcut mu, yeterince güncel mi ve kullanımı yetkili mi? Arayüzde göstermek istediğin alanların kaynak sistemde aynı anlamla bulunup bulunmadığını araştır.
Örneğin sipariş gecikmesini açıklayan bir araç için yalnız son durum bilgisi yeterli olmayabilir; olay zamanları ve devir teslimler gerekebilir. Bu veri yoksa prototipte kusursuz bir zaman çizgisi göstermek temel yapılabilirlik sorununu saklar.
Eksik veri durumunu tasarıma dahil etmek gerekir. Bir ürünün güvenilirliği yalnız tam veriyle doğru görünmesinden değil, bilmediği şeyi anlaşılır biçimde belirtmesinden de gelir.
Mevcut çözümün neden yetmediğini anlamak
Kullanıcı zaten bir tablo, mesaj grubu veya başka araçla işi yapıyor olabilir. Yeni ürünün rekabeti yalnız benzer yazılımlar değildir; alışılmış çalışma düzeni de alternatiftir.
Mevcut yöntemin hangi kısmı gerçekten sorunlu? Hız, hata, görünürlük, koordinasyon veya bakım yükü olabilir. Yeni çözümün bu sorunu azaltırken yaratacağı öğrenme ve geçiş maliyetini de düşün.
Sadece daha modern görünmek, önemli bir işte araç değiştirmek için yeterli olmayabilir. Prototipin sınayacağı değer farkı somut bir görev sonucuna bağlanmalıdır.
Kanıt haritası hazırlamak
Kısa bir tabloyla bilinenleri, varsayımları ve test edilecek soruları ayır. Her satırda iddia, mevcut kanıt, güven sınırı ve sonraki en ucuz anlamlı test bulunabilir.
| İddia | Uygun erken kontrol |
|---|---|
| Problem düzenli yaşanıyor | Son gerçek örnekler ve iş kayıtları |
| Mevcut yöntem maliyetli | Görev gözlemi ve müdahale adımları |
| Gerekli veri kullanılabilir | Yetkili kaynakta örnek alan ve anlam kontrolü |
| Önerilen akış anlaşılır | Görev odaklı prototip denemesi |
| Sonuç işte değerli | Çıktının gerçek karar içinde kullanıldığı sınırlı pilot |
Bu kontrollerin her biri farklı iddiayı destekler. Prototipin anlaşılması ödeme isteğini, veri erişimi ise kullanım kolaylığını tek başına kanıtlamaz.
Prototipi doğru anda kullanmak
Problem ve temel koşullar yeterince anlaşılınca prototip belirsiz etkileşimi sınamak için hazırlanır. En gösterişli ekranları değil, yanlış anlaşılma ihtimali yüksek karar noktalarını seç. Eksik veri, hata ve geri dönüş yollarını dahil et.
Katılımcıya ne yapacağını adım adım söylemeden görev ver. Beğeni kadar nerede durduğunu, hangi kavramı yanlış yorumladığını ve çıktıyı nasıl kullanacağını gözle. Sonucu gözlem ve yorum olarak ayrı kaydet.
Bir prototipin reddedilmesi problemin olmadığı anlamına gelmeyebilir; seçilen çözüm uygun olmayabilir. Benzer biçimde beğenilmesi de ürünün hazır olduğunu göstermez. Keşif Atlası araştırma planı ve MerchNivo karar rehberi bu kanıt zincirini uygulamaya taşımak için okunabilir.