UX tasarımı nedir? Adım adım UX tasarım süreci

Kısaca

UX tasarımı, ekrana bir şey çizmeden önce sorulan sorularla başlar. Bu ürünü kim kullanacak, ne yapmaya çalışıyor, nerede takılıyor? Çizim, bu soruların cevabından sonra gelir.

Kavramın kendisini UX (kullanıcı deneyimi) sözlük sayfasında tanımladım. UI ile UX arasındaki farkı ise UI UX nedir rehberinde ayrıca anlattım. Bu sayfa işin nasıl yapıldığına, yani sürece odaklanıyor.

Sürecin tek bir kuralı var: son sözü kullanıcıdan gelen bilgi söyler. Buna kullanıcı merkezli tasarım denir. Bu yaklaşımın uluslararası standardı ISO 9241-210'dur.

UX tasarım süreci: yedi adım

Ben süreci yedi adıma bölüyorum. Her adımın elle tutulur bir çıktısı var. Çıktısı olmayan adım, toplantı olarak kalır.

Süreç şeması

1. 1Araştır

   1. Araştır

   Çıktı

   Kullanım bağlamı notu: kim kullanıyor, hangi amaçla, hangi cihazda. Görüşme notları ve kullanıcı grubu profilleri.

   Süre

   Kapsama ve kullanıcıya ne kadar kolay ulaştığınıza göre değişir. Yeni bir üründe sürecin en uzun adımlarından biri olabilir.

   Araçlar

   Görüşme rehberi, görüntülü görüşme ve kayıt, analitik paneli, destek talepleri.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Kullanım bağlamını anla ve belirle. Double Diamond: Keşfet.

2. 2Tanımla

   2. Tanımla

   Çıktı

   Tek cümlelik problem tanımı, kullanıcı gereksinimleri listesi ve bu gereksinimlerin öncelik sırası.

   Süre

   Kısa ve yoğun bir adım. Araştırma notları hazırsa birkaç ortak çalışma oturumunda biter.

   Araçlar

   Dijital beyaz tahta (notları kümelemek için), ortak doküman.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Kullanıcı gereksinimlerini belirle. Double Diamond: Tanımla.

3. 3Fikir üret

   3. Fikir üret

   Çıktı

   Akış taslakları, kaba eskizler ve aralarından seçilmiş birkaç çözüm yönü.

   Süre

   Bilerek kısa tutulur. Önce çok seçenek çıkar, sonra çoğu elenir.

   Araçlar

   Kâğıt ve kalem, beyaz tahta, akış şeması aracı.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Tasarım çözümleri üret. Double Diamond: Geliştir.

4. 4Proto­tiple

   4. Prototiple

   Çıktı

   Wireframe, kullanım senaryoları ve tıklanabilir prototip. Kaba sürümden gerçeğe yakın sürüme doğru ilerler.

   Süre

   Prototipin doğruluk seviyesine bağlıdır. Kaba bir taslak hızlı çıkar, gerçeğe yakın bir prototip daha uzun sürer.

   Araçlar

   Figma gibi bir tasarım aracı, kâğıt prototip ya da doğrudan kod.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Tasarım çözümleri üret. Double Diamond: Geliştir.

5. 5Test et

   5. Test et

   Çıktı

   Kullanılabilirlik testi raporu: kim nerede takıldı, hangi sorun ne kadar ciddi, sırada ne var.

   Süre

   Tek bir tur kısadır. Az kişiyle sık test etmek, seyrek ve büyük testten daha çok şey öğretir.

   Araçlar

   Prototip bağlantısı, görüntülü görüşme, ekran kaydı, not şablonu.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Tasarımı gereksinimlere göre değerlendir. Double Diamond: Teslim et (küçük ölçekte dene).

6. 6Yayınla

   6. Yayınla

   Çıktı

   Geliştirmeye hazır tasarım dosyası, bileşenler ve sonunda canlıdaki arayüz.

   Süre

   Ekibe ve kapsama göre değişir. Küçük parçalar halinde yayınlamak öğrenmeyi hızlandırır.

   Araçlar

   Tasarım dosyası, tasarım sistemi, kod deposu.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Tasarım çözümleri üret (uygulanan arayüz). Double Diamond: Teslim et.

7. 7Ölç

   7. Ölç

   Çıktı

   Metrik panosu, saha notları ve kullanıcı anketi sonuçları. Bir sonraki turun araştırma girdisi buradan çıkar.

   Süre

   Bitmez. Ürün canlıda kaldığı sürece devam eder.

   Araçlar

   Web analitiği, anket formu, destek talepleri, oturum kaydı aracı.

   Çerçevelerdeki karşılığı

   ISO 9241-210: Değerlendir (uzun vadeli izleme). Double Diamond: Yeniden keşfet.

Döngü: Test sonucu yetmezse Tanımla ya da Prototiple adımına dönülür. Ölç adımı da bir sonraki turun Araştır adımını besler.

Bir adıma basın: altında o adımın çıktısı, ne kadar sürdüğü ve hangi araçlarla yapıldığı görünür. Süreler bilerek rakamsız verildi, çünkü her projede değişir.

Şemadaki sırayı bir öneri olarak okuyun. Küçük bir değişiklikte araştırma, birkaç destek talebini okumaktan ibaret olabilir. Yeni bir üründe ise çoğu zaman en uzun adımlardan biridir.

Sürecin dayandığı iki çerçeve

Yedi adımı kendim uydurmadım. İki yaygın çerçeveden yola çıktım ve onları günlük işe uyarladım. Biri ISO 9241-210, diğeri Design Council'ın Double Diamond modeli.

ISO 9241-210: insan odaklı tasarım

ISO 9241-210, etkileşimli sistemler için insan odaklı tasarım standardıdır. Bu rehberde 2019'da yayımlanan ikinci baskıya dayanıyorum. Standart belirli bir tasarım süreci varsaymaz, şelale gibi farklı yöntemlerin içine de eklenebilir.

Standart dört etkinlik sayar:

1. Kullanım bağlamını anla ve belirle.
2. Kullanıcı gereksinimlerini belirle.
3. Bu gereksinimleri karşılayan tasarım çözümleri üret.
4. Tasarımı gereksinimlere göre değerlendir.

Standardın Tablo 1'i, her etkinliğin örnek çıktılarını da verir. Bağlam adımından kullanıcı grubu profilleri ve personalar çıkar. Tasarım adımı düşük ve yüksek doğruluklu prototipler, değerlendirme ise kullanılabilirlik testi raporu üretir.

Standardın altı ilkesi de var. En çok dayandığım ikisi şunlar: kullanıcılar tasarım boyunca sürece katılır ve süreç tekrarlıdır. Standart, kullanıcı ihtiyacını eksik ya da yanlış anlamayı sistemlerin başlıca başarısızlık nedenlerinden biri sayar.

Double Diamond: iki elmas, dört aşama

Double Diamond, Birleşik Krallık'taki Design Council'ın 2004'te tanıttığı modeldir. İki elmastan oluşur. Her elmasta önce konu genişletilir, sonra odaklanılır.

İlk elmas problemle ilgilidir. Keşfet aşaması, problemi varsaymak yerine anlamaya çalışır. Tanımla aşaması, toplanan içgörüyle problemi yeniden çerçeveler.

İkinci elmas çözümle ilgilidir. Geliştir aşamasında farklı cevaplar üretilir. Teslim et aşamasında çözümler küçük ölçekte denenir, işe yaramayanlar bırakılır.

Design Council, modelin doğrusal bir süreç olmadığını açıkça yazar. Kurumun inovasyon çerçevesindeki dört ilkeden biri doğrudan "tekrarla, tekrarla, tekrarla" der.

Yedi adım bu iki çerçeveye nasıl oturuyor

Adım	ISO 9241-210	Double Diamond
1. Araştır	Kullanım bağlamını anla ve belirle	Keşfet
2. Tanımla	Kullanıcı gereksinimlerini belirle	Tanımla
3. Fikir üret	Tasarım çözümleri üret	Geliştir
4. Prototiple	Tasarım çözümleri üret	Geliştir
5. Test et	Tasarımı gereksinimlere göre değerlendir	Teslim et (küçük ölçekte dene)
6. Yayınla	Tasarım çözümleri üret (uygulanan arayüz)	Teslim et
7. Ölç	Değerlendir (uzun vadeli izleme)	Yeniden keşfet

Benim eklediğim fark şu: iki çerçeve de yayından sonrasını ayrı bir adım olarak çizmez. Ben yayınla ve ölç adımlarını ayrı tutuyorum. Küçük ekiplerde en sık atlanan kısım burası.

Adımlar tek tek

1. Araştır

Amaç, kullanım bağlamını anlamak. ISO 9241-210 bağlamı kullanıcılar, hedefler, görevler, kaynaklar ve ortamın bileşimi diye tanımlar. Yani ekranın önündeki kişi kadar, o kişinin ekrana hangi koşulda baktığı da önemlidir.

Bir e-ticaret sitesinde iade akışını yeniden tasarladığınızı düşünün. Önce iade talebi açan birkaç müşteriyle konuşur, destek ekibinin en sık aldığı soruları okursunuz. Çoğu zaman müşteri formu doldurabilir. Asıl takıldığı yer, iadenin nereden başlatıldığını bulmaktır.

2. Tanımla

Araştırma notlarını kümeler ve tek bir problem cümlesine indirirsiniz. "Müşteri, siparişler sayfasında iadeyi başlatan yeri bulamıyor" iyi bir cümledir. "İade deneyimi kötü" ise hiçbir şey söylemez.

Ardından gereksinimleri yazarsınız. Çelişen istekler varsa hangisinin öne geçeceğine bu adımda karar verilir.

3. Fikir üret

Bu adımda tek bir çözüme hemen bağlanmayın. Ben önce kaba eskizlerle birçok yol çizerim, sonra çoğunu elerim. Double Diamond'daki ikinci elmasın genişleyen kısmı tam olarak budur.

İade örneğinde iki yol öne çıkabilir: sipariş kartına bir "İade et" butonu ya da kargo bildirimine bir bağlantı. Hangisinin doğru olduğunu henüz bilmezsiniz. Bunu test söyleyecek.

4. Prototiple

Seçtiğiniz yönü, test edilebilecek bir şeye çevirirsiniz. ISO 9241-210 prototipi geniş tanımlar: basit bir eskiz de olabilir, neredeyse tamamı çalışan bir sistem de.

Ben genelde gri kutulu bir wireframe ile başlarım. Akış oturunca tıklanabilir bir prototipe geçerim. Prototip gereğinden gerçekçi olursa katılımcı akıştan çok renklere bakar.

5. Test et

Prototipi gerçek kullanıcının önüne koyar ve bir görev verirsiniz: "Geçen hafta aldığınız ayakkabıyı iade edin." Sonra susup izlersiniz.

Akışın ne kadar kullanılabilir olduğunu bu izleme gösterir. Kişinin nerede durakladığı, ne söylediğinden daha çok şey anlatır.

Kaç kişi gerektiği sık sorulur. Jakob Nielsen 2000'de yazdığı makalede, beş kullanıcıyla yapılan ilk testin kullanılabilirlik sorunlarının yüzde 85'ini bulduğunu söyler. Bu yüzden on beş kişilik tek test yerine beşer kişilik üç test önerir.

Testten bir bulgu listesi çıkar. Bulguları nasıl yazıp önem derecesine göre sıraladığımı UX audit rehberinde anlattım.

6. Yayınla

Tasarım, kullanıcı ona dokunana kadar bir hipotezdir. Bu adımda tasarım dosyası geliştirmeye hazır hale gelir ve arayüz canlıya çıkar.

Tasarımcıyla geliştirici arasında kaybolan ayrıntıyı en çok bu adımda görüyorum. Boş durumlar ve hata mesajları tasarımda vardır, kodda unutulur. Tasarım ve kod aynı kişideyse bu kayıp azalır.

7. Ölç

Canlıdaki ürün, prototipin söyleyemediği şeyleri söyler. İade talebi açan kişi sayısı arttı mı, destek ekibine gelen "iade nerede" sorusu azaldı mı?

ISO 9241-210 bu kısmı da değerlendirmenin içinde sayar ve uzun vadeli izleme sonuçlarını bir çıktı olarak listeler. Design Council da hiçbir fikrin tam olarak bitmediğini yazar. Ölçümden çıkan soru, bir sonraki turun araştırmasıdır.

Örnek: bir banka uygulamasında yedi adım

Kurgusal bir örnek: bir bankanın mobil uygulamasında otomatik fatura talimatı az kullanılıyor. Ekip talimat ekranını yenilemek istiyor. Süreç şöyle işler.

1. Araştır. Ekip, faturasını her ay elle ödeyen birkaç müşteriyle görüşür. Çoğu talimat özelliğinin varlığından haberdar değildir. Bilenlerin bir kısmı da yanlış tutarın çekileceğinden korkar.

2. Tanımla. Problem cümlesi şöyle yazılır: müşteri, talimatın ne zaman ve ne kadar çekeceğini önceden göremiyor. Gereksinim de buradan çıkar: çekimden önce bir bildirim ve bir iptal yolu.

3. Fikir üret. Fatura ödendikten sonra çıkan bir öneri kartı, ayrı bir talimat sayfası ve çekimden önce gelen bir bildirim çizilir. Ekip öneri kartıyla bildirimi birlikte denemeye karar verir.

4. Prototiple. Önce kâğıtta akış çizilir. Sonra öneri kartı ve bildirim ekranı tıklanabilir hale getirilir.

5. Test et. Beş kişiyle yapılan turda iki kişi bildirimin tarihini okuyamaz. Ekip tarihi büyütür ve tutarın yanına taşır, sonra yeni bir tur yapar.

6. Yayınla. Değişiklik önce kullanıcıların küçük bir kısmına açılır. Hata mesajları ve iptal ekranı da bu sürümde hazırdır.

7. Ölç. Ekip yeni talimat sayısına ve iptal oranına bakar. İptaller beklenenden yüksekse araştırma adımına döner ve nedenini müşterilere sorar.

Bu örnekte hiçbir adım haftalar sürmüyor. Adımlar küçük, ama hiçbiri atlanmıyor. Benim işlerim de çoğu zaman bu ölçekte ilerliyor.

Testte bulunan sorunları adlandırmak için Nielsen'in 10 ilkesi ortak bir dil verir. Örnekteki tarih sorunu, sistem durumunun görünürlüğü ilkesiyle ilgilidir.

Süreç düz bir çizgi değil

Yedi adım liste halinde yazılınca sırayla gidiliyormuş gibi görünür. Gerçekte süreç bir döngüdür. ISO 9241-210, etkileşimli bir sistem için en uygun tasarıma genelde tekrar olmadan ulaşılamayacağını yazar.

Standart bunun nedenini de açıklar. Kullanıcı ihtiyaçlarının çoğu ancak geliştirme sırasında ortaya çıkar. Kullanıcılar da ihtiyacını, önüne olası bir çözüm konunca daha iyi anlatır. Bu yüzden ilk gün her ayrıntıyı tam ve doğru yazmak mümkün değildir.

Pratikte bu şu demek: test kötü geçerse prototiple adımına dönersiniz. Problem yanlış tanımlandıysa tanımla adımına. Design Council da benzer bir uyarı yapar: yolda ortaya çıkan bir sorun, ekibi bazen en başa geri gönderir.

Küçük bir ekipte süreç nasıl işler

Yedi adım, büyük bir araştırma ekibi istiyormuş gibi görünebilir. Oysa küçük bir ekip de hepsini yürütebilir. ISO 9241-210, kullanıcıların sürece ne sıklıkla katılacağının projenin türüne göre değiştiğini yazar.

Tek kişilik bir girişimde araştırma, birkaç müşteriyle yapılan kısa görüşmeler olabilir. Test için bir prototip bağlantısı ve görüntülü bir görüşme yeter. Adımları atlamayın, her birini küçük tutun.

Benim Tasarla & Yayınla Sprinti bu küçük döngü için kuruldu. Tasarım ve kod iki hafta içinde aynı kişide ilerler, sonuç doğrudan reponuza gider.

Sık hatalar

Araştırmayı atlayıp çizmeye başlamak. Ekran özenle çizilir ama yanlış soruya cevap verir. Standardın ilk ilkesi, tasarımın kullanıcıyı, görevi ve ortamı açıkça anlamaya dayanmasıdır.

Problemi çözümle birlikte tanımlamak. "Bize yeni bir menü lazım" bir problem değil, bir çözümdür. Problem cümlesinde hiçbir arayüz parçasının adı geçmemelidir.

Tek fikre erkenden âşık olmak. İlk eskiz genelde en tanıdık olandır, ama tanıdık olmak doğru olmak demek değil. Birkaç yolu yan yana koymadan seçim yapmayın.

Testi yayından sonraya bırakmak. Canlıdaki bir hatayı düzeltmek, prototipteki bir hatayı düzeltmekten pahalıdır. Küçük ve erken testler bu maliyeti düşürür.

Testi ekip içinde yapmak. Ürünü yapan kişi akışı ezbere bilir. Testi, ürünü hiç görmemiş biriyle yapın.

Yayından sonra durmak. Ölçmeden bir sonraki işe geçerseniz, değişikliğin işe yarayıp yaramadığını hiç öğrenmezsiniz.

Erişilebilirliği sona bırakmak. Kontrast ve klavye kullanımı tasarım adımında düşünülmezse, sonradan eklemek zorlaşır. Ayrıntıları anlattığım yer WCAG rehberi.

Benim notum

Ekiplerle çalışırken en sık gördüğüm şey, sürecin ortasında başlamak. Biri bir ekran fikriyle gelir, ekip doğrudan prototipe geçer. Araştırma ve tanım sonradan yapılır, o da fikri savunmak için.

Ben bu yüzden her işe tek bir soruyla başlıyorum: bu ekranı açan kişi o an ne yapmaya çalışıyor? Cevap net değilse çizime geçmiyorum.

İkinci gözlemim ölçümle ilgili. Ekipler yayın gününü bitiş çizgisi sanır. Oysa asıl öğrenme, ürün birkaç hafta canlıda kaldıktan sonra başlar.