12 Kas 2025·7 dk
48 saatte çalışan bir prototiple kullanıcı görüşmeleri
48 saatte çalışan bir prototiple kullanıcı görüşmeleri planlayın: hızlı işe alım, görev senaryoları yazma, not alımı ve geri bildirimi net yapım taleplerine çevirme.
48 saatte çalışan bir prototiple kullanıcı görüşmeleri planlayın: hızlı işe alım, görev senaryoları yazma, not alımı ve geri bildirimi net yapım taleplerine çevirme.
Çalışan bir prototip çoğu tartışmayı hızlıca bitirir. Birisi gerçek bir görevi tamamlamaya çalıştığında, ne yapacaklarını tahmin etmeyi bırakırsınız ve gerçekte ne yaptıklarını görmeye başlarsınız. Bu yüzden, prototip kaba olsa bile, çalışan bir prototiple yapılan kullanıcı görüşmeleri sohbet ortamında fikir tartışmaktan üstündür.
Kapsamı sıkı tuttuğunuzda 3 ila 6 oturumla çok şey öğrenebilirsiniz. Mükemmel istatistikler elde edemezsiniz, ama bu hafta düzeltebileceğiniz tekrarlayan desenleri görürsünüz.
48 saat içinde insanların takıldığı veya geri döndüğü yerleri, hangi etiketlerin kafa karıştırdığını, önce ne denediklerini (ve neyi görmezden geldiklerini), akışa güvenmeden önce neyin eksik hissettirdiğini ve fiyatlandırma, izinler veya kaydetme gibi şüphe yaratan anları güvenilir şekilde ortaya çıkarabilirsiniz.
Bu yaklaşım büyük araştırma projelerinden, uzun anketlerden ve açık uçlu aramalardan kaçınır. Pazarın tamamını haritalamaya çalışmıyorsunuz. Önemli bir akıştaki en büyük sürtüşmeyi gidermeye çalışıyorsunuz.
Herkesi planlamadan önce tek bir öğrenme hedefi tanımlayın. Basit bir format iyi çalışır: “İlk kez kullanan birinin X görevini Y dakikadan kısa sürede yardımsız yapıp yapamayacağını?” Basit bir CRM inşa ediyorsanız bu şu olabilir: “Yeni bir kullanıcı bir kişi ekleyip etiketleyebilir ve tekrar bulabilir mi?”
Eğer prototipi hızlıca Koder.ai gibi bir araçta oluşturduysanız, amaç aynı kalır: bir akış seçin, gerçek insanların denemesini izleyin ve tam olarak ne değişmesi gerektiğini kaydedin.
48 saatlik tur yalnızca kapsamı azaltırsanız işe yarar. Belirli bir kullanıcı tipini ve zaten anladıkları bir senaryoyu seçin. Aynı oturumda kayıt, fiyatlandırma, ayarlar ve uç durumları kaplamaya çalışırsanız, kanıt yerine görüşlerle sonuçlanırsınız.
Bir cümlelik hedef yazın: “İlk kez kullanan serbest çalışan bir tasarımcı, yardım almadan 3 dakika içinde bir fatura oluşturup gönderip gönderemez?” O cümle size kişinin kim olduğunu, ne yapması gerektiğini ve "iyi"nin neye benzediğini söyler.
Kiminle konuşacağınıza başlamadan önce ne ölçeceğinize karar verin. Oturum sırasında görünür ve basit tutun. Çoğu ekip için bu, hız (tamamlama süresi), sürtünme (ne sıklıkla takıldıkları veya "sonraki ne?" dedikleri), gezinme sorunları (tereddüt, yeniden okuma, geri gitme) ve güven işaretlerinin (ödeme, gizlilik veya hatalarla ilgili endişeler) bir karışımıdır.
Sonra turun sonunda mutlaka cevaplamanız gereken 3 ila 5 soru yazın. Örnekler:
Sadece yapabildiğiniz için görüşmeye devam etmeyin. Ne zaman duracağınızı önceden belirleyin ki tekrar inşa etmeye dönebilesiniz. Pratik bir kural: beş oturumdan sonra durun veya aynı iki ana sorun ardışık üç oturumda tekrarlanırsa daha erken durun.
Örnek: beş katılımcıdan üçü “Create invoice”ı “Billing” altında gizlendiği için bulamıyorsa, zaten net bir yapım isteğiniz var: etiketi değiştirin, giriş noktasını taşıyın ve o tek değişikliği yeniden test edin.
Prototiple çalışan kullanıcı görüşmelerini iki günde kullanışlı şekilde yürütebilirsiniz; bunu kısa bir sprint gibi ele alın: işe al, hazırla, yürüt, sonra taze iken sentezle. 3 ila 5 oturum hedefleyin. Üç, en büyük problemleri görmek için minimumdur. Beş genelde desenleri gösterir.
Gerçekçi bir plan şöyle görünür:
Eğer işe alım yavaşsa beklemeyin. Kapsamı azaltın ve kullanılabilirliği genişletin. Daha fazla zaman aralığı teklif edin (erken sabah veya akşam dahil), oturumları 15 dakikaya kısaltın veya hedef kullanıcınıza yakın bir çevreden işe alın. Yedekler planlayın—iki kişi fazla almayı amaçlayın; no-show’lar olur ve yedekler programınızı korur.
Düzenli kalmak için ilk görüşmeden önce küçük bir klasör sistemi kurun:
01_Recruiting02_Recordings03_Notes04_Synthesis05_TicketsDosya adlarını P01_2026-01-16_Record.mp4 ve P01_Notes.md gibi adlandırın. Bu küçük alışkanlık, prototip kullanılabilirlik testlerini daha sonra incelemeyi kolaylaştırır.
Hız, mükemmellikten daha önemlidir. Hedefiniz istatistiksel olarak kusursuz bir örneklem değil. Hedefiniz, yaklaşık olarak istediğiniz kullanıcılarla uyuşan, bir gün içinde rezerve edilmiş 5 ila 8 gerçek kişidir.
En hızlı havuzlarla başlayın, sonra genişletin. Ürünü zaten isteyen insanlarla (müşteriler, deneme kullanıcıları, bekleme listesi) başlayın; sonra yakın konuşmalara (destek mesajları, demo istekleri, e-posta cevapları) geçin. Daha fazlasına ihtiyacınız olursa, sorunun tartışıldığı topluluklara bakın, arkadaşların arkadaşlarından tanıdık isteyin (görüş değil, tanıtım), ve aynı iş akışına sahip eski meslektaşlar veya müşterilerle iletişime geçin.
Daveti kısa ve spesifik tutun. Satış çağrısı olmadığını ve ürünün değil kişinin test edildiğini netleştirin. Ne yaptığınızı ve kim için yaptığınızı, istek (20 dakika video veya ses), ne yapacaklarını (prototipte 2-3 görev deneyecekleri) ve küçük bir teşekkür (hediye kartı, bir aylık ücretsiz kullanım veya bağış) ekleyin. Bugün veya yarın için iki zaman seçeneği sunun.
Eğer hızlı bir iç CRM prototipi (örneğin Koder.ai ile) yaptıysanız, hem “dağınık tablo” kullananları hem de hali hazırda CRM kullananları davet edin. Bu karışım yalnızca ileri düzey kullanıcıların geri bildirimlerine dayanmanızı engeller. Ayrıca sadece yakın arkadaşlara güvenmeyin; onlar nazik olmaya çalışırlar.
Teşvikler normal hissettirmeli, utanılacak türden olmamalı. Küçük sabit bir ücret “ne düşünüyorsanız ödeyin”den daha iyidir. Ücretsiz bir ay teklif ediyorsanız, satın alma gerektirmediğinden emin olun.
Son olarak, ekstra rezervasyonlar ayarlayın. İki kişi fazla hedefleyin; no-show’lar olur ve yedekler programınızı sağlam tutar.
Eleme, zamanlama ve onayı tek bir hızlı akış olarak ele alarak saatler kazanın. Gerçek kullanıcı gibi görünüp görünmediklerini onaylayın, bir zaman ayarlayın ve kaydı ve not almayı ilk görüşmeden önce netleştirin.
Hafif bir eleme formu sadece üç soru olabilir:
Oturumları boşa harcayan kırmızı bayraklara dikkat edin. Hedefinizden çok uzak kişiler uyumsuz geri bildirim verir. Çok ilgili kişiler (yakın arkadaş, ortak veya aynı şeyi yapan biri) kişisel gündemlerini öne çıkarabilir. Çok meşgul olanlar acele eder, çoklu görev yapar veya gelmez.
Zamanlama için sıkı olun: 30 dakikalık oturumlar ve 15 dakikalık tampon. Tampon, temiz not yazdığınız, kayıtları adlandırdığınız ve prototipi sıfırladığınız alandır. Çağrıları ardı ardına yığarsanız notlar dağılır ve desenler kaçırılır.
Onay tek kısa mesaj olabilir: kaydetme izni isteyin, notların ürün geliştirme için kullanılacağını açıklayın ve paylaşılması durumunda alıntıların anonimleştirileceğini söyleyin. Kolay bir vazgeçme verin: kayıt istemezlerse not alacaksınız.
Görüşmeden önce basit bir ön arama mesajı gönderin: zaman, beklenen uzunluk, gündem (5 dakika giriş, 20 dakika görev, 5 dakika kapanış) ve ihtiyaçlar (dizüstü mü telefon mu, giriş bilgisi gerekirse, sessiz bir alan). Bu, "mobilden bağlandım" sürprizlerinin oturumları rayından çıkarmasını önler.
İyi bir görüşme prototip kötü olduğu için başarısız olabilir. Amaç insanları görevleri denemeye teşvik etmek; yarı bitmiş bir “tam uygulama” ile onları öylece bırakmak değil.
Prototipi küçük tutun. Görevlerinizin gerektirdiği ekranlar ve yolları dahil edin, diğer her şeyi gizleyin. Kısa bir yol, yarım kalmış “tam uygulama”dan daha iyidir.
İçeriği gerçekçi yapın. Lorem ipsum'u gerçekçi metin ve verilerle değiştirin ki kullanıcılar doğal tepki versin. Bir CRM akışını test ediyorsanız 6 ila 10 kişi gösterin; girişlerde isim, şirket ve birkaç not olsun. Checkout test ediyorsanız gerçekçi fiyatlar ve teslim seçenekleri kullanın. Sahte ama spesifik, genel olandan iyidir.
Oturumlardan önce her gözlemle yazacağınız şeyleri belirleyin: önce nereye tıkladılar, kafa karışıklığı anları (ne dediler ve sonra ne yaptılar), nerede döndüler veya geri gittiler, özellikler için kullandıkları kelimeler ve eksik bilgiyi açığa çıkaran sorular.
Her katılımcının aynı durumdan başlaması için özel bir test hesabı ve sıfırlama rutini kurun. Prototip kayıtlar oluşturuyorsa kısa bir sıfırlama kontrol listesi (sepeti temizle, son oluşturulan öğeyi sil, ana ekrana dön, çıkış yap ve yeniden giriş yap) tutun.
Konuşmadan önce hangi kayıt araçlarını kullanacağınızı seçin. Çağrıyı kayıt yapabiliyorsanız kaydedin ve Task, Observations, Quotes şeklinde üç sütunlu basit bir not şablonu kullanın. Eğer Koder.ai kullanıyorsanız, ilk oturumdan önce bir snapshot almak gün içinde yanlışlıkla bir şeyi değiştirirseniz geri dönmeyi kolaylaştırır.
İyi bir görev senaryosu insanların gerçek hayatta nasıl davranacaklarını gösterir, testte nasıl davranacaklarını değil. Kısa, tekrarlanabilir ve tek bir ana senaryoya bağlı tutun. Çalışan bir prototip için genelde 2 ila 4 görev, desenleri görmek için yeterlidir.
Ana senaryoyu basitçe adlandırın (örneğin: “İlk projemi kurup bir ekip arkadaşı davet etmek istiyorum”). Sonra başarısızlığın en çok zarar vereceği anları temsil eden görevler seçin: ilk kez kurulum, önemli bir özelliği bulma ve anlamlı bir işlemi tamamlama.
Her oturumda aynı yapıyı kullanın ki sonuçlar karşılaştırılabilir olsun:
Her görev istemini buton adını veya kesin yolu açıklamayacak şekilde yazın. Kötü: “Snapshots'a tıklayın ve geri alın.” Daha iyi: “Bir hata yaptınız ve dünkü sürüme dönmek istiyorsunuz. Ne yapardınız, gösterin.”
Her görevin ardından bir kısa soru sorun. Tıklamadan önce: “Nereden başlardınız?” Sonra: “Hangi sebeple o yolu seçtiniz?” Takılırlarsa “Şu anda ne arıyorsunuz?” diye sorun, “Menüyü gördünüz mü?” diye değil.
Koder.ai ile prototip yaptıysanız, görevleri platform terimleri yerine sonuçlara (bir uygulama oluştur, kaynak kodu dışa aktar, özel alan ayarla) dayandırın. Böylece notlar yapım taleplerine temizce dönüşür.
Her oturuma aynı şekilde başlayın. Bu gerginliği düşürür ve sonuçların kişiler arasında karşılaştırılmasını kolaylaştırır.
Hızlı bir senaryo ile açın: teşekkür edin, ürünü test ettiğinizi (kişi değil), yanlış cevap olmadığını ve düşüncelerini sesli paylaşmalarını isteyin. Bir kerede bir görev verin, sonra sessiz kalın. Sizin ana göreviniz onların tereddüt ettiği yeri izlemek ve “Ne düşünüyorsunuz?” veya “Ne bekliyordunuz?” gibi kısa nötr sorular sormaktır. Öğretmekten, övmekten veya prototipi savunmaktan kaçının.
Takıldıklarında kurtarmadan önce yönlendirin. İyi bir yönlendirme hedefleriyle ilgilidir: “Sonraki ne denersiniz?” veya “Bunu nerede arardınız?” Eğer gerçekten bir dakika boyunca bloklandılarsa devam edin ve bunu yüksek şiddetli bir sorun olarak not edin. Oturum sırasında prototipi düzeltme isteğine direnin; yakalayın ve oturumu devam ettirin.
Özellik istekleri faydalıdır ama tartışmayın. Bir cümleyle park edin: “Bu hangi problemi çözer?” sonra geri dönün.
Kapatış da tutarlı olsun. Neyi beğendiklerini, neyin sinir bozduğunu, ödemeye razı olup olmadıklarını (ve neyin adil olduğunu) sorun ve bir sonraki güncelleme sonrası tekrar iletişime geçebilir misiniz diye sorun.
İyi notlar "olan her şey" değildir. Küçük, tutarlı birimlerdir ki sonra sıralanabilsin. Yapıyı oturumlar boyunca aynı tutarsanız, üçüncü görüşmeden sonra desenler ortaya çıkar.
Her gözlemciin kullanacağı tek bir not dokümanı veya tablo seçin. Her görev denemesi için bir satır oluşturun ve her seferinde kısa, gerçekçi notlar yazın. Basit düzen:
Zaman damgaları kayıtlara geri dönüp doğrulama yapmanızı sağlar. Görev numaraları akışlar arasında sorun karışmasını engeller.
Bir şey ters gittiğinde, bağlamı olmadan bir takım arkadaşınızın anlayabileceği bir düz cümleyle yazın. Yorumunuzu değil, olayı belirtin.
Örnek: “T2 06:14: ‘Save’e tıkladı, onay bekledi ama hiçbir şey olmadı ve bunun çalışıp çalışmadığını sordu.”
Güven veya kafa karışıklığı için önemliyse bir alıntı ekleyin (“Bunun güvenli olduğundan emin değilim” veya “Nereden başlamalıyım?”). Alıntılar önceliklendirmeyi kolaylaştırır çünkü etkinin boyutunu gösterir.
Etiketleri küçük tutun ki hızlıca filtreleyebilin:
Eğer prototip Koder.ai ile oluşturulduysa, notları kullanıcı davranışına ve ürün davranışına odaklayın, prototipin nasıl oluşturulduğuna değil.
Son kural: bir notu ticket başlığına çeviremiyorsanız, onu yeniden yazın ta ki çevrilebilsin.
Geri bildirimi sadece alıntılar ve hisler halinde bırakmak hızınızı kaybettirir. Gördüğünüzü, bir geliştiricinin tahmin etmesine gerek kalmadan uygulayabileceği yapım taleplerine dönüştürün.
Önce sorunları göreve göre gruplayın, kişiye göre değil. Üç kişi “hesap oluşturma” sırasında zorlandıysa, bu bir problemdir ve birçok veri noktasıdır, üç ayrı görüş değil.
Her sorun için tek tip bir istek formatı kullanın:
“İfade ve açıklık” düzeltmelerini “kapsam” değişikliklerinden ayırın. “Bu butonun ne yaptığı belli değil” genelde etiket veya yerleşim düzeltmesidir. “İhracatlar, roller ve onaylar gerekiyor” daha büyük bir ürün kararıdır. Karıştırmak ticketları şişirir.
Sonra her sorunu değerlendirin: şimdi düzelt, tekrar test et veya sonraya al. Basit bir sıralama yöntemi: kullanıcı etkisi, çaba, güven (tekrarlandı mı?) ve sonraki eylem (inşa et, yeniden test et, beklet).
Eğer Koder.ai kullanıyorsanız, kabul kontrolünü düz İngilizce yazın ki build sohbetine yapıştırılabilecek net, test edilebilir bir talimat olsun.
Teknik olmayan bir kurucu, basit bir CRM onboarding akışını Koder.ai'de hızlıca oluşturur ve ertesi gün kullanıcı görüşmeleri yapar. Hedef dar: bir satış temsilcisi “ilk anlaşma oluşturuldu” noktasına yardımsız gelebilir mi?
İşe alım hızlıdır: ağlarına ve birkaç yerel satış topluluğuna kısa bir mesaj gönderir, küçük bir hediye kartı teklif eder. Beş satış temsilcisi öğleden sonra için 20 dakikalık slotlara kaydolar.
Her oturum aynı üç görevi kelimesi kelimesine kullanır:
Beş oturum boyunca tekrar eden sorunlar ve birkaç engelleyici not edilir. İki temsilci içe aktarma yerini bulamaz. Üç temsilci “Reminder”ı bildirim ayarı sanıyor, takip olarak değil.
Günün sonunda bu gözlemler derhal uygulanabilir yapım taleplerine dönüşür:
Nokta bu: tutarlı görevler, tekrarlayan desenler ve ticketların o kadar açık yazılması ki aynı gün içinde inşa edilebilmeleri.
Kötü görüşme sonuçlarının çoğu prototipten değil, birkaç küçük hatadan kaynaklanır.
“Bu mantıklı değil mi?” gibi yönlendirici sorular nazik onay alır. Nötr istemler kullanın: “Bunun ne yaptığını düşünüyorsunuz?” sonra sessiz kalın.
Bir oturumda çok fazla şeyi test etmeye çalışmak yüzeysel yorumlara ve zayıf sinyallere yol açar. 2-3 ana akışı seçin.
Senaryoyu ortasında değiştirmek karşılaştırılabilirliği bozar. Yeni fikirleri bir backlog'a atın ve görevleri sabit tutun.
Dağınık notlar başka bir gizli hatadır. Hafızaya güvenirseniz komik kısımları hatırlarsınız, acı veren kısımları değil. Takıldıkları tam adımı ve sonra ne denediklerini yazın.
Basit bir gerçeklik kontrolü: bir katılımcı “Güzel görünüyor” derken sonraki butonu bulmak için 90 saniye harcıyorsa, eylemleri veridir. İltifat gürültüdür.
Bir yüksek sesli görüş çok kolay plana dönüşebilir. Güçlü bir görüşü, birden fazla oturumda aynı sorunu görmediğiniz sürece hipotez olarak değerlendirin.
Büyük değişiklikler yapacaksanız, hızlıca yeniden test edin. İki kısa oturum bile değişikliğin problemi çözüp çözmediğini doğrulayabilir.
İlk görüşmeyi ayarlamadan önce temelleri kilitleyin:
Her oturumdan hemen sonra üç dakikalık bir kontrol yapın: ilk üç sorununuzu ve bir sürprizi yazın. Söyleyemiyorsanız görevleriniz çok geniş veya notlarınız çok belirsiz olabilir.
Aynı gün, ham notları kararlara dönüştüren kısa bir özet yapın. Benzer problemleri gruplayın, en önemlileri seçin ve sıradaki değişiklikleri tanımlayın.
Düzeltmeleri yayınladıktan sonraki 72 saat içinde yeniden test planlayın. Hatta üç kısa oturum bile değişikliğin işe yarayıp yaramadığını doğrulayabilir.
Eğer Koder.ai (koder.ai) üzerinde iterasyon yapıyorsanız, Planning Mode bulguları kapsamlı görevler olarak yeniden yazmanıza yardımcı olabilir (“X değişikliğini yapın ki kullanıcı Z'yi Y olmadan yapabilsin”) ve snapshotlar sabit bir sürümü kaybetmeden hızlıca deney yapmanızı sağlar.
Hedef olarak 3 ila 5 oturum planlayın. Üç genelde en büyük tıkanmaları ortaya çıkarır; beş ise örüntüleri doğrulamaya yeter. Aynı iki ana sorun ardışık üç oturumda tekrarlanırsa erken durun ve inşa-et/test döngüsüne dönün.
Kullanıcıyı, görevi ve ölçülebilir başarı ölçütünü adlandıran tek cümlelik bir format kullanın. İyi bir örnek: “İlk kez kullanan bir [kullanıcı tipi], **[görev]**i yardım almadan [süre] içinde yapabilir mi?” Bu, oturumu gözlemlenebilir davranışa odaklar.
Her oturumda test edilecek 2 ila 4 görev seçin; bunlar genelde ilk kurulum ve anlamlı bir işlemi tamamlama gibi akışın en önemli anlarını temsil eder. Görevleri sonuç odaklı tutun, böylece insanların başarılı olup olmadığını test edersiniz, belirli bir buton adını bulup bulmadıklarını değil.
En hızlı kaynaklarla başlayın: ürünle zaten ilişkisi olan kişiler (deneme kullanıcıları, bekleme listesi), destek konuşmaları veya demo istekleri. Daveti kısa ve net tutun; satış çağrısı olmadığını belirtin ve bugün veya yarın için iki belirli zaman seçeneği sunun.
Üç hızlı soru sorun: bugün bu problemi çözmek için ne kullanıyorsunuz, işi en son ne zaman denediniz ve ne oldu, hangi rol sizi en iyi tanımlar (ve neden)? Hedef kullanıcınızdan çok uzak, aşırı ilgili (yakın arkadaş veya aynı şeyi yapan biri) veya çok meşgul görünenleri eleyin.
Kaydetme izni isteyin, kaydın ve notların ne için kullanılacağını söyleyin (ürünü geliştirmek) ve paylaşırsanız alıntıların anonimleştirileceğini taahhüt edin. Kolay bir vazgeçme sunun: kayıt istemezlerse not alırsınız ve yine de katılabilirler.
Prototipi sadece görevleriniz için gereken ekranlarla sınırlayın ve içeriği gerçekçi yapın ki kullanıcılar doğal reaksiyon versin. Her katılımcının aynı durumdan başlaması için test hesabı ve basit bir sıfırlama rutini oluşturun—böylece sonuçlar karşılaştırılabilir olur.
Her oturumu aynı şekilde yürütün: aynı başlangıç, aynı görevler ve katılımcı çalışırken büyük ölçüde sessizlik. “Şu anda ne arıyorsunuz?” gibi nötr sorular sorun ve tasarımı öğretmekten, savunmaktan kaçının—bu, ürünün nerede gerçekten başarısız olduğunu gizler.
Her görev denemesi için kısa, tutarlı notlar alın: ne denediler, ne beklediler ve ne oldu; önemliyse bir alıntı ekleyin. Basit bir öncelik etiketi ekleyin (engelleyici, yavaşlatıyor, önemsiz) ki kanıt taze iken hızlıca önceliklendirebilin.
Tekrarlanan her sorunu şu beş bölümle bir yapım isteğine dönüştürün: problem, kanıt (gözlem veya alıntı + nerede oldu), etki (zaman kaybı, kafa karışıklığı, bırakma), önerilen değişiklik ve bir kabul kontrolü (bir sonraki testte nasıl doğrulanır). Sorunları katılımcıya göre değil, göreve göre gruplayın.