Appropriation: Kullanıcı Ürünü Beklemediğiniz Şekilde Kullandığında
Bir ürünü tasarlarken kullanıcının onunla ne yapacağını tahmin edersiniz. Sonra kullanıcı gelir, e-posta alanına telefon numarası yazar, etiket sistemini görev listesine çevirir, tabloyu takvim gibi kullanır. Buna appropriation deniyor. Genellikle ürünün ömrünü uzatıyor, ama bedava değil.
Tasarımcının öngörmediği kullanım
Appropriation, bir sistemin kendisine yüklenmemiş bir işi üstlenmesi. Excel'in yarım dünyada proje yönetim aracı olarak kullanılması bunun en bilinen hâli. Interaction Design Foundation konuyu bir kaza değil, hedeflenebilir bir tasarım özelliği olarak ele alıyor: sistem, kullanıcının kendi anlamını yükleyebileceği kadar gevşek olmalı.
Gevşeklik burada anahtar kelime. Her boşluk bir davet, ama her davet sonradan ödenecek bir hesap açıyor.
Esnekliğin faturası nereye kesiliyor
Serbest bir metin alanı açtığınız anda orada bir veri formatı doğar. Siz tanımlamazsınız, kullanıcı tanımlar. Bir iletişim alanına insanlar "0532 ... , pazartesiden sonra" yazmaya başladıysa artık ayrıştırılması gereken bir yapı var demektir, üstelik hiç dokümante edilmemiş bir yapı.
Alanı hemen kilitlemem. Önce ne yazıldığına bakarım, çünkü oraya yazılan şey çoğu zaman eksik bir özelliğin tarifidir. Fatura ise veriyi taşımak gerektiğinde çıkıyor: on bin kayıtlık bir tabloda serbest metni normalize etmek, o alanı en baştan iki parçaya bölmekten kat kat pahalı.
Aynı şey davranışlar için de geçerli. Kullanıcılar dokümante etmediğiniz bir yan etkiyi keşfedip üstüne iş kurarsa, o yan etki artık sizin sözleşmenizdir. Bir sonraki sürümde "zaten böyle çalışmaması gerekiyordu" demek destek kuyruğunu kısaltmıyor.
Konfigürasyon mu, eklenti mi
Peki kullanıcıya alanı nereden açmalı? İki yol var ve maliyetleri hiç benzemiyor.
Konfigürasyon, sınırları sizin çizdiğiniz bir seçim kümesi. Renk, sıralama, hangi alanların görüneceği. Ucuz, geri alınabilir, kimseye söz vermez. Eklenti ise bir arayüz sözleşmesidir. Yayınladığınız gün versiyonlamaya, kırıcı değişiklikleri duyurmaya ve eski sürümü bir süre daha ayakta tutmaya söz vermiş olursunuz.
Küçük ekipte eklenti API'si açmak, ürünün kendisinden fazla bakım işi çıkarabilir. Önce konfigürasyonu genişletin, kullanıcıların hangi sınırı zorladığını görün, API'yi ondan sonra o sınırın etrafına kurun.
Görünürlük ne kadar
Klasik tavsiye şu: kullanıcıya gerektiğinden fazla bilgi gösterin, sistemin iç durumunu açın, böylece insanlar onunla oynayacak yer bulur. Doğru tarafı var. Ya öbür tarafı? Gösterdiğiniz her iç durum, kullanıcının üstüne alışkanlık kurduğu bir sinyale dönüşüyor. Bir işlem sırasında sıra numarası gösteriyorsanız, birileri o numaraya bakarak iş planlıyor demektir; kuyruğu yeniden yazdığınızda sadece kodu değil, onların planını da bozarsınız.
Bu görünürlüğü kısmak için bir sebep değil. Sadece hangi göstergenin kalıcı olduğunu baştan bilmek gerekiyor. Kalıcı olacaksa açın, geçici bir hata ayıklama çıktısıysa kullanıcı arayüzünde bırakmayın.
Appropriation'ı fark etmenin en ucuz yolu
Anket değil, destek kayıtları. İnsanların bulduğu geçici çözümler, yazılmamış özellik taleplerinin en dürüst hâli. Birisi aynı işi yapmak için üç ekran arasında gidip geliyorsa, üçüncü ekranı hızlandırmak yerine o üç adımı tek işe çevirmeye bakın.
Toplulukla paylaşım da burada işe yarıyor. Kullanıcıların birbirine gösterdiği kullanım biçimleri, sizin hiç sormayı akıl etmediğiniz sorunun cevabı oluyor. Yeter ki paylaşılan şeyi bir sonraki sürümde sessizce kırmayın.
Kaynaklar