Persona ve görev akışı düşüncesi: Alan Cooper'ın basit yöntemi

Özellik listeleri neden iyi ekranlara dönüşmez

Uzun bir özellik listesi ilerleme gibi gelebilir. Gösterip “Ne inşa ettiğimizi biliyoruz” diyebilirsiniz. Sonra ilk ekranı tasarlamaya çalışırsınız ve liste, kullanıcının şu anda ne yaptığına, bitirmeye çalıştığı işe ya da uygulamanın önce ne göstermesi gerektiğine dair bir şey söylemez.

Özellik listeleri öncelikleri gizler. “Bildirimler”, “arama”, “profiller” ve “ayarlar” hep önemli gibi görünür; bu yüzden her şey aynı seviyeye düşer. Ayrıca niyeti gizlerler. İnsanlar filtreler veya yönetici rolleri istemek için uyanmazlar. Randevu almak, ödeme almak, teslimatı takip etmek veya aileyle fotoğraf paylaşmak isterler.

Bu yüzden özellik listesi vs kullanıcı hedefleri sadece planlama tartışması değildir. Ekranları değiştirir. Hedef “Cuma için saç kesimi randevusu almak” ise, ilk ekran zaman aralıklarını ve net bir sonraki adımı göstermelidir; on özellikten oluşan bir menü değil.

Özellik listeleri ekipleri UI tartışmalarına da erken çeker. İnsanlar düğme yerleşimi, sekme isimleri, karanlık mod ve kaç ayar sayfası olması gerektiği hakkında tartışır. Bu seçimler somut hissedilir, ama uygulamanın birinin tamamlamasına yardım etmesi gereken işi üzerinde anlaşmadan önce yapılan tahminlerdir.

Daha iyi bir başlangıç basit: gerçek bir kullanıcı seçin, onların tek oturumda bitirmek istediği bir işi seçin ve onları sona ulaştıran en küçük adım setini haritalayın. Bunu yaptığınızda ekranlar doğal olarak oluşmaya başlar. Her ekran akıştaki bir adımı destekleyerek yerini hak eder.

Alan Cooper’ın temel fikri: özellikler değil hedefler etrafında tasarla

Alan Cooper, hâlâ geçerli olan bir kaymayı popüler hale getirdi: yazılıma bir özellik yığını gibi davranmayı bırakın, bir etkileşim gibi davranmaya başlayın. Önemli olan uygulamanızın neler yapabildiği değil. Önemli olan bir kişinin neyi başarmaya çalıştığı ve uygulamanın bunu minimum sürtüşmeyle yapmalarına yardımcı olup olmadığıdır.

Bu zihniyet, bugün birçok kişinin Alan Cooper etkileşim tasarımı derken kastettiğidir. Niyete ve sıraya odaklanın. Yolculuğu net tarif edebiliyorsanız, ekranlar neredeyse kendi kendine tasarlanır. Edemiyorsanız, uzun bir özellik listesi sizi kurtarmaz; genellikle her özellik kararlar, düğmeler ve uç durumlar eklediğinden dağınıklık yaratır.

Cooper’ın pratik araç seti iki parçadan oluşur:

• Personalar (kim): Belirli bir kullanıcı türü seçin ve onların ne yapacağını tahmin edebilecek kadar gerçek kılın.
• Görev akışları (nasıl): O personanın niyetten sonuca ulaşmasını sağlayan en küçük adım setini haritalayın.

Bir akış, özellik listelerinin kaçındığı soruları cevaplamaya zorlar: görevi ne tetikler, “başarı” nasıl görünür, kullanıcı şu anda ne karar vermeli ve her adımda gerçekten hangi bilgiye ihtiyaç var.

Eğer sohbet tabanlı bir vibe-coding aracı gibi Koder.ai ile inşa etmeyi planlasanız bile, yine de bu netliğe ihtiyacınız var. Aksi halde makul görünen ama baştan sona tatmin edici bir deneyime bağlanmayan pek çok ekran üreteceksiniz.

Personalar: önce tasarlayacağınız bir gerçek kullanıcı seçin

Bir persona, ilk önce tasarladığınız kişi için kısa, inandırıcı bir tanımlamadır. Tam bir biyografi değildir. Sürekli “duruma bağlı” demeyi bırakmanızı sağlayacak kadar ayrıntıdır.

Demografilerle değil, hedefler ve bağlamla başlayın. Aynı “meşgul ebeveyn”, bulundukları yere, cihazlarına ve üzerlerindeki baskıya bağlı olarak farklı davranır. Ürün tasarımı için iyi personelar o kısıtlamaları somutlaştırır, böylece ekranlarınızın net bir amacı olur.

Persona çok belirsizse, bunu hissedersiniz. “Herkes” gibi görünmeye başlar, çoğunlukla demografiye dönüşür, tercihleri listeler ama net bir hedef göstermez ve bu kişinin bugün uygulamayı neden kullanacağı açıklanamaz.

Personayı hafif tutun. Birkaç satır yeterlidir:

• kim olduğu (rol),
• uygulamayı ne zaman ve nerede kullandığı (bağlam),
• en önemli hedefi (basit sözlerle),
• bugün onu yavaşlatan şey (sorun),
• “başarı” nasıl görünür (basit, test edilebilir bir kazanım).

Örnek: “Mina, bir diş kliniği resepsiyonisti, hastalar arasında telefonundan uygulamayı kullanıyor. Hedefi yarının randevularını hızlıca onaylamak. Sorunu ise cevap vermeyen insanları takip etmek. Başarı, bir dakikadan kısa sürede hatırlatma gönderip ‘onaylandı’ durumunu görmek.”

Bir kural daha: persona bir pazarlama hedefi değil, bir tasarım aracıdır. Daha sonra birçok hedef kitle olabilir, ama şimdi bir birincil persona gerekir. Bir ekran hakkında tartışma çıktığında, Mina’ya geri dönün: bu onun gerçek bağlamında hedefine ulaşmasına yardım ediyor mu yoksa sadece başka bir özellik mi?

Görev akışları: önemli adımları haritalayın

Bir görev akışı, bir kişinin tek bir açık hedefe ulaşmak için attığı en küçük adım setidir. Sitemap değildir, özellik listesi değildir ve tam bir yolculuk haritası değildir. “X yapmak istiyorum”dan “X tamamlandı”ya kadar tek bir yoldur.

İyi bir akış tetikleyici ile başlar ve bir başarı durumu ile biter. Tetikleyici, kullanıcının başlamasını sağlayan nedendir: bir ihtiyaç, bir mesaj, bir düğme veya bir sorun. Başarı durumu “tamam”ın düz bir dille nasıl göründüğüdür: “randevu alındı ve onaylandı”, “fatura gönderildi” veya “parola değiştirildi ve giriş yapıldı”. Her ikisini de birer cümleyle tanımlayamıyorsanız, akış hâlâ belirsizdir.

Başlangıç, bitiş ve aradaki kararlar

Çoğu akış karar çıkana kadar basittir. Kararlar sonraki adımı değiştiren çatallardır; örneğin “Zaten hesabın var mı?” veya “Bu ürün stokta mı?” gibi. Bu çatalları erken belirtmek, mükemmel bir mutlu yol tasarlayıp gerçeğin ortaya çıkmasıyla bozulan bir akıştan kaçınmanıza yardımcı olur.

Bir akışı fazla düşünmeden şekillendirmek için beş soruyu yanıtlayın:

• Görevi ne başlatıyor?
• Tek bir başarı anı nedir?
• Hangi bilgiler gerekli (ve hangi bilgiler isteğe bağlı)?
• Hangi kararlar yolu değiştirebilir?
• Ne ters gidebilir ve ters gittiğinde kullanıcı ne görmeli?

Kullanıcıların güvenceye ihtiyaç duyduğu yerler

İnsanlar belirsiz hissettiklerinde görevleri bırakırlar. Akışınız güvence gereken anları işaretlemeli: ilerleme, durum, onay ve net hatalar.

Basit bir örnek “şifremi sıfırla”. Tetikleyici: “Giriş yapamıyorum.” Başarı: “Hesabıma geri döndüm.” Karar: “E-postaya erişiminiz var mı?” Güvence noktaları: “e-posta gönderildi”, “bağlantı süresi doldu”, “şifre değiştirildi”, “giriş yapıldı”. Bunlar yazıldığında ekranlar açıkça ortaya çıkar çünkü her adımın gerçekleşmesi için bir yer ve şüpheyi ortadan kaldıracak bir mesaj gerekir.

Hafif bir yöntem: belirsiz fikirden net ilk akışa

Çoğu uygulama fikri isim yığını olarak başlar: gösterge paneli, sohbet, takvim, ödemeler. Netliğe giden daha hızlı yol fikri bir vaat, bir kişi ve bir adım dizisine zorlamaktır.

Önce ön sayfada olabilecek bir cümle yazın. Birinin kafa sallayıp “Hayır, bu ben değilim” diyebileceği kadar spesifik olsun. Örnek: “Serbest tasarımcıların daha hızlı ödeme almasına yardımcı olmak: temiz bir fatura gönderip 2 dakika içinde kartla ödeme almak.”

Sonra birincil personayı seçin. “Herkes” değil, “küçük işletmeler” değil. Normal bir Salı günü hayal edebileceğiniz bir kişiyi seçin. Üç farklı kişi için aynı anda tasarım yaparsanız, kimseye yardımcı olmayan ekstra ekranlar eklersiniz.

Sonra önce tasarlayacağınız bir hedef seçin; ideal olarak ana değeri yaratan hedef. “Düzenli hissetmek” belirsizdir. “Fatura gönder ve görüntülendiğini doğrula” nettir.

Tekrarlanabilir süreç şöyle görünür:

1. Bir cümlelik vaat yazın (kim + sonuç + süre/çaba).
2. Birincil personayı ve bir ana kısıtlamayı tanımlayın (zaman, cihaz, beceri).
3. Mutlu yolu kısa fiillerle taslaklaştırın (seç, gir, gözden geçir, onayla, öde).
4. Akışı kırılmasın diye 2–3 gerçekçi hata anı ekleyin.

Akış bir sayfaya sığana kadar özellik listesi yazmayın. Kısa ve öncelikli tutun: adımları mümkün kılan birkaç özellik ve bu hatalardan kurtulmak için gereken asgari araçlar.

Koder.ai gibi bir araç kullanıyorsanız, planlama modu burada yardımcı olur. Vaat, persona ve akışı tek bir yere yapıştırın ve ekip ekranlar ve kod çoğalmadan önce hizalanmış kalsın.

Akışı ekranlara ve aksiyonlara dönüştürmek (UI üzerinde fazla düşünmeden)

Bir görev akışı niyetler dizisidir. Şimdi her adımı ya kullanıcının ulaştığı bir ekrana ya da mevcut bir ekranda yaptığı tek bir aksiyona dönüştürün.

Açık tutun: bir adım = bir net sonuç. Bir adım iki sonuç veriyorsa, genellikle iki adımdır.

Ekranlara amaçlarına göre isim verin, görünüm parçalarına göre değil. “Saat seç” “Takvim ekranı”ndan, “Detayları onayla” “Form sayfası”ndan daha iyidir. Amaç isimleri ekranın ne yapması gerektiğine odaklanmanızı sağlar, neye benzediğine değil.

Bir akışı ekranlara çevirirken her adım için üç şeyi belirleyin: kullanıcının ne görmesi gerekiyor, ne seçmesi gerekiyor ve ne girmesi gerekiyor. Sonra mantıklı bir sonraki aksiyonu seçin (genellikle tek bir birincil düğme). Bu adımı tamamlamaya yardımcı olmayan her şeyi çıkarın.

Gezinim sıkıcı olmalı. Her ekran şu soruyu yanıtlamalı: “Sonraki ne yapmalıyım?” Eğer birinin bir sonraki hareketi bulmak için menüye ihtiyacı varsa, ekran çok fazla şey yapmaya çalışıyor demektir.

Ayrıca temel durumları not olarak yakalayın, tam tasarım olarak değil: yükleniyor, boş, başarı, hata ve ana aksiyonun ne zaman devre dışı olması gerektiği. Ekip bunları inşa ederken hatırlasın; günlerce renk tartışmasınlar.

Koder.ai gibi araçlar akış metninizden ekran taslakları çıkarmaya yardımcı olabilir, ama netlik sizden gelir: amaç, gerekli bilgi ve sonraki aksiyon.

Örnek: “bir rezervasyon uygulaması”nı tutarlı ekran setine dönüştürme

Yerel bir derse (yoga, ders, saç kesimi) rezervasyon aldıran basit bir uygulama istiyorsunuz. Bir özellik listesi “arama, takvim, ödemeler, hatırlatmalar” diyebilir. Bu yine size ilk ekranın ne olduğunu veya biri “Rezerve et”e dokunduktan sonra ne olduğunu söylemez.

Bir persona ile başlayın: Sam, bir otoparkta telefonda 60 saniyeden kısa sürede yer ayırtmak isteyen meşgul bir ebeveyn. Sam hesap oluşturmak, 20 seçeneği karşılaştırmak veya uzun açıklama okumak istemez.

Mutlu yolu kısa bir hikaye olarak yazın: Sam uygulamayı açar, doğru dersi hızlıca bulur, bir zaman seçer, adını girer, öder ve net bir onay alır.

Akışı dürüst tutmak için iki uç durum ekleyin: Sam bir zamana dokunduğunda sınıf dolmuş olabilir, veya ödeme başarısız olabilir.

Bu akıştan çıkan ekranlar basit olur:

• Ders bul: yakındaki/gelecek seçenekler, basit gün/zaman filtresi ve net kartlar (başlık, başlangıç zamanı, fiyat, kalan kontenjan).
• Ders detayları: ilk olarak sonraki müsait zamanlar, süresi ve mekân gibi temel bilgiler ve birincil eylem: zaman seç.
• Saat seç: müsait slotlar, açıkça tükenmiş etiketleri ve tarihe hızlı geçiş.
• Kişisel bilgiler: bir veya iki alan (isim, makbuz için telefon/e-posta) ve devam düğmesi.
• Ödeme: toplam tutar, ödeme yöntemi ve tek bir ödeme eylemi.
• Onay: rezervasyon detayları ve bir sonraki adım (takvime ekle veya rezervasyonu görüntüle).

“Tükenmiş” olduğunda bunu saat seçicide ele alın: basitçe açıklayın, en yakın uygun zamanı önerin ve Sam’i aynı ekranda tutun. Ödeme başarısız olduğunda girilmiş bilgileri koruyun, ne olduğunu normal dille söyleyin ve “tekrar dene” ile “başka yöntem kullan” seçeneklerini sunun.

Koder.ai ile bunu inşa ediyorsanız, akış metninden bu ekranları oluşturmasını isteyebilir, sonra 60 saniyelik hedef gerçek hissedene kadar metinleri ve alanları sıkıştırabilirsiniz.

Akışların bozulmasına neden olan yaygın tuzaklar

Akışlar genellikle tek bir nedenle bozulur: kalabalık için tasarlarsınız, bir kişi için değil. Persona “herkes” olduğunda her karar bir uzlaşma olur. Biri hız ister, diğeri rehberlik, diğeri tam kontrol ister. Sonuç, kimseye hizmet etmeyen şişkin bir akıştır.

Çözüm persona daraltmaktır. “Meşgul profesyoneller” değil, “telefonla randevu alan ve arada çalışan bir resepsiyonist” veya “çatlamış ekranlı çocuğu için saç kesimi alan bir ebeveyn” gibi spesifik birini seçin. Günlerini hayal edebildiğinizde neyi kesmeniz gerektiğine karar verebilirsiniz.

Diğer bir başarısızlık modu, ilk taslağınızı depolayabildiğiniz şeylerden başlatmaktır. Eğer ilk taslak veri tabanı alanlarına ve iç yönetici adımlarına dayanıyorsa, ürün uzun formlara dönüşür ve ana görev gömülür. İnsanlar “alan doldurmak” için uyanmaz; rezervasyonu onaylamak, ödemek, hatırlatma almak isterler.

Üçüncü tuzak “önce ekstralar” düşüncesidir. Ayarlar, tercihler, roller, etiketler ve özelleştirme kolayca listelenir, bu yüzden erken karışır. Ama çekirdek görev zayıfsa, ekstralar sadece daha fazla yol ve daha fazla kafa karışıklığı ekler.

Koder.ai ile hızlı ekran üretiyorsanız aynı risk geçerlidir: hız yalnızca akışı dürüst tutuyorsanız faydalıdır — bir persona, bir hedef, her ekranda bir net sonraki adım.

Başlamadan önce hızlı kontrol listesi

Bir tasarım aracını açmadan veya koda başlamadan önce fikrinizin gerçekten tamamlanabilir ekranlara dönüşüp dönüşemeyeceğini kontrol edin.

Birincil personanın hedefini bir cümlede ve net bir bitiş çizgisiyle söyleyebilmelisiniz: “Cumartesi 11:00 için saç kesimi randevusu al ve bir onay al.” Mutlu yol bir sayfaya sığmalı. Eğer yayılıyorsa, muhtemelen iki görev karışmış ya da aynı anda birden fazla persona için çözüm üretiyorsunuz demektir.

Her ekranın amacıyla isimlendirildiğini ve bir akış adımıyla ilişkilendirildiğini kontrol edin (amaç, widgetlardan daha önemlidir). Kararları ve onayları açık hale getirin; ima edilen değil. Kullanıcının bir şeyi seçmesi gerekiyorsa, seçimi gösterin. Önemli bir şey olduysa, onay veya net bir hata gösterin.

Sonra görevi ilerletmeyen her şeyi kesin. Bir ekran kullanıcının karar vermesine, bilgi girmesine, ödeme yapmasına veya onaylamasına yardımcı olmuyorsa, genellikle ilk sürüm için gürültüdür.

Akışı bir hikaye gibi yüksek sesle okuyun: “X istiyorum, A yapıyorum, sonra B, sonra onaylıyorum, sonra bitiyor.” Takıldığınız yerler tasarım problemleridir.

Koder.ai kullanıyorsanız, bu aynı zamanda güçlü bir başlangıç istemidir: bir cümlelik hedefi ve mutlu yol adımlarını yapıştırın, sonra minimum ekran ve aksiyon setini isteyin.

Sonraki adımlar: ilk sürümü planlayın ve inşa etmeye geçin

Personanın hedefine ulaşabileceğini en iyi kanıtlayan tek akışı seçin. Ona omurga gibi davranın. Diğer her şey bu uçtan uca çalışana kadar isteğe bağlıdır.

Bu akışı küçük bir inşa planına dönüştürün: kişinin ziyaret ettiği birkaç ekran, her birinde yaptıkları eylemler, sistemin bilmesi gereken asgari veri, ele alınması gereken kısa bir hata listesi ve “tamamlandı”yı doğrulayan başarı durumu.

Sonra neyi keseceğinize karar verin. Kesmek yalnızca asgari olmak değil; ana hedefin zahmetsiz hissetmesini sağlamak içindir. Bir özellik bugünkü akışı bitirmeye yardımcı olmuyorsa, “daha sonra”ya gider.

Planı kendi üzerinizde test ederek doğrulayın. Persona tanımını okuyun ve adımları onların yerine yapın. Eksik bilgi hemen ortaya çıkar: Tarih nereden geldi? Seçimi nasıl değiştiririm? Hata yaparsam ne olur?

Daha hızlı ilerlemek istiyorsanız, Koder.ai planlama modunu kullanarak persona ve akışı sohbet içinde yineleyin, sonra ekranları üretin. İnşa etmeye başladığınızda, anlık görüntüler (snapshots) ve geri alma (rollback) özellikleri küçük bir değişikliğin yolu bozması durumunda hızla geri dönmenize yardımcı olur.