Kullanıcı deneyimi tasarımının temelleriyle ilgili adım adım açıklamalı bir kılavuz.
Bu makalede ekiplerin, ürünlerin, startup'ların ve şirketlerin, müşterileri için daha iyi bir kullanıcı deneyimi geliştirmek amacıyla sağlam ve anlamlı bir süreç oluşturmasına yardımcı olabilecek bir iş akışı tanıtılmaktadır. Sürecin farklı bölümlerini ayrı ayrı da kullanabilirsiniz ancak bunlar bir dizi adım halinde en iyi sonucu verir.
Bu kılavuzda büyük ölçüde, Google'daki birden fazla ekibin Kendi Kendine Sürüşlü Araba ve Project Loon gibi zorlukları gidermek için kullandığı Design Sprint metodolojisinden yararlanılmıştır.
Çift Elmas
Bu akış çalışması, kullanıcı deneyimi çevrelerinde İngiliz Tasarım Konseyi tarafından popüler hale getirilen çift elmas dediğimiz yaklaşıma dayanır. Ekibiniz araştırma yaparak bir fikri anlamak için farklı noktalara başvurur, ardından zorluğu tanımlamak için farklılaşır, farklı fikirler ortaya koyar, fikirleri paylaşır, en iyi yolun ne olduğuna karar verir, test eder ve doğrular.
Zemin hazırlama
İlki, eldeki temel zorlukla başlamak ve bunu bir teklif gibi yazarak kendinize “Aslında çözmeye çalıştığım sorun ne?” diye sormaktır. Zorluk ifadesi, proje için belirlediğiniz ve hedefinizi içeren özettir.
Bu zorluk, daha hassas hâle getirilmesi gereken mevcut bir ürün özelliği ya da tamamen yeni bir ürünle ilgili olabilir. Göreviniz ne olursa olsun, konuşma dilini, ulaşmaya çalıştığınız hedefe uygun şekilde ayarlamanız yeterlidir. Bir ifade ekip hedeflerinize bağlı olmalı, kitlenize odaklanmalı, ilham verici ve özlü olmalıdır.
Aşağıda geçmişte üzerinde çalıştığım ürünlerle ilgili gerçek hayattan bazı örnekler verilmiştir.
Kulüp kullanarak hastaların tedavi ve takip bakımını yönetmek için bir sistem tasarlayın.
Karmaşık finansal sistemleri basitleştiren ve temel bilgilere indirgeyen bir uygulama oluşturun.
Markadan ödün vermeden farklı platformlarda tutarlı bir mobil uygulama tasarlayın.
Yarışma açıklamanız güncelleniyor
Hedefin farklı versiyonlarını yazdıktan sonra fikir birliğine varmak için onu ekibinize sunun. Ekibin soruna odaklanmasını kolaylaştıracağı için teslim tarihi ekleyebilirsiniz. Eklenen düzenlemelerle yukarıdaki liste şöyle olabilir:
- Bu yılın 1. çeyreğinde kullanıma sunulacak çarpık ayakla 2 yaşından küçük çocukların tedavi ve takip bakımını yönetecek bir sistem tasarlayın.
- Temmuz 2017'de kullanıma sunulacak olan bu uygulamayla, finans dünyası hakkında önceden bilgi sahibi olmadan, tek bir düğmeye dokunarak hisse senetlerini alıp satmanıza olanak tanıyan basit bir finans uygulaması geliştirildi.
- Birden çok platformda esnek bir tasarım kılavuzu hazırlayın ve bu yılın sonuna kadar şirketin markasını her platformda etkili bir şekilde konumlandırın.
Meydan okuma ifadesi bittiğinde, çalışırken kolayca görülebilmesi için göze çarpan bir yere koyun. Sürekli olarak bu şablondan bahsetmeniz, hatta projeniz boyunca bu bilgiyi güncellemeniz veya değiştirmeniz gerekebilir.
Sorun doğrulanıyor
Bir sonraki adım, zorluğu araştırmak ve problem hakkında bilgi edinmektir. Keşfetmeniz gereken şey, ekibinizin sorunu anlayıp anlamadığının geçerli olup olmadığıdır. Sorunlara genellikle kendi bakış açımızdan bakarız. Teknoloji alanında çoğumuz aslında deneyimli kullanıcılar ve aslında az sayıda kullanıcı olduğumuz için bu tehlikelidir. Sözlü bir azınlığız ve bir şeyin aslında öyle olmadığı halde gerçekten sorun olduğunu düşünebiliriz.
Sorgulamayı doğrulamak için çeşitli veri toplama yöntemleri vardır. Her çözüm ekibinize ve kullanıcılara erişiminizin olup olmadığına bağlıdır. Amaç, mevcut sorunu daha iyi anlamaktır.
Paydaşlarla yapılan şirket içi görüşmeler
Mülakat sürecinde, pazarlamadan hesaplara kadar şirketinizdeki her ekip üyesi ve paydaşla görüşme yapılır. Bu sayede gerçek zorlukların neler olduğunu ve potansiyel çözümlerin neler olabileceğini öğrenebilirsiniz. Çözüm derken teknik çözümlerden değil, şirket veya ürün için en iyi senaryo ve nihai hedef olduğundan bahsediyorum. Örneğin, “çarpık ayak yazılımımızı yıl sonuna kadar tıbbi tesislerin% 80'ine eklemek” gibi yukarıdaki zorlukları ele almak, harika bir hedef olacaktır.
Dikkat edilmesi gereken bir nokta var. Bu doğrulama yöntemi ekip tartışmalarını ve iş birliğini engelleyerek kurumda silo yapılmış bir atmosfer yaratabileceğinden en az tercih edilen yöntemdir. Yine de müşteriler ve aksi halde gözden kaçırabileceğiniz tasarım sorunları hakkında iyi bilgiler verebilir.
Kısa konuşmalar
Bu, şirket içi görüşmelere benzer ama bu kez her paydaşı tek bir odaya çağırıyorsunuz. Ardından, bu paydaşlardan beş veya altısını (pazarlama, satış, tasarım, hesaplar, araştırma vb.) seçerek en fazla 10 dakika sürecek, her biri söz konusu soruna kendi bakış açısından odaklanır. Sunumlarında ele almaları gereken konular:
- İşletmenin hedefleri
- Kendi bakış açısından projenin zorlukları (ör. teknik, araştırma toplama, tasarım oluşturma vb.)
- Mevcut kullanıcı araştırmanız
Seçimin sonunda, seçilmiş bir kişinin konuşmayı dinlediği sorular için 5 dakika bırakın. İşiniz bittiğinde meydan okumayı, öğrendiğiniz yeni bilgileri yansıtacak şekilde güncelleyebilirsiniz. Amaç, ürün hedefinize ulaşmanıza yardımcı olacak bir özelliği veya akışı teşvik edebilecek maddelerin bir listesini toplamaktır.
Kullanıcı görüşmeleri
Bu, belki de kullanıcının yolculuğunu, sorunlarını ve akışını öğrenmenin en iyi yoludur. En az beş kullanıcı görüşmesi düzenleyin. Erişiminiz varsa daha da fazla kullanıcı görüşmesi ayarlayın. Onlara soracağınız sorular şunları içermelidir:
- Mevcut bir görevi nasıl tamamlarlar? Örneğin, yukarıdaki finansal uygulamayla ilgili yaşadığınız sorunu çözmek istediğinizi düşünelim. Onlara "şu anda hisseleri ve hisseleri nasıl satın alıyorsunuz?" diye sorabilirsiniz.
- Bu akışın hangi yönlerini beğeniyorlar?
- Bu akışın hangi yönlerini sevmiyorlar?
- Kullanıcı şu anda hangi benzer ürünleri kullanıyor?
- Neleri beğenirler?
- Neleri sevmezler?
- Ellerinde sihirli bir değnek olsaydı ve bu süreçle ilgili bir şeyi değiştirebilselerdi ne olurdu?
Röportaj, kullanıcının yaşadığı zorluklar hakkında konuşmasını sağlamaktır. Bu konu sizin açınızdan bir tartışma değildir. Bu nedenle mümkün olduğunca sessiz kalmanız gerekir. Bu, kullanıcı konuşmayı bıraktığında bile geçerlidir. Düşüncelerini toplayabileceklerinden daima bir an bekleyin. Birinin birkaç saniye durduktan sonra ne kadar da konuşmaya devam ettiğine şaşıracaksınız.
Görüşme boyunca notlar alın ve mümkünse gözden kaçırmış olabileceğiniz şeyleri yakalayın. Amaç, görevi edindiğiniz kullanıcı analizleriyle karşılaştırmaktır. Uyumlular mı? Meydan okuma ifadenizi güncellemenize yardımcı olacak bir şey öğrendiniz mi?
Etnografik alan araştırması
Bu aşamada kullanıcıyı sahada bir yandan alışveriş yaparken, işe nasıl seyahat ettiği, nasıl SMS mesajları gönderdiği gibi bir işlem yaparken gözlemlersiniz. Bazı durumlarda bunun nedeni, kullanıcıların duymak istediklerinizi söylemesidir. Ancak kullanıcıların eylemlerini ve görevleri kendi başlarına gerçekleştirmelerini izlemek bilgilendirici olabilir. Temelde, müdahale etmeden gözlemler, kolay veya zor buldukları ve gözden kaçırmış olabilecekleri şeyleri not edersiniz. Amaç, kullanıcının bulunduğu çevreye yoğunlaşmak ve sorunlu noktalarla ilgili daha iyi empati kurmaktır.
Bu teknik genellikle daha uzun bir süre boyunca yapılan bazı işleri içerir ve projenin bu kısmına bir araştırmacının liderlik etmesi gerekir. Ancak, kendi doğal ortamlarında incelemekte olduğunuz bir grup insanı gördüğünüzde, belki de en bilgilendirici yol budur.
Tüm verileri toplamak
Projenizin öğrenme aşamasını tamamladıktan sonra, projenize son bir kez göz atmanız gerekir. Doğru yolda mısınız? Ayarlamanız gereken bir şey var mı? Öğrendiğiniz her şeyi yazın ve bunları kategoriler halinde gruplandırın. Bunlar, çözdüğünüz soruna bağlı olarak bir özelliğin veya akışın temeli olabilir. Meydan okumayı güncellemek ve revize etmek için de kullanılabilirler.
Yeterli geri bildirim ve bilgi edindikten sonra sıra bu bilgileri bir proje haritası oluşturmak için kullanmaya gelir.
Proje Haritası
Çözmeye çalıştığınız problem genellikle her birinin projenin akışında pay sahibi olan farklı tür insanlardan (ya da oyunculardan) oluşur. Öğrendikleriniz doğrultusunda, olası oyuncuları listelemeniz gerekir. Bu bir kullanıcı türü veya paydaş olabilir. Örneğin, "çarpık ayaklarını tedavi eden bir doktor", "ayakları olan bir hasta", "hastaya bakan bir bakım görevlisi" vb. Her oyuncuyu bir sayfanın sol tarafına veya erişiminiz varsa beyaz tahtaya yazın. Sağ tarafta her oyuncunun hedeflerini yazın.
Son olarak her oyuncu için hedefine ulaşması için gereken adım sayısını yazın. Örneğin, "çarpık ayağı tedavi eden bir doktor" için hedef "çarpık ayağı olan bir hastayı iyileştirmek" olur, yani "hastayı sisteme kaydetmek", "tıbbi bir plan başlatmak", "tıbbi sağlık durumunu gözden geçirmek" ve "tıbbi müdahalede bulunmak" olabilir.
Sonuç olarak sürecin ana adımlarını içeren bir proje haritası elde edilir. Çok fazla ayrıntıya girmeden projenin bir özetini düşünün. Ayrıca ekip üyeleri, haritanın meydan okuma ifadesiyle eşleştiğine karar vermesine de olanak tanır. Daha sonra her bir adımı ayrıntılarına geçirdiğinizde karşınıza daha fazla ayrıntı çıkar. Ama şu an için proje haritası, bir kullanıcının nihai hedefini tamamlamak için atması gereken adımların genel bir kırılımını sunar.
Yeniden çerçeveleme ve resimli taslak oluşturma
Çılgın 8'ler
Bunun için, sekiz panel elde etmek için bir kağıdı iki kez bütmeyi içeren, deli 8'ler adlı bir yöntem öneriyoruz. Sonra her panelde, şimdiye kadar öğrendiklerinizi temel alan bir fikir çiziyorsunuz. Sekiz panelin hepsini doldurmak için kendinize on dakika verin. Kendinize 20 dakikadan fazla zaman ayırırsanız işi ertelemeye başlayabilir, kendinize bir kahve hazırlayabilir, e-postalarınızı kontrol edebilir, ekibinizle genel bir sohbet edebilir ve hiçbir işi yapmaktan kaçınabilirsiniz. Bu adımda hızlı ve etkili bir şekilde çalışmanız gerektiği için bir aciliyet duygusu yaratmak istersiniz.
Bir ekiple çalışıyorsanız herkesin kendi çalışmasını sağlayın. Bu süreç, zihninizi çalıştıracak ve yarışma hakkında düşünmenizi sağlayacaktır. Genel olarak taslak, bir arayüz tasarımı şablonudur.
Sonrasında, siz ve ekibinizdeki herkes gruba fikirlerini sunar. Herkes sahip olduğu sekiz fikrin her birini ve neden belirli bir yolda ilerlemeyi seçtiğini ayrıntılı olarak açıklamalıdır. Her ekip üyesine, öğrendiklerini fikirlerini doğrulamak amacıyla kullanmalarını hatırlatın. Herkes sunduktan sonra sıra fikirlere oy vermeye gelir. Her kullanıcı iki yapışkan nokta alır ve istediği fikre oy verebilir. Gerçekten beğenirlerse tek bir fikre her iki oyu da verebilirler.
Tasarımınızı hassaslaştırın
Oylamadan sonra en çok oy alan fikri alın ve nihai bir taslak belirleyin. İş arkadaşlarınızdan gelen diğer fikirleri de kullanabilirsiniz. Bu görevi tamamlamak için kendinize on dakika daha verin. Etkinliği tamamladığınızda fikirlerinizi tekrar ekibinize sunun ve önceki gibi oy verin.
Fikrin resimli taslağı
Tasarımınız elinizin altında olduğuna göre, kullanıcıyla etkileşiminin görsel senaryo taslağını oluşturabilirsiniz. Bu noktaya kadar, kullanıcının uyguladığı farklı adımları düşünmüş olmalısınız. İş arkadaşlarınızın tasarımlarından birinin de akışa dahil edilmesi oldukça yaygın bir durumdur. Kullanıcının ayrılabileceği bazı noktaların açık ve adım adım yürütülmesini istersiniz. Tasarımınızı hedefe göre doğrulamak için proje haritasına bakın.
Prototip oluşturma
Prototip oluşturmak mükemmel kod parçasını oluşturmak değildir, biri tarafından kullanıldığında inandırıcı bir şey yapmaktır. Prototip oluşturmak için kullanılan araçlar kişiden kişiye değişir. Keynote veya Powerpoint gibi tasarım ayrıntılarıyla değil, akışı düşünmenizi gerektirir. Size daha fazla davranış kontrolü sağlayabilecek Balsamiq, Marvel veya Framer gibi öğrenme araçlarına zaman ayırmak isteyebilirsiniz. Kullandığınız araç ne olursa olsun, akışa odaklanmanızı ve gerçekçi görünmenizi sağlayacak bir araç olmalıdır. Prototipi gerçek insanlar üzerinde test etmeniz gerekir. Böylece inandırıcı olması gerekir ama aynı zamanda oluşturmak için haftalar gerekmez.
Prototip oluşturmak zaman ve gerçek arasında bir denge kurar. Bu nedenle iki uç noktaya çok fazla sapmamaya dikkat edin. Her iki durumda da zaman kaybına neden olabilirsiniz.
Tasarımlarınızın kullanılabilirliğini test edin
Bir test laboratuvarınız varsa çok iyi olur. Aksi takdirde, kullanıcılarınız için dikkat dağıtıcı olmayan rahat bir ortam oluşturmaya çalıştığınız sürece bir hesap oluşturmak zor değildir. Testte genellikle kullanıcı ve ekibinizden iki kişi not alır, diğeri sorular sorar. Hangouts gibi bir uygulama kullanıp eylemlerini kaydetmek iyi bir kurulumdur. Bu, ekibin geri kalanının reklamları farklı bir odadan gözlemlemesini istediğinizde de kullanışlı olur. Tasarımlarımızı dışarıda gördüğümüzde uygulama geliştiricileri olarak bunu yapmak bizim için oldukça korkutucu olabiliyor. Bu, hem yenileyici hem de unutulmaz bir deneyim olabilir.
Sorulacak sorular
Tasarımınızı test ederken kullanıcıdan uygulamanızda görevleri gerçekleştirmesini ve yüksek sesle konuşmasını, neyi neden yaptığını sözlü bir şekilde ifade etmesini isteyin. Bunu yapmak tuhaf bir şey ama ne düşündüklerini duymanıza yardımcı olur. Takıldıklarında ne yapmaları gerektiğini onlara söylemeyin veya söylememeye çalışın. Tamamladıktan sonra (ya da DEĞİLSE) neden belirli bir akışı gerçekleştirdiklerini sorun.
Öğrenmeniz gereken bilgiler şunlardır:
- Prototipin hangi yönlerini beğeniyorlar?
- Prototipin hangi yönlerini sevmiyorlar?
- Sorunlu noktalar neler?
- Akış neden iyi performans gösterdi?
- Akış neden başarısız oldu?
- Neyi iyileştirmek istiyorlar?
- Genel tasarım/akış, ihtiyaçlarını karşılıyor mu?
Tasarımları ve başka bir test turunu tekrar gözden geçirin
Geri bildirim içeren çalışan bir prototipiniz var. Şimdi tasarımlarınızı gözden geçirmenin ve işe yarayan ve yaramayan şeyleri analiz etme zamanı. Tamamen yeni bir tel çerçeveli görsel senaryo taslağı oluşturup yeni bir prototip yapmaktan korkmayın. Baştan başlamak, önceki prototipinizde bir şeyleri hareket ettirmeye çalışmaktan daha iyi bir akış sağlayabilir. Bu sadece bir prototip olduğu için çok değerli olmamaya çalışın.
Tasarımlarınızdan memnun kaldığınızda, tekrar test edip biraz daha hassaslaştırabilirsiniz. Prototipin isabetli olmadığı durumlarda projenin başarısız olduğunu düşünebilirsiniz. Aslında öyle değil. Muhtemelen tasarıma kıyasla daha az zaman harcamışsınızdır ve kullanıcıların gerçekte nasıl bir şey olduğunu daha iyi biliyorsunuzdur. Tasarım sprintleriyle ilgili bir felsefemiz vardır. Böylece kazanırsanız ya da ders alırsınız. Bu nedenle, fikir planlandığı gibi gitmediyse kendinizi çok fazla dövmeyin.
Başarın.
Fikirlerinizi test ettiniz. Kullanıcı bunları beğenir. Paydaşlar projeye en başından beri dahil oldukları için çok emek harcıyorlar. Artık ürünü geliştirme zamanı. Şimdiye kadar neler yapılması gerektiği ve deneyimin önceliklerinin neler olduğu konusunda net bir fikre sahip olmuş olmalısınız. Projenin her ara hedefinde, çalışmanızı doğrulamaya ve işlerin yolunda gitmesine yardımcı olacak kullanılabilirlik testleri yapmak isteyebilirsiniz.
Doğru çözüm olmayabilecek bir konuda çok fazla çalışma, zaman ve emek harcamadan önce mümkün olduğunca fazla bilgiye ulaşmanın ne kadar önemli olduğunu vurgulayamam.
Bu makale size kullanıcı deneyimine ve bunun önemine dair temel bilgiler vermelidir. UX, bir tasarımcı veya araştırmacı rolü olarak düşünülmesi gereken bir şey değildir. Projeye dahil olan herkesin sorumluluğunda olduğu için her fırsatta projeye dahil olmasını öneririm.