Sadık Kullanıcılara Zarar Vermeden Yeni Özellikler Nasıl Sunulur?

“Çevik olun; erken serbest bırakmak; sık sık serbest bırakın.” Tatbikatı biliyoruz. Ancak özellikleri sık sık kullanıma sunmaya devam etmek stratejik olarak akıllıca mı? Özellikle oluşturduğunuz bir ürün belirli bir boyuta ulaştığında, muhtemelen her yeni küçük sürümde uygulamanızın bütünlüğünü riske atmak istemezsiniz.

Ürününüzün başına gelebilecek en kötü şey, sadık kullanıcıların, bu küçük özelliği yıllar boyunca sürekli olarak kullanan müşterilerin bir anda onu aynı uygun şekilde kullanamamasıdır. Değişiklik, kullanıcıları daha fazla güçlendirebilir, ancak deneyim daha az anlaşılır hale gelir. Hayal kırıklığı ve endişe sosyal medyaya hızla ve aniden giriyor ve müşteri desteğinin anlamlı ve zamanında yanıt verme baskısı her dakika artıyor. Tabii ki, yalnızca sadık kullanıcılara gerçekten zarar verdiklerini anlamak için yeni özellikleri kullanıma sunmak istemiyoruz.

SmashingMag'de Daha Fazla Okuma : Bağlantı

• Özellikleri İki Kat Daha Hızlı Yayınlamaya Nasıl Başladık?
• Web Sitesi Başlatma Kontrol Listesi – Canlı Yayına Başlamadan Önce 15 Temel Kontrol
• Mobil Cihazlar İçin Web Tasarımına Kullanıcı Merkezli Bir Yaklaşım
• Herhangi Bir Şey Nasıl Başlatılır

Ürünlerimizin yeni sürümlerini kullanıma sunarken daha stratejik davranarak bunu önleyebiliriz. Bu makalede, ürün tasarımcıları ve ön uç mühendisleri için bir özelliği tüm kullanıcı tabanına yayınlamadan önce kapsamlı bir şekilde test edip dağıtacakları bir stratejiyi ve UX sorunlarının yol boyunca sürünerek nasıl önleneceğini inceleyeceğiz.

Gerçek bir test stratejisine dalmadan önce, bir adım geriye gidelim ve yeni bir özelliğin nasıl tasarlandığına, oluşturulduğuna ve nihayetinde dağıtıldığına dair yaygın yanlış anlamaları inceleyelim.

Yeni Özellik Yanılgıları

Mevcut bir ürün için yeni bir özellik tasarlandığında, ana odak noktası genellikle bunun mevcut arayüze tam olarak nasıl entegre edilmesi gerektiğidir. Tutarlılığı sağlamak için, biz tasarımcılar genellikle mevcut kalıplara bakarız ve yeni özelliğin kullanıcı arayüzünde iyi oturmasını sağlamak için yerleşik tasarım dilini uygularız. Bununla birlikte, sorunlar genellikle bileşenlerin görsel olarak birlikte çalışmadığı için değil , beklenmedik şekillerde bir araya getirildiklerinde kafa karıştırıcı veya belirsiz oldukları için ortaya çıkar .

Belki de arayüzün kopyası web sitesinin ilgili ancak uzak alanlarında belirsizdir veya iki özelliğin aynı anda aktif olarak kullanılmasının sonucu teknik açıdan anlamlıdır ancak kullanıcı beklentilerini karşılamaz veya önemli performans etkilerine sahiptir ve UX'e zarar verir. .

Aslında, tasarımda, tam olarak tahmin edilmesi ve gözden geçirilmesi çok zor olan bu sayısız kombinasyondur. Zaten tasarım sürecindeyken soruna yaklaşmanın bir yolu, aykırı değerleri dikkate almaktır - işlerin ters gitme olasılığının daha yüksek olduğu durumları kullanın. Kullanıcının adı çok uzunsa bir kullanıcı profili nasıl görünür? Bir düzine gelen kutusu etiketi kullanıldığında yanıtlanmamış e-postaların genel görünümü hala açık mı? Yeni kaydolan ve gelen kutularında yalnızca birkaç e-postası olan kullanıcılar için yeni bir filtre anlamlı olur mu?

Aykırı Değerler Tasarlama: Kullanıcı Arayüzü Yığını

Aykırı değerleri belirledikten sonra tam olarak nasıl tasarlayabiliriz? İyi bir strateji, kullanıcı arayüzünün farklı durumlarını incelemektir. Scott Hurff tarafından ortaya atılan bir fikir olan "kullanıcı arayüzü yığını" çok yönlü ve karmaşıktır ve arayüzlerimizi tasarlarken Photoshop, Sketch veya HTML ve CSS'de piksel mükemmel bir maket oluşturmak genellikle yeterli değildir - dikkate almalıyız çeşitli uç durumlar ve durumlar: boş durum, yükleme durumu, kısmi durum, hata durumu ve ideal durum. Bunlar sandığımız kadar basit değil.

Boş durumun boş olması gerekmez - düzenli ziyaretçilere daha iyi bir çevrimdışı deneyim sağlamak için hizmet çalışanlarını kullanıyor olabiliriz. Kısmi durumun bozulması gerekmez - aşamalı iyileştirme yoluyla bozuk görüntüler ve bozuk JavaScript ile deneyimi iyileştirebiliriz.

İdeal durum, özel kullanıcı tercihleri ​​ve kullanıcının tarayıcı seçimi nedeniyle "mükemmel sonuç" modellerimizden önemli ölçüde farklı olabilir; örneğin bir tarayıcının yapılandırması nedeniyle bazı içerik ve web yazı tipleri görüntülenmeyebilir.

Dolayısıyla, manzara, her zaman olduğu gibi, karmaşık, dolambaçlı ve öngörülemez ve işlerin yanlış gitme riskini göz ardı edemeyiz, ancak bu, riski etkin bir şekilde en aza indiremeyeceğimiz anlamına gelmez. Aykırı değerleri ve tüm kullanıcı arabirimi yığınını erken keşfederek, erken tasarım aşamasında yaygın UX sorunlarını önleyebiliriz. Yine de teknik açıdan daha kolay olmuyor.

Dağıtımda Kelebek Etkisi

Küçük değişiklikler bile zincirleme reaksiyonlara yol açarak kesinlikle alakasız gibi görünen alanlarda ve durumlarda hatalara yol açma eğilimindedir. Bunun ana nedeni, kullanıcı deneyimini etkileyen ancak kontrolümüz dışında olan çok sayıda değişkendir. Tarayıcılarla olan yollarımızı biliyoruz, ancak bu, bir kullanıcının yorulmadan ve kapsamlı bir şekilde oluşturduğumuz web sitesini görmeyi seçtiği bağlam hakkında daha fazla bilgi sahibi olduğumuz anlamına gelmiyor.

Şimdi, bir düğmedeki dolgu veya kademeli olarak geliştirilmiş bir metin alanı gibi küçük değişiklikler büyük bir sorun gibi görünmese de, bu parlak küçük değişikliklerin veya özelliklerin büyük ölçekte etkisini hafife alma eğilimindeyiz. Bir tasarım veya geliştirme kararı verdiğimiz her seferinde, bu değişikliğin inşa ettiğimiz karmaşık sistemde bir miktar etkisi olur, çünkü inşa ettiğimiz bileşenler asla tek başına var olmaz.

Gerçek şu ki, asla sadece bir düğme oluşturmayız veya asla yeni bir JavaScript işlevi yazmayız - düğmeler ve işlevler bir bileşen veya kitaplık ailesine aittir ve hepsi belirli bir ayar içinde çalışır ve kaçınılmaz olarak diğerleriyle bağlantılıdır. sistemin parçaları özelliklerine veya kapsamlarına göre veya adlarına veya ekibin yazılı olmayan kurallarına göre.

Bu "sessiz", neredeyse hiç fark edilmeyen bağlantılar, özelliklerin kullanıma sunulmasının zor olmasının ve bir değişikliğin geniş kapsamlı sonuçlarını tahmin etmenin genellikle keskin bir görüş egzersizi olmasının nedenidir. Bu nedenle, ister CSS ister JavaScript'te olsun, gereksiz bağımlılıklardan olabildiğince kaçınmak iyi bir fikirdir - özellikle tam olarak anlamadığınız bir kitaplığa güveniyorsanız, bakım veya hata ayıklama konusunda size yardımcı olmazlar. .

Neyse ki, bir değişikliğin etkisini daha iyi anlamak için tarayıcının geliştirici araçları gibi kaynakları kullanabiliriz. Bir seçicinin erişimini veya bir JavaScript işlevinin erişimini ölçebiliriz ve bazen değişikliğin kapsamını mümkün olduğunca yerel ve minimum düzeyde tutmak için geliştirme sırasında ona geri dönmeye devam etmek iyi bir fikir olabilir.

Bu yararlıdır, ancak aynı zamanda hikayenin sadece bir kısmıdır. Arayüzle ilgili kendi deneyimlerimize ve kendi alışkanlıklarımıza dayanarak bilinçli ve bilinçsiz olarak varsayımlar yaparız - genellikle varsayımların kullanıcıdan kullanıcıya önemli ölçüde değişebileceğini (ve dolayısıyla değişeceğini ) unuturuz. Çoğu uygulamanın yalnızca bir arabirimi vardır, ancak bu arabirim veya yapılandırmaları, kullanıcının ayarlarına ve tercihlerine bağlı olarak değişen görünümlerle birlikte düzinelerce duruma sahip olabilir.

Özelleştirilebilir kartlara sahip panolar (analiz yazılımı), "kompakt", "rahat" ve "ayrıntılı" görünümlere sahip posta istemcileri (Gmail), oturum açmış müşteriler ve misafirler için değişen bir rezervasyon arayüzü, bir okuma deneyimi düşünün. bir reklam engelleyici veya agresif bir antivirüs filtresi kullanan kişiler için. Kelebek etkisinin sadece kod tabanından daha fazlası üzerinde etkisi vardır; tüm bu dış etkenler de etkilidir ve bunlara karşı test yapmak - birim testleri veya genel olarak KG'den farklı olarak - çok zordur çünkü çoğu zaman neye karşı test yapacağımızı bile bilmiyoruz.

Özellik Doğrulama ve Yerel Maksimum

Hangi değişikliklerin yapılması gerektiğini belirlemek için tanılama ve ölçümleri kullanabiliriz, ancak yalnızca verileri izleyerek, "yerel maksimum" dediğimiz, yeterince iyi bir tasarıma sahip bir arayüz durumu olan, ancak inovasyondan tamamen yoksundur çünkü her zaman öngörülebilir, mantıklı yinelemeleri takip eder. Bir proje üzerinde çalışırken ve verileri keşfederken, özellikleri aşağıdaki dört bölümde gruplandırma eğilimindeyiz:

• Bozuk özellikler. . Bozuk veya verimsiz görünen özellikler — açıkçası, bunları düzeltmemiz gerekiyor;
• Kullanılmayan özellikler. . Amaçlandığı gibi çalışan, ancak nadiren kullanılan özellikler — genellikle bunların kaldırılması gerektiğinin veya büyük ölçüde yeniliğe ihtiyaç duyulduğunun bir işareti;
• Beklenmeyen kullanım özellikleri. . Yaratıcılarının başlangıçta tasavvur ettiklerinden son derece farklı bir şekilde kullanılan özellikler — yavaş, sürekli iyileştirme için iyi bir aday;
• İş gücü özellikleri. . Yoğun olarak kullanılan ve planlandığı gibi çalışıyor gibi görünen özellikler — bu durumda kendimize, hem yavaş yinelemeli süreci hem de tamamen farklı yenilikçi kavramları paralel olarak keşfederek UX'lerini daha da geliştirmenin bir yolu olup olmadığını soruyoruz.

İlk iki grup, bir arayüzü işlevsel ve kullanılabilir tutmak için kritik öneme sahipken, son ikisi kullanıcıları meşgul etmek ve memnun etmek için kritik öneme sahiptir. İdeal olarak, her iki hedefe de aynı anda ulaşmak isteriz, ancak zaman, bütçe ve ekip kısıtlamalarının üstünlüğü vardır.

Yine de, yeni bir yineleme veya yeni bir fikir seçildiğinde, hemen yeni özelliği tasarlamaya veya oluşturmaya başlamak cazip gelebilir. Ancak bir özelliğin mevcut bir arayüze nasıl uyacağını düşünmeden önce, hızlı bir prototip ve kullanıcı araştırması ile önce fikri doğrulamak iyi bir stratejidir. Bunu başarmanın yaygın bir yolu, Google Ventures'ın tasarım sprint'i gibi hızlı yinelemeli bir süreç kullanmaktır. Birkaç gün içinde yineleyerek, yeni özelliğin nasıl uygulanması gerektiğini ve/veya başlangıçta hayal ettiğiniz şekilde yararlı olup olmadığını belirleyebilirsiniz.

Tasarım sprintleri ile fikri, kullanılabilirlik araştırmalarına erkenden sunarız. Google Ventures'ın metodolojisinde, bir tasarımı günde beş kullanıcıyla test edersiniz; daha sonra, yeni tasarımı yineler ve başka bir test turundan geçersiniz. Aynı kullanıcıların hepsinin dahil olmasının nedeni, o gün her kullanıcıyla farklı bir tasarımı test ederseniz, hangi öğelerin değişmesi gerektiğini bilmek için geçerli bir veriye sahip olmayacak olmanızdır. Bir tasarım yinelemesini doğrulamak için birkaç kullanıcıya ihtiyacınız var.

Sprintlerimizde biraz farklı bir model uyguluyoruz. Yeni bir özellik üzerinde çalışmaya başladığımızda, erken bir ilk prototip oluşturulduktan sonra tasarımcıları, geliştiricileri ve UX ekibini aynı odada bir araya getiriyor, gerçek kullanıcıları test etmeye ve ardından sıkı bir programda yinelemeye davet ediyoruz. İlk gün, ilk testçiler (iki ila üç kişi) sabah 9:00'da 30 dakikalık bir görüşme için, ikinci grup saat 11:00'de, bir sonraki görüşme saat 14:00'te ve sonuncusu için planlanabilir. biri 4:00 civarında. Kullanıcı görüşmeleri arasında, bir noktada uygun bir şeye sahip olana kadar tasarımı ve prototipi gerçekten yinelediğimiz zaman "açık zaman pencerelerimiz" var.

Bunun nedeni, başlangıçta tamamen farklı, hatta bazen zıt yönleri hızla keşfetmek istememizdir; farklı arayüzler hakkında geri bildirim topladığımızda, "mutlak maksimum" arayüz gibi hissettiren şeye yakınlaşabiliriz. Bu şekilde çok çeşitli tasarım yinelemeleri hakkında çok çeşitli geri bildirimleri daha hızlı alabiliriz. Geri bildirim çoğunlukla üç faktöre dayanır: kullanıcı tıklamalarını kaydeden ısı haritaları, kullanıcıların bir görevi tamamlamak için ihtiyaç duyduğu süre ve deneyimin onlar için ne kadar keyifli olduğu. Haftanın ilerleyen saatlerinde, Google'ın yaptığı gibi, daha fazla sayıda kullanıcıyla tutarlı bir şekilde çalışmaya devam ederek, ilerledikçe yeni tasarımı kalıcı olarak doğrularız.

Şimdiye kadar çok iyi, ancak bazen yenilikçi görünen yeni bir özellik mevcut bir özellikle çarpışıyor ve her ikisinin de aynı arayüzde olması tasarımı karmaşıklaştırıyor. Bu durumda, seçeneklerden birinin diğerinin uzantısı olarak kabul edilip edilemeyeceği araştırılır. Olabilirse, işlevselliğini ve tasarımını yineleyerek başlıyoruz. İşte o zaman radikal yeniden tasarımı veya kademeli değişimi seçmemiz gerekir. İkincisi daha az risklidir ve kullanıcılar için tanıdık bir etkileşim kalıbını korurken, ilki kritik değişikliklerin başka türlü başarılmasının imkansız olduğu veya artımlı değişikliklerden elde edilen kazanımların çok sığ olacağı durumlarda gereklidir.

Her iki durumda da, o üründeki tek bir özelliğin değerine odaklanmak yerine, ürünün tüm kullanıcı deneyimine odaklanmak çok önemlidir. Özelliği seçtikten ve ilk prototipi tasarlayıp oluşturduktan sonra, test etme zamanı.

Testin Sekiz Seviyesi

Peki, o zaman, hataların ve başarısızlıkların gerçek bir canlı ortama sızmasını nasıl etkili bir şekilde önleyebiliriz? Bir özellik dağıtılmadan önce kaç tane kontrol, inceleme ve test yapıyoruz? Ve bu testleri hangi sırayla yapıyoruz? Başka bir deyişle, özellikleri kullanıma sunmanın nihai stratejisi nasıl olurdu?

Özelliklerin kullanıma sunulması için daha iyi stratejilerden biri, Rusya'daki büyük bir e-posta sağlayıcısı olan Mail.ru'nun geliştirme başkanı Andrew Sumin tarafından önerildi. Strateji her proje için geçerli olmayabilir, ancak orta ve büyük ölçekli ürünleri binlerce müşteriye sunan şirketler için makul ve kapsamlı bir yaklaşımdır.

Stratejiye ayrıntılı olarak bakalım ve Mail.ru'nun ürün geliştirme sürecini kapsayan bir özelliğin kullanıma sunulmasının sekiz adımını ele alalım:

1. geliştiricilerle test edin,
2. kontrollü bir ortamda gerçek kullanıcılarla test edin,
3. şirket çapındaki kullanıcılarla test edin,
4. beta test kullanıcıları ile test edin,
5. manuel olarak kaydolan kullanıcılarla test edin,
6. bölünmüş test ve kontrol tutma,
7. yavaş ve kademeli olarak bırakın,
8. sonrasını ölçün.

Mail.ru'nun durumunda, mesajı oluşturan şey ne olursa olsun (tabii ki) bozulmadan kalmanın en önemli özelliği. Bu, arayüzün en çok kullanılan parçasıdır ve saniyeler boyunca kullanılamamasına veya hatalı çalışmasına izin vermek kesinlikle söz konusu olmayacaktır. Peki, bir metin alanının işlevselliğini, belki birkaç akıllı otomatik tamamlama işlevi, bir sayaç veya bir yan önizleme ekleyerek genişletmek istersek ne olur?

1. Geliştiricilerle Test Edin

Geliştirmede ne kadar zaman geçerse, bir sorunu çözmek o kadar pahalı hale gelir. Yine, ürün geliştirmede tüm kararların ne kadar bağlantılı olduğunu düşünün; ürün ne kadar rafine olursa, o kadar çok kararın geri alınması gerekir, bu da zaman ve kaynaklara mal olur. Bu nedenle, sorunları hem iş perspektifinden hem de tasarım ve geliştirme perspektifinden erkenden belirlemek ve çözmek.

Yine de bir fikirde hata ayıklayamazsınız, bu nedenle ilk testler üretim sırasında, ilk prototiplerde yapılmalıdır. O halde Mail.ru'daki ilk testçiler, kodu gerçekten yazan geliştiricilerdir. Şirket, çalışanlarını ürünü kurum içi iletişim (ve hatta özel iletişim) için kullanmaya teşvik eder; bu nedenle, geliştiriciler ürünün sıkı kullanıcıları olarak kabul edilebilir.

İlk adım oldukça açıktır: Özelliği tasarlayın ve oluşturun ve ardından yerel olarak test edin, gözden geçirin ve hazırlama sunucusunda kullanıma alın. Kapsamlı araçlar ve özelliği ve arabirimi çökertmeye çalışan görev yürütücüleri ile QA testinin devreye girdiği yer burasıdır ve potansiyel olarak Gremlins.js gibi maymun testi araçlarıyla otomatikleştirilmiştir.

Sonuçlar izlenir ve ardından özelliğin bir sonraki yinelemesi için geri besleme döngüsüne geri beslenir. Bir noktada, geliştiriciler yapıdan oldukça emin hissedecekler: değişiklik beklendiği gibi çalışıyor ve gereksinimler karşılandı. İşte o zaman gerçek kullanıcı testi devreye girer.

2. Kontrollü Bir Ortamda Gerçek Kullanıcılarla Test Edin

İlk çalışan prototip bittiğinde, özellik gerçek kullanıcılarla yapılan görüşmelerde test ediliyor. Müşteriler görevleri tamamlamaya davet edilir ve bunu yaparken UX ekibi çıkmazları ve ortaya çıkan sorunları izler ve bunları yerinde ele alır.

Ancak, yalnızca yeni özellik test edilmekle kalmıyor; Kullanılabilirlik testinin amacı, yeni özelliğin arayüzün kritik bileşenlerini etkilememesini sağlamaktır; bu nedenle, kullanıcılar bir mesaj oluşturma ve gelen kutularındaki e-postaları açma, yanıtlama ve e-postalara göz atma gibi rutin görevleri tamamlarlar. Hem yeni özellik hem de eski özellikler iyi anlaşılırsa süreç devam edebilir.

3. Şirket Genelindeki Kullanıcılarla Test Edin

Açıkçası, kullanılabilirlik testinden gelen geri bildirim, geliştiricilerin değişiklikleri uygulamaya koymasını ister, bu da daha sonra kullanılabilirlik testçilerine geri bildirimde bulunur, sonuç daha geniş bir kitle için değer taşıyor gibi görünene kadar ileri geri gider. Bir sonraki adım, özelliğin şirket içinde öne çıkarılmasıdır: Tüm iş arkadaşlarını özelliği kontrol etmeye ve bir izleyicide raporlar, hatalar ve öneriler sunmaya teşvik eden şirket çapında bir e-posta gönderilir.

Test ile, şirket içindeki "uzak" departmanlardaki kullanıcılar ile vahşi kullanıcılar arasında özellikle büyük bir fark yoktur. Dahili kullanıcılar bile hangi değişiklikleri bekleyeceklerini bilmiyorlar veya bir özelliğin tam olarak ne yaptığını veya nasıl çalışması veya nasıl görünmesi gerektiğini bilmiyorlar. Tek temel fark, iş arkadaşlarınızdan hızlı bir şekilde geri bildirim göndermelerinin veya yorum bırakmalarının istenebilmesidir. O zaman oylama formları tanıtıldı. Test kullanıcıları yalnızca özellik ile oynamakla kalmaz, aynı zamanda bir yorum ekleyebilir ve onu olumlu veya olumsuz yönde oylayabilir. Oylama, ürün stratejisi ve iş gereksinimlerine göre değerlendirilmelidir, ancak kullanıcılar bir özelliği açıkça yararsız veya yararlı bulursa, bu, geri bildirim toplamanın ve ürünün beklendiği gibi çalışıp çalışmadığını test etmenin basit ve etkili bir yoludur.

4. Beta Test Cihazlarıyla Test Edin

Bir özellik şirket içinde teknik kontrolden, kullanılabilirlik kontrolünden ve incelemeden geçtiyse, bir sonraki mantıklı adım onu ​​hedef kitlenin bazı kesimlerine tanıtmaktır. Bununla birlikte, ekip, rastgele bir kullanıcı segmentine sunmak yerine, beta test kullanıcıları - testlere katılmayı ve deneysel özellikler için geri bildirim göndermeyi seçen kullanıcılar - arasında incelenmek üzere bir özellik gönderir. Bir özelliği olumsuz oylayabilir veya yükseltebilir, ayrıca hataları bildirebilir ve kod parçalarını işleyebilirler.

Ancak uygun beta test cihazlarını nasıl seçersiniz? Eh, test kullanıcılarını arayüzü kırmaya teşvik etmek istiyorsanız, teknik becerilere sahip gelişmiş sadık kullanıcılara odaklanabilirsiniz - gerekirse bir hata hakkında teknik ayrıntı sağlayabilecek kullanıcılar ve mevcut arayüzü yeterince iyi bilen kullanıcılar. diğer kullanıcıların yaşayabileceği sorunları tahmin edebilir.

Ancak, bir kullanıcının beta test kullanıcısı olacak kadar gelişmiş olup olmadığını belirlemek için ölçütlere ihtiyacınız vardır. Bir e-posta istemcisi söz konusu olduğunda, Chrome veya Firefox kullanan (yani varsayılan tarayıcılarını nasıl değiştireceklerini bilen), gelen kutusunda üçten fazla klasör oluşturmuş ve aynı zamanda mobil uygulamayı da yükleyen biri olabilir.

5. Manuel Olarak Kaydolan Kullanıcılarla Test Edin

Bu noktaya kadar testler, yönetilebilir sayıda kullanıcı, yapılandırma ve test raporu içeriyordu. Yine de, işletim sistemi, tarayıcı, eklentiler, ağ ayarları, antivirüs yazılımı ve yerel olarak kurulmuş diğer uygulamalar dahil olmak üzere, vahşi doğada bulunan kullanıcı, sistem ve konfigürasyon çeşitliliği, ölçek açısından biraz daha göz korkutucu olabilir.

Mail.ru'nun durumunda, bir sonraki adım, özelliği canlı bir arayüzde, bir bayrağın arkasında sunmak ve bu daha geniş aktif kullanıcı segmentine bir e-posta göndererek yeni özelliği sunmak ve onları kendi sistemlerinde etkinleştirmeye davet etmektir. genellikle parlak bir "Güncelle" düğmesi ile arayüzde kendi Özelliğin gerçek kullanıcılar için değerini ölçmek için, ekip yine bir oylama sistemi kullanıyor ve burada ve orada birkaç istemle, temel olarak kullanıcılara özelliği yararlı veya yararlı bulup bulmadıklarını soruyor. Bu seviye ile önceki seviye arasındaki farkın, manuel katılımın çok daha geniş bir kitleyi içermesi olduğuna dikkat edin - çoğu beta testçilerinin aksine teknik değildir.

Yani zamanlama ve koordinasyon önemlidir . Aktif kullanıcılara e-posta göndermek için muhtemelen rastgele bir gün seçmezsiniz, çünkü müşteri destek ekibinin ve geliştiricilerin hata raporları akışı başladığında hazır olmasını istersiniz. Bu nedenle e-posta şu saatte gönderilir. tüm (veya çoğu) geliştiricinin müsait olduğu ve destek ekibinin bilgilendirildiği ve Skype veya Slack aracılığıyla geliştiricilerle aktif olarak bağlantı kurduğu haftanın başında. Daha küçük bir şirkette, doğrudan müşterilerle konuşarak bir sorunun özüne daha hızlı ulaşmak için geliştiricilerin destek masalarında birkaç saat oturmasını bile sağlayabilirsiniz.

6. Ayrık Test ve Kontrol Tutma

Şimdiye kadarki adımlarda, kullanılabilirlik testi dışında, tüm test kullanıcıları yeni özelliği gönüllü olarak kullandı. Ancak, özelliği varsayılan olarak etkinleştirirseniz, birdenbire kullanıcıların bunu kullanması gerekecek ve bu, hiç test etmediğimiz çok farklı bir grup türüdür.

Pasif kullanıcıların alışkanlıklarını bozmadığınızdan emin olmak için , üç küçük kullanıcı segmentiyle ayrı test yapabilir ve elde tutmayı ölçebilirsiniz . Sonuçta, yeni bir sürümün en az önceki sürüm kadar iyi çalıştığından emin olmak istiyorsunuz. Arayüzdeki en önemli etkinliği belirleyin ve kullanıcıların yalnızca kullanıma sunmadan önce ve sonra üzerinde ne kadar zaman harcadıklarını değil, aynı zamanda geri dönene kadar ne kadar zaman geçtiğini de ölçün. Mail.ru örneğinde, saklama, kullanıcıların e-postalarını kontrol etmesini ve bir mesaj oluşturmasını gerektirir. Bir kullanıcı ne kadar sık ​​geri gelirse, daha iyi bir UX göstergesi olan elde tutma oranı o kadar yüksek olur.

Her segment biraz farklı bir görünüm alır , bu da yeni özelliğin daha sonra tüm kullanıcılara nasıl görüntüleneceğini test etmemizi sağlar. İlk bölüm için yeni özelliği ekliyoruz ve nasıl kullanılacağına dair bir eğitim sunuyoruz. İkinci segment için sadece yeni özelliği ekliyoruz. Üçüncü segment için özelliği olduğu gibi bırakabiliriz. Tüm bu segmentler için değişikliği aynı anda uygulayabilir, testi çalıştırmak için makul bir zaman çerçevesi seçebilir, elde tutmayı ölçebilir ve ardından sonuçları karşılaştırabiliriz. Bir segmentin elde tutma oranı ne kadar yüksek olursa, tasarımın daha sonra tüm kullanıcılara tanıtılması o kadar olasıdır.

7. Yavaşça ve Kademeli Olarak Bırakın

Bir özellik bu noktaya kadar geldiyse, muhtemelen izleyicinin büyük bir kesimi için zaten iyi çalışıyor. Bu, geri bildirim toplamak için bir oylama istemiyle yavaş yavaş tüm kullanıcılara sunabileceğiniz zamandır. Geri bildirim çoğunlukla olumluysa, özelliği kullanıma sunmaya devam edebilirsiniz ve bu, sonunda arayüzün ayrılmaz bir parçası olacaktır. Aksi takdirde, geri bildirimi değerlendirir ve bir sonraki yineleme için laboratuvara dönersiniz.

Ancak özelliği kullanıma sunmak yeterli değil: Kullanıcılara iletilmesi gerekiyor. Bunu yapmanın yaygın bir yolu e-posta ve sosyal medyadır. Yine de, özelliğin gerçek yaşam senaryolarındaki değerini açıklayan hızlı bir kılavuz da yardımcı olabilir. Ayrıca, hemen geri bildirim toplamak için bir öneri kutusu eklemeyi unutmayın.

8. Sonucu Ölçün

Özellik kullanıma sunulduktan sonra, nasıl performans gösterdiğini izleyebilir ve buna dikkat çekmek için farklı yöntemler deneyebiliriz, böylece kullanıcılar görevlerini daha verimli bir şekilde yerine getirebilirler. En yaygın görevleri veya en çok ziyaret edilen sayfaları izleyebilir ve ardından kullanıcının hedeflerine ulaşması için biraz daha akıllı ve daha hızlı bir yol öneren küçük bir satır içi not görüntüleyebilir ve ardından kullanıcının bu yeni özelliği mi yoksa olağan yöntemi mi tercih ettiğini ölçebilirsiniz.

Geri bildirimi yalnızca geliştiricilere veya tasarımcılara değil, tüm ekibe geri getirmeyi unutmayın, böylece motive olurlar ve etkileşim kurarlar ve insanların başlangıçta kaba bir fikirden başka bir şey olmayan bir özelliği nasıl kullandıklarını görürler. Hiçbir şey, bir uygulamayı tam olarak hayal ettiğiniz şekilde veya tamamen farklı şekillerde kullanan mutlu, memnun insanları görmekten daha motive edici olamaz. Ayrıca takımın sonraki özelliklerinin büyümesini de besleyecektir.

İnceleme süreci karmaşık ve kapsamlı görünüyor, ancak bazen yalnızca zaman ve kullanıcı testi için geniş bir ağ bir sorunu ortaya çıkarabilir. Örneğin, bir değişiklik gelen iletilere genel bakışın nasıl göründüğünü etkilerse, hiçbir birim testi yardımcı yazılım kullanıcılarının karşılaşabileceği zorlukları ortaya çıkaramaz. Bir posta arayüzünde, erişilebilirlik cihazının ilk olarak neyi okumasını istersiniz: tarih, gönderen, konu satırı veya mesajın kendisi? Genel bakışta sütunları yeniden düzenleme biçiminiz, kullanıcıların bilgilere erişmeyi seçme biçimini değiştirebilir; bu nedenle, yeni özelliği kapatmalarına izin vermek de kritik olacaktır.

Çözüm

Peki, bir dağıtım stratejisi neye benziyor? Değişikliğinizin ne kadar kapsamlı olabileceğini anlamak için bağımlılık grafiğini keşfederek başlayabilirsiniz. Ardından, kontrollü bir ortamda geliştiriciler ve gerçek kullanıcılar ile özelliği test edebilirsiniz. Ardından, belirli bir beta testçi grubuna göndermeden önce iş arkadaşlarınızdan özelliği incelemelerini isteyebilirsiniz. Son olarak, özelliği kullanıcılara bir seçenek olarak sunabilirsiniz. Ve özelliği herkes için etkinleştirmeden önce, özelliği tanıtmanın en iyi yolunu bulmak için bir bölünmüş test yapabilir ve ardından kritik görevler için elde tutma oranlarını ölçebilirsiniz.

Dağıtımın doğrusal bir süreç olmadığı açıktır. Süreç boyunca, bir adım ileri gitmek için iki adım geri gitmeniz gerekebilir - sonunda bir serbest bırakma adayınız olana kadar. Yukarıda ele alınan iş akışı oldukça yavaş ve özellikle çevik değilmiş gibi görünebilir, ancak kullanıcıların aniden beklenmedik bir sorunla karşılaşması ve bunun sonucunda daha düşük bir deneyim yaşaması riskini büyük ölçüde en aza indirirsiniz. Bazı durumlarda, buna çok değer olabilir.