Stephanie Walter ile Çarpıcı Podcast Bölüm 9: UI Çerçeveleriyle Nasıl Çalışabilirim?

Kendim de bir geliştirici olarak, UI çerçeveleri hakkında sevdiğim şeylerden biri, genellikle varsayılan stille gelmeleri, ancak bu projelerde güvenmemiz gereken bir şey mi? Basitçe varsayılan stili kullanmak ve çerçeveyi üreten kişinin bu bileşenleri tasarlamada gerçekten iyi bir iş çıkardığına güvenmek mi? UX Tasarımcısı Stephanie Walter ile bir UI çerçevesi oluştururken göz önünde bulundurmamız gereken şeyler hakkında konuştuğum bugünkü podcast bölümünde bana katılın.

Notları göster

• Stephanie'nin web sitesi
• Twitter'da Stephanie

Haftalık güncelleme

• Anna Prenzel tarafından “Angular ve RxJS Kullanarak Bir Kart Eşleştirme Oyunu Nasıl Oluşturulur”
• Sarah Drasner tarafından “JAMstack'te Başsız Bir WordPress Sitesi Nasıl Oluşturulur”
• Dan Halliday tarafından “Sihirli Çevirmeli Kartlar: Ortak Bir Boyutlandırma Problemini Çözme”
• Philip Kiely'nin "Django Öne Çıkanlar: Kullanıcı Modelleri ve Kimlik Doğrulama (Bölüm 1)"
• Shajia Abidi'den “React And Leaflet ile Haritalar Nasıl Oluşturulur”

Transcript

Drew McLellan: Kullanıcı merkezli bir tasarımcı ve mobil deneyimde uzman, keyifli ürünleri ve arayüzleri performansa odaklanarak birleştirdi. Lüksemburg Üniversitesi, Avrupa Yatırım Bankası, BMW ve Microsoft gibi birkaç isim için projeler üzerinde çalıştı ve bu müşterilerin stratejiden nihai ürüne kadar hedef kitlelerine başarılı projeler sunmalarına yardımcı oluyor. Ürün tasarımında bir Google Developer uzmanı ve bilgisini çok sayıda blog yazısı, makale, atölye çalışması ve konferans sunumunda paylaşan tutkulu bir öğretmendir. Yani onun uzman bir kullanıcı deneyimi tasarımcısı olduğunu biliyoruz, ancak bir zamanlar Sir Elton John ile halı döşeme işi yaptığını biliyor muydunuz? Smashing arkadaşlarım, lütfen Stephanie Walter'a hoş geldiniz. Merhaba Stephanie, nasılsın?

Stephanie Walter: Merhaba, bayıldım ve tanıtımı çok sevdim.

Drew: Bugün sizinle belirli bir konu hakkında konuşmak istedim ve bu, kullanıma hazır kullanıcı arabirimi çerçevelerini kullanma konusu. Artık bir kullanıcı deneyimi tasarımcısısınız ve birçok farklı müşteriyle çalışıyorsunuz ve işiniz, bu müşterilerin son derece kullanışlı kullanıcı arayüzleri oluşturarak mümkün olan en iyi kullanıcı deneyimlerini yaratmalarına yardımcı olmaktır. Bu yüzden, kullanıma hazır bir takım araçlarla bunu yapabilme fikri bana biraz zorlama gibi görünüyor. UI çerçevesinin kullanımı, işiniz boyunca çok gördüğünüz bir şey mi?

Stephanie: Evet, özellikle son birkaç yılda çok gördüğüm bir şey çünkü bir ajansla çalışmaya başladım ve şimdi şirket içinde çalışıyorum. Bu süper büyük BT teknolojisi ekiplerinde ve evet, şu anda en çok gördüğüm gibi birçok çerçeve kullanıcı arayüzü var Material-UI, temel olarak Materyal tasarımı bir Google tasarımı tür yönergeleri ve şeydir ve Material -UI, Angular'ın takımıdır, aynı zamanda React'in takımıdır. Google'ın Materyal tasarımının görünümünü ve verdiği hissi kullanarak kendi çerçevelerini oluşturdular. Ama artık Google ile ilgisi yok. Tıpkı onlar gibi, bilmiyorum, görünüşünü ve hissini beğendiklerini düşünüyorum. Yani şu anda birlikte çalıştığım iki ana UI çerçevesi bunlar. Ayrıca Ant Design diye bir şey var, oldukça popüler hale geldi.

Stephanie: Bu bir React çerçevesi. Onlarda da Angular var mı bilmiyorum. Çin'de bir ekip tarafından yapıldığını düşünüyorum. Ve bu ilginç çünkü sadece bileşenleri, React'teki her şeyi sağlamakla kalmıyor, aynı zamanda web sitelerine giderseniz karalama dosyalarını da alacaksınız, ki bu aslında oldukça ilginç çünkü o zaman tasarımcıyı inşa etmeye veya şekillendirmeye motive ediyor veya yardımcı oluyor. arabirimi, bu çerçeve tarafından kullanılan UI bileşenlerine dönüştürür. Yani evet, özellikle büyük BT ekiplerinde çok gördüğüm bir şey çünkü çoğu zaman bir tasarımcısı yok. Şu anda temelde bir Avrupa yatırım bankasında küçük bir ekipten birinin UX ekibiyim. Yani bir UX tasarımcısı olarak benim. Geliştiriciler, iş analistleri ve tüm iyi insanlardan oluşan bir ekiple çalışıyorum, ancak yine de tüm proje için tek bir tasarımcıyım.

Stephanie: Ben gelene kadar tasarımcı yoktu. Yani bir çok şirkette uygulanan bir çözüm, özellikle de örneğin iç ürünlerde. Genelde derler, tamam, bunun için bir tasarımcıya gerçekten ihtiyacımız yok. Sadece dahili kullanıcılarımız için çalışan bir şeye ihtiyacımız var ve geliştiriciler için uygun olduğu için bir çerçeve kullanalım. Bileşenlerin çoğu zaten orada ve takımda tasarımcıları olmadığı için, bir UI tasarımcısının rolünün yerini alıyor. Evet, bununla ilgili sorun şu ki, tamam, o zaman bileşenlere sahipsiniz, ancak UI tasarımcısının rolü sadece düğmenin kırmızı, yeşil, turuncu, mavi, ne olursa olsun karar vermek değildir. Genellikle UI tasarımcısının rolü, kullanıcı ihtiyaçlarını anlamak için bilgi mimarisidir. Yani arayüzün ötesine geçen her şey. Bu tür bir çerçeveye sahip olsanız bile, bu tür tüm kullanıcı arayüzüyle ilgilenir, yani görsel olarak ekranda gördüğünüz şey.

Stephanie: Hala bir noktada ekrana ne koyduğumuzu anlama işini yapacak birine ihtiyacınız var, nasıl davranacak? Buraya tıkladığımızda ne olur? Kullanıcı amacına nasıl ulaşır? A noktasından B noktasına nasıl gideriz? Çünkü bir model kullanabiliriz, sekmeleri kullanabiliriz, tüm bileşenleri kullanabiliriz. Bu yüzden her zaman biraz karmaşık ve aldatıcıdır.

Drew: Sizce kullanıma hazır bir UI çerçevesi kullanarak kullanışlı bir kullanıcı arayüzü oluşturulabilir mi, yoksa her zaman biraz taviz mi olacak?

Stephanie: Umarım öyledir. Umarım öyledir çünkü aksi halde kullanılabilir olmayan arayüzler inşa ediyorum. Yani bu cevap tamamen taraflı, ama evet, bence öyle, ama aynı zamanda yapmaya istekli olduğunuz uzlaşma düzeyine de bağlı ve her iki tarafta da uzlaşmalar var. Şu anda örneğin birçok düğmeden ödün veriyorum çünkü Material-UI'de gerçekten özel düğmeleriniz var ve düğmedeki dalgalanma efektini gerçekten sevmiyorum. Mobilde harika çalıştığını düşünüyorum çünkü mobilde kullanıcı düğmeye tıkladığında veya düğmeye dokunduğunda bir tür büyük geri bildirime ihtiyacınız var. Ama sonra adımlar, düğmenin sonuna kadar giden bir tür dalgalanma etkisidir. Özellikle çok fazla düğme olduğunda, biraz abartılı. Ama yine de bu dalgalanma etkisini koruyacağız çünkü bu, React çerçevesinde yerleşik olduğu için onu kaldırmak çok karmaşık olacaktır. Ve bu düğme üzerinde başka bir fareyle üzerine gelme efektine sahip olmak için, burada bu tür bir vızıltı olmayacak daha incelikli bir şey. Süper karmaşık olurdu.

Stephanie: Demek bu, yaptığın türden tavizler. Ancak bu arada, özel bileşenler olan belirli şeylerden ödün vermiyorum. Daha önce çalıştığım yerde, bir seyahat ve havayolu şirketinin şu anki müşterisi. Ve havayolunun gerçekten, gerçekten süper özel ihtiyaçları var. Örneğin, havayolunun takvimi, fiyatları koymak istiyorsunuz, koymak istiyorsunuz… bu varış noktasına belirli bir tarihte seyahat etmiyorsanız, ne zaman koyacağınızı bilmiyorsunuz, bu kalkış ve varış var ve bu UI çerçevelerinin çoğunun temel takvimi bu tür şeyleri sağlamaz. Yani bir noktada, tamam, sadece sahip oldukları takvimi kullanacağız diyebilirsiniz. Ve bu kadar. Bunun ötesine geçmeniz gerekiyor. Yani uzlaşmaların çoğu temelde bunun üzerine kurulu, temel bileşeni kullanıyor muyuz? Kullanıcı ihtiyaçlarına uygun özel bir tane oluşturuyor muyuz? Yoksa ikisinin karışımını mı yapalım? Örneğin takvim söz konusu olduğunda, takvim ızgarasını kullanıyoruz, bu nedenle temel bileşeni kullanıyoruz ve ardından bunun üzerine özelleştirme ile geliştirdik. Bu yüzden onun için çok fazla React geliştirmesi oldu.

Stephanie: Ve evet, yani genellikle çok fazla taviz verirsin.

Drew: Yani bir kullanıcı arayüzü çerçevesi kullanmak size belli bir miktar yol kat edebilir gibi görünüyor, ancak bunun sonucunda gerçekten iyi bir kullanıcı arayüzüne sahip olmak için, birazcık özelleştirme yapmanız gerekiyor mu?

Stephanie: Genellikle. Evet.

Drew: Bu özelleştirme, tema oluşturmanın ötesine geçiyor mu?

Stephanie: Evet, geliştiricim tema oluşturmanın ötesine geçmemesini diledi. Eugene beni dinlersen. Her şeyde sadece birkaç renk değiştirirsek çok mutlu olacağını düşünüyorum. Ama evet, bir noktada özelleştirmenin ötesine geçmeniz gerekiyor çünkü ilk olarak, UI çerçeveleri gibi Lego araçları bir tür araç kutusu gibidir. Yani kutuda birçok farklı bileşen var, ancak bu bir sayfa oluşturmaz. Hala bir üst bilgiye ihtiyacınız var, yine bir alt bilgiye ihtiyacınız var. Hala çerçevede olmayan ekstra içeriğe ihtiyacınız var. Böylece bazen bir bileşeni ihtiyacınız olana göre ayarlayabilirsiniz. Anladığım kadarıyla, kalıcı bir pencere oluşturmak için kart bileşenini kullanıyoruz, ancak kalıcı pencerelerle ilgili olan şey, gerçekten bir kart gibi davranmamasıdır.

Stephanie: Bunun biraz ötesine gidiyorsun. Karartma içeren bir arka plana ihtiyacınız var. Kartınız genellikle arayüzde zaten oradayken, tıklamayla tetiklemeniz gerekir. Bu yüzden bu kart bileşenini kullanıyoruz çünkü arka plan, üstbilgi ve başlık gibi ihtiyacımız olan birçok şeye sahip, altta bazı düğmeler. Yani bir yapıya sahibiz ve sonra onu biraz değiştiriyoruz. Ancak bazen anlambilim, HTML konusunda da bazı çatışmalarla karşılaşıyoruz. Çünkü örneğin, buton şekilleri olmayan butonlara sahip olmak istedim, bu yüzden tıpkı link butonu gibi ve geliştirici “Tamam, bu yüzden href bağlantınız gibi bir bağlantı kullanıyoruz” dedi. "Hayır, bu bir bağlantı değil" dedim. Bu bir düğme. Tıklayınca yeni bir sayfa açmıyor. Forma giren her şeyi temizler.”

Stephanie: Yani teknik olarak anlamsal bir bakış açısıyla olmalı, bir düğme olmalı. "Evet. Ama çerçevede yok.” "Peki tamam, biliyorum o halde ne yapacağız?" diyorum. Bu yüzden genellikle bu küçük şeyleri tartışmaya başlarsınız ve geliştiricilerimi erişilebilirlikle gerçekten rahatsız ettiğim için, bu, birlikte iyi çalışacakları temel bileşenlere sahip olduğumuzdan emin olmaya çalışmanın başka bir ekstra katmanıdır. Ama aynı zamanda anlamsal olarak gifler içinde gifler içeren düğmelere sahip olmak istemiyorum gibiler. Aksi takdirde, sonunda sorunlarımız olacak.

Drew: Sanırım bir UI çerçevesi kullanacak yeni bir projeye başlarken, muhtemelen bir çeşit kullanıcı araştırması ile başlamanız gerekiyor.

Stephanie: Evet.

Duru: Bu adil mi?

Stephanie: Yapmalısın . Gerek. Yani evet, genellikle istediğiniz tüm bileşenlere sahip olabilirsiniz. Yine de kullanıcılarınızın sayfalarda neye ihtiyacı olduğunu, nasıl gezineceklerini bilmeniz gerekiyor? Bir akış oluşturmanız gerekir. Bu nedenle, genellikle bir çerçeveye karar vermeden önce bile, yaptığımız şey kullanıcılarımıza gitmek, onlarla konuşmak, ihtiyaçlarını anlamaya çalışmaktır. Bu yüzden şu anda oldukça şanslıyım çünkü kullanıcılar dahili olarak bankanın içinde. Bu yüzden onlarla çok sayıda atölye çalışması yapıyoruz ve bunun süper karmaşık bir arayüz olduğunu hayal etmeniz gerekiyor. Bilmiyorum, sanırım 10, hatta 15 yıl önce yapılmış bir şeyden Material-UI React kullanılarak tamamen yeni ve parlak bir şeye geçiyoruz. Bu oldukça büyük bir değişiklik ve bu 15 yıl boyunca, bir şey isteyen herkesin desteğe gidebileceğini ve ardından BT ekibinden bunu uygulamasını isteyeceklerini anlamalısınız. Yani şu anda arayüzüm tablolarla, tablolarla, tablolarla, diğer tablolarla ve tablolarda bile olmaması gereken şeylerle 400 sayfa gibi.

Stephanie: Tıpkı anahtar değer, anahtar değer, anahtar değer gibi birçok şeye sahip olduğumuz gibi. Böylece tabloyu iki sütunlu oluştururlar. “Hayır, belki bununla daha iyi bir şeyler yapabiliriz” gibiyim. Yani şu anda yaptığımız şey, kullanıcıların farklı hedeflerini anlamak için bazı kullanıcı araştırması yapmak. Arayüzle yaptıklarının bazı planlama hedefleri olduğunu belirledik. İşlerini planlamaları gerekiyor. Bu operasyonun bu toplantıya gideceğini bilmek istiyorum, bu yüzden o programda buna ihtiyacım var, bunun gibi şeyler. Bir şeyi izlemek istiyorlar, verileri rapor etmek istiyorlar. Dolayısıyla izleme, verilere bakmak ve her şeyin yolunda olduğundan emin olmak gibidir. Raporlama, verilerden yararlanabilmek, onunla paylaşmak istedikleri bir şey yapabilmek ve iş arkadaşlarıyla bir tür işbirliği yapabilmek ve tüm bunları doğrudan kullanıcılarla tartışarak keşfettiğimiz şeylerdir.

Stephanie: Ve keşfettiğimiz şey, aslında sonunda taşımayı planladığımız bazı şeylerin kullanıcı için günlük olarak en önemli şeylerden bazıları olduğuydu. Bu nedenle, planifikasyon kullanıcı hedefi şu anda en büyük türlerden biridir. Yani gerçekten, gerçekten bunun üzerinde çalışıyoruz. Yani evet, görüşmeyi kullanıyoruz ve şu anda süper yüksek seviyede olduğumuz, tamam, kabuğu inşa etmemiz gerekiyor, navigasyonu anlamamız gerektiğini söyleyen aşamadayız. Ancak şu anda tüm verilerin üzerinden gerçekten geçmedik ve şimdi yapacağımız şey bu. Ve bu ilginç çünkü çok fazla masamız var ve ya akıllı olmayan bir yoldan gidebiliriz ve tabloları yeni arayüze koyarız ve işimiz biter, ya da diyebiliriz ki, tamam, ne olduğunu anlamaya çalışalım. bu tablolar, kullanıcılarımız bu tabloyu ne için kullanıyor?

Stephanie: Ve sonra belki bazı tablolar veri görselleştirme olarak gösterilebilir ve sonra bunu yapmak için tüm işi anlamanız gerekir, böylece veriler anlamlı olur. Yani güzel bir çerçeveniz varsa ve tamam bu çizelgeyi kullanalım diyorsanız… Sanırım buna çizelge JS çerçevesi deniyor. Bir çok şeye sahipsiniz, histograma, pasta grafiklere, grafiklere ve her şeye sahip olabilirsiniz, ancak bir noktada hala karar vermenize yardımcı olacak bir tasarımcıya ihtiyacınız var. Tamam, bu veri, bir grafikte göstersek mantıklı mı yoksa bütünün bir kısmını göstermek istediğimiz için pasta olarak göstermek daha mantıklı mı yoksa son 10'daki bir ülkenin evrimini karşılaştırmak istiyoruz. yıllar sonra bir histogram daha ilginçtir. Yani kullanıcının verilerle ne yapmak istediğine bağlı olarak, onları tamamen farklı bir şekilde göstereceksiniz.

Stephanie: Ve bunu yapmak genellikle bir geliştirici işi değildir. Geliştiricimiz, onlar süper zeki adamlar. Üzgünüm, ama dürüstçe erkek geliştiricilerle çalışıyorum, keşke birkaç hanımım olsaydı, ama hayır. Hiçbiri kadın değil. Çok zeki adamlar ama onlar, tamam, bu veriler şöyle, şöyle, böyle gösterilmeli, diyecek kadar nitelikli değiller. Sonuç olarak, yine de bazı tasarımcıların kullanıcılarla konuşmasına, verilerle neler yapabileceğinizi anlamalarına ihtiyacınız var ve bu, tamam, bu bir sekme çubuğu olmalı veya bu soldaki bir gezinme olmalı demenin çok ötesine geçiyor.

Drew: Ve kullanıcılarla konuşarak bu tür kararları verdikten sonra. Örneğin, grafik seçiminizin türünü anlayıp anlamadıklarını görmek için onları tekrar test etmek için ortaya çıkan prototipleri veya tasarımları genellikle kullanıcılara geri götürür müsünüz?

Stephanie: Evet, aslında bunu çok yaptık, bu gerçekten güzel çünkü o zaman yararlı ve kullanılabilir olacağını bilene kadar bir şey geliştirmiyorsun. Yani bağlıdır. Bileşenlerin çoğuna zaten sahip oldukları için bir şeyi gerçekten geliştirmek daha hızlıysa, genellikle yaptığım şey, gerçekten hızlı kağıt prototipleme yapmaktır ve sonra bir şeyi geliştiririz çünkü veriler olmadan bile hızlıdır. Karmaşık bir şeyse, gerçekten çok yeni ve geliştirilmesi çok zaman alacaksa, o zaman tamam diyoruz, birkaç ekran tasarlıyoruz ve doğrudan ekranda bazı testler yapıyoruz. InVision adında bir aracımız var, temelde tüm tasarımınızı yerleştiriyorsunuz, farklı parçalar arasında bağlantılar oluşturabiliyorsunuz. Mesele şu ki, neyi test etmek istediğinize de bağlı. Örneğin telefonları test etmek istiyorsanız, InVision'dakileri test etmek bir kabus çünkü insanlar onları gerçekten hissedemiyorlar ve özellikle cep telefonunda.

Stephanie: Yani her zaman akıllı olmak bir bakımadır. En hızlı ve en ucuz yol nedir? Yalnızca tasarımları test etmek daha hızlı ve daha ucuz mu? Bu yeterli mi? Genellikle formlar için, gerçekten kullanıcının bir formu doldurmasını sağlayan ön uca koyduğunuz tüm ağır kaldırma işlemlerini otomatik olarak tamamladığınız için değil, belki de gerçekten bir form oluşturmak ve test etmek daha verimli olabilir. Ama yeni şeyler için evet, birçok tasarım yapıyoruz. Kullanıcıların yanına gidiyoruz. Yani şu anda ya bire bir yapıyoruz ama kullanıcılarım gerçekten meşgul insanlar. Bir Avrupa yatırım bankası olduğu için fazla zamanları yok. Genelde yaptığımız şey, eğer kullanıcılarla bire bir görüşürsek, daha çok odak grupları gibi küçük toplantılar yaparız. Ayrıca ilginç çünkü bazen bir tür yüzleşme yaşarsınız. Bazı insanlar, “Evet, bence bu benim için işe yarıyor çünkü ben şöyle ve böyle çalışıyorum” diyor ve sonra, “Oh, sen böyle mi çalışıyorsun? Aslında hayır, ben böyle yapıyorum.”

Stephanie: Yani odada birkaç kişinin olması ve sadece konuşmayı dinleyip not almak ve "Ah, belki o zaman bunu yapabiliriz" ve "Bu bileşen, az önce yaptığım şeye dayanarak daha iyi olurdu" demek de ilginç. Duymak." Ve bunun gibi şeyler.

Drew: Ürününüz için daha genel bir hedef kitleyle çalışıyorsanız. Belki de sizin gibi dahili kullanıcılar değil, daha çok genel halk, tasarımcıların bu araştırmayı kullanmalarının ucuz yolları var mı? Kullanıcılarınızın kim olacağını doğrudan bilmiyorsanız daha kolay yollar var mı?

Stephanie: Kim olacaklarını bilmelisin, yoksa ürünü üretmeden önce pazarlamacıların işini görür. Ama evet, örneğin bazı gerilla kullanıcı testleri yaptık, örneğin yine de InVision'ı kullanabilirsiniz. Böylece InVision'da bazı prototipler oluşturabilir ve ardından kullanıcıları örneğin sosyal medya aracılığıyla işe alabilirsiniz. Yardımcı olan bir ürün için çalışıyordum, adı nedir, bir şeyleri tamir eden araba bayileri tamircileri ve daha sonra müşteriyi ekstra onarımlar hakkında bilgilendirmek, bunun gibi şeyler. Bu yüzden LinkedIn ve Facebook'ta zaten büyüyen bir topluluğumuz vardı. Yani yapabileceğiniz şey, bu insanları işe almaktır. Çevrimiçi bir araç gibi bir araçta sohbet ediyormuşuz gibi uzaktan test yapabilirsiniz. Biraz ekran paylaşımı yapabilirsiniz. Biz de bunu bir proje için yaptık.

Stephanie: Size sadece bir tavsiyede bulunacağım, aracı daha önce test edin, çünkü kullanıyordum, adı Görünüyor.in. Ama sanırım adı Whereby ya da başka bir şey olarak değiştirdiler, ama gerçekten tarayıcıda dedim ki, tamam, güzel çünkü o zaman kullanıcıların herhangi bir şey yüklemelerine gerek yok, ancak kullanıcılar gerçek bir bilgisayarda değillerdi. VM'ye, Citrix'e girdiler ve mikrofonları yoktu, bu yüzden yaptığımız şey, ekranı paylaşmak için benim aracımı kullanmaları gibi oldu. Prototipi tıklıyorlardı ve aynı zamanda, onlarla doğrudan konuşmam için sabit hatlı bir telefon gibi telefonda tuttum. Yani her zaman vardı, bu oldukça ucuzdu çünkü harika bir işe alım günüydü, sanırım 10 kullanıcımız falan vardı. Evet, yüz yüze gidemeseniz bile birçok şey yapabilirsiniz, doğrudan Skype veya bunun gibi birçok kullanılabilirlik testi yaptım. Yani bunu yapmanın her zaman bazı ucuz yolları vardır.

Drew: Çalışmak için bir UI çerçevesi seçmeye gelince, gideceğiniz yol buysa, bu sadece geliştiricilere bırakacağınız bir şey mi yoksa tasarımcıların da dahil olması gereken bir şey mi?

Stephanie: Benim için tüm ekibi dahil etmelisin. Tasarımcılar, geliştiriciler, belki biraz varsa mimarlar gibi, çünkü çerçevenin nasıl inşa edildiği de bu tür şeyleri etkileyebilir. Ne yazık ki, çoğu zaman projeye geldiklerinde çerçeveye zaten karar verilmişti. Hayır, aslında komik, ya çoktan karar verildi ya da benden çerçeve seçimlerini doğrulamamı istediler, ama ben herhangi bir inceleme ya da araştırma yapmadım. Projede ne olduğu hakkında hiçbir fikrim yok çünkü bana ekranlarını bile göstermediler. Onlar, “Evet, işini yap. Bu çerçeveyi kullanabiliriz.” Bilmiyorum. Peki, ekranımız var mı? Böylece, bulutta taşımak istedikleri bir Windows yerel uygulaması olan size birkaç ekran gösterdiler. “Evet, sadece düğmelere ihtiyacımız var ve çoğunlukla formları ve bunun gibi şeyleri seviyoruz” dediler.

Stephanie: Ama "Evet, bu çerçeveyi kullanın, ihtiyacımız olan tüm bileşenlere sahibiz" demek gerçekten zor. Veya "İçeriğinizin ne olacağı, navigasyonun ne olduğu hakkında kabaca bir fikriniz yoksa gitmeyin" gibi. Bu nedenle, tüm bileşenlere sahip olduğunuzdan %100 emin değilseniz, çerçevelerinizi seçmeden önce yine de küresel bir genel bakışa sahip olmanız gerektiğini düşünüyorum. Ancak çoğu zaman çerçeve seçiminin temel olarak geliştiricinin şu anda hangi teknolojileri sevdiğine bağlı olduğunu hissediyorum, bundan önce bir çerçeve ile deneyimleri var mı? Bazı projelerde Ant'ı kullandık çünkü birkaç geliştirici bununla ilgili deneyime sahipti ve gerçekten beğendiler ve Ant'ı kullanma konusunda biraz verimli oldular. Ve Material React UI için aynı. Bu, geliştiricinin onu önceki projelerde zaten kullanmış olması gibi bir şey, bu yüzden onunla verimli oluyorlar.

Drew: Yani geliştiricilerin ne konusunda rahat oldukları, bildikleri, teknoloji yığınlarında neyin işe yarayacağı ve daha sonra iyi bir kullanıcı arayüzü oluşturmak açısından ürünün gereksinimleri arasında bir denge olması gerekiyor. Ve bunun için ideal çerçeveyi bulmak için bir şekilde ikisini dengelemeniz gerekir.

Stephanie: Evet. Bazı projeler için bir tür özel şartım var, ki bu… Lüksemburg'dayım, birçok Avrupa kurumumuz ve bunun gibi şeyler var, bu yüzden bunlardan bazıları için ekstra erişilebilirlik şartımız var. Ve genellikle çerçeveye karar verildiğinde, çerçevelerinin erişilebilirliğini gerçekten kontrol etmediler ve projenin başlangıcından birkaç ay sonra geri döndüler, “Ah, bize bu yeni yasanın olduğunu söyledik ve biz de yapmalıyız. erişilebilir olacak ama bunu nasıl yapacağımızı bilmiyoruz.” Evet gibi, biraz geç oldu. Bu yüzden benim için, bir çerçeve seçmek için projenin başlangıcındaki tüm kısıtlamaları gerçekten bilmeniz gerekir ve erişilebilirlik bunlardan biriyse bileşenlerinizi test etmeniz ve erişilebilir olacaklarından emin olmanız gerekir. Ancak ben bir React veya Angular geliştiricisi değilim, ancak erişilebilir olmayan bir UI çerçevesini erişilebilir bir şeye dönüştürmenin çok karmaşık olduğundan eminim. Sanırım tüm bileşenleri yeniden oluşturmak biraz karmaşık olabilir, bu yüzden böyle şeyler.

Drew: Kendinizi bu sürecin gerçekleşmediği ve bir UI çerçevesinin önceden seçildiği bir proje üzerinde çalışırken bulursanız, kullanıcı arayüzünün bu çerçevede halihazırda var olan bileşenlerden etkilenmeye başlaması tehlikesi var mı? kullanıcının ihtiyaçları tarafından yönlendiriliyor mu?

Stephanie: Gerçekten, dürüst olmak gerekirse, üzerinde çalıştığım projelerin çoğu, gerçekten zorlamaya çalışsanız bile, sonunda bir sürü takasla sonuçlanıyorsunuz. Bu yüzden çoğunlukla denge ve geliştiricilerle tartışma ile ilgili. Bu yüzden genellikle yaptığım şey, bazı tel çerçeveler yaparız, hatta hızlı kağıt tel çerçeveler bile, tamam diyoruz, bu sayfada buna ve şuna ve şu bileşene ihtiyacımız olacak, yaptığım ilk şey geliştiriciye şunu sormak, bizim dosyamızda var mı? Şu anda çerçeve? Nasıl görünüyor? Ve sonra birlikte karar veriyoruz, tamam, bu işi yapacak bir bileşen ya da tamam bu işi yapmayacak. ince ayar yapıyor muyuz? Mesela, bileşeni hala koruyor muyuz, ancak işi yapması için biraz değiştiriyor muyuz, yoksa sıfırdan bir şey mi inşa ediyoruz?

Stephanie: Ve günün sonunda elbette bütçeye bağlı olacak. Böylece takasları bitirdiniz. Sanki mükemmel değillerse ve birkaç sorun varsa, neredeyse hiç kullanılmayan küçük bileşenler için iyi olurdum. Ancak ana navigasyon, ana yapı, ekranda sürekli gördüğünüz şeyler için örneğin bunun gerçekten çalışması gerekiyor. Kullanıcının nasıl verimli çalıştıklarını anlaması gerekiyor ve evet, sizin de söylediğiniz gibi, herhangi bir çerçeveniz olmasaydı sahip olmak isteyeceğiniz ideal deneyim ile elinizdekiler, bütçe ve ayrıca bütçe arasında bir denge bulmaktır. zamanlama. Bu sprintler için tamam dersek özelliğin bu sprint sonunda bitmesi gerekiyor ve sonra tamam diyorlar ama siz bu sprint sonunda o özelliği asla bitirmeyeceğiz. tartışmaya başlayın, tamam, bir sonraki ekranda bu özelliği bitiriyor muyuz, düzgün yapmak için daha fazla zaman alıyor muyuz? Ve genellikle gerçekten bağlıdır.

Stephanie: Beni en çok hayal kırıklığına uğratan şeyler, bir kırpma düzeltme bileşeni kullandığımızı bildiğim ve bana "Oh hayır, endişelenme" dedikleri zaman. Bunu daha sonra düzelteceğiz. Ve daha sonra ne yazık ki asla gerçekleşmeyeceğini biliyordum. Yani takıma bağlı. Ama bir süre sonra deneyime sahipsin ve biliyorsun, bu daha sonra gelecek mi, gelmeyecek mi? Evet, uzlaşmalarla ilgili. Bu tür araçlarla çalışırken.

Drew: Kendim de bir geliştirici olarak, UI çerçeveleriyle ilgili sevdiğim şeylerden biri, genellikle varsayılan stille gelmeleridir. Bu, belki de tüm bileşenlerin görünümü ve hissi konusunda bana yardımcı olacak bir tasarımcıya ihtiyacım olmadığı anlamına geliyor. Bu, projelerde güvenmemiz gereken bir şey mi? Sadece varsayılan stil ve çerçeveyi üreten kişinin bu bileşenleri tasarlamada gerçekten iyi bir iş çıkardığına güvenmek mi? Yoksa bu bileşenleri kendiniz mi şekillendirirsiniz?

Stephanie: Bence gerçekten bağlı. Örneğin, Material-UI ile ilgili sorun, bir web uygulamanızın görünümü ve verdiği hissiyatın temelde yapılandırılmış Google ürünleri olacağıdır. Yani yazı tipini gerçekten değiştirmezseniz, birkaç renk değiştirirseniz ve kendi marka kimliğinizi getirirseniz ve bunu yaparsanız, herhangi bir Google ürününe benzeyen bir ürününüz olur, bu iyi bir şey olabilir çünkü eğer kullanıcılarınız Google ürünlerine alışkınsa bu, anlamalarına yardımcı olabilir. Yani genellikle takımda bir tasarımcınız yoksa, başka seçeneğiniz var mı? Gördüğüm birçok farklı çalışma gibi, en azından renkleri değiştirebilmeniz için özel temalarla geliyorlar. Yazı tiplerini de oldukça kolay bir şekilde değiştirebileceğinizi düşünüyorum. Ama yine, renkleri değiştirirseniz ve tasarımda ve hatta erişilebilirlikte süper iyi değilseniz, kullanacağınız renkler çakışabilir, kontrast sorunları olabilir.

Stephanie: Örneğin, turuncuyu severim ama üzerinde çalışılması en sinir bozucu renklerden biri çünkü örneğin beyaz metinli bir düğme gibi gerçekten erişilebilir bir turuncuya sahip olmak neredeyse kahverengimsi görünüyor. Ve bu gerçekten parlak turuncuya sahip olmak istiyorsanız, okunabilir hale getirmek için üzerine koyu renkli bir metin gerekir, ancak bu, arayüzünüzün günün sonunda Cadılar Bayramı gibi görünmesini sağlar. Evet, güldüğünü görüyorum. Ama gerçek bu. Bu yüzden her zaman bu tür tavizler hakkındadır ve eğer bir geliştiriciyseniz ve çerçeveyi olduğu gibi kullanmak istiyorsanız ve bir tasarımcınız yoksa, bence yine de hiçbir şeye sahip olmamak ve onu sıfırdan inşa etmekten daha iyidir. o zaman kullanımı süper karmaşık. Ama mesele şu ki, bileşenlere sahip olmanız harika bir arayüz oluşturacağınız anlamına gelmez. Lego tuğlaları gibi. Lego tuğlalarınız varsa, sorun değil, ama gerçekten güzel bir uzay gemisi yapabilirsiniz ya da gerçekten bir planınız olmadığı için bir arada durmayan ve dağılacak bir şey yapabilirsiniz.

Stephanie: Yani tasarım bundan biraz daha fazlası. Tasarım, ekranda ne olacağını, nasıl çalışacağını gerçekten anlamakla ilgilidir. Ve bunu yapabilecek kapasiteye sahip bazı geliştiriciler tanıyorum. Bu nedenle, kullanılabilirlik yönergelerinde gerçekten iyidirler ve örneğin birçok tasarım kuralını anlarlar. Dolayısıyla, konu bileşenleri seçmeye geldiğinde, bu konuda gerçekten çok iyiler. Ve hangi bileşenleri seçeceği hakkında hiçbir fikri olmayan ve işi yapan ilkini seçen geliştiriciler tanıyorum. Ama bir süre sonra artık çalışmıyor. Örneğin sekmeler gibi, bazı geliştiricilerin sekmeleri seçtiği bir arayüzümüz vardı. Sadece üç öğeniz olduğunda başlangıçta mantıklı olduğunu düşünüyorum. Ama sonra ekranda 12 öğe vardı ve sonra üç satır sekme olan sekmeleriniz var ve bunların hepsi aynı seviye bir sekmeler ve sekmeler içinde sekmeler var. Bileşene sahiplerdi, çerçeveyi kullandıkları için güzel görünüyordu, ama gerçekten kullanışlı değildi.

Stephanie: Aynısını örneğin kalıcı pencerelerde de yaşadım. Projeleri tasarımcı olmadan inşa ettikleri ve bir süre sonra müşterinin bu modele giderek daha fazla şey istediğini düşünüyorum. Böylece bir tablo ile bir ekranla sonuçlandılar ve bir satır ekle'yi tıkladığınızda, bir modal açıyorsunuz ve bu modalde iki sekmeniz var ve sonra bu sekmelerden birinde başka bir tablonuz bile var ve sonra onlar istediler. Buna fazladan bir şey ekle, tamam, belki bir kipin üstüne bir kip koyabiliriz dedim. Ve bir noktada tasarımcı cevap verecekti, tamam, modalde bu kadar çok içeriğiniz varsa, modal bir pencere olmamalıdır. Bir sayfa olmalıdır. Bu nedenle, bileşene sahip olsanız bile, planı yapmak ve tüm bu bileşenlerin birlikte iyi çalıştığından emin olmak için yine de bir tür mimara ihtiyacınız var.

Drew: Yani bir tasarımcı olarak sizden bazı bileşenlerin stilini değiştirmeniz isteniyorsa, tüm stili değiştirmeyi dener misiniz? Hepsini özelleştirebilir misiniz yoksa odaklanacağınız belirli alanlar var mı?

Stephanie: Renkler Bence ilk gördüğünüz şey, renkler size kimlik kazandırabilir. Güçlü bir marka kimliğiniz varsa, en azından ürününüzün renklerinin düğmelerde veya simgelerde ve bunun gibi şeylerde olması zaten çerçeveyi özelleştirmenize yardımcı olur. Yazı tipleri, bence kolay, çünkü çerçeve iyi oluşturulmuşsa, genellikle bir yerde tüm yazı tipi ailesini değiştirirsiniz ve sonra sitenin geri kalanında bir çeşit kademeli olmalıdır. Yani renkler ve yazı tipleri, çerçeveyi hızlı bir şekilde özelleştirmenin iki kolay yolu olduğunu düşünüyorum. Simgeler, kişilik kazandırmanın başka bir güzel yoludur, ancak bu zor olabilir çünkü gördüğüm kadarıyla, çerçevenin çoğu özel simgelerle veya Harika Yazı Tipiyle veya zaten yerleşik bir kitaplık gibi gelir. Bunları değiştirmek için önce bir hepsini değiştirmek istiyorsanız çok sayıda simge. O yüzden biraz karmaşık olabilir. Ayrıca kullanmak istediğiniz simge paketini seçmenize izin veren çerçeveler de gördüm. Font Awesome, Glyphicons ve diğerleri gibi. Yani bu, kolayca özelleştirebileceğiniz türden şeyler.

Stephanie: Ve sonra görünüş ve his ile ilgili, örneğin üst bilgi, genellikle farklı türde üstbilgiler, altbilgiler var. Böyle şeylerde nasıl geziniyorsun. Bu nedenle, Malzeme-UI-ish görünmemesi için getirebileceğiniz çok sayıda küçük özelleştirme var, daha çok markanıza benziyor ve ardından örneğin kenar yarıçaplarıyla oynayabilirsiniz. İster tamamen yuvarlak butonlar, ister kare butonlar veya ortada gölgeler gibi bir şey istiyorsanız. Bu yüzden, bu çerçevelerin çoğunda CSS değişkenlerinde bulunduğundan, özelleştirmesi genellikle kolay olan bazı küçük şeyler. Bu dalgalanma efektleri dışında bence çok fazla çaba harcamadan özelleştirebileceğiniz türden küçük şeyler. Bundan nefret ediyorum. Bununla savaşacağım. Umarım sonunda değiştirirler.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. Peki. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.