Mehmet
Admin
Projenizi paylaşırken önce hangi sorunu çözdüğünü, kimin kullanacağını ve demoda neyin denenebileceğini anlatın. Uzun bir özellik listesi veya yalnız ekran görüntüsü, ürünün nasıl çalıştığını göstermeyebilir. Okurun küçük bir görevi güvenle deneyebilmesi ve size belirli bir konuda geri bildirim verebilmesi daha değerlidir.
Bir ekran kaydı kullanıyorsanız işlemi gösterecek kadarını paylaşın. Hesap, bildirim, müşteri adı ve anahtar gibi ilgisiz bilgileri temizleyin. Bir başarı örneğinin yanında hangi durumda sonuç alınamadığını açıklamak, projenin sınırlarını anlamayı kolaylaştırır.
Bu alanların her birini uzun paragraflarla doldurmak gerekmez. Amacınız, okurun neyi inceleyeceğini anlamasıdır. Teknik ayrıntıyı merak edenler için kullandığınız yaklaşımı ayrıca açıklayabilirsiniz; ilk paragrafı yalnız model ve teknoloji adlarından oluşturmayın.
Düzeltme yayımladığınızda aynı konuda neyin değiştiğini ve nasıl yeniden denenebileceğini belirtin. Bir üyeden gelen yorumu ölçülmüş kullanıcı memnuniyeti veya başarı oranı gibi sunmayın. Gerçek test kaydı yoksa “herkes beğendi” veya “verimliliği katladı” gibi sonuçlar eklemeyin.
Çalışan kısım ile hedeflenen kısmı ayırın
“Belgeden yanıt veren bir asistan hazırlıyorum” diyorsanız, demoda hangi belgelerin kullanılabildiğini belirtin. Kendi örnek belgenizle çalışan sürüm ile kullanıcının her türlü dosyayı yükleyebildiği sürüm aynı şey değildir. Henüz yapılmamış özelliği mevcutmuş gibi sunmayın.Bir ekran kaydı kullanıyorsanız işlemi gösterecek kadarını paylaşın. Hesap, bildirim, müşteri adı ve anahtar gibi ilgisiz bilgileri temizleyin. Bir başarı örneğinin yanında hangi durumda sonuç alınamadığını açıklamak, projenin sınırlarını anlamayı kolaylaştırır.
Sunumu şu sırayla hazırlayabilirsiniz
- Bir cümlelik ihtiyaç açıklaması yazın. Örneğin “Özel bilgi içermeyen toplantı notlarını görev listesine dönüştüren bir araç geliştiriyorum.”
- Kısa bir örnek girdi ve elde edilen çıktıyı gösterin. Bunun gerçek bir kullanım kaydı mı yoksa temsili demo mu olduğunu belirtin. Çıktıyı düzenlediyseniz bu ayrımı da koruyun.
- Denenebilir sürüm varsa erişim koşulunu açıklayın. Giriş gerekip gerekmediğini, örnek verinin nerede bulunduğunu ve hangi işlemin sonunda ne beklendiğini yazın.
- Kullanıcının gerçek belge veya hesap bilgisi yüklemesi gerekmiyorsa bunu somut örnekle kolaylaştırın. Deneme için temiz bir örnek içerik sunun; gereksiz izin veya ödeme adımı istemeyin.
- Bir veya iki odaklı geri bildirim sorusu seçin. “Nasıl olmuş?” yerine “Çıktıdaki görev sahibini düzeltme adımı anlaşılır mı?” gibi cevaplanabilir bir soru sorun.
Kısa bir paylaşım iskeleti
Kod:
Çözdüğü ihtiyaç:
Hedef kullanıcı:
Şu an çalışan akış:
Örnek girdi ve çıktı:
Nasıl denenir:
Bilinen sınır veya hata:
Geri bildirim istediğim nokta:Gelen yorumu geliştirmeye dönüştürün
Bir kullanıcı hata bildirdiğinde hangi girdide ve hangi adımda oluştuğunu sorun; özel veriyi herkese açık biçimde istemeyin. Yorumu bir gereksinime çevirin: “Sonuç karışık” ifadesi, görev sahibi ile tarihin ayrı alanlarda gösterilmesi ihtiyacına işaret ediyor olabilir.Düzeltme yayımladığınızda aynı konuda neyin değiştiğini ve nasıl yeniden denenebileceğini belirtin. Bir üyeden gelen yorumu ölçülmüş kullanıcı memnuniyeti veya başarı oranı gibi sunmayın. Gerçek test kaydı yoksa “herkes beğendi” veya “verimliliği katladı” gibi sonuçlar eklemeyin.
