UX Case Study’de Problem Tanımı Nasıl Yazılır?

Güçlü bir UX case study problem tanımı, kullanıcı ihtiyacını, iş bağlamını ve tasarım karar alanını anlaşılır hale getirir.

Bir case study’nin ilk paragrafında çoğu zaman çözümü görürüm. “Kullanıcılar için daha kolay bir deneyim tasarladım” gibi. Bu cümle kulağa iyi gelebilir, ama okuyucunun en temel sorusunu cevaplamaz: Neden bu problem vardı ve çözülmeye değer miydi?

Problem tanımı, case study’nin yönünü belirler. Sadece “ne tasarlandı?” sorusunu değil, “hangi belirsizlik içinde karar verildi?” sorusunu da açar.

Çözümden değil, durumdan başlayın

Problem tanımı yazarken en sık yapılan hata, çözüm diline erken geçmektir. “Yeni bir dashboard tasarladım” cümlesi çıktıdan bahseder. Problem ise henüz görünür değildir.

Daha iyi başlangıç şu olabilir:

B2B SaaS ürününde ekip yöneticileri, haftalık performans sorunlarını fark etmek için üç farklı sayfa arasında geçiş yapmak zorunda kalıyordu. Bu durum özellikle yoğun kullanım dönemlerinde karar alma süresini uzatıyordu.

Burada çözüm yok. Ama durum, kullanıcı, bağlam ve sürtünme var.

Kullanıcıyı adlandırın, ama jenerik acıdan kaçının

“Users were confused” çok sık kullanılan ama zayıf bir ifadedir. Türkçede de “kullanıcılar zorlanıyordu” tek başına yeterli değildir. Hangi kullanıcı? Nerede zorlanıyor? Bu zorlanma hangi davranışa yol açıyor?

Zayıf ifade:

Kullanıcılar ödeme adımında zorlanıyordu.

Daha net ifade:

İlk kez alışveriş yapan kullanıcılar, kayıt olmadan devam edip edemeyeceklerini ödeme adımında anlayamıyordu. Bu belirsizlik, sepetten çıkışların özellikle üyelik ekranı öncesinde artmasına neden oluyordu.

İkinci ifade problem alanını daraltır. Böylece sonraki araştırma ve tasarım kararları daha okunabilir hale gelir.

İş bağlamı kararı etkiliyorsa ekleyin

Her case study’ye iş hedefi eklemek zorunda değilsiniz. Fakat karar alanını etkiliyorsa bunu belirtmek gerekir. Örneğin onboarding sadeleştirme çalışmasında amaç sadece kullanıcı memnuniyeti olmayabilir. Aktivasyon, destek talebi sayısı veya demo talebi gibi metrikler de kararı etkileyebilir.

İş bağlamı eklerken abartıya kaçmayın. “Bu proje şirketin büyümesini değiştirdi” gibi iddialar yerine, daha ölçülü bir çerçeve kurun:

Ürün ekibi, onboarding’in ilk üç adımında yaşanan kopuşu azaltmak istiyordu. Bu nedenle problem tanımını sadece görsel sadeleştirme olarak değil, kullanıcının ilk değere daha hızlı ulaşması olarak ele aldım.

Bu ifade tasarım kararını iş hedefiyle bağlar.

Scope görünür olmalı

Problem çok genişse case study dağılır. “Bankacılık deneyimini iyileştirmek” gibi bir cümle çoğu zaman gerçek bir problem tanımı değildir. Hangi akış? Hangi kullanıcı grubu? Hangi karar noktası?

Scope’u netleştirmek için şu soruları kullanabilirsiniz:

• Bu case study hangi akışı kapsıyor?
• Hangi kullanıcı grubuna odaklanıyor?
• Hangi davranışı değiştirmeyi hedefliyor?
• Hangi alan bilerek dışarıda bırakıldı?

Scope’u açık yazmak, projeyi küçük göstermez. Aksine okuyucuya karar disiplininizi gösterir.

Problem tanımı yöntemi de yönlendirmeli

Problem tanımı ile kullandığınız yöntem arasında bağ olmalı. Eğer problem davranışı anlamakla ilgiliyse görüşmeler anlamlı olabilir. Eğer problem mevcut akıştaki kopuşu görmekle ilgiliyse analytics, session replay veya usability test daha doğal görünür.

Bir hiring panel’de şu soru hızlıca oluşur: Bu yöntem bu problem için neden seçildi? Case study bunu cevaplıyorsa, süreç daha güvenilir görünür.

Kullanabileceğiniz pratik formül

Aşağıdaki yapı çoğu UX case study için iyi bir başlangıç verir:

[Kullanıcı grubu], [belirli bir bağlamda], [hangi sürtünmeyle] karşılaşıyordu. Bu durum [davranış, iş sonucu veya deneyim etkisi] yaratıyordu. Bu nedenle çalışmanın odağı [net tasarım alanı] olarak belirlendi.

Örnek:

İlk kez yatırım ürünü kullanan kullanıcılar, risk bilgisini okurken hangi kararın kendilerine ait olduğunu anlamakta zorlanıyordu. Bu durum, işlem öncesi geri dönüşleri artırıyordu. Bu nedenle çalışmanın odağı, risk bilgisini daha anlaşılır bir karar akışına yerleştirmek olarak belirlendi.

Sıkça Sorulan Sorular

Problem tanımı kaç cümle olmalı? Genellikle 3 ila 5 cümle yeterlidir. Ama problem karmaşıksa kısa bir bağlam paragrafı eklenebilir.

Problem statement İngilizce mi kullanılmalı? Türkçe içerikte “problem tanımı” daha doğal. Başlık içinde SEO için “problem statement” kullanılacaksa bağlama dikkat edilmeli.

İş metriği yoksa problem tanımı zayıf mı olur? Hayır. Her projede metrik olmayabilir. Kullanıcı davranışı, destek talebi, gözlem veya test bulgusu da problem tanımını güçlendirebilir.

Problem tanımı ile hedef aynı şey mi? Değil. Problem mevcut durumu açıklar. Hedef, bu problem karşısında neyi iyileştirmek istediğinizi söyler.

Çözümü problem tanımında söylemeli miyim? Çözümü erken söylemek case study’nin akışını zayıflatabilir. Önce karar alanını kurmak daha iyi çalışır.