UI, user interface kısaltması ve çizilen ekranı adlandırıyor; UX ise user experience kısaltması ve kullanıcının o ekranı kullanırken yaşadığını, en başta da geldiği işi bitirip bitiremediğini adlandırıyor. Teklifte tek bir tasarım kalemi duruyorsa o kalem bu iki işi birden adlandırıyor ve hangisinin fiyatlandığı adından okunmuyor. Bunu söyleyen tek şey, o kalemden hangi çıktıların teslim edileceği.
Kalem adının iki işi birden taşıması okura bir sorun gibi görünmüyor, çünkü ikisi de tasarım sayılıyor. Oysa biri bir yüzeyi, öteki kullanıcının o yüzeyde bitirdiği işi adlandırıyor. Aradaki farkın teklifte karşılığı var: kalemden yalnız çizilmiş ekranlar çıkıyorsa, kullanıcının işini hangi sırada bitireceği kararı hiçbir yere yazılmamış oluyor.
UI çizilen ekrandır, UX o ekranda işin bitip bitmediğidir
Ayrımı yapan şey ölçünün ne olduğu. UI’ın ölçüsü bir yüzey: yerleşim, düğmeler, yazı, renk, ikon. Kullanıcının gördüğü ve dokunduğu her şey bu adın altında duruyor.
UX’in ölçüsü ise bir sıra. Kullanıcı ekrana bir iş için geliyor; o işi bitirip bitiremediği UX’in alanı. Hangi adımlar var, hangi sırada geliyor, kullanıcının elinde ne olması gerekiyor, bir şey eksikken ne oluyor. Türkçede kullanıcı arayüzü ve kullanıcı deneyimi karşılıkları var; yazılı teklifte ve günlük konuşmada kısaltmalar geçtiği için bu yazı da kısaltmaları kullanıyor.
Farkın pratikteki hâli şöyle görünüyor: bir ekran düzgün çizilmiş olabilir ve kullanıcı yine geldiği işi bitiremez. Tersi de oluyor; sıra doğru kurulmuş olabilir ve ekran okunmaz kalır. İki hata birbirinin yerine geçmiyor, çünkü ikisi ayrı şeyi ölçüyor.
En sık karışma burada doğuyor: UX’in güzel görünmek olduğu sanılıyor. Görünüm UI’ın alanı. Bir demonun beğenilmesi UX’i ölçmez; ölçen şey kullanıcının o ekranda yaşadığı, en başta da işini bitirip bitirmediği. Bu karışmanın bedeli teklif okurken ödeniyor, çünkü güzel görünen bir ekran demosu iki işin birden yapıldığı izlenimini veriyor. Demoda görünen şey çizimin bittiği; sıranın tutup tutmadığı aynı ekranda görünmüyor.
Ayrımın bir faydası da burada: iki işin ayrı adlandırılması, bir şey yanlış gittiğinde nereye bakılacağını söylüyor. Kullanıcı ekranı okuyamıyorsa sorun yüzeyde duruyor; ekranı okuyup yine işini bitiremiyorsa sorun sırada. İki soru aynı düzeltmeyle kapanmıyor, çünkü biri çizimi, öteki akışı değiştirmeyi gerektiriyor.
Ayrım her yüzeyde iş görmüyor. Tek ekranlı, tek adımlı bir sayfada bitirilecek işin sırası diye bir şey yok; orada geriye kalan şey yerleşim. Ayrımın değeri, kullanıcının işini birden çok adımda bitirdiği yerlerde çıkıyor.
İki iş nerede birbirine bağlanıyor
İki ad yan yana duruyor ama aralarında bir teslim noktası var. O nokta akış ve durum listesi: akışın adımları ve her adımın alabileceği durumlar yazılı hâle getiriliyor, çizim o listeden yapılıyor.
Durum listesi, teklifte en sık eksik kalan çıktı. Bir adımın dolu hâli çiziliyor, çünkü hem tasarımı yapan hem alıcı ekranı dolu hayal ediyor. Henüz hiçbir şey girilmemiş hâli, bir cevabın beklendiği hâli ve bir şeyin eksik kaldığı hâli ise listede yazılı olmadıkça çizilmiyor.
Listede olmayan bir durumun bedeli ürün kullanılmaya başlandığında ödeniyor. O durum ekranda bir boşluk olarak çıkıyor: kullanıcı ne olduğunu anlamıyor ve ekranda da onu anlatan bir şey yok. Tasarımın bitmiş ama eksik görünmesinin kaynağı çoğu zaman burası.
Bağlanma noktasının yönü tek taraflı. Durum listesi çizimi besliyor; çizim durum listesini üretmiyor. Bir ekranı açıp “burada bir de şu olabilir” demek, listeyi sonradan ve eksik kurmak oluyor. Sonradan kurulan liste de hep aynı yerden eksik kalıyor: kimse kullanıcının takıldığı hâli hayal etmiyor, çünkü o hâl ekranda görünmüyor.
Durum sayısı birden fazla değilse bu çıktı ayrı bir belge gerektirmiyor. Tek hâlde duran bir ekranda bağlanma noktası diye ayrı bir teslim doğmuyor; liste o zaman ekranın kendisiyle aynı şey.
UX kararı ekran çizilmeden verilir
Sıra UX’ten UI’a doğru işliyor, çünkü hangi ekranların var olacağını akış belirliyor; çizim o ekranların neye benzeyeceğini belirliyor.
Yeniden çizmek bu yüzden bir düzeltme aracı değil. Bir ekranın görünümünü değiştiriyor, o ekranın hangi işi bitirdiğini değiştirmiyor. Akış değiştiğinde var olacak ekran kümesi de değişiyor; ortada düzeltilecek bir ekran değil, baştan yapılacak bir çizim duruyor.
“Önce ekranları çizelim, akışı sonra düşünürüz” sırası bu yüzden ters. Çizilen ekranlar hangi işin bitirileceği kararını zaten vermiş oluyor. Karar verilmiş ama yazılı değil: ne teklifte, ne de ekranların yanında.
Kararın yazılı olmaması ile verilmemiş olması aynı şey değil. Çizilen her ekran bir karar taşıyor: hangi bilgi ekranda duruyor, hangi adım hangi adımdan sonra geliyor, kullanıcı neyi ne zaman görüyor. Bu kararlar çizim sırasında ve çoğu zaman konuşulmadan veriliyor. Teklifte görünmemesinin nedeni de bu: kalem çizimi fiyatlıyor, çizimin içinde sessizce verilen kararları değil.
Sessiz kararın pahalı olmasının nedeni geri alınma anı. Ekranlar çizilip onaylandıktan sonra akış sorusu açıldığında, elde onaylanmış bir görüntü ve ona bağlanmış bir beklenti duruyor. O noktada akışı değiştirmek bir tasarım işi olmaktan çıkıyor, onaylanmış bir işi geri açmak oluyor. Aynı soru çizimden önce sorulduğunda ise bedeli bir toplantı.
Akış tek adımdan oluşuyorsa sıranın bir hükmü kalmıyor. Orada çizimle başlamak hiçbir şey kaybettirmiyor, çünkü verilecek bir sıra kararı yok.
Teklifte bu iki işin çıktıları ne
Kalem adı neyin fiyatlandığını söylemiyor; çıktı listesi söylüyor. Aşağıdaki satırlar tasarım işinin bilinen çıktılarını yan yana koyuyor: her satır bir kalemin ne olduğunu, ne teslim ettiğini ve hangi soruyu cevapladığını yazıyor. Satırlar genel bilgi, yani bir kanıt listesi değil bir sözlük.
| Kalem | Ne teslim edilir | Hangi soruyu cevaplar |
|---|---|---|
| Kullanıcı akışı | Adımların ve sıranın yazılı hâli; hangi adımdan hangisine geçildiği | Kullanıcı işini hangi yoldan bitiriyor |
| Tel çerçeve | Ekranların yerleşimi; renk, yazı tipi ve görsel karar henüz yok | Hangi bilgi hangi ekranda ve nerede duruyor |
| Prototip | Tıklanabilir hâli; sıra gerçek bir cihazda denenebiliyor | Sıra kâğıt üstünde değil, kullanımda da tutuyor mu |
| Kullanıcı testi | Gerçek bir kişinin akışı denemesi ve nerede duraksadığının kaydı | Kullanıcı tarif edilen işi gerçekten bitiriyor mu |
| Görsel tasarım | Ekranların son hâli: renk, yazı, ikon, boşluk | Ekran neye benziyor ve ne okunuyor |
| Tasarım sistemi | Yeniden kullanılan bileşenler ve bunların kullanım kuralları | Sonradan eklenen ekran öncekiyle aynı dili konuşuyor mu |
Tablonun okura bıraktığı iş, teklifteki kalemin yanına hangi satırların yazılı olduğuna bakmak. Akış ve kullanıcı testi satırları UX tarafını ölçüyor; görsel tasarım ve tasarım sistemi satırları UI tarafını. Tel çerçeve ile prototip ikisinin arasında duruyor, çünkü akışın çizime döndüğü yer orası.
Kalemlerin hepsi her işte gerekli değil. Yüzey küçükse akışın ve durumların yazılı hâli tek sayfaya sığıyor, ayrı bir prototip adımı da doğmuyor. Gereken şey listenin tamamı değil, kalemin hangi satırları taşıdığının yazılı olması.
Satırların adları işten işe değişebiliyor; belirleyici olan ad değil, satırın karşısındaki teslim. Bir teklifte tel çerçeve yerine başka bir ad geçiyorsa sorulacak şey aynı kalıyor: bu kalemden ekranların yerleşimi mi çıkıyor, son hâli mi.
Listede görünmeyen bir çıktı daha var: kapsam cümlesi. Hangi ekranların bu işe girmeyeceği de bir karar ve kalem adının içinde durmuyor. Aşağıdaki bölümler o kararın yayındaki işlerde nasıl göründüğünü gösteriyor.
Ekrana gelen soru bir karşılaştırmaysa ekranın birimi liste değildir
Kullanıcı ekrana bir soruyla geliyor ve o sorunun biçimi ekranın birimini belirliyor. Soru tek bir kalem hakkındaysa liste iş görüyor. Soru bir fark hakkındaysa liste iş görmüyor, çünkü farkı okuyabilmek için karşılaştırılan şeylerin aynı yüzeyde durması gerekiyor.
Mağaza zemininde araç tanıtım ekranı olarak duran KGM SsangYong showroom kiosku bu soruyu taşıyor. Proje kaydı koşulu yazıyor: yoğun saatte donanım farkını anlatacak boş bir danışman kalmıyor, uygulama da bu farkları tek ekranda yan yana getiriyor.
Arayüzün bu işte hangi kullanım koşuluna göre kurulduğu ayrı bir konu; onu basılı kataloğu ve menüyü yazılıma taşıdığımız yazıda açtık. Burada önemli olan karar daha erken veriliyor: ekranın birimi tek bir araç mı, araçların farkı mı. İyi çizilmiş bir katalog listesi farkı soran soruyu cevaplamıyor.
Aynı soru endüstriyel makine tarafında da çıkıyor. Plastik ve Makina platformunda alıcının sorusu bir karşılaştırma olduğu için sıfır ve ikinci el tek listede duruyor, durum da açılıp kapanan bir filtre. Bu kararın neden bir görünüm tercihi olmadığını filtrenin cevabını hangi yarının ürettiğini anlattığımız yazıda açtık.
Bu bölümün dışında kalan bir soru da var. Kiosk mağazanın kendi dokunmatik ekranında çalışıyor; uygulamanın hangi cihazda açılacağı ve cihazı kimin işlettiği cihaz sahipliğini koddan önce karara bağladığımız mobil uygulama çalışmasının konusu, tasarım kaleminin değil.
Soru bir fark değil tek bir kalemse karşılaştırma yüzeyi gereksiz ağırlık. Çatalca Merkez Kasap menüsünde masadaki kod okuru doğrudan ilgili bölüme indiriyor; karar birkaç saniyede orada veriliyor.
Ekranın bir şeyin yerine geçmesi gerekiyorsa
Bazı işlerde ekranın taşıması gereken şey bir görüntü değil, kullanıcının kullanamadığı bir duyunun yerine geçecek bir bilgi. Bu karar yerleşimden önce geliyor, çünkü ekranda ne olacağını belirliyor.
Kokunun tek ürün kaydı olarak durduğu Kokudankokuya parfüm mağazasında koşul proje kaydında yazılı: müşteri kokuyu duymadan ödeme yapıyor, yani kararı taşıyacak tek şey kokunun yazıyla anlatılmış hâli oluyor.
Böyle bir koşulda fotoğrafın yapabileceği iş sınırlı kalıyor. Kullanıcının karşılaştırabileceği bir tarife ihtiyacı var; o tarifin hangi eksende kurulduğu ürün varyantının nasıl modellendiğini anlattığımız yazıda duruyor. Buradaki soru ondan önce sorulan soru: ekran hangi bilgiyi taşıyacak.
Aynı sorun otomotivde de çıkıyor. KGM SsangYong online satış kanalında alıcı aracı ekranda donanım ve renk üzerinden kuruyor; satılan şey o yapılandırmanın kendisi. Ekranın işi var olan bir ürünü göstermek değil, henüz var olmayan bir sonucu kurdurmak.
Hangi ekranların var olacağı bu okumadan çıkıyor. Kurulan sonucun ödemeye nasıl taşındığı ayrı bir konu ve hesap çıktısının teklife dönüştüğü yazıda anlatılıyor. Çizim bu kararı değiştirmiyor; kurulmuş bir sonucun ekranda nasıl göründüğünü değiştiriyor.
Bu örneklerin ortak yanı, ekranın bir eksiği kapatıyor olması. Birinde kullanıcı ürüne dokunamıyor, ötekinde ürün henüz ortada yok. Her durumda ekranın taşıyacağı bilgiyi belirleyen şey bir yerleşim tercihi değil, kullanıcının o andaki koşulu.
Ürün elde tutulup denenebiliyorsa ekranın yerine koyacağı bir şey yok; tarif yükü düşüyor ve ekranın işi ürünü bulunur kılmakla sınırlı kalıyor.
Arayüzün işi bazen bir adım eklememek
Tasarım kararı denince akla eklenen bir şey geliyor: yeni bir ekran, yeni bir adım, yeni bir düğme. Oysa kararların bir kısmı eklememekle veriliyor ve teklifte hiç görünmüyor, çünkü teklif eklenen kalemleri sayıyor.
AlgoKlima’yı kendimiz işletiyoruz; sistem yayında ve üstünde çalışmayı sürdürüyoruz. Saha uygulaması bağlantının gelmesini beklemediği için arayüz tarafında tasarlanan şey bir ekranın yokluğu oluyor.
Kaydın bağlantı yokken nerede durduğu ve bağlantı dönünce ne olduğu bağlantı yokken çalışan saha uygulamalarını anlattığımız yazıda duruyor. Bu karar bir ekran üretmediği için kalem adının içinde de görünmüyor.
Çıkarılan katmanın en net hâli bölümleri ayrı adreslenen Çatalca Merkez Kasap QR menüsünde duruyor. Proje kaydı kapsamı tereddütsüz çiziyor: sipariş de ödeme de stok da dışarıda. Kapsamın neden dar tutulduğunu basılı menüyü yazılıma taşırken hangi katmanın dışarıda kaldığını anlattığımız yazıda açtık.
Kapsamın dışında bırakılan katman teklifte bir satır olarak görünmüyor. Eklenen ekranlar yazılıyor, çıkarılanlar yazılmıyor. Oysa “bu katman bu işe girmiyor” cümlesi de kalemin içeriğini anlatıyor; kapsamı okunur kılan şey tam olarak o cümle.
Bir sınırı açıkça söylemek gerekiyor. Erişilebilirlik kararlarının çoğu bu kalemin içinde duruyor: kontrastın ölçüsü, odağın görünürlüğü ve hedef boyutu görsel tasarım ve tasarım sistemi çıktılarıyla birlikte geliyor. Kalemin dışında kalan tek şey, yükümlülüğün ne zaman doğduğu sorusu; onu erişilebilirliğin ne zaman zorunlu hâle geldiğini ayrıca ele aldığımız yazıda açtık.
Eklenmeyen adımın bir yüzü daha var: kapsamı daraltan karar da bir tasarım kararı. Hangi ekranın yapılmayacağına karar vermek, yapılacak ekranların hangi işi bitireceğini de netleştiriyor.
Her adımın kaldırılması da kazanç değil. Kaldırılan adım bir kayıt üretiyorsa o kayıt da kayboluyor ve kaybın ölçüsü ayrı bir hesap.
Teklifteki kalemi nasıl okursunuz
Bütün bölümlerin altındaki soru tek cümlede toplanıyor: bu kalemden akış ve durum listesi çıkıyor mu, yoksa yalnız çizilmiş ekranlar mı.
Cevap “akış ve durum listesi de çıkıyor” ise kalemin içinde UX tarafı fiyatlanmış oluyor. Cevap “yalnız çizilmiş ekranlar” ise kalem UI tarafını fiyatlıyor ve kullanıcının işini hangi sırada bitireceği kararı başka birine kalıyor. O başka biri çoğu zaman kodu yazan kişi oluyor ve kararı eldeki ekranlara bakarak veriyor.
Kalemin yanında kapsam cümlesine de bakın. KGM SsangYong showroom kiosku bilerek dar tutuldu: gamı gezdiren bir ekran olarak kuruldu, satış yapan bir kanal olarak değil. Proje kaydı bu sınırın baştan çizildiğini yazıyor; böyle bir cümle kalemin içeriğini kalem adından daha iyi anlatıyor, çünkü neyin dışarıda kaldığını da söylüyor.
Sıraya da bakın. Akış ile çizim aynı kalemin içindeyse hangisinin önce yapılacağı yazılı mı; yazılı değilse sıra çoğu zaman çizimden başlıyor.
Kalem adının arkasındaki iş tanımının teklifte hiç yazılı olmaması ayrı bir konu; onu aynı işe neden farklı fiyat çıktığını anlattığımız yazıda açtık. Burada tek ölçüt kalıyor: kalemin teslim edeceği şeyler yazılı mı.
Bu soruyu görüşmeye götürmek için elinizde olması gereken tek şey, kullanıcınızın ekrana hangi soruyla geldiği. Onu yazıya dökebiliyorsanız kalemin hangi çıktıyı teslim edeceğini birlikte yazabiliriz; akışın ekranlardan önce çıkarıldığı web yazılımı çalışmalarımızda sıra böyle işliyor.
