Startuplar için UX: hangi aşamada ne kadar?

Kısaca: aşamaya göre UX

Erken aşamada UX'in asıl işi, neyi yapmayacağınıza karar vermektir. Doğru görevle gösterilen bir kâğıt taslak, cilalı on ekrandan daha çok şey öğretir.

Aşağıdaki tablo bu rehberin özeti. Her satırı ayrı başlıkta açıyorum.

Aşama	Asıl soru	UX'in işi
Fikir	Bu sorun gerçek mi?	Görüşme ve kâğıt taslak.
MVP	Çözümümüz işe yarıyor mu?	Tek akış, küçük testler.
İlk müşteriler	Neden bırakıyorlar?	İlk oturum ve destek mesajları.
Büyüme	Bu hızı nasıl koruruz?	Tasarım sistemi ve düzenli araştırma.

Fikir aşaması: önce sorunu dinleyin

Bu aşamada ekran tasarlamanıza gerek yok. Sorunu yaşayan insanlarla konuşun. Onlara ürününüzü anlatmak yerine bugün o işi nasıl çözdüklerini sorun.

Paul Graham, 2013 tarihli "Do Things that Don't Scale" yazısında ilk kullanıcıların elle bulunması gerektiğini anlatır. Kurucu onları beklemez, kendisi gidip bulur. Bu görüşmeler aynı zamanda ilk UX araştırmanızdır.

Bir çözüm fikri belirdiğinde onu kâğıda çizin. Jakob Nielsen'in 2003 tarihli kâğıt prototip yazısına göre erken toplanan kullanılabilirlik verisi, geç toplanandan en az on kat fazla fayda sağlar. Aynı yazıdaki en yaygın tahmine göre kod yazılmadan önce yapılan bir değişiklik 100 kat daha ucuzdur.

Görüşmede ne sorulur?

Görüşmede fikrinizi onaylatmaya çalışmayın, kişinin geçmişte ne yaptığını dinleyin. "Böyle bir uygulamayı kullanır mıydınız?" sorusuna nezaketen evet demek kolaydır ve bu cevap size bir şey öğretmez.

Bunun yerine somut ve geçmişe dönük sorular sorun:

• Bu işi en son ne zaman yaptınız? Adım adım anlatır mısınız?
• En çok nerede zorlandınız? O an ne yaptınız?
• Bugün bunun için hangi aracı kullanıyorsunuz, ne kadar ödüyorsunuz?
• Bu sorunu çözmek için daha önce bir şey denediniz mi?

Notları aynı gün yazın ve kişinin kendi kelimelerini koruyun. Bu kelimeler ileride buton metinleri ve menü adları olacak.

Kâğıt taslakla deneme

Kâğıt taslağı birkaç kişinin önüne koyun ve bir görev verin, örneğin "Faturanızı buradan nasıl ödersiniz?" Nereye dokunduklarını ve nerede durduklarını yazın.

Kâğıt taslak, wireframe, mockup ve prototip basamaklarından önce gelir ve hepsinden ucuzdur. Logo ve ayrıntılı ekranlar bekleyebilir, çünkü ikisi de "bu sorun gerçek mi" sorusunu cevaplamaz.

MVP: tek akış, küçük testler

"MVP tasarımı nereden başlamalı" sorusunun cevabı, ürünün tek temel akışıdır. Bu akış, kullanıcının ürünü açma sebebi olan iştir. Profil ekranı ya da bildirim ayarları bekleyebilir.

Eric Ries, 2009 tarihli yazısında MVP'yi, müşteriler hakkında en az emekle en çok doğrulanmış bilgiyi toplamanızı sağlayan sürüm diye tanımlar. Ries'e göre MVP küçük bir ürün yapmak demek değildir. Amaç öğrenmektir. Terimin kendisini MVP sözlük sayfasında ayrıca anlattım.

Ries bir de şu uyarıyı yapar: ilk sürümden öğrenmek çoğu zaman emek ister. Müşteriyle konuşmaya ya da sayılara bakmaya ciddi zaman ayırmanız gerekir. Bu yüzden MVP'yi yayınlayıp beklemek yetmez.

Akışı yayından önce test edin. Nielsen'in 2000 tarihli yazısına göre beş kullanıcı, bir tasarımdaki kullanılabilirlik sorunlarının yaklaşık %85'ini bulur.

Nielsen tek büyük test yerine bütçenizin elverdiği kadar çok küçük test önerir. Sorunları düzeltir, düzeltmenin işe yarayıp yaramadığını bir sonraki testte görürsünüz. Kaç kişiyle ne zaman test edeceğinizi kaç kullanıcıyla test rehberinde anlattım.

Örnek: küçük işletmeler için ön muhasebe uygulaması

Diyelim ki esnaf ve serbest çalışanlar için bir ön muhasebe uygulaması yapıyorsunuz. Aklınızda bir sürü özellik var: gider takibi, stok, raporlar, banka bağlantısı. Hepsi makul görünür.

Temel akışı bulmak için tek bir soru sorun: kullanıcı uygulamayı neden açar? Cevap, müşterisine fatura kesmektir.

MVP bu akışı uçtan uca çalıştırır. Kullanıcı müşteriyi seçer, kalemleri girer ve faturayı gönderir. Geri kalan her şey ikinci sürümün listesine yazılır.

Testte beş kişiye "Dün yaptığınız iş için müşterinize fatura kesin" görevini verin. Kaç kişinin bitirdiğine ve nerede durduklarına bakın. Bir kişi bile KDV oranını seçerken takıldıysa, raporlardan önce orayı düzeltirsiniz.

Görsel tasarımda hazır bir arayüz kütüphanesiyle başlayın. Kendi bileşen setinizi çizmek bu aşamada zaman kaybıdır. Butonun rengini değil, butonun yerini test edin.

İlk müşteriler: neden bıraktıklarını bulun

Ürün yayında ve birkaç müşteriniz var. Artık sormanız gereken şu: bazı kullanıcılar neden bırakıyor? Cevabı aramaya ilk oturumdan başlayın.

Yeni kullanıcının kayıttan ilk değere kadar geçtiği adımları sayın. Hangi adımda en çok kişi duruyor? Onboarding ekranları ve boş durumlar bu aşamanın asıl işidir.

Destek mesajlarını bir listeye toplayın ve ekrana göre gruplayın. Aynı ekran üç farklı müşteriden şikâyet alıyorsa, orada büyük ihtimalle bir tasarım sorunu vardır. Bu listede ilk bakacağınız yerlerden biri hata mesajlarıdır.

Graham aynı yazıda Wufoo'nun yeni kullanıcılarına elle yazılmış teşekkür notları gönderdiğini anlatır. Ona göre küçük olmanın bir avantajı, hiçbir büyük şirketin veremeyeceği düzeyde hizmet verebilmektir.

Siz de bazı müşterilerin kurulumunu ekran paylaşarak birlikte yapın. Böylece nerede duraksadıklarını kendi gözünüzle görürsünüz.

Bu aşamada izlemek için tek bir sayı seçin. Örneğin kayıt olanların kaçı ilk faturasını kesti? Bu sayıyı her değişiklikten önce ve sonra karşılaştırın.

Değişiklikleri küçük tutun. Aynı anda beş şeyi değiştirirseniz hangisinin işe yaradığını ayırt edemezsiniz.

Ürününüz bir SaaS ise ilk değere ulaşma süresi ayrı bir konudur. Bunu SaaS UX rehberinde anlattım.

Büyüme: tekrar edeni sisteme bağlayın

Ekip büyüdükçe aynı buton farklı ekranlarda farklı şekillerde çizilmeye başlar. Bu noktada bir tasarım sistemi gerçek bir sorunu çözer. Daha önce kurulan sistem, çoğu zaman henüz var olmayan bir sorunu çözer.

Bu aşamada araştırmayı da takvime bağlayın. Örneğin her ay birkaç kullanıcıyla görüşün, belli aralıklarla bir uzman değerlendirmesi yaptırın. Kurucu artık her müşteriyle konuşamaz, bilgiyi toplayacak bir düzen gerekir.

Erişilebilirliği de bu aşamada sürecin parçası yapın. Sonradan eklenen erişilebilirlik, bitmiş ekranları yeniden açmak demektir. Temel ölçütleri WCAG rehberinde anlattım.

Büyüyen ekipte bir karar kaydı da tutun: hangi ekranı neden böyle tasarladınız, hangi testten ne çıktı? Böylece yeni gelen biri aynı soruyu yeniden sormaz. Eski bir kararı değiştirirken neyi bozacağınızı da bilirsiniz.

Aşama seçici: sizin durumunuzda önce ne gelir?

Aynı aşamada bile ekip yapısı önceliği değiştirir. Tasarımcısı olan bir ekiple yalnızca iki kurucudan oluşan bir ekibin ilk adımı aynı değildir. Aşağıdan kendi durumunuzu seçin.

Aşama seçici

Aşağıdaki liste MVP aşamasındaki, yalnızca kuruculardan oluşan bir ekip için. Diğer aşamalar metinde ayrı başlıklarla anlatılıyor.

MVP · Yalnızca kurucular

Önce bu üç iş

1. Ürünün tek temel akışını seçin. İlk sürümde yalnızca o akış eksiksiz çalışsın.
2. Bu akışı yayından önce beş kişiyle test edin. En çok takıldıkları yeri düzeltin.
3. Hazır bir arayüz kütüphanesi ya da şablonla başlayın. Kendi bileşenlerinizi çizmeyin.

Sonraya kalabilir

• Ayarlar ve profil ekranları
• Karanlık mod
• Animasyonlar
• Eksiksiz tasarım sistemi

Aşamayı ve ekibi seçin. Liste o durumda önce yapılacak üç UX işini ve şimdilik bekleyebilecek işleri gösterir. Bu bir kural değil, benim başlangıç önerim.

Kendi başınıza yapabilecekleriniz

Erken aşamadaki UX işlerinin çoğu için tasarımcı gerekmez, kurucunun zamanı ve dikkati gerekir. Kendi başınıza yapabilecekleriniz:

• Sorunu yaşayan insanlarla görüşmek ve notları aynı gün yazmak.
• Çözümü kâğıda çizip birkaç kişiye bir görevle göstermek.
• Beş kişilik küçük testler yapmak. Kullanıcıdan düşündüğünü sesli söylemesini isteyin, siz yalnızca izleyin.
• Kendi ürününüzü Nielsen'in 10 ilkesine göre ekran ekran gözden geçirmek.
• Destek mesajlarını ekrana göre gruplamak.
• Buton ve hata metinlerini kullanıcının kelimeleriyle yeniden yazmak.

Beş kişilik bir test nasıl yapılır?

1. Ürününüzün hedef kitlesinden beş kişi bulun. Arkadaşınız olmasın, yoksa size nazik davranır.
2. Her birine tek bir gerçekçi görev verin. Ekranınızı paylaşın ya da telefonu kişinin eline verin.
3. Düşündüğünü sesli söylemesini isteyin. Siz yardım etmeyin, yalnızca not alın.
4. Beş oturum bitince en çok tekrar eden iki sorunu seçin ve onları düzeltin.
5. Bir sonraki hafta aynı görevle yeniden deneyin.

Her oturum yarım saat kadar sürebilir. Kayıt alacaksanız kişiden açıkça izin isteyin.

Nielsen 2009'da "indirimli kullanılabilirlik" yaklaşımını üç parçaya ayırır: sesli düşünmeye dayalı basit testler, tek bir yolu destekleyen kâğıt prototipler ve ilkelere göre inceleme. Onun özet cümlesi kurucular için de geçerli: "Bad user testing beats no user testing." Kusurlu bir test, hiç test yapmamaktan iyidir.

Kendi listenizi hazırlamak isterseniz UX audit kontrol listesi iyi bir başlangıçtır.

Ne zaman dış destek almalı?

Dış destek, kendi başınıza yapamadığınız ya da yapacak zamanınız olmayan bir iş varsa anlamlıdır. Ürünü henüz kimse kullanmıyorsa, para harcamadan önce görüşmeleri yapın. Bu durumda "dış destek gerekir mi" sorusunun dürüst cevabı bence "henüz değil"dir.

Şu işaretlerde dışarıdan bir göz işe yarar:

• Bir akışta kullanıcıların bıraktığını biliyorsunuz ama nedenini bulamıyorsunuz.
• Ekip ürüne o kadar alıştı ki yeni gelenin takıldığı yeri artık görmüyor.
• Bir yatırım ya da büyük bir müşteri görüşmesi öncesinde ürünün ilk izlenimi önem kazandı.
• Geliştiriciniz var ama ekranları kimin tasarlayacağı belli değil.

Benim tekliflerim bu işaretlere göre ayrılır. Sorun belli ama nedeni bilinmiyorsa UX Audit ($79, tek akış, 48 saat içinde teslim) ile başlarsınız. Neyin düzeleceği belliyse Tasarla & Yayınla Sprinti iki haftada tasarımı ve kodu reponuza getirir. Sprint $1.999'dur ve 30 gün içinde audit aldıysanız audit ücreti düşülür.

MVP'yi sıfırdan yaptırmak istiyorsanız sabit fiyatlı proje daha uygun olabilir. Ne yapmak istediğinizi anlatırsınız, 24 saat içinde size tek bir fiyat ve teslim tarihi verilir. Hangi modelin size uyduğunu tasarım aboneliği mi, sabit fiyat mı rehberinde karşılaştırdım.

Kurucuların sık yaptığı UX hataları

İlk sürümü cilalamak. Karanlık mod ve animasyonlar hazırdır ama temel akışı kimse test etmemiştir. Cila, yanlış bir akışı daha pahalı hale getirir.

Tasarım sistemini erken kurmak. Üç ekranlık bir ürün için bileşen kütüphanesi yazmak, henüz değişecek kararları dondurur.

Testi büyük bir etkinliğe dönüştürmek. Nielsen, 15 kullanıcılı tek bir çalışma yerine beşer kullanıcılı üç çalışma önerir. Her turdan sonra düzeltin.

Rakibin ekranını kopyalamak. Başka bir ürünün akışı, onun kullanıcıları ve onun iş modeli için kurulmuştur. Kopyalamadan önce kendi kullanıcılarınıza gösterin.

Kendini kullanıcı sanmak. Kurucu ürünü en iyi bilen kişidir. Bu yüzden yeni kullanıcının nerede takıldığını en zor gören de odur.

Benim notum

"Bize güzel bir arayüz lazım" cümlesi bir girişim için zayıf bir başlangıç noktası. Bence ihtiyaç çoğu zaman başka: kullanıcının ilk on dakikada ne yaşadığını görmek.

Bu yüzden ilk sorum şu olur: ürününüzü en son kullanan beş kişiyle ne zaman konuştunuz? Cevap "hiç" ise tasarımdan önce görüşmeleri öneririm.

Bir tasarımcıya para vermeden önce bir öğleden sonranızı ayırın. Beş kişiye ürününüzü kullandırın ve susun. Bana getireceğiniz notlar, bir audit'in de en değerli girdisi olur.