Bir yazılım teslim edilir, her özelliği çalışır ve yine de kimse kullanmak istemez. Bayiler siparişi hâlâ telefonla verir, çünkü portalda bir ürünü bulmak yedi adım sürer, hata mesajı ne yapacaklarını söylemez ve "Sepete ekle" düğmesi aradıkları yerde değildir. Sorun kodda değil, tasarımdadır. UX (kullanıcı deneyimi) tasarımı, bir ürünün gerçek insanlar tarafından bir işi kolayca, hızlıca ve hatasız yapmalarını sağlayacak biçimde tasarlanması işidir.
Bu rehberde UX tasarımı nasıl yapılır sorusunu, tek bir örnek ekran üzerinden, kullanıcı araştırmasından kullanılabilirlik testine ve SUS puanı hesabına kadar adım adım cevaplıyoruz. Rehberi bir eğitim gibi kurduk: yedi ders, her biri bir kavram, bir örnek ve bir ders görevi. Örnek ekranımız, önceki yazılardan tanıdığınız bayi portalının sipariş ekranı. Tasarımcı olmanız gerekmez; bir yazılım projesini sipariş eden, yöneten ya da kabul eden biri olarak iyi tasarımı nasıl isteyeceğinizi ve nasıl ölçeceğinizi öğreneceksiniz.
UX Nedir, UI ile Farkı Nedir?
UX (User Experience, kullanıcı deneyimi), bir kişinin bir ürünü kullanırken yaşadığı bütün deneyimdir: işini ne kadar kolay yaptığı, nerede takıldığı, neye güvendiği ve sonunda ne hissettiği. UI (User Interface, kullanıcı arayüzü) ise bu deneyimin görünen kısmıdır: düğmeler, renkler, yazı tipleri ve ekran düzeni.
Bir benzetmeyle: UI bir restoranın dekoru ve menüsünün tasarımı, UX ise yemeğe oturduğunuzdan hesabı ödeyip çıkana kadar yaşadığınız her şeydir; masa bulmak, sipariş vermek, beklemek, hesap istemek. Dekor çok güzel olabilir, ama garson hiç gelmiyorsa deneyim kötüdür. İyi bir UX, UI'dan önce başlar: kullanıcının kim olduğunu, ne yapmak istediğini ve nerede zorlandığını anlamakla.
Okumanızı öneririz: Web yazılım hizmetimiz: kurumsal siteden müşteri ve bayi portallarına
Bu Rehberi Nasıl Kullanmalısınız?
Dersleri sırayla izleyin; her ders bir öncekinin çıktısını kullanır. Tüm örneklerde bayi portalının sipariş ekranını tasarlıyoruz. Rakamlar temsilidir.
| Ders | Konu | Sonunda yapabildiğiniz |
|---|---|---|
| 1 | Kullanıcı ve problem tanımı | Kimin hangi işte neden zorlandığını tek tabloda yazmak |
| 2 | Kullanıcı araştırması | Doğru yöntemi seçip bulguları cümleye dökmek |
| 3 | Kullanıcı akışı | Bir görevin adım sayısını azaltmak |
| 4 | Wireframe ve prototip | Kod yazmadan tasarımı sınamak |
| 5 | Arayüz ilkeleri ve erişilebilirlik | Ekranı ilkelere göre denetlemek |
| 6 | Kullanılabilirlik testi ve SUS | Tasarımı gerçek kullanıcılarla sınayıp puanlamak |
| 7 | İyileştirme ve ölçüm | Tasarım değişikliğinin etkisini rakamla göstermek |
Ders 1: Kullanıcı ve Problem Nasıl Tanımlanır?
UX tasarımı, bir ekranı çizmeden önce üç soruya yazılı cevap vermekle başlar: kim kullanıyor, hangi işi yapmaya çalışıyor ve neden zorlanıyor? Cevabı olmayan bir tasarım, tasarımcının tahminine dayanır.
| Başlık | Örnek projede |
|---|---|
| Kullanıcı | Bayinin sipariş sorumlusu; haftada birkaç kez, çoğunlukla masa başında ve acele içinde sipariş veriyor |
| Görev | Bilinen ürünlerden tekrar eden bir siparişi hızla vermek |
| Bugünkü engel | Ürünü bulmak için birçok menü açılıyor; son siparişi tekrarlamanın yolu yok |
| Problem cümlesi | Bayi, her hafta aynı ürünleri sipariş etmek için aynı adımları baştan tekrarlıyor ve vazgeçip telefonla veriyor |
| Başarı ölçütü | Görev başarı oranı yükselir, sipariş süresi kısalır, telefonla gelen sipariş azalır |
Başarı ölçütü satırı kritiktir: tasarımın işe yarayıp yaramadığını daha sonra ancak bununla anlarsınız. "Kullanıcı dostu olsun" bir ölçüt değildir; "bilinen bir siparişi dört adımda vermek" bir ölçüttür.
Okumanızı öneririz: Yazılım gereksinim analizi nasıl yapılır? Problem cümlesi ve kullanıcı hikâyesi
Ders 2: Kullanıcı Araştırması Nasıl Yapılır?
Kullanıcı araştırması, tasarımı tahminlerle değil gözlemlerle yapmak için kullanıcıların işlerini nasıl yaptığını öğrenme çalışmasıdır. Tek bir yöntem her soruyu cevaplamaz; hangi sorunun hangi yöntemle cevaplanacağını bilmek gerekir.
| Yöntem | Ne öğretir? | Sınırı |
|---|---|---|
| Görüşme | Kullanıcının hedefini, alışkanlıklarını ve nedenlerini | İnsanlar yaptıklarını değil, yaptıklarını sandıklarını anlatabilir |
| Gözlem | Kullanıcının gerçekte ne yaptığını ve nerede takıldığını | Zaman alır, az kişiyle yapılır |
| Anket | Bir görüşün ne kadar yaygın olduğunu | "Neden" sorusunu cevaplamaz |
| Kullanım verisi | Hangi ekranların kullanıldığını, nerede terk edildiğini | Nedenini söylemez |
| Destek kayıtları ve şikâyetler | En sık yaşanan sorunları | Yalnızca şikâyet edenleri yansıtır |
İyi bir görüşme, kullanıcıya "bu ekranı beğendiniz mi?" diye sormaz; "son siparişinizi nasıl verdiniz, bana adım adım anlatır mısınız?" diye sorar. Beğeni sorusu nezaket cevabı alır; geçmiş davranış sorusu gerçeği gösterir. Gözlemde ise kullanıcı işini yaparken siz sessizce izlersiniz ve müdahale etmezsiniz.
Bulguları, kimin ne yaptığını ve sonucunu gösteren cümlelere dökün. Örneğin: "Altı bayi görüşmesinin dördü, sipariş vermeden önce eski sipariş belgesini açıp ürün kodlarını oradan kopyalıyor." Bu cümle, tasarıma doğrudan bir karar verir: ürün kodunu yazma ya da son siparişten seçme yolu sunulmalı.
Ders 3: Kullanıcı Akışı Nasıl Tasarlanır?
Kullanıcı akışı, bir görevin başlangıçtan sonuca kadar kullanıcıdan istediği adımların sırasıdır. İyi akışın ölçüsü kısalıktır: her ekstra adım, kullanıcıyı vazgeçirebilecek bir engeldir. Akışı çizerken her adım için "bunu kullanıcıdan istemek zorunda mıyız, yoksa sistem bilebilir mi?" sorusunu sorun.
Örnekte bugünkü akış yedi adım: girişten sonra menüden sipariş ekranını açmak, ürünü aramak, listeden seçmek, adedi girmek, sepeti açmak ve siparişi onaylamak. Araştırma bulgularına göre yeni akışı dört adıma indirebiliriz:
| Mevcut akış (7 adım) | Yeni akış (4 adım) | Karar |
|---|---|---|
| 1. Giriş yap | 1. Giriş yap; sipariş ekranı doğrudan açılır | Bayi zaten sipariş vermeye geliyor; ara menü gereksiz |
| 2. Menüden "Sipariş"i aç | 2. Ürün kodunu yaz ya da "Son siparişi tekrarla"yı seç | Arama ve seçme tek alanda birleşir; sık alınanlar öne çıkar |
| 3. Ürünü ara | ||
| 4. Listeden ürünü seç | 3. Adedi gir; sepet yanda görünür | Sepet ayrı bir sayfa değil, ekranın yanında canlı bir özet |
| 5. Adedi gir | ||
| 6. Sepeti aç | 4. Siparişi onayla | Sepeti açma adımı ortadan kalkar |
| 7. Siparişi onayla |
Adım sayısındaki azalma: (7 − 4) ÷ 7 ≈ %43. Ama dikkat: kısa akış her zaman iyi akış değildir. Geri alınamayan önemli bir işlemden (siparişi onaylamak gibi) önce kullanıcının özeti görmesi gerekir; bu yüzden onay adımı korundu ve sepet özeti ekranın yanında kalıcı gösterildi.
Ders 4: Wireframe ve Prototip Nasıl Hazırlanır?
Wireframe, bir ekranın görsel süslerden arındırılmış iskeletidir: hangi öğenin nerede olacağını, hangisinin öne çıkacağını ve ne yapacağını gösterir. Prototip ise bu ekranların tıklanabilir hâlidir. İkisinin amacı, değişikliği kod yazılmadan önce, en ucuz olduğu yerde yapmaktır.
| Doğruluk düzeyi | Nedir? | Ne için kullanılır? |
|---|---|---|
| Kâğıt ya da tahta eskizi | Elle çizilmiş kaba ekranlar | Çok sayıda fikri hızla denemek |
| Gri wireframe | Renksiz, gerçek içeriksiz düzen iskeleti | Öğelerin yerini ve akışı tartışmak |
| Tıklanabilir prototip | Ekranlar arası geçişi olan, gerçek içeriğe yakın model | Kullanıcıyla test etmek, paydaşa göstermek |
| Görsel tasarım | Renk, yazı tipi ve görsellerle son görünüm | Geliştirmeye teslim, marka uyumu |
Kural basit: kararlar belirsizken düşük doğrulukla, netleştikçe yüksek doğrulukla çalışın. Görsel tasarımdan başlamak, rengi ve yazı tipini tartışırken asıl akış sorusunu gölgede bırakır. Örnek ekranımızın wireframe kararları şunlardı: ürün kodu alanı ekranın en üstünde ve otomatik odaklı, "Son siparişi tekrarla" düğmesi onun hemen yanında, sepet özeti sağ tarafta sabit, onay düğmesi sepet özetinin altında.
Ders 5: Arayüzü Hangi İlkelere Göre Denetlersiniz?
Tasarımı kullanıcıya göstermeden önce yerleşik ilkelerle denetlemek, bariz sorunları test öncesinde yakalar. Aşağıdaki ilkeler, kullanılabilirlik alanında yaygın kabul gören sezgisel değerlendirme (heuristic) ilkelerinden seçilmiştir; her biri örnek ekrana uygulanmıştır.
| İlke | Anlamı | Sipariş ekranında |
|---|---|---|
| Sistem durumunu göster | Kullanıcı ne olduğunu her an bilsin | Sepet toplamı adet değiştikçe anında güncellenir |
| Gerçek dünyanın diliyle konuş | Kullanıcının kendi kelimeleri | "Stok kodu" yerine bayinin bildiği "ürün kodu" |
| Kullanıcıya kontrol ve özgürlük ver | Hata yapınca kolayca geri dönülsün | Sepetten ürün çıkarma, siparişi onaylamadan önce düzenleme |
| Tutarlı ol | Aynı şey her yerde aynı görünür ve davranır | Tüm ekranlarda aynı renkte ve yerde onay düğmesi |
| Hatayı önle, yaptıysa açıkla | Hata mesajı ne olduğunu ve ne yapılacağını söylesin | "Adet en çok 500 olabilir" (yalnızca "Geçersiz değer" değil) |
| Hatırlatma yerine tanıma | Kullanıcı bir şeyi ezberlemek zorunda kalmasın | Ürün kodu yazarken öneri listesi, son siparişlerin görünmesi |
Erişilebilirlik de ayrı bir denetimdir ve herkesin ürünü kullanabilmesi için gereklidir. Temel kontrol listesi şöyledir: normal metin ile zemin arasındaki kontrast oranı en az 4,5:1 olmalı (WCAG AA ölçütü); tıklanabilir alanlar parmakla rahat dokunulacak büyüklükte olmalı; her form alanının görünür bir etiketi olmalı; bilgi yalnızca renkle verilmemeli (hata hem kırmızı hem ikon ve metinle gösterilmeli); tüm işlemler klavyeyle yapılabilmeli; görsellerin metin karşılığı bulunmalı.
Ders 6: Kullanılabilirlik Testi ve SUS Puanı Nasıl Uygulanır?
Kullanılabilirlik testi, gerçek kullanıcılara prototipte gerçekçi görevler verip onları izleyerek tasarımın nerede takıldığını bulmaktır. Kullanıcıya "ekran güzel mi?" diye sorulmaz; "şu ürünlerin siparişini vermeyi dene" denir ve sessizce izlenir.
Görevleri sonuç olarak yazın, adım olarak değil: "Ürün kodu MUT-TRM-500-CLK'den 10 adet sipariş ver" bir görevdir; "ürün kodu alanına tıkla" bir talimattır. Talimat vermek, kullanıcının neyi nerede arayacağını söylemek demektir ve testi anlamsız kılar. Kullanıcıdan düşünerek yüksek sesle konuşmasını isteyin, müdahale etmeyin ve takıldığı yerleri not edin.
Kaç kullanıcıyla test edilir?
Sorun keşif modeli, her kullanıcının bir sorunu bulma olasılığına (p) göre n kullanıcının bulacağı sorun oranını verir: Bulunan sorun oranı = 1 − (1 − p)ⁿ. Örnekte p = 0,30 alıyoruz (temsilî; gerçek değer projeden projeye değişir).
| Kullanıcı sayısı | Hesap | Bulunan sorun oranı |
|---|---|---|
| 1 | 1 − 0,70 | %30,0 |
| 3 | 1 − 0,70³ | %65,7 |
| 5 | 1 − 0,70⁵ | %83,2 |
| 8 | 1 − 0,70⁸ | %94,2 |
Eğri yatıklaşıyor: beşinci kullanıcı tek başına %83,2 − %76,0 = yaklaşık 7 puan ekliyor. Bu yüzden küçük gruplarla test edip düzeltmek ve yeniden test etmek, tek seferde çok kişiyle test etmekten verimlidir.
SUS puanı nasıl hesaplanır?
SUS (System Usability Scale), kullanılabilirliği tek bir 0–100 puanında özetleyen standart bir ankettir. Kullanıcı, bir görev bittikten sonra on ifadeye 1 (kesinlikle katılmıyorum) ile 5 (kesinlikle katılıyorum) arasında puan verir; tek numaralı ifadeler olumlu, çift numaralılar olumsuzdur. Tek numaralı ifade katkısı = cevap − 1; çift numaralı ifade katkısı = 5 − cevap; SUS = toplam katkı × 2,5.
| İfade | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| Kullanıcının cevabı | 4 | 2 | 4 | 1 | 4 | 2 | 5 | 2 | 4 | 2 |
| Katkı | 3 | 3 | 3 | 4 | 3 | 3 | 4 | 3 | 3 | 3 |
Tek numaralıların katkısı 3 + 3 + 3 + 4 + 3 = 16, çift numaralılarınki 3 + 4 + 3 + 3 + 3 = 16; toplam 32. SUS = 32 × 2,5 = 80. Bir ürünün SUS puanı, tek bir kullanıcının değil tüm katılımcıların puanlarının ortalamasıdır. SUS puanı yüzde değildir; yorumlamak için kendi ürününüzün önceki sürümüyle karşılaştırın. Literatürde yaygın başvuru değeri olarak yaklaşık 68 kullanılır.
Okumanızı öneririz: Yazılım testi nasıl yapılır? Kabul testi ve test senaryoları
Ders 7: Tasarım Değişikliğinin Etkisi Nasıl Ölçülür?
UX çalışması bir kez yapılıp biten bir iş değil, test–düzelt–yeniden test döngüsüdür. Her turun sonunda aynı metrikler ölçülür ve değişikliğin işe yarayıp yaramadığı rakamla görülür. Üç temel metrik vardır: görev başarı oranı, görev süresi ve SUS puanı.
Örnekte altı kullanıcı beş görevi denedi: 6 × 5 = 30 deneme. İlk turda 19'u başarılı oldu: görev başarı oranı = 19 ÷ 30 ≈ %63,3. Bulgulara göre akış dört adıma indirildi, hata mesajları yeniden yazıldı, "Son siparişi tekrarla" eklendi. İkinci turda aynı görevler yeniden denendi:
| Metrik | Tur 1 (eski tasarım) | Tur 2 (yeni tasarım) | Değişim |
|---|---|---|---|
| Adım sayısı | 7 | 4 | 3 adım (%43) azaldı |
| Görev başarı oranı | 19 ÷ 30 ≈ %63,3 | 27 ÷ 30 = %90,0 | 26,7 puan arttı |
| Ortalama görev süresi | 4 dk 10 sn (250 sn) | 2 dk 20 sn (140 sn) | (250 − 140) ÷ 250 = %44 kısaldı |
| SUS puanı (ortalama) | 62 | 80 | 18 puan arttı |
Bu tablo, tasarım kararını zevk tartışmasından çıkarıp veriye bağlar: "yeni akış daha iyi görünüyor" yerine "görev başarısı yaklaşık 27 puan arttı ve süre %44 kısaldı". Yayından sonra aynı metrikleri gerçek kullanımdan da izleyin: telefonla gelen sipariş sayısı, siparişin ekranda kaç saniyede tamamlandığı ve ekran terk oranı, tasarımın gerçek hayattaki sonucunu gösterir.
UX Tasarımında Sık Yapılan Hatalar Nelerdir?
UX hatalarının çoğu tasarım yeteneğinden değil, kullanıcıyı sürece katmamaktan doğar. En sık görülenler şunlardır:
- Kullanıcıya sormadan tasarlamak: Ekibin ya da yöneticinin zevki, kullanıcının ihtiyacının yerine geçer.
- Görsel tasarımla başlamak: Renk ve yazı tipi tartışmaları, asıl akış sorununu gölgeler.
- Testi en sona bırakmak: Kod yazıldıktan sonra bulunan bir akış hatası, prototipte bulunandan çok daha pahalıdır.
- Kullanıcıya talimat vermek: "Şuraya tıkla" dediğiniz testte hiçbir sorun bulunmaz.
- Kendini ya da ekibi test etmek: Ürünü bilen biri, bilmeyenin takılacağı yeri göremez.
- Erişilebilirliği sona bırakmak: Kontrast, etiket ve klavye desteği baştan düşünülmezse sonradan düzeltmek zordur.
Okumanızı öneririz: Mobil Uygulama Nasıl Yapılır? Fikirden Mağaza Yayınına Adım Adım Rehber
Okumanızı öneririz: Mobil Uygulama Maliyeti Nasıl Hesaplanır? Efor, Kapsam, MVP ve Üç Yıllık Toplam Maliyet Rehberi
Okumanızı öneririz: Destek talep yönetim sistemi nedir? Talep yaşam döngüsü, öncelik matrisi, SLA uyumu ve ekip kapasitesi rehberi
İnovabil ile UX Tasarımı
İnovabil olarak ekran akışlarını ve veri yapısını kod yazılmadan önce tasarlıyoruz. Süreç sayfamızda da anlattığımız gibi, kullanıcıların ekranları nasıl dolaşacağını görerek değişiklikleri en ucuz olduğu aşamada yapıyoruz; kullanıcı akışları ve ekran taslakları, tıklanabilir prototip ve görsel arayüz tasarımı tasarım adımımızın parçası. Taslaklar üzerindeki geri bildiriminiz bir sonraki adıma yön veriyor. Mobil uygulamalarda ekranları iOS ve Android alışkanlıklarına uygun tasarlıyoruz.
Yazılımınızı kimin, hangi işte kullanacağını ve bugün nerede zorlandığını birkaç cümleyle anlatın; size özel bir tasarım ve prototip yol haritası hazırlayalım.
Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım
Sık Sorulan Sorular
UX tasarımı nasıl yapılır, kısaca hangi adımlardan oluşur?
UX tasarımı yedi adımda yapılır: kullanıcı ve problemin tanımlanması, kullanıcı araştırması, kullanıcı akışının tasarlanması, wireframe ve prototip hazırlanması, arayüzün ilkelere ve erişilebilirliğe göre denetlenmesi, kullanılabilirlik testi, ve sonuçların ölçülüp tasarımın iyileştirilmesi.
UX ile UI arasındaki fark nedir?
UX, kullanıcının ürünle yaşadığı bütün deneyimdir: işini ne kadar kolay yaptığı, nerede takıldığı ve ne hissettiği. UI ise bu deneyimin görünen kısmıdır: düğmeler, renkler, yazı tipleri ve ekran düzeni. İyi bir UI, iyi bir UX'in parçasıdır ama onun yerine geçmez.
Kullanılabilirlik testi kaç kullanıcıyla yapılmalıdır?
Sabit bir sayı yoktur; sorun keşif modeli 1 − (1 − p)ⁿ formülünü verir. Örneğin her kullanıcının bir sorunu bulma olasılığı 0,30 ise beş kullanıcı sorunların yaklaşık %83'ünü bulur. Küçük gruplarla test edip düzeltmek ve yeniden test etmek, tek seferde çok kişiyle test etmekten verimlidir.
SUS puanı nedir, nasıl hesaplanır?
SUS (System Usability Scale), kullanılabilirliği 0–100 puanında özetleyen on ifadelik bir ankettir. Tek numaralı ifadeler için cevap − 1, çift numaralılar için 5 − cevap hesaplanır, katkılar toplanıp 2,5 ile çarpılır. Puan yüzde değildir; ürünün önceki sürümüyle karşılaştırılarak yorumlanır.
UX tasarımının etkisi nasıl ölçülür?
Görev başarı oranı, görev süresi ve SUS puanı tasarım değişikliğinden önce ve sonra aynı görevlerle ölçülür. Yayından sonra da sipariş tamamlama süresi, ekran terk oranı ve destek taleplerinin sayısı gibi gerçek kullanım verileri izlenir.