Design thinking nedir? Tasarım odaklı düşünme ve 5 aşaması

Kısaca

Design thinking, bir ekibin çözüme atlamadan önce sorunu yaşayan kişiyi tanımasını isteyen bir çalışma biçimidir. Türkçede tasarım odaklı düşünme ya da tasarım düşüncesi denir. Bu sayfada hepsini aynı anlamda kullanıyorum.

IDEO'nun eski CEO'su Tim Brown'a göre design thinking, tasarımcının araç kutusundan beslenen ve inovasyonda insanı merkeze alan bir yaklaşımdır. IDEO, bu yaklaşımın üç şeyi bir araya getirdiğini söyler: insanların istediğini, kurumun sürdürebileceğini ve teknolojinin yapabileceğini.

Nielsen Norman Group'tan Sarah Gibbons ise design thinking'i bir süreçle desteklenen bir ideoloji olarak tanımlar. Bu ayrım bence önemli, çünkü aşamaları ezberlemek kolaydır. Zor olan, bakış açısını ekibe yerleştirmektir.

Gibbons'a göre terimi 1990'larda IDEO'dan David Kelley ile Tim Brown, bir de Roger Martin ortaya attı. İyi tasarımcılar insan odaklı yaratıcı bir süreci bundan çok önce de kullanıyordu. Terim, yıllardır olgunlaşan yöntemleri tek bir kavramda topladı ve onları iş sorunlarına uygulanan bir çerçeveye çevirdi.

Design thinking aşamaları

En yaygın anlatım Stanford d.school'un beş aşamasıdır. d.school bunlara aşama değil “mod” der ve 2018 tarihli Design Thinking Bootleg destesinde her modun yöntem kartlarını verir. Destenin girişinde, istediğiniz yerden başlayabileceğiniz de yazıyor.

1. Empati

d.school empatiyi insan odaklı tasarımın temeli sayar. Çözmeye çalıştığınız sorun nadiren sizin sorununuzdur, belirli kullanıcıların sorunudur. Bu yüzden kullanıcıyı kendi ortamında gözleyip onunla konuşursunuz, yaşadığını da bir süre kendiniz yaşarsınız.

2. Tanımla

Empati aşamasında topladıklarınızı ihtiyaçlara ve içgörülere çevirir, sonunda üzerinde çalışılabilecek bir sorun cümlesi yazarsınız. d.school bu cümleye bakış açısı (point of view, POV) der. Cümle bir demografik grubu değil, belirli bir kullanıcıyı anlatmalıdır.

3. Fikir üret

Bu aşamada amaç genişlemektir: d.school hem çok sayıda hem de birbirinden farklı fikir ister. Kartlardaki uyarı açık, fikir üretirken değerlendirme yapmayın. d.school'a göre yenilikçi fikirler çoğu zaman en aykırı fikirlerden çıkar.

4. Prototip

Prototip, fikri kafanızdan çıkarıp elle tutulur hale getirir. d.school'a göre bu bir duvar dolusu yapışkan not, bir canlandırma ya da bir nesne olabilir. Erken aşamada ucuz ve kaba tutulur; dijital üründe bu çoğu zaman kâğıt ekran ya da tıklanabilir bir prototip demektir.

5. Test

Prototipi kullanıcının kendi ortamına götürür ve geri bildirim alırsınız. d.school'un kartında bir uyarı var: test bazen yalnızca çözümün değil, sorunun da yanlış tanımlandığını gösterir. O zaman POV cümlenizi yeniden yazarsınız.

Altıncı aşama: uygula

NN/g'nin çerçevesinde altıncı bir aşama daha var: uygula. Gibbons bunu en önemli ve en sık unutulan aşama sayar. Atölyede çıkan fikir ürüne girmiyorsa, ortada yalnızca güzel bir gün kalır.

NN/g'ye göre aşamalar düz bir sıra izlemez, tekrar eder ve döngü kurar. Ekipler bir prototipi test ettikten sonra sık sık empati ve tanımla aşamalarına döner.

Aşama haritası: bir belediye randevu uygulaması

Beş aşamayı soyut anlatmak yerine tek bir senaryo üstünde gösteriyorum. Bir belediyenin randevu uygulamasında alınan randevuların bir kısmına kimse gelmiyor. Ekip nedenini bilmiyor.

Aşama haritası

Aşama 1 / 5

Empati

Amaç

Sorunu yaşayan kişiyi tanımak. d.school bu aşamada üç şey ister: kullanıcıyı kendi ortamında gözlemek, onunla konuşmak ve yaşadığını bir süre siz de yaşamak.

Örnek etkinlik

Ekip, belediye hizmet binasında sırada bekleyen vatandaşlarla ikişer kişilik gruplar halinde konuşur. Biri soru sorar, diğeri not alır. Soru “Genelde nasıl randevu alırsınız?” değil, “En son randevu aldığınız günü anlatır mısınız?” olur. Bir ekip üyesi de randevuyu, uygulamayı hiç bilmeyen biri gibi baştan alır.

Çıktı

Alıntılar, gözlem notları ve fotoğraflar. Örnek bir not: “Randevuyu oğlum aldı, saati bana kimse söylemedi.”

Aşama 2 / 5

Tanımla

Amaç

Notları ihtiyaçlara ve içgörülere çevirmek. Sonunda ekibin üzerinde anlaştığı tek bir bakış açısı cümlesi çıkar. d.school buna “point of view” (POV) der.

Örnek etkinlik

Ekip notları duvara asar ve benzerlerini gruplar. Sonra şu cümleyi yazar: “Randevuyu çocuğuna aldıran yaşlı bir vatandaşla tanıştık. Randevu bilgisinin ona hiç ulaşmadığını görünce şaşırdık.” Ardından bu cümleden “Nasıl yapabiliriz?” soruları çıkarılır.

Çıktı

Bir POV cümlesi ve birkaç “Nasıl yapabiliriz?” sorusu. Örneğin: “Randevuyu alan başkaysa, gidecek kişiye nasıl haber verebiliriz?”

Aşama 3 / 5

Fikir üret

Amaç

Çok sayıda ve birbirinden farklı fikir toplamak. Bu sırada fikirleri yargılamamak gerekir. Eleme, üretme bittikten sonra yapılır.

Örnek etkinlik

Ekip “Nasıl yapabiliriz?” sorusunu tahtaya yazar ve yarım saatlik bir beyin fırtınası yapar. Her fikir yapışkan nota yazılır. Randevuya “gidecek kişi” alanı eklemek, SMS yerine sesli arama, muhtarlıktan randevu almak gibi fikirler çıkar. Sonunda herkes oy verir.

Çıktı

Duvar dolusu not ve oyla seçilmiş iki üç fikir.

Aşama 4 / 5

Prototip

Amaç

Fikri kafadan çıkarıp dokunulabilir hale getirmek. Erken aşamada prototip ucuz ve kaba olur, böylece hızlı öğrenilir.

Örnek etkinlik

“Gidecek kişiyi ekle” adımı kâğıda çizilir. Hatırlatma mesajı için kod yazılmaz: vatandaş mesajı sistemden geliyor sanır, ama onu bir ekip üyesi elle gönderir. d.school bu yönteme Wizard of Oz prototipi der.

Çıktı

Kâğıt ekranlar ve elle yürütülen bir hatırlatma senaryosu. İkisi de bir öğleden sonrada hazırlanır.

Aşama 5 / 5

Test

Amaç

Prototipi kullanıcının gerçek ortamına koyup geri bildirim almak. d.school'a göre test hem çözümü hem de kullanıcıyı öğrenme fırsatıdır.

Örnek etkinlik

Vatandaş masasında birkaç kişiye kâğıt prototip verilir ve fazla açıklama yapılmaz. Ekip araya girmeden izler, sonra “Neden?” diye sorar. Günün sonunda ekip “Beğendim, keşke, ya şöyle olsaydı” turu yapar.

Çıktı

Neyin işe yaradığını ve neyin yaramadığını gösteren bir liste. Gerekirse yeniden yazılmış bir POV cümlesi ve bir sonraki turun kararı.

Senaryo kurgusal: bir belediyenin randevu uygulaması, gelmeyen vatandaşlar yüzünden boş kalan randevular. Bir aşamaya basın, altındaki kartta o aşamanın amacı, örnek etkinliği ve çıktısı değişsin. Amaçlar d.school'un Design Thinking Bootleg kartlarından benim özetimdir.

Senaryoda dikkat etmenizi istediğim yer, tanımla aşaması. Ekip “hatırlatma SMS'i ekleyelim” diye başlasaydı, randevuyu başkasına aldıran vatandaşı hiç görmeyecekti. Doğru sorun, empati notlarından çıktı.

Atölyede nasıl uygulanır

Design thinking en çok atölyede görünür hale gelir: farklı birimlerden insanlar aynı odada, aynı soruya bakar. d.school destesindeki kartlar bu iş için yazılmış küçük araçlardır. En çok kullandıklarım şunlar.

Acemi zihniyeti

d.school ekibe, bildiklerini bir kenara koyup soruna yeni gözle bakmasını önerir. Yargılamayın, her şeyi sorgulayın, gerçekten merak edin. Belediye senaryosunda bu, “vatandaş zaten SMS alıyor” varsayımını sorgulamak demektir.

Empati görüşmesi

Kartın önerileri basit ama sık çiğnenir. Soruda “genelde” demeyin, belirli bir anı sorun: “En son ne zaman ... yaptığınızı anlatır mısınız?” Kişinin söyledikleriyle yaptıkları arasındaki çelişkiye dikkat edin ve sessizlikten korkmayın.

d.school görüşmeyi ikişer kişi yapmayı önerir: biri konuşur, diğeri not alır. Uç kullanıcılarla da konuşun, çünkü kartlara göre onların abartılı ihtiyaçları ortalama kullanıcıda gözden kaçan ihtiyaçları görünür kılar. Görüşmelerden sonra bir persona çıkarmak bulguları ekibe taşımayı kolaylaştırır.

“Nasıl yapabiliriz?” soruları

d.school bu soruları “How might we” diye adlandırır. Soru, fikir üretmeyi başlatacak kadar geniş, ekibe sınır koyacak kadar dar olmalıdır. Desteğin örneğiyle: tatlıyı baştan tasarlamak fazla geniş, damlamayan dondurma külahı fazla dardır.

Beyin fırtınası

Kart, ekibin tahtanın önünde 15 ila 30 dakika yalnızca fikir üretmesini önerir. Bu sürede kimse fikir elemez. Her fikir ayrı bir yapışkan nota yazılır, seçim sonraya kalır.

Kullanıcıyla test

d.school prototipi anlatmak yerine kullanıcının eline vermenizi ve onu hemen düzeltmemenizi ister. Nasıl kullandığını ve nasıl yanlış kullandığını izleyin. Sonra sorun: “Bunun size neden işe yarayıp yaramayacağını gösterir misiniz?”

Daha yapılandırılmış bir tur için kullanılabilirlik testi rehberine bakın.

Test sonrası ekip için “Beğendim, keşke, ya şöyle olsaydı” turunu severim. Herkes kısa başlıklarla konuşur ve her başlığa cevap vermek gerekmez. Kart bu aracı neredeyse yazmaya değmeyecek kadar basit ama atlanmayacak kadar faydalı bulur.

Bir günlük atölyeyi ben nasıl kurarım

Sabah görüşme notlarını ve varsa bir kullanıcı yolculuğu haritasını birlikte okuruz. Öğleden önce POV cümlesini ve “Nasıl yapabiliriz?” sorularını yazarız. Öğleden sonra fikir üretir, kâğıt prototip çizeriz.

Günün son saatini gerçek kullanıcıya ayırırım. Kullanıcı yoksa test ertesi güne kalır ama asla atlanmaz. Kullanıcı görmeden biten bir atölyede ekip yalnızca kendi varsayımlarını onaylamış olur.

UX tasarımı ve Double Diamond ile farkı

Bu üç kavram sık karıştırılır, çünkü aşama adları birbirine benzer. Benim ayrımım şu: design thinking bir zihniyet ve atölye pratiğidir, UX tasarımı ise bir ürünü haftalarca, aylarca yürüten iştir. Double Diamond bu işi anlatan bir modeldir.

Ürün sürecini adım adım UX tasarımı rehberinde anlattım. Design Council'ın modelini ise Double Diamond sayfasında ayrıca ele alıyorum. Design Council'ın kendi sayfasındaki tarihçe, 2003'te tasarım sürecini standart bir dille anlatma arayışıyla başlıyor.

Eleştiriler

Design thinking'in güçlü savunucuları kadar güçlü eleştirmenleri de var. Aşağıdaki görüşlerin hepsini kaynağından okudum.

“Faydalı bir efsane.” Don Norman 2010'da Core77'deki yazısında, tasarımcıların herkesten üstün, gizemli bir düşünme biçimi olduğu fikrine efsane dedi. Ona göre design thinking, eski usul yaratıcı düşünmenin halkla ilişkiler adıydı. Yine de terimi faydalı buldu: terim, tasarımcıların işinin bir şeyleri “güzel göstermek”ten fazlası olduğunu anlatıyordu.

Karşı cevap. Bill Moggridge aynı yıl Core77'de Norman'a cevap verdi. Ona göre design thinking etiketi bir efsane değildir ve sürecin tekrarlayan yapısı hep oradadır. Süreci geçmişi ne olursa olsun herkes kullanabilir; en çok da işin başında ne yapılacağına karar verirken işe yarar.

Norman'ın dönüşü. Norman 2013'teki “Rethinking Design Thinking” yazısında görüşünü kısmen değiştirdi. Design thinking'in gerçekten özel olduğunu yazdı, ama bunun yalnızca tasarımcılara ait olmadığını da ekledi. Varsayımları sorgulamayı merkeze koydu.

Tasarımcıyı merkeze koyması. NYU'dan Natasha Iskander, 2018'de Harvard Business Review'da design thinking'in temelde muhafazakâr olduğunu savundu. Ona göre yöntem mevcut düzeni korur ve tasarımcıyı hizmet ettiği insanların üstüne yerleştirir.

Uygulamanın unutulması. Bu bir dış eleştiri değil, NN/g'nin kendi uyarısı. Gibbons uygulama aşamasını en önemli ve en sık ihmal edilen aşama sayar. Yapışkan notlarla dolu bir duvar, ürüne giren tek bir değişikliğin yerini tutmaz.

Benim notum

Design thinking'i bir yöntem olarak değil, bir alışkanlık olarak görüyorum. Ekip ilk toplantıda çözüm konuşmaya başladığında, “Bunu kimden duyduk?” diye sorarım. Cevap yoksa önce birkaç kullanıcıyla konuşuruz.

Iskander'in eleştirisini haklı buluyorum. Empati görüşmesi, kullanıcıyı karar odasına sokmanın yerini tutmaz. Bu yüzden atölyelere mümkünse gerçek kullanıcıyı ya da onunla her gün konuşan destek ekibini çağırırım.

Atölyeden çıkan fikirlerin çoğu ürüne girmez, bu normaldir. Benim ölçütüm şu: atölyeden sonraki iki hafta içinde en az bir fikir prototipten koda geçti mi? Geçmediyse atölye değil, gösteri yapmışızdır. Bu geçişi tasarımdan koda rehberinde anlattım.