Kullanıcı deneyimi tasarımının temelleri hakkında adım adım açıklamalı kılavuz.
Bu makalede, ekiplerin, ürünlerin, girişimlerin ve şirketlerin müşterileri için daha iyi bir kullanıcı deneyimi geliştirmek üzere güçlü 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ı kullanabilirsiniz ancak bu bölümlerin en iyi şekilde çalışması için bir dizi adım olarak kullanılması idealdir.
Bu kılavuzda, Google'daki birden fazla ekibin Self Driving Car ve Project Loon gibi zorluklarla ilgili sorunları gidermek için kullandığı Design Sprint metodolojisinden yoğun şekilde yararlanılmıştır.
Çift Elmas
Bu akış çalışması, kullanıcı deneyimi çevrelerinde çift elmas olarak adlandırdığımız ve British Design Council tarafından popüler hale getirilen bir akışa dayanır. Bu akışta ekibiniz, bir fikri araştırma yoluyla anlamak için ayrılır, ardından sorunu tanımlamak için birleşir, fikri tek tek taslak haline getirmek için ayrılır, fikirleri paylaşır, en iyi yönteme karar verir, test eder ve doğrular.
Giriş
Öncelikle, ele aldığınız temel sorundan başlayın ve "Aslında çözmeye çalıştığım sorun nedir?" diye kendinize sorarak sorunu bir teklif gibi yazın. Sorun beyanı, proje için belirlediğiniz ve hedefinizi içeren özettir.
Bu zorluk, geliştirilmesi gereken mevcut bir ürün özelliği veya tamamen yeni bir ürün için olabilir. Göreviniz ne olursa olsun, dili ulaşmaya çalıştığınız hedefe uyacak şekilde ayarlayın. Beyanınız ekip hedeflerinize bağlı, kitlenize odaklanmış, ilham verici ve kısa olmalıdır.
Geçmişte üzerinde çalıştığım ürünlere dair bazı gerçek hayattan örnekleri aşağıda bulabilirsiniz;
Çökük ayak hastalarının tedavisini ve takip bakımını yönetecek 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.
İtiraz beyanınızı güncelleme
Hedefin birkaç varyantını yazdıktan sonra, fikir birliğine varmak için ekibinize sunun. Ekibin soruna odaklanmasına yardımcı olacağı için son tarih ekleyebilirsiniz. Bu nedenle, yapılan düzenlemelerle birlikte yukarıdaki liste şu şekilde olabilir:
- Bu yılın 1. çeyreğinde kullanıma sunulacak, 2 yaşından küçük ve doğuştan çarpık ayaklı çocukların tedavisini ve takip bakımını yönetecek bir sistem tasarlayın.
- Temmuz 2017'de ilk kez kullanıma sunulan, finans dünyasına dair önceden bilgi sahibi olmadan tek bir düğmeye dokunarak hisse satın almanıza ve satmanıza olanak tanıyan basit bir finans uygulaması oluşturun.
- Bu yılın sonuna kadar, birden fazla platformda esnek olan ve şirketin markasını her platformda etkili bir şekilde konumlandıran bir tasarım kılavuzu hazırlayın.
Zorluk beyanı tamamlandığında, çalışırken görebilmeniz için belirgin bir yerde gösterin. Bu planı sürekli olarak referans olarak kullanmanız, hatta projeniz boyunca güncellemeniz veya değiştirmeniz gerekebilir.
Sorunu doğrulama
Sonraki adım, sorunu araştırmak ve hakkında bilgi edinmektir. Ekibinizin sorun hakkındaki anlayışının geçerli olup olmadığını keşfetmeniz gerekir. Sık sık sorunlara kendi bakış açımızdan bakarız. Teknoloji sektöründeki çoğumuz aslında ileri düzey kullanıcılar ve kullanıcıların azınlık kesimi olduğumuz için bu tehlikelidir. Azınlıktayız ve bir şeyin sorun olduğunu düşünmemiz için kandırılabiliriz.
Zorluğu doğrulamak için veri toplamanın çeşitli yöntemleri vardır. Her biri, ekibinize ve kullanıcılara erişiminizin olup olmadığına bağlıdır. Amaç, söz konusu sorunu daha iyi anlamaktır.
Paydaşlarla yapılan şirket içi görüşmeler
Görüşme süreci, pazarlamadan muhasebeye kadar şirketinizdeki her ekip üyesi ve paydaşla görüşmeyi içerir. Bu sayede, gerçek zorlukların ne olduğunu ve olası çözümlerin neler olabileceğini öğrenebilirsiniz. Çözüm derken teknik çözümlerden değil, şirket veya ürün için en iyi durum senaryosu ve nihai hedeften bahsediyorum. Örneğin, yukarıdaki zorluklardan yararlanarak "ayakta durmakta güçlük çeken çocuklara yönelik yazılımımızın yıl sonuna kadar sağlık kuruluşlarının% 80'inde kullanılmasını sağlamak" iyi bir hedef olabilir.
Bununla ilgili bir uyarımız var. Ekip tartışmalarını ve işbirliğini engellediği ve kuruluşta silolu bir ortam oluşturabileceği için bu doğrulama yöntemi en az tercih edilen yöntemdir. Yine de müşteriler ve tasarım zorluğu hakkında, aksi takdirde gözden kaçırabileceğiniz bazı yararlı bilgiler sağlayabilir.
Kısa konuşmalar
Bu, şirket içi görüşmelere benzer ancak bu sefer tüm paydaşları tek bir odada toplarsınız. Ardından, bu paydaşlardan (pazarlama, satış, tasarım, muhasebe, araştırma vb.) beş veya altı tanesini seçip konuşma yapmalarını isteyin. Her biri, en fazla 10 dakika boyunca kendi bakış açısıyla soruna odaklanmalıdır. Sunularında ele almaları gereken konular şunlardır:
- İşletmenin hedefleri
- Projenin kendi bakış açılarına göre zorlukları (teknik, araştırma toplama, tasarım oluşturma vb. olabilir)
- Şu anda sahip olduğunuz kullanıcı araştırması
Sonunda sorular için 5 dakika ayırın. Toplantı boyunca notları seçilmiş bir kişi tutmalıdır. İşlemi tamamladıktan sonra, yeni öğrendiklerinizi yansıtacak şekilde meydan okumayı güncelleyebilirsiniz. Amaç, ürün hedefinize ulaşmanıza yardımcı olacak bir özellik veya akış sağlayabilecek madde işaretleri listesi oluşturmaktır.
Kullanıcı görüşmeleri
Kullanıcının yolculuğu, sorunları ve akışı hakkında bilgi edinmenin en iyi yolu bu olabilir. En az beş kullanıcıyla (erişiminiz varsa daha fazlasıyla) röportaj yapın. Bu kişilere soracağınız sorular şunlar olmalıdır:
- Mevcut bir görevi nasıl tamamlar? Örneğin, yukarıdaki finans uygulamasıyla ilgili sorunu çözmek istediğinizi varsayalım. Kullanıcılara "Şu anda hisse ve borsa satın alırken nasıl işlem yapıyorsunuz?" sorusunu sorabilirsiniz.
- Bu akışta neleri beğendiler?
- Bu akışta neleri beğenmediler?
- Kullanıcı şu anda hangi benzer ürünleri kullanıyor?
- Neleri beğenirler?
- Nelerden hoşlanmazlar?
- Sihirli bir değneği olsaydı bu süreçle ilgili neyi değiştirirdi?
Görüşme yapmanın amacı, kullanıcının karşılaştığı zorluklardan bahsetmesini sağlamaktır. Bu sizin için bir tartışma konusu 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 toplamaya çalışıyor olabileceği için her zaman bir süre bekleyin. Birisi birkaç saniye durakladıktan sonra ne kadar konuşmaya devam edeceğine şaşırabilirsiniz.
Atladığınız noktaları yakalamanıza yardımcı olması için görüşme boyunca not alın ve mümkünse görüşmeyi kaydedin. Amaç, sorunu topladığınız kullanıcı analizleriyle karşılaştırmaktır. Bu iki öğe uyumlu mu? İtiraz beyanınızı güncellemenize yardımcı olacak bir şey öğrendiniz mi?
Etnografik saha çalışması
Bu aşamada, kullanıcıyı sahada gözlemlersiniz. Kullanıcının alışverişi nasıl yaptığını, işe nasıl gittiğini, SMS mesajlarını nasıl gönderdiğini vb. gözlemleyebilirsiniz. Bunun nedeni, bazı durumlarda kullanıcıların duymak istediğinizi düşündükleri şeyleri size söylemesidir. Ancak kullanıcıların işlemleri ve görevleri kendi başlarına gerçekleştirmelerini izlemek yararlı olabilir. Temel olarak, müdahale etmeden gözlem yapar, kolay veya zor buldukları noktaları ve atlamış olabilecekleri noktaları not edersiniz. Amaç, kullanıcıların karşılaştığı sorunlara daha iyi empati kurabilmek için kendinizi onların ortamına kaptırmaktır.
Bu teknik genellikle daha uzun bir süre boyunca yapılan bazı çalışmaları içerir ve projenin bu bölümünün bir araştırmacı tarafından yönetilmesini gerektirir. Ancak, incelediğiniz bir grup insanı doğal ortamlarında görebildiğiniz için belki de en faydalı yöntemdir.
Tümünü bir araya getirme
Projenizin öğrenme aşamasını tamamladıktan sonra, meydan okumanıza son bir kez göz atmanız gerekir. Doğru yolda mısınız? Düzenlemeniz gereken bir şey var mı? Öğrendiğiniz her şeyi yazın ve kategorilere ayırın. Bunlar, çözdüğünüz soruna bağlı olarak bir özelliğin veya akışın temelini oluşturabilir. Ayrıca, yarışmayı güncellemek ve düzeltmek için de kullanılabilir.
Yeterli geri bildirim ve analize sahip olduktan sonra bu bilgileri proje haritası oluşturmak için uygulama zamanı gelmiştir.
Proje Haritası
Çözmeye çalıştığınız sorun genellikle her biri projenin akışında pay sahibi olan farklı türde kişilerden (veya oyunculardan) oluşur. Öğrendiklerinize göre olası oyuncuları listelemeniz gerekir. Bu, bir kullanıcı türü veya paydaş olabilir. Örneğin, "kalça çıkıklığı tedavisi yapan bir doktor", "kalça çıkıklığı olan bir hasta", "hastaya bakan bir bakıcı" vb. Her bir oyuncuyu bir kağıdın sol tarafına veya erişiminiz varsa beyaz tahtaya yazın. Sağ tarafta her oyuncunun hedeflerini yazın.
Son olarak, her oyuncunun hedefine ulaşması için gereken adım sayısını yazın. Örneğin, "kalça çıkıklığı tedavisi yapan bir doktor" için hedef "kalça çıkıklığı olan bir hastayı iyileştirmek" olur. Bu durumda adımlar "hastayı sisteme kaydetme", "hastaya tıbbi bir plan uygulamaya başlama", "hastanın tıbbi sağlığına dair bir inceleme döngüsü oluşturma" ve "tıbbi prosedür gerçekleştirme" olabilir.
Sonuç olarak, süreçteki ana adımları içeren bir proje haritası elde edilir. Çok fazla ayrıntı içermeyen, projeye genel bir bakış olarak düşünebilirsiniz. Ayrıca ekip üyelerinin haritanın meydan okuma beyanı ile eşleşip eşleşmediğini değerlendirmesine olanak tanır. Daha sonra, her bir adımı ayrıntılı olarak inceleyebilirsiniz. Ancak şu anda proje haritası, kullanıcının nihai hedefine ulaşmak için uygulayacağı adımların genel hatlarıyla dökümünü sunar.
Wireframe ve resimli taslak
Crazy 8s
Bunun için, bir kağıdı iki kez katlayarak sekiz panel elde etmenizi sağlayan çılgın 8'ler yöntemini öneririm. Ardından, her panelde şu ana kadar öğrendiklerinizden yola çıkarak bir fikir geliştirin. Sekiz panelin tamamını dolduracak fikirler bulmak için kendinize on dakika verin. Kendinize 20 dakikadan fazla süre tanırsanız ertelemeye başlayabilir, kendinize kahve yapabilir, e-postaları kontrol edebilir, ekibinizle genel bir sohbet edebilir ve aslında işi yapmaktan kaçınabilirsiniz. Bu adımda, hızlı ve daha etkili bir şekilde çalışmanıza zorladığı için aciliyet hissi yaratmak istersiniz.
Ekip halinde çalışıyorsanız herkesin de kendi analizini yapmasını sağlayın. Bu süreç, beyninizi harekete geçirir ve sizi zorluk hakkında düşünmeye sevk eder. Genellikle eskiz, arayüz tasarımı taslağı olur.
Ardından, siz ve ekibinizdeki herkes fikirlerini gruba sunar. Her katılımcı, sekiz fikrinin her birini ayrıntılı olarak açıklamalı ve neden belirli bir yolu seçtiğini belirtmelidir. Her ekip üyesine, fikirlerini gerekçelendirmek için edindikleri bilgileri kullanmalarını hatırlatın. Herkes sunumunu yaptıktan sonra fikirler için oy verme zamanı gelir. Her katılımcı iki adet yapışkan nokta alır ve diledikleri fikirlere oy verebilir. Gerçekten beğendikleri bir fikre iki oy verebilirler.
Tasarımınızı hassaslaştırma
Oylama bittikten sonra en çok oyu alan fikri alın ve nihai fikrin taslağını çıkarın. Çalışma arkadaşlarınızdan duyduğunuz diğer fikirlerden de yararlanabilirsiniz. Bu görevi tamamlamak için kendinize on dakika daha verin. İşlemi tamamladığınızda fikirleri ekibinize tekrar sunun ve önceki gibi oy verin.
Fikrin resimli taslağını oluşturun
Tasarımınız hazır olduğuna göre, kullanıcıyla etkileşimini hikaye tahtasına ekleme zamanı gelmiştir. Bu aşamaya kadar kullanıcının uygulayacağı farklı adımları düşünmüş olmanız gerekir. İş arkadaşlarınızın tasarımlarından birini de akışa dahil etmek yaygın bir uygulamadır. Kullanıcının farklı noktalarda ayrılabileceği bazı noktalar içeren, adım adım açık bir işleme sahip olmak istersiniz. Tasarımınızı hedefe göre doğrulamak için proje haritasına tekrar bakın.
Prototip oluşturma
Prototip oluşturmak, mükemmel bir kod parçası oluşturmak değil, kullanıcılar tarafından kullanıldığında inandırıcı olan bir şey yapmaktır. Prototip oluşturmak için kullanılan araçlar kişiden kişiye değişir. Bazıları, sizi tasarım ayrıntıları yerine akış üzerinde düşünmeye zorladığı için Keynote veya PowerPoint'i tercih eder. Size daha fazla davranış kontrolü sunabilecek Balsamiq, Marvel veya Framer gibi araçları öğrenmeye zaman ayırabilirsiniz. Hangi aracı kullanırsanız kullanın, akışa odaklanmanızı sağlayan ve gerçek gibi görünen bir araç kullandığınızdan emin olun. Prototipi gerçek kişiler üzerinde test etmeniz gerekir. Bu nedenle, prototip mümkün olduğunca inandırıcı olmalı ancak aynı zamanda oluşturması haftalar sürmemelidir.
Prototip oluşturma, zaman ve gerçeklik arasında bir denge kurmaktır. Bu nedenle, iki uçtan birine çok fazla kaymamaya dikkat edin. Her iki durumda da zaman kaybedebilirsiniz.
Tasarımlarınızı kullanılabilirlik testi
Test laboratuvarınız varsa bu çok iyidir. Henüz bir web siteniz yoksa kullanıcılarınız için dikkat dağıtıcı olmayan, rahat bir ortam oluşturmaya dikkat ettiğiniz sürece web sitesi oluşturmak zor değildir. Test genellikle kullanıcının yanı sıra ekibinizden biri not alırken diğerinin soru sorduğu iki kişiyi içerir. Hangouts gibi bir uygulamayı kullanarak kullanıcıların işlemlerini kaydetmek iyi bir ayardır. Ekibin geri kalanının farklı bir odadan gözlem yapmasını istiyorsanız bu yöntemden yararlanabilirsiniz. Tasarımlarımızın kullanıma sunulduğunu görmek, uygulama geliştiriciler olarak bizim için oldukça korkutucu olabilir. Bu hem yenileyici hem de ciddi bir deneyim olabilir.
Sorulacak sorular
Tasarımınızı test ederken kullanıcıdan uygulamanızdaki görevleri yapmasını isteyin ve ne yaptığını ve neden yaptığını yüksek sesle anlatmasını sağlayın. Bu biraz tuhaf bir yöntem olsa da çocuğunuzun ne düşündüğünü anlamanıza yardımcı olur. Sorunla karşılaştıklarında onları bölmeye veya ne yapmaları gerektiğini söylemeye çalışmayın. Kullanıcılar belirli bir akışı tamamladıktan (veya tamamlamadıktan) sonra neden bu akışı kullandıklarını sormanız yeterlidir.
Bilmeniz gerekenler:
- Prototipte neleri beğendiler?
- Kullanıcılar prototipte neleri beğenmemiştir?
- Sorun alanları nelerdir?
- Akış neden işe yaradı?
- Bir akış neden çalışmadı?
- Neyi iyileştirmek istiyorlar?
- Genel tasarım/akış ihtiyaçlarını karşılıyor mu?
Tasarımlara tekrar göz atma ve başka bir test turu
Geri bildirim içeren çalışan bir prototipiniz var. Artık tasarımlarınızı gözden geçirmenin ve nelerin işe yarayıp nelerin yaramadığını analiz etmenin zamanı geldi. Tamamen yeni bir taslak şema ve yeni bir prototip oluşturmaktan çekinmeyin. Baştan başlamak, önceki prototipinizdeki öğeleri taşımaya çalışmaktan daha iyi bir akış oluşturabilir. Yalnızca bir prototip olduğu için çok fazla önemsemeye çalışmayın.
Tasarımlarınızdan memnun kaldığınızda tekrar test edebilir ve daha da hassaslaştırabilirsiniz. Prototipin hiç hedefe ulaşmadığı durumlarda projenin başarısız olduğunu düşünebilirsiniz. Aslında öyle değil. Tasarımınızı kendiniz oluşturduysanız harcayacağınız geliştirme süresinden daha az süre harcamış olursunuz ve kullanıcıların ne istediğini daha iyi bilirsiniz. Tasarım sprintlerinde, kazandığınız veya bir şeyler öğrendiğiniz bir felsefemiz var. Bu nedenle, fikir planlandığı gibi çalışmadıysa kendinizi fazla üzmeyin.
Yap.
Fikirlerinizi test ettiniz. Kullanıcı bu içerikleri beğeniyor. Paydaşlar, başından beri dahil oldukları için projeye yatırım yapar. Şimdi asıl işe başlama zamanı. Bu aşamada, nelerin yapılması gerektiği ve deneyimin öncelikleri hakkında net bir fikriniz olmalıdır. Projenin her aşamasında, çalışmanızı doğrulamanıza ve doğru yolda kalmanıza yardımcı olması için kullanılabilirlik testi uygulamak isteyebilirsiniz.
Doğru çözüm olmayabilecek bir şey için çok fazla çalışma, zaman ve enerji harcamadan önce mümkün olduğunca fazla bilgi edinmenin ne kadar önemli olduğunu vurgulamak isterim.
Bu makale, kullanıcı deneyimi ve önemi hakkında temel bilgiler edinmenize yardımcı olacaktır. UX, bir tasarımcı veya araştırmacı rolü olarak değerlendirilmemelidir. Bu aslında projede yer alan herkesin sorumluluğudur. Bu nedenle, her fırsatta dahil olmanızı öneririm.