Ürün kullanıcıları konferansı: program ve organizasyon

Ürün kullanıcı konferansı nasıl düzenlenir: rotalar, vaka örnekleri, uygulama, gelişim planı, sorular ve etkinlik sonrası materyaller.

Ürün kullanıcı konferansı, şirket çözümle gerçek çalışma etrafında dış bir topluluk oluşturmak istediğinde gereklidir. Bunun için yeni bir özelliğin duyurusu tek başına yeterli değildir. Katılımcıların meslektaşlarının vaka örneklerine, uygulamaya, ürün ekibiyle konuşmaya, deneyim paylaşımına ve etkinlik sonrası net bir devam sürecine ihtiyacı vardır.

Biz Aventura'da kullanıcı rotalarıyla başlıyoruz: her grubun neyi anlaması, neyi denemesi ve işine neyi taşıması gerektiği. Bu sonuçlara göre sahneyi, uygulamayı ve danışmanlıkları bir araya getiriyoruz. Ürünle ilgili gerçekleri ve gelişim planlarını müşteri ekibi teyit eder.

Ürün kullanıcı konferansı planınızda yer alıyorsa, teklif isteyin ve formatı konuşalım. İlk görüşme için ürünü, ana kullanıcı rollerini, program hedeflerini, şehri ve öngörülen katılım formatını belirtmeniz yeterlidir.

Ürün kullanıcı konferansı nedir?

Ürün kullanıcı konferansı, belirli bir çözümü seçen, uygulayan veya günlük olarak kullanan kişilere yönelik dış etkinliktir. Program, ürün bağlamını, kullanıcı deneyimini ve pratiği bir araya getirir.

Bu format genellikle kullanıcı konferansı (user conference) olarak adlandırılır. İngilizce adı ürün ekibi içinde kullanışlıdır, ancak davet edilen kişi için daha önemli olan net bir vaattir: hangi görevleri ele alabileceği, neyi kendisinin deneyeceği ve kendi durumunu kiminle tartışacağı.

Atlassian Team Europe ve Salesforce Dreamforce programları, ürün duyurularını müşteri hikâyeleri, uygulamalı oturumlar, danışmanlıklar ve topluluk etkileşimiyle birleştirir. Kayıtlar ve materyaller, yüz yüze kısımdan sonra da çalışmaya devam eder. Bu, mimari için faydalı bir referanstır; ancak başkasının programı evrensel bir norm olarak kopyalanamaz.

Konferansın dört sonucu vardır:

• kullanıcı, hangi yeteneklerin kendi rolü ve göreviyle ilgili olduğunu anlar;
• katılımcı en az bir senaryoyu vaka çalışması, gösterim veya uygulama yoluyla test eder;
• sorular bağlam, sahip ve durum kazanır;
• etkinlikten sonra materyaller ve ziyaret edilen rota ile bağlantılı bir sonraki adım kalır.

Biz, program ve etkinlik prodüksiyonundan sorumluyuz: kayıttan mekânın işleyişine kadar. Müşterinin ekibi, ürün tezlerini, açıklama kurallarını ve kullanıcılara verilecek yanıtları onaylar.

Beş komşu formatla sınır

En önemli fark, hedef kitle yapısı ve beklenen sonuçtur. Kullanıcı konferansı tek bir ürünün uygulanması etrafında kurulur; partner, iç ve araştırma formatları başka amaçlara hizmet eder.

Sınır, senaryo üzerinde çalışmadan önce gereklidir. Hedef kitle belirli bir çözümün kullanıcılarından daha genişse, müşteri B2B etkinliği rehberiyle başlayın. Katılımcıların tek bir mühendislik görevi konusunda derinlemesine eğitime ihtiyacı varsa, müşteriler için teknik seminer daha faydalıdır.

Şirket içi ürün günü, şirketin iç işleyişini tartışır: portföy, bağımlılıklar, araştırmalar ve ürün ekiplerinin kararları. Ürün kullanıcı konferansı dışa dönüktür. Kullanıcılar aynı gelişim yönlerini tartışabilir, ancak iç portföy kararlarını almazlar ve tüm ürün mutfağına erişemezler.

CAB, konferansa ayrı bir kapalı oturum olarak entegre edilebilir. Böyle bir toplantının bileşimi önceden belirlenir, konu bir araştırma görevi olarak formüle edilir ve sinyaller sahiplerini ve durumlarını alır. Tekrarlayan bir bileşimi olmayan normal bir VIP akşam yemeği veya yuvarlak masa CAB olarak adlandırılmamalıdır. Ayrıntılı sınır, müşteri danışma kurulu hakkındaki makalede ele alınmıştır.

Bayi konferansı kanalla çalışır. Kullanıcı konferansı, ürünün son kullanıcı kitlesi tarafından uygulanmasıyla ilgilenir. Karıştırma, belirsiz bir programa yol açar: bazı konuklar ticari koşullar bekler, diğerleri çalışma senaryosunu tartışmak ister. İş ortağı formatı için bayi konferansı programı hakkında ayrı bir materyal vardır.

Katılımcı kitlesini rotalara nasıl ayırırız?

Rota, katılımcının rolüne, deneyimine ve iş görevine bağlıdır. Bu üç özellik, materyalin derinliğini ve oturum formatını etkiler.

Programı değiştiren segmentlerle başlayın. Unvanın kendisi ihtiyaç hakkında fazla bir şey söylemez. Küçük bir kurulumun yöneticisi ile olgun bir ürün programının yöneticisi farklı izler seçebilir. Bir çözüm sürümünün administratörü için başka bir ortama yönelik laboratuvar her zaman uygun olmayabilir.

İşleyen segmentasyon dört eksen kullanır:

Bu matristen birkaç küratörlü rota oluşturun. Örneğin: «ilk kurulum», «olgun ortam yönetimi», «entegrasyonlar ve genişleme», «müşteride ürün yöneticisi». Katılımcı tek tek oturumları değiştirebilir, ancak hazır bir temel görür.

Kayıt yalnızca rotayı değiştiren verileri toplar: rol, deneyim, ilgilenilen senaryo ve erişilebilirlik koşulları. Teknik bilgiler yalnızca önceden belirlenmiş bir görev için sorulur ve atanmış sahibine iletilir. Formun ve check-in sürecinin tamamı etkinlik katılımcı kaydı makalesinde ele alınmıştır.

Segmentleri, akışları, mekânı ve teknik kısıtlamaları tek bir projede birleştirmek isterseniz, hesaplama için talep bırakın. Programı ve prodüksiyonu rastgele bir sunum listesi etrafında değil, kullanıcı eylemleri etrafında oluşturmaya yardımcı oluruz.

Büyük ortak bölüm ve paralel oturumlar için konferans organizasyonu yaklaşımını benimsiyoruz: tek bir zamanlama, oturum moderatörleri, anlaşılır geçişler, teknik plan ve her bloğun sonuçlarının toplanması. Böylece katılımcı sahne, uygulama ve danışmalar arasında rotasını kaybetmez.

Program matrisi ve günün ritmi

Program, anlatım ve eylemi dönüşümlü olarak sunmalıdır. Genel oturumun ardından katılımcı bir vaka çalışmasına, uygulamaya veya bir uzmanla görüşmeye geçer.

Önce, konferansın ardından kullanıcıda gerçekleşmesi gereken değişimleri tanımlayın. «Yenilikleri öğrendi» ifadesi fazla belirsizdir. Daha faydalısı: uygun senaryoyu seçti, ayarları eğitim ortamında test etti, süreci meslektaşlarıyla karşılaştırdı, ürün ekibine bir soru yöneltti veya pilot planı hazırladı.

Program matrisi şöyle görünebilir:

Arka arkaya birkaç uzun konuşma koymayın. Katılımcının dinlediği bir bölümün ardından ona karşılaştırma yapma, deneme veya soru sorma imkânı tanıyın.

Çalışma sırası şöyle olabilir:

1. Ürünün, konuların ve rotaların genel haritasını verin.
2. Güncellemeyi gerçek bir kullanım senaryosunun yanında gösterin.
3. Dinleyici kitlesini vaka çalışmalarına ve olgunluk düzeyine göre ayırın.
4. Gözlemlenebilir bir sonucu olan laboratuvarlar veya klinikler düzenleyin.
5. Rol veya göreve göre deneyim paylaşım grupları oluşturun.
6. Gelişim yönlerini ve belirlilik derecesini işaretleyin.
7. Soruları bir yanıt, durum bilgisi veya doğrulama rotasıyla kapatın.
8. Kişinin kendi kişisel sonraki adımını kaydetmesini sağlayın.

Bölümler arasındaki tamponlar geçişler, sorular ve danışmanlıklar için gereklidir. Bunlar boş zaman olarak görülmemelidir. Laboratuvar, bir sonraki zorunlu sunumun başlangıcıyla aynı anda biterse katılımcı ya işini yarıda bırakır ya da salona geç kalır. Program, sahne, uygulama alanı ve toplantı odaları arasındaki fiziksel mesafeyi hesaba katmalıdır.

Reklam sunumu olmadan kullanıcı vakaları

İyi bir kullanıcı vakası; sorunu, kısıtları ve doğrulanmış sonucu gösterir. Başlangıç koşulları olmadan hikâye hızla reklama dönüşür.

Vaka seçimi için basit bir soru sorun: başka bir kullanıcı kendi koşullarında neyi test etmesi gerektiğini anlayabilecek mi? Tanıdık bir logo, içi boş bir hikâyeyi telafi etmez. Kısıtları dürüstçe ele alan küçük bir proje, yalnızca genel başarıların kaldığı büyük ölçekli bir sunumdan daha faydalı olabilir.

Oturum çerçevesi:

1. Kullanıcıyı ve süreci izin verilen kapsamda belirtin.
2. Proje öncesindeki başlangıç sorununu açıklayın.
3. Kısıtları gösterin: veriler, entegrasyonlar, süreler, yetkinlikler veya mevzuat.
4. Hangi seçeneklerin değerlendirildiğini açıklayın.
5. Seçilen yolu aşamalar halinde inceleyin.
6. Çalışma sırasında nelerin değiştirilmesi gerektiğini belirtin.
7. Doğrulanmış sonucu ve ölçüm yöntemini gösterin.
8. Tekrarlanabilir uygulamayı, belirli bağlama ait ayrıntılardan ayırın.
9. Ekibin bir sonraki adımıyla bitirin.

AWS müşteri hikâyelerinde sıklıkla basit bir çerçeve görülür: başlangıçtaki zorluk, çözüm, sonuç. Sahne için buna kısıtlar ve başarısız dönemeçler de eklenmelidir; aksi halde neden-sonuç ilişkisi fazla pürüzsüz olur.

Sunumu konuşmacıyla birlikte önceden hazırlıyoruz. Başlığı bir kullanıcı görevi olarak, üç ana çıkarımı, süreç şemasını ve izin verilen materyalleri kontrol ediyoruz. Prova, aynı jestleri yerleştirmek için değildir. Projede yer almayan bir kişi için kararların mantığının anlaşılır olup olmadığını gösterir.

Sonuç açıklanamıyorsa, vaka anonimleştirilir veya eğitim senaryosuyla değiştirilir. İkna edicilik için rakam uydurulamaz. «Azalttık», «hızlandırdık» veya «artırdık» gibi ifadeler de anlaşılır bir karşılaştırma temeli ve müşteri onayı gerektirir.

Uygulamalı oturumlar nasıl düzenlenir?

Uygulamalı oturum tek bir eylem ve doğrulanabilir bir sonuç etrafında kurgulanır. Katılımcı yalnızca eğitmeni izliyorsa, bu bir gösterimdir.

Burada aktif öğrenme ilkesi basittir: katılımcı adımı kendi atar ve geri bildirim alır. Cornell bu tür öğrenmeye tartışma, araştırma, oluşturma ve problem çözmeyi dahil eder.

Her laboratuvar için bir pasaport hazırlıyoruz:

Format olgunluğa bağlıdır. Adım adım laboratuvar grubu tek bir senaryo boyunca yönlendirir. Bağımsız laboratuvar görevi ve kriterleri tanımlar, yolu ise katılımcı kendisi seçer.

Belirli bir sorunun analizi klinik olarak kurgulanır. Mevcut bir sürecin ortak analizi çözümün yapısını görmeye yardımcı olur, kısa danışmanlıklar ise önceden ayrılmış slotlarda yürütülür.

Uygulama, mekân seçildikten sonra bir araya getirilemez. Çalışma yeri sayısı, elektrik beslemesi, ağ, akustik, mobilya ve güvenli geçiş yolları kapasiteyi ve rotasyonu etkiler. Arama sırasında mekân kataloğu ile başlanabilir, ancak nihai uygunluğu teknik planla yapılan bir inceleme doğrular.

Laboratuvarın eklem yerlerini provada kontrol ederiz: erişim verilmesi, ortamın başlatılması, bilgilendirme, geride kalan katılımcıya yardım, arıza sonrası kurtarma ve bir sonraki oturuma geçiş. Uçtan uca teknik provanın genel düzeni, etkinliğin teknik provası hakkındaki kılavuzda açıklanmıştır.

Ürün geliştirme planı ve vaatler olmadan geri bildirim

Geliştirme planı ürünün yönünü ve ekibin güven derecesini gösterir. Test aşamasındaki bir fikir, vaat edilen bir sürüm olarak sunulamaz.

GOV.UK, geliştirme planını, önceliklerle birlikte değişen olası bir ürün yönü olarak tanımlar. Belge, gelecekteki işleri ve ekibin şu anda bilinçli olarak yapmadığı şeyleri göstermeye yardımcı olur. Sahne için bu, her tarihin bir taahhüt gibi göründüğü bir takvimden daha faydalıdır.

Kullanışlı etiketleme:

• Yayınlandı: özellik kullanılabilir, gösterilebilir ve belgelerle desteklenebilir.
• Şimdi: çalışma yüksek derecede güvene sahip, ancak doğrulanmamış bir tarih belirtilmez.
• Sonraki: öncelikli sorun veya beklenen sonuç; çözüm hâlâ netleştiriliyor.
• Hipotez test ediliyor: ekip veri ve geri bildirim topluyor.
• Şu anda plan dışı: beklenti sınırı doğrudan belirtilmiştir.

Her yön için kullanıcı sorununu, hedef kitleyi, beklenen sonucu, bağımlılıkları, riskleri ve gözden geçirme faktörlerini gösterin. Prototip, açık bir durum etiketine sahip olmalıdır. Yayınlanmış bir özellik gibi tasarlanamaz.

Önce kısa bireysel yanıtlar veya kriterlere göre oylama toplayın. Ardından genel tartışmaya geçin ve değer koşullarını, uygulama riskini ve zorunlu unsurları netleştirin. Rol, senaryo ve sonuç olmadan «bir özellik ekleyin» talebi çok zayıf bir sinyal olarak kalır.

Sinyal kartında rol, sorun, bağlam ve doğrulama sahibi kaydedilir. Olası durumlar: kabul edildi, veri gerektiriyor, sahibine iletildi veya yanıtla kapatıldı.

Demo, sorular ve kullanıcılar arası paylaşım

Demo, sorular ve deneyim paylaşımı ayrı bloklara ayrılmalıdır. Aksi halde özel sorunlar programı bastırır ve sorular bağlamını ve sahibini kaybeder.

Gösterim için bir tez, bir senaryo ve bir başlatma sahibi gerekir. Ekranda güvenli verileri ve aynı tezi doğrulayan yedeği ayrıca hazırlıyoruz.

Soru, bağlamıyla birlikte kaydedilir:

• kullanıcının rolü ve görevi;
• gerekiyorsa sürüm veya ortam;
• zaten gerçekleştirilen işlemler;
• beklenen sonuç;
• kabul edilebilir yanıt modu;
• sahip ve durum.

Genel duyuru, vaat edilen kişisel yanıtın yerini tutmaz. Soru müşteri verilerini gerektiriyorsa, tartışma kapalı bir danışmanlığa taşınır. Sahnede moderatör güvenli bir genel ilke verebilir ve devam yolunu açıklayabilir.

Deneyim paylaşımı oturumu bir konu ve kolaylaştırma gerektirir. Cornell, işbirliğine dayalı öğrenmeyi küçük gruplarda çalışma, tartışma ve ortak sorun çözme ile ilişkilendirir. Profesyonel bir izleyici kitlesi için grup; role, sektöre, ölçeğe, uygulama aşamasına veya senaryoya göre oluşturulur. Katılımcıya bir bağlam şablonu ve hassas ayrıntıları açıklamama hakkı verilir.

Böyle bir toplantının işleyiş sırası şöyledir:

1. Her katılımcı rolünü ve bir görevini belirtir.
2. Katılımcılar bağlamı kısa bir şablon kullanarak ayrı ayrı kaydeder.
3. Grup birkaç durumu ele alır.
4. Kolaylaştırıcı, gereksiz kişisel veriler olmadan tekrar eden engelleri işaretler.
5. İletişim bilgileri yalnızca gönüllü onay ile paylaşılır.

Serbest networking, ek bir katman olarak bırakılabilir. Özellikle izleyici kitlesi büyük olduğunda ve insanlar birbirini henüz tanımadığında, tematik paylaşımın yerini tutmaz.

Hibrit, erişilebilirlik ve veri

Hibrit format, salondan yapılan bir yayın değil, birbiriyle bağlantılı iki rotadır. Çevrimiçi katılımcının sunuma, sorulara, grup çalışmasına ve materyallere erişimi olmalıdır.

Erişilebilirliği hazırlığın en başından itibaren mekâna, platforma ve materyallere dahil ediyoruz. W3C, yüz yüze, uzaktan ve hibrit katılımcıların önceden dikkate alınmasını önerir. Section508.gov ayrıca belgelerin, web sitelerinin erişilebilirliğini ve davetiyede özel koşulların nasıl talep edileceğini vurgular.

Minimum hibrit katman şunları içerir:

• tüm katılımcılar için tek bir katalog ve materyaller;
• uzaktaki izleyicilerin sorularını ileten bir çevrimiçi moderatör;
• salondan soru sormak için mikrofonlar;
• ortak bir soru-cevap kanalı;
• sunum sırasında erişilebilir slaytlar ve bağlantılar;
• seçilen formatta altyazılar ve kontrol edilmiş kayıt;
• yüz yüze böyle bir bölüm varsa, paylaşım için ayrı çevrimiçi odalar;
• yedek iletişim, yerel kayıt ve alternatif materyal sunumu.

Tam kapsamlı uzaktan izleyici kitlesi olan bir etkinlik için hibrit etkinliği birbiriyle bağlantılı iki rota olarak kurgularız. Salonun arkasındaki bir kamera, arayüze, sorulara ve grup tartışmasına eşit erişim sağlamaz.

Yüz yüze kısım için girişten katılımcının yerine kadar olan yol kontrol edilir: geçişler, oturma düzeni, akustik, ışık ve yardım noktası. Materyaller için yapı, kontrast, metin boyutu ve alternatif açıklamalar kontrol edilir.

NIST'in federal dijital kimlik kılavuzunda minimizasyon ilkesi tanımlanmıştır: yalnızca belirli bir işlev için gerekli bilgileri istemek ve işlemeyi anlaşılır şekilde açıklamak. Bir konferansa kayıt için bu, verilerle özenli çalışmanın genel bir göstergesidir. Zorunlu alanlar isteğe bağlı kişiselleştirmeden ayrıdır ve pazarlama izni temel programa erişimden ayrıdır. Soruların, danışma kayıtlarının ve davranışsal verilerin saklama süresi önceden belirlenir.

Konferanstan sonra ne bırakılmalı?

Konferanstan sonra katılımcının kendi rotasına uygun materyallere ve net bir sonraki adıma ihtiyacı vardır. Ekibe ise soru kaydı, ürün sinyalleri ve devam süreçlerinin sahipleri kalır.

Materyal matrisi etkinlikten önce oluşturulur:

materyal → hedef kitle → kaynak → sahip → kontrol eden → haklar → sürüm → kanal → hazır olma kriteri → yedek

Konferanstan sonra özet, izin verilen fotoğraf ve kayıtlar, laboratuvar materyalleri ve sorulara yanıtlar yayımlanır. Her rota için kendi devamı hazırlanır; kapalı oturum için ise ayrı ve güvenli bir özet.

Ayrıntılı üretim süreci, konferans sonrası içerik makalesinde ele alınmıştır. Projenin kayıtlara, röportajlara ve izlere göre materyal setine ihtiyacı varsa, plana baştan fotoğraf ve video prodüksiyon, haklar, kadrajdaki arayüzlerin kontrolü ve onay rotasını dahil ederiz.

Metrikleri bir merdiven şeklinde oluşturmak daha iyidir:

GOV.UK önce kullanıcı problemini tanımlamayı ve beklenen faydayı hâlâ verilerle doğrulanması gereken bir hipotez olarak ele almayı önerir. Bu nedenle etkinlik tarihinden sonra ürün kullanımındaki artış otomatik olarak konferansa atfedilemez. Başlangıç çizgisi, seçilmiş grup, gözlem penceresi ve diğer faktörlerin hesaba katılması gerekir.

Nihai iç değerlendirme, programı devamıyla ilişkilendirir. Ekip hızlı soruları kapatır, karmaşık konulara sahipler atar, rotalara göre materyaller hazırlar ve katılımcılara bir sonraki kontrol noktasını bildirir. İçeriği, mekânı, teknik ekipmanı, oturum akışlarını ve materyal yayınını tek bir planda bir araya getirebiliriz. Ürün kullanıcı konferansı için teklif isteyin.

Kaynaklar

• Atlassian Team Europe FAQ
• Salesforce Dreamforce FAQ
• W3C WAI: Making Events Accessible
• Section508.gov: Accessible Meetings
• GOV.UK Service Manual: Developing a roadmap
• GOV.UK Service Manual: Measuring service benefits
• NIST: Privacy guidance
• Cornell University: Active Learning
• Cornell University: Collaborative Learning
• AWS Customer Success Stories