Kullanıcı testi, tasarım metodolojisinin temel bir parçası olarak her teorik çerçevede, her eğitim programında ve her tasarım manifestosunda yer alıyor. Ama gerçek proje koşullarında tasarım kullanıcı testi eksikliği sıkça gündeme geliyor: test yapılmıyor, kısaltılıyor ya da yalnızca onay alma ritüeline dönüşüyor. Bu neden böyle? Zaman ve bütçe baskısı en yaygın gerekçe. Bir proje takviminde kullanıcı araştırması ve testi için gerçek bir alan açılmadığında, süreç çoğunlukla kısaltılıyor. Hızlı bir pilot çalışma ya da dahili ekiple yapılan kısa bir değerlendirme "test yapıldı" kutusu dolduruyor; ama gerçek kullanıcı davranışı gözlemlenmemiş oluyor. Tasarım kullanıcı testi eksikliğinin bir başka nedeni, testin ne zaman yapıldığıdır. Pek çok projede test, tasarımın büyük bölümü tamamlandıktan sonra gerçekleşiyor. Bu aşamada bulunan sorunları düzeltmek, maliyet ve zaman açısından çok daha ağır. Erken aşamada yapılan testin değeri çok daha büyük; ama bu değer yeterince içselleştirilmemiş. Bir üçüncü boyut, testin nasıl algılandığıyla ilgili. Bazı organizasyonlarda kullanıcı testi, tasarımcının kendi kararına duyulan güvensizliğin işareti olarak görülüyor. "Bu kadar tasarım deneyimimiz varken neden test yapıyoruz?" sorusu, kullanıcı merkezli düşünceyle çelişen bir öz-güven refleksi olarak karşımıza çıkıyor. Tasarım kullanıcı testi eksikliğinin maliyeti çoğunlukla lansman sonrasında ortaya çıkıyor. Kullanıcıların anlayamadığı bir akış, terk edilen bir sepet, bulunamayan bir özellik, bunlar test edilseydi erken tespit edilebilecek sorunlar. Bu noktada düzeltme maliyeti, başta yapılacak test maliyetinin çok üstünde. Kullanıcı testini projelere gerçekten entegre etmek için takvim ve bütçede bu adımı açıkça yer almak gerekiyor; isteğe bağlı bir ekstra olarak değil, tasarım sürecinin ayrılmaz bir parçası olarak.