Kuruluşunuza Daha İyi Bir Tasarım Süreci Getirmek

Kullanıcı deneyimi (UX) tasarımcıları ve araştırmacıları olarak, kullanıcılardan duyduğumuz en yaygın şikayet:

“Neden neye ihtiyacım olduğunu düşünmüyorlar?”

Aslında, birçok kuruluş, kullanıcıların ve müşterilerin ihtiyaç duyduğu şeyi sağlamaya adanmış ekiplere sahiptir. Gittikçe daha fazla yazılım geliştiricisi, müşterilerin kullanacağı ve anlayacağı arayüzleri kodlamak için UX tasarımcılarıyla çalışmaya hevesli. Sorun şu ki, karmaşık yazılım projeleri, rekabet halindeki öncelikler ve daha sonra ne yapılacağı konusunda kafa karışıklığı içinde kolayca çıkmaza girebilir.

Sonuç, üretkenliği engelleyen zayıf tasarımdır. Örneğin, sağlık hizmetlerinde verimlilik elektronik tıbbi kayıtlar (EMR'ler) tarafından engellenmektedir. Bu yazılım sistemleri hakkında şikayetler çoktur. Boston merkezli dermatolog ve Yale Tıp Fakültesi mezunu Dr. Steven Ugent bir istisna değildir.

2010'dan beri Dr. Ugent iki EMR sistemi kullanıyor: 2010'dan önce her gün 5:15'te işini hemen bitirdi. O ve meslektaşları EMR kullanmaya başladığından, akşamları genellikle yarım saatten 1,5 saate kadar fazladan çalışıyor. “Tıbbi kayıt sisteminden memnun olan bir doktor tanımıyorum. Çılgınca olan şey, kalem ve kağıt kullanırken çok daha verimli olmamdı.”

EMR sistemleri hantal, esnek değildir ve özelleştirilmesi zordur. Örneğin Ugent, fotoğrafları doğrudan grafik notlarına yerleştiremez. Bunun yerine, köstebeğin fotoğrafının bulunduğu klasörü açmalı ve ardından metni görmek için farklı bir klasör açmalıdır. Bu kurulum, hastaları tedavi ederken büyük ölçüde fotoğraflara güvenen dermatologlar için özellikle zahmetlidir.

Ugent, EMR'lerle ilgili sorunu kısa ve öz bir şekilde özetliyor:

“Onu [EMR sistemini] tasarlayan insanlar iş akışımı anlamıyor. Yapsalardı, farklı bir sistem tasarlarlardı.”

Doktorlar, hantal yazılımlarla ilgili hayal kırıklıklarında yalnız değiller. Dünyanın dört bir yanındaki tüketiciler ve profesyoneller benzer şikayetlerde bulunuyor:

“Neden ihtiyacım olanı bulamıyorum?”

"Neden bu kadar zorlaştırıyorlar?"

“Sadece bu ürünü satın almak istediğimde neden bir giriş oluşturmam gerekiyor. Onlara para veriyorum. Bu yeterli değil mi?”

Tıknaz yazılımlara en büyük katkı kusurlu tasarım süreçleridir. Bu makalede, dört tasarım süreci sorununu ana hatlarıyla açıklayacağız ve bunların nasıl ele alınacağını açıklayacağız.

1. karmaşıklık
2. Sonraki Yayın Sendromu
3. Tasarım Yinelemeleri İçin Yetersiz Zaman
4. Kontrolün Dış Satıcılara Teslim Edilmesi

1. Karmaşıklık

Ölçek, çoklu paydaşlar ve karmaşık kod ihtiyacı, büyük yazılım projelerinin karmaşıklığına katkıda bulunan birçok faktör arasındadır.

Ancak bazen gözden kaçan karmaşık yasalar ve düzenlemelerdir. Örneğin, sigorta, eyalet düzeyinde yoğun bir şekilde düzenlenir ve birden fazla eyalette faaliyet gösteren sigorta şirketleri için bir karmaşıklık katmanı ekler. Bankalar ve kredi birlikleri düzenlemeye tabiyken, kamu hizmetleri eyalet ve federal çevre yasalarına uymak zorundadır.

FDA düzenlemelerine tabi sağlık ürünleri ve yazılımları daha da büyük bir zorluk sunuyor. Sorun, düzenlemelerin mantıksız olması değil. Güvenlik her şeyden önemlidir. Sorunlar zaman, bütçe ve FDA gerekliliklerini karşılamak için gerekli planlamadır.

Sağlık alanında geniş deneyime sahip bir UX danışmanı olan Ph.D. Jeff Horvath'ın açıkladığı gibi: "Bu gereksinimler, test protokolleri yazma, test kurulumu, veri toplama, analiz, kalite kontrolleri ve ilk etapta araştırmayı yürütmek için onay almak. ” Örneğin, tek bir kullanılabilirlik testi turu altı haftadan (standart bir kullanılabilirlik testi için makul bir zaman dilimi) altı aya sıçrar. Ve bu, tek bir kullanılabilirlik testi turu ile . Çoğu zaman, iki veya daha fazla test turu gereklidir.

Bu titizlik düzeyi, FDA ile çalışmaya yeni başlayan şirketler için bir uyandırma çağrısıdır. Horvath, FDA gerekliliklerini karşılamak için gereken uzatılmış zaman çizelgeleri ve ek bütçe için hazırlıksız olan müşterilerle birçok kez zorlu görüşmelerle karşı karşıya kaldı. Zor ama gerekli. Horvath, "Kapsamlı olmakta fayda var" diyor. 2018'de FDA, pazar öncesi başvuruların yalnızca %11'ini onayladı.

FDA uyumluluğu gerektiren sağlık hizmeti yazılımları için araştırmacılar, tasarımcılar ve geliştiriciler üzerindeki talepler, geleneksel yazılım ürünlerinden daha yüksektir. Örneğin:

• Bir UX araştırmacısı, standart yazılım için günde daha yaygın olan beş ila altı oturumun aksine, günde yalnızca bir veya iki kullanılabilirlik testi oturumu yürütebilir.
• UX tasarımcıları, kullanıcının yazılımla etkileşiminin her yönüne aşırı derecede dikkat etmelidir. Tek bir kafa karıştırıcı etkileşim bile bir klinisyenin hastanın sağlığını tehlikeye atabilecek bir hata yapmasına neden olabilir. Aynı nedenle, UI tasarımcıları her etkileşime sadık kalan arayüzler çizmelidir.
• Tasarım ve kullanılabilirlik testi için daha uzun bir zaman çerçevesi, geliştiricinin kodlama çabalarının dikkatli bir şekilde planlanması gerektiği anlamına gelir. Nitelikli ve iyi niyetli geliştiriciler, genellikle yeni bilgiler elde edilir edilmez kodu değiştirmeye heveslidir. Bu yaklaşım, hızlı yinelemede iyi uygulanmış kuruluşlarda çalışabilirken, karmaşık sistemleri tasarlarken ve kodlarken risk taşır.

Danielle McCray, doğum yapmak üzereyken Tallahassee Memorial Hastanesine kabul edildiğinde olduğu gibi, karmaşıklığın yönetilememesi ölümcül sonuçlara yol açabilir. Rahatsızlığı hafifletmek için sağlık çalışanları onu hasta kontrollü bir analjezi makinesine, programlanabilir bir infüzyon pompasına bağladı.

Sekiz saat sonra McCray'in aşırı dozda morfinden öldüğü açıklandı. Bu trajedide önemli bir faktör, ilacı uygulamak için kullanılan infüzyon pompasının hatalı tasarımıydı. Pompa, 27 programlama adımı gerektiriyordu. Daha sezgisel bir kullanıcı arayüzü tasarlayarak bu tür karmaşıklığın üstesinden gelinememesi, gereksiz ölüme katkıda bulundu.

Çözüm

Çözüm, karmaşıklığı kabul etmek ve ele almaktır. Bu nokta kulağa mantıklı geliyor. Yine de, yukarıda açıklandığı gibi, karmaşık FDA düzenlemeleri genellikle şirket liderlerini şaşırtıyor. İnkar işe yaramaz. Plan yapmamak, kuruluşunuzun, FDA'nın 2018'de reddettiği pazar öncesi başvuruların %89'una düşeceği anlamına gelir.

Kullanılabilirlik testleri yürütürken, kullanıcı deneyimi araştırmacıları, FDA düzenlemeleriyle ilişkili karmaşıklığı yönetmek için üç adım atmalıdır:

1. Moderatör (kullanılabilirlik testini yapan kişi) aşırı dikkatli olmalıdır. Örneğin, bir MRI taraması, bir teknisyenin ilgili yazılımı kullanırken katı bir dizi adımı izlemesini gerektiriyorsa, moderatör, katılımcının mektuba yönelik talimatları izleyip izlemediğini belirlemek için dikkatli bir şekilde gözlem yapmalıdır. Değilse, görev, hem arayüz tasarımının hem de ilgili belgelerin değişiklik gerektireceği anlamına gelen bir başarısızlık olarak derecelendirilir;
2. Moderatör ayrıca yakın aramaları da izlemelidir. Örneğin, bir katılımcı başlangıçta adımları sıra dışı olarak gerçekleştirebilir, hatayı keşfedebilir ve uygun sırayı izleyerek düzeltebilir. FDA bunu ramak kala olarak değerlendirir ve moderatör bunu bu şekilde rapor etmelidir;
3. Moderatör ayrıca katılımcının bilgisini de değerlendirmelidir. Doğru sırayı izlediğine inanıyor mu? Bu inanç doğru mu?

2. Sonraki Yayın Sendromu

Karmaşıklığı kabul etmedeki başarısızlıktaki faktörlerden biri, bir sonraki sürüm sendromu dediğimiz daha sonra düzelt zihniyetidir. Yazılım hataları sorun değil çünkü "bunu bir sonraki sürümde düzelteceğiz." Kalite ve güvenlikten çok hıza verilen önem, zor sorunları çözmeyi ertelemeyi çok kolaylaştırır.

Ürün tasarımı ve geliştirmesine dahil olan herkes, bir sonraki sürüm sendromuyla mücadele etmelidir. İki örnek konuyu açıklıyor:

• Bir müşterinin sağlık hizmeti izleme yazılımında ciddi tasarım kusurları keşfettik. Şirket, bu sorunları çözmeden yazılımı piyasaya sürmeyi seçti. Şaşırtıcı olmayan bir şekilde, müşteriler mutsuzdu.
• ABD merkezli büyük bir kredi birliği için kullanılabilirlik testleri gerçekleştirdik Katılımcılar deneyimli mali danışmanlardı. Testler, kafa karıştırıcı durum simgeleri, belirsiz bir amaca sahip düğmeler ve katılımcıların önemli verileri görüntülemesini engelleyen neredeyse gizli bir bağlantı gibi ciddi tasarım kusurlarını ortaya çıkardı. Unutmayın, kullanıcı görmüyorsa, orada değildir. Bulguları bildirdiğimizde aldığımız yanıt şuydu: "Bunu bir sonraki sürümde düzelteceğiz." Beklendiği gibi, web uygulaması iyi karşılanmadı. Kullanıcılardan gelen yanıtlar şunları içeriyordu: "Değişiklik yapma niyetiniz yoksa neden uygulamayı incelememizi istediniz?"

Çözüm: Sonraki Seferde Onar Zihniyetini Reddedin

Çözüm, şimdi ciddi tasarım sorunlarını çözmektir. Kulağa basit geliyor. Ancak, karar vericileri yerleşik “sonra düzelt” zihniyetini değiştirmeye nasıl ikna edersiniz?

Anahtar, başarı hakkındaki konuşmayı ürün tesliminden yaratılan değere kaydırmaktır. Örneğin, kullanıcı araştırmasına dayalı olarak bir tasarımı revize etmek için zaman ayıran ekiplerin daha iyi müşteri tepkileri ve zamanla artan müşteri sadakati görmeleri olasıdır.

Karar vericilere kullanıcı araştırması ile artan gelir ve olumlu bir müşteri deneyimi arasındaki doğrudan bağlantıyı göstermek için nicel verileri kullanarak durumu güçlendirin.

Değeri yeniden tanımlamak, aslında bir süreç iyileştirmesidir, çünkü müşterilere ve şirketinizin uzun vadeli çıkarlarına daha iyi hizmet eden yeni bir dizi öncelik belirler. McKinsey'in The Business Value of Design'da bildirdiği gibi: “Üst çeyrek şirketler tam kullanıcı deneyimini benimsiyor; fiziksel, dijital ve hizmet tasarımı arasındaki iç engelleri yıkıyorlar.”

3. Tasarım Yinelemeleri İçin Yetersiz Zaman

Bir sonraki sürüm sendromuyla ilgili olarak, araştırma bulgularına veya değişen iş gereksinimlerine dayalı tasarımı yinelemek için yeterli zaman yoktur. Geliştiricilerin ve ürün sahiplerinin ortak kaçınması “Bunun için zamanımız yok”. Çevik ortamlarda çalışan tasarımcılar, geliştirme ekibini "beklemekten" kaçınmak için sıklıkla baskı altındadır.

Geliştirme hızlanır ve yazılım yayınlanır. Hepimiz, kafa karıştırıcı telefon uygulamalarından, hantal tıbbi kayıt yazılımlarına ve yukarıda atıfta bulunulan mali danışmanlar için hantal kullanıcı arayüzüne kadar sonuçları gördük.

Çözüm: Tasarım Sivrisinekler

Kodlama dünyasından bir çözüm geliyor. Damon Dimmick, "Büyük Resim Kullanıcı Deneyimini Çevik Geliştirmeye Yerleştirmek" adlı makalesinde, tasarım sıçramaları, "tasarımcıların karmaşık kullanıcı deneyimi sorunlarına odaklanmasına olanak tanıyan zaman baloncukları" fikrini sunuyor. Normal bir sprintin yerini geçici olarak alarak Scrum çerçevesine uyarlar.

Tasarım sivri uçları çeşitli avantajlar sunar:

• UX ekiplerinin bütünsel konulara odaklanmasına ve bazen tek bir sprint içinde vurgulanan ayrıntılı tasarım sorunlarına saplanmaktan kaçınmasına olanak tanır;
• Karmaşık UX sorularını üst düzeyde keşfetme fırsatı sunarlar. Gerekirse, UX tasarım ekibi, daha büyük UX zorluklarını çözmek için herhangi bir noktada tasarım merkezli düşünceye girebilir;
• UX ekipleri, tasarım artışlarını benimseyerek, geliştirme ekiplerinin çevik süreçte kullandığı esnekliğin aynısından yararlanabilir ve her zaman standart bir scrum sprint'e tam olarak uymayan tasarım sorunlarına odaklanmak için gereken zamanı ayırabilir;
• Tasarım kararlarından etkilenmesi muhtemel olmayan geliştirme devam edebilir.

Doğal olarak, tasarım yinelemeleri genellikle bir site, uygulama veya yazılım ürünü için kodun belirli bölümlerini etkiler. Bu nedenle, tasarım ani yükselişleri sırasında, tasarım ani yükselişinden etkilenmesi muhtemel olan herhangi bir kod ilerleyemez. Ancak, Dimmick'in açıkça belirttiği gibi, bu “gecikme”, yeniden çalışmayı önleyerek büyük olasılıkla zaman kazandıracaktır. Şimdi kod yazıp, ekibin revize edilmiş bir tasarım üzerinde anlaşmaya varmasından birkaç hafta sonra yeniden yazmanın bir anlamı yok. Kısacası, bazı kodlamaları ertelemek aslında zamandan ve bütçeden tasarruf sağlar.

4. Satıcılara Çok Fazla Güvenmek

Etkili bir tasarım süreci için karmaşıklığı ele almak, bir sonraki sürüm sendromuna direnmek ve yineleme için zaman tanımak çok önemlidir. Birçok firma için bir diğer husus, yazılım satıcılarıyla olan ilişkileridir. Bu satıcılar, geliştirmede önemli, hatta kritik bir rol oynamaktadır. Yine de onlara çok fazla kaldıraç vermek, kendi ürününüzü kontrol etmenizi zorlaştırır.

Elbette iş arkadaşlarımıza ve satıcılara saygılı davranmalı ve makul taleplerde bulunmalıyız. Ancak bu, büyük bir finans firmasında görev yaptığım süre boyunca olduğu gibi tüm kaldıraçtan vazgeçmem gerektiği anlamına gelmez.

UX tasarımcısı olarak bu firmada çalışırken şu dinamikle sık sık karşılaştım:

Yönetici : “Hey, Eric, satın almayı planladığımız bu iddia yazılımını değerlendirebilir misin? Sadece amaçlandığı gibi çalıştığından emin olmak istiyoruz.”

Ben : “Tabii, hafta sonuna kadar ön bulgularımı size gönderirim.”

Yönetici : “Harika”

Önümüzdeki hafta:

Yönetici : “İnceleme için teşekkürler. Görüyorum ki üç ciddi sorun bulmuşsunuz: Mevcut bir hak talebinin numarasını bulmak zor, çok fazla metin içeren ve okunması zor olan ekranlar ve yeni bir hak talebini işlerken önceki ekrana dönmenin zorluğu. Bu ilgili. Bu sorunların üretkenliği engelleyeceğini düşünüyor musunuz?”

Ben : “Evet, bu konuların Hasar Merkezinde stresi ve işlem süresini artıracağını düşünüyorum. Oldukça endişeliyim çünkü Janet'in ekibiyle yaptığım önceki çalışmam, Hasar Merkezi temsilcilerinin zaten oldukça stresli olduğunu gösterdi.”

Yönetici : “Bilmek gerçekten güzel. Az önce çek gönderdim. Satıcıdan sorunları göndermeden önce düzeltmesini isteyeceğim.”

Ben (içeriden bağırarak): "Yoooooooooooooo!"

Bu iyi niyetli yönetici kesinlikle yanlış olanı yaptı. Çeki gönderdikten sonra değişiklik istedi. Satıcının istenen değişiklikleri asla yapmaması şaşırtıcı değil. Neden yapsınlar? Onların parası vardı.

Bu senaryo sadece o şirkette tekrar tekrar oynamakla kalmadı, aynı zamanda UX kariyerim boyunca buna tanık oldum.

Çözüm

Çözüm açık. Satıcı ürünü müşteri ve iş ihtiyaçlarını karşılamıyorsa ve talep ettiğiniz değişiklikler kapsam dahilindeyse, satıcı değişiklikleri yapana kadar ödeme yapmayın. Gerçekten bu kadar basit.

Çözüm

Bu yazıda, kaliteli tasarım ve buna karşılık gelen çözümler için dört ortak engel belirledik:

1. Karmaşık düzenlemeler ve standartlar
   Çözüm, araştırma ve yinelemeli tasarım için gerçekçi zaman çizelgeleri ve yeterli bütçe oluşturarak karmaşıklığı kabul etmek ve ele almaktır.
2. Hataları daha sonra düzeltme sözü veren yazılım gönderme
   Çözüm, bir sonraki sürüm sendromundan kaçınmak ve şimdi ciddi sorunları ele almaktır. Kuruluşunuzdaki değerin anlamını yeniden tanımlayarak karar vericileri ikna edin.
3. Tasarım yinelemeleri için yetersiz zaman
   Çözüm, çevik geliştirme sürecine tasarım artışlarını dahil etmektir. Bu zaman baloncukları geçici olarak bir sürat koşusunun yerini alır ve tasarımcıların karmaşık UX sorunlarına odaklanmasına olanak tanır.
4. Satıcılara çok fazla güvenmek
   Çözüm, bu değişiklikler orijinal proje kapsamında olduğu sürece, satıcı istenen değişiklikleri yapana kadar nihai ödemeyi alıkoymak suretiyle kaldıracı elde tutmaktır.

Dördüncü çözüm basittir. İlk üçü kolay olmasa da, doğrudan mevcut tasarım süreçlerine uygulanabildikleri için somutturlar. Bunların uygulanması, büyük bir yeniden yapılanma veya milyonlarca dolar gerektirmez. Sadece daha iyi bir deneyim sunma taahhüdünü gerektirir.