Smashing Podcast Episode 9 Dengan Stephanie Walter: Bagaimana Saya Bisa Bekerja Dengan Kerangka UI?

Sebagai pengembang sendiri, salah satu hal yang saya suka tentang kerangka kerja UI adalah mereka sering datang dengan gaya default, tetapi apakah itu sesuatu yang harus kita andalkan dalam proyek? Cukup menggunakan gaya default dan percaya bahwa siapa pun yang membuat kerangka kerja telah melakukan pekerjaan yang sangat baik dalam mendesain komponen tersebut? Bergabunglah dengan saya untuk episode podcast hari ini di mana saya berbicara dengan Desainer UX Stephanie Walter tentang hal-hal yang harus kami pertimbangkan saat membangun kerangka kerja UI.

Tampilkan Catatan

• Situs web Stephanie
• Stephanie di Twitter

Update mingguan

• “Cara Membuat Game Mencocokkan Kartu Menggunakan Angular Dan RxJS” oleh Anna Prenzel
• “Cara Membuat Situs WordPress Tanpa Kepala di JAMstack” oleh Sarah Drasner
• “Kartu Balik Ajaib: Memecahkan Masalah Ukuran Umum” oleh Dan Halliday
• “Sorotan Django: Model Pengguna Dan Otentikasi (Bagian 1)” oleh Philip Kiely
• “Cara Membuat Peta Dengan React Dan Leaflet” oleh Shajia Abidi

Salinan

Drew McLellan: Dia adalah desainer yang berpusat pada pengguna dan ahli dalam pengalaman seluler, yang melintasi produk dan antarmuka yang menyenangkan dengan fokus khusus pada kinerja. Dia mengerjakan proyek untuk klien seperti Universitas Luksemburg, Bank Investasi Eropa, BMW dan Microsoft untuk menyebutkan beberapa, dan dia membantu klien tersebut memberikan proyek yang sukses kepada audiens mereka mulai dari strategi hingga produk akhir. Dia adalah pakar Pengembang Google dalam desain produk dan guru yang bersemangat untuk membagikan pengetahuannya dalam berbagai postingan blog, artikel, lokakarya, dan presentasi konferensi. Jadi, kami tahu dia adalah perancang pengalaman pengguna yang ahli, tetapi tahukah Anda bahwa dia pernah memiliki pekerjaan yang sesuai dengan karpet dengan Sir Elton John? Teman-teman Smashing saya, tolong sambut Stephanie Walter. Halo Stefani, apa kabar?

Stephanie Walter: Hai, saya senang dan menyukai perkenalannya.

Drew: Jadi saya ingin berbicara dengan Anda hari ini tentang masalah tertentu dan itulah topik penggunaan kerangka kerja antarmuka pengguna yang tersedia. Sekarang Anda adalah seorang desainer pengalaman pengguna dan Anda bekerja dengan banyak klien yang berbeda dan tugas Anda adalah membantu klien tersebut menciptakan pengalaman pengguna terbaik melalui pembuatan antarmuka pengguna yang sangat berguna. Jadi gagasan untuk dapat melakukan itu dengan seperangkat alat yang tersedia tampaknya agak sulit bagi saya. Apakah penggunaan kerangka kerja UI sesuatu yang sering Anda lihat di sepanjang pekerjaan Anda?

Stephanie: Ya, itu adalah sesuatu yang sering saya lihat, terutama dalam beberapa tahun terakhir karena saya mulai bekerja dengan agensi dan sekarang saya bekerja di dalam perusahaan. Jadi dalam tim teknologi TI super besar itu dan ya, saat ini ada banyak UI kerangka kerja seperti yang paling sering saya lihat adalah Material-UI, pada dasarnya Desain material adalah semacam pedoman dan hal desain Google, dan Material -UI adalah tim dari Angular, tetapi juga tim dari React. Mereka membuat kerangka kerja mereka sendiri menggunakan jenis tampilan dan nuansa desain Material dari Google. Tapi itu tidak ada hubungannya dengan Google lagi. Sama seperti mereka, saya tidak tahu, saya pikir mereka menyukai tampilan dan nuansanya. Jadi saat ini, itu adalah dua kerangka kerja UI utama yang saya gunakan. Dan juga ada sesuatu yang disebut Ant Design, yang cukup populer.

Stephanie: Ini adalah kerangka kerja React. Saya tidak tahu apakah mereka juga memiliki Angular. Saya pikir itu dibuat oleh tim di Cina. Dan ini menarik karena tidak hanya menyediakan komponen, semua yang ada di React, tetapi jika Anda mengunjungi situs web mereka, Anda juga akan mendapatkan file awal, yang sebenarnya cukup menarik karena memotivasi atau membantu desainer membangun atau membentuk antarmuka ke dalam komponen UI yang digunakan oleh kerangka kerja itu. Jadi ya, itu adalah sesuatu yang sering saya lihat, terutama di tim IT besar karena sebagian besar waktu mereka tidak memiliki desainer. Saat ini saya pada dasarnya adalah tim UX dari satu tim kecil di bank investasi Eropa. Jadi ini saya sebagai desainer UX. Saya bekerja dengan tim pengembang, analis bisnis, semua orang baik, tetapi masih merupakan salah satu desainer untuk keseluruhan proyek.

Stephanie: Sampai saya tiba tidak ada desainer. Jadi itu semacam solusi yang diterapkan di banyak perusahaan, terutama pada produk internal misalnya. Di mana mereka biasanya berkata, oke, kami tidak benar-benar membutuhkan seorang desainer untuk itu. Kami hanya membutuhkan sesuatu yang berfungsi untuk pengguna internal kami dan mari kita gunakan kerangka kerja karena itu nyaman untuk pengembang. Sebagian besar komponen sudah ada di sana dan karena mereka tidak memiliki desainer dalam tim, maka itu seperti menggantikan peran desainer UI. Ya, masalahnya adalah, oke, lalu Anda memiliki komponen, tetapi peran perancang UI bukan hanya untuk memutuskan apakah tombolnya harus merah, hijau, oranye, biru, apa pun. Biasanya peran desainer UI adalah arsitektur informasi, memahami kebutuhan pengguna. Jadi segala sesuatu yang melampaui antarmuka. Jadi bahkan jika Anda memiliki kerangka kerja semacam ini yang menangani keseluruhan UI, Jadi secara visual apa yang Anda lihat di layar.

Stephanie: Anda masih membutuhkan seseorang di beberapa titik untuk melakukan pekerjaan memahami apa yang kita taruh di layar, bagaimana perilakunya? Apa yang terjadi ketika kita klik di sini? Bagaimana pengguna mencapai tujuan mereka? Bagaimana kita pergi dari titik A ke titik B? Karena kita bisa menggunakan model, kita bisa menggunakan tab, kita bisa menggunakan semua komponen. Jadi itu sebabnya selalu agak sedikit rumit dan rumit.

Drew: Apakah mungkin, menurut Anda dapat membuat antarmuka pengguna yang dapat digunakan menggunakan kerangka kerja UI yang sudah ada, atau apakah itu akan selalu menjadi sedikit kompromi?

Stephanie: Saya agak berharap begitu. Saya agak berharap demikian karena kalau tidak saya sedang membangun antarmuka yang tidak dapat digunakan. Jadi jawaban ini benar-benar bias, tapi ya, menurut saya, tapi itu juga tergantung pada tingkat kompromi yang ingin Anda lakukan dan ada kompromi di kedua sisi. Saat ini saya mengorbankan banyak tombol misalnya, karena Anda memiliki beberapa tombol yang sangat spesifik di Material-UI, dan saya tidak terlalu menyukai efek riak pada tombol. Saya pikir ini berfungsi dengan baik di seluler karena di seluler Anda memerlukan semacam umpan balik yang besar ketika pengguna mengklik atau menyentuh tombol. Tapi kemudian langkah-langkahnya adalah semacam efek riak yang berlangsung sepanjang tombol. Ini sedikit berlebihan, terutama ketika ada banyak tombol. Tapi tetap saja kita akan menyimpan efek riak ini karena akan sangat rumit untuk menghilangkannya karena ini sudah ada di dalam kerangka kerja React. Dan untuk memiliki efek melayang lain pada tombol ini, sesuatu yang lebih halus yang tidak akan menjadi hal yang menderu di sini. Ini akan menjadi sangat kompleks.

Stephanie: Jadi ini adalah jenis kompromi yang Anda lakukan. Tetapi sementara itu, saya tidak berkompromi pada hal-hal tertentu yang merupakan komponen khusus. Tempat saya bekerja sebelumnya, klien saat ini untuk perusahaan perjalanan dan penerbangan. Dan maskapai memiliki beberapa kebutuhan yang sangat, sangat spesifik. Kalender untuk maskapai penerbangan misalnya, Anda ingin memasukkan harga, Anda ingin memasukkan… jika Anda tidak melakukan perjalanan ke tujuan ini pada tanggal tertentu, Anda tidak tahu kapan harus meletakkannya, Anda memiliki keberangkatan dan kedatangan ini dan kalender dasar dari sebagian besar kerangka kerja UI itu tidak menyediakan hal-hal semacam ini. Jadi pada titik tertentu Anda bisa mengatakan, oke, kami hanya akan menggunakan kalender yang mereka miliki. Dan itu saja. Anda harus melampaui itu. Jadi sebagian besar kompromi pada dasarnya dibangun, apakah kita menggunakan komponen dasar? Apakah kami membuat yang khusus yang sesuai dengan kebutuhan pengguna? Atau apakah kita membuat campuran keduanya? Dalam kasus kalender, misalnya, kami menggunakan kisi kalender, jadi kami menggunakan komponen dasar dan kemudian kami menyempurnakannya dengan penyesuaian di atasnya. Jadi itu banyak pengembangan React untuk yang satu itu.

Stephanie: Dan ya, jadi biasanya Anda melakukan banyak kompromi.

Drew: Jadi kedengarannya seperti menggunakan kerangka kerja antarmuka pengguna dapat memberi Anda sejumlah cara, tetapi untuk benar-benar memiliki antarmuka pengguna yang baik sebagai hasilnya, Anda perlu melakukan sedikit penyesuaian di atas?

Stefani: Biasanya. Ya.

Drew: Apakah penyesuaian itu melampaui tema?

Stephanie: Ya, pengembang saya berharap itu tidak melampaui tema. Eugene Jika Anda mendengarkan saya. Saya pikir dia akan sangat senang jika kami hanya mengubah beberapa warna dalam segala hal. Tapi ya, pada titik tertentu Anda harus melampaui penyesuaian karena pertama, seperti kerangka kerja UI seperti alat Lego adalah semacam kotak alat. Jadi Anda memiliki banyak komponen berbeda di dalam kotak, tetapi ini tidak membangun halaman. Anda masih membutuhkan header, Anda masih membutuhkan footer. Anda masih membutuhkan konten tambahan yang tidak ada dalam kerangka. Jadi terkadang Anda dapat mengubah komponen menjadi apa yang Anda butuhkan. Dari apa yang saya pahami, kami menggunakan komponen kartu untuk membangun jendela modal, tetapi masalahnya dengan jendela modal adalah bahwa itu tidak benar-benar berperilaku seperti kartu.

Stephanie: Anda agak melampaui itu. Anda membutuhkan latar belakang dengan pengaburan. Anda perlu memicunya saat klik sementara biasanya kartu Anda sudah ada di antarmuka. Jadi kami menggunakan komponen kartu ini karena memiliki banyak hal yang kami butuhkan seperti latar belakang, header dan judul di bagian atas, beberapa tombol di bagian bawah. Jadi kami memiliki strukturnya dan kemudian kami mengubahnya sedikit. Tapi terkadang kita berakhir dengan beberapa konflik tentang semantik, HTML juga. Karena misalnya, saya ingin memiliki tombol yang tidak memiliki bentuk tombol, jadi seperti tombol tautan dan pengembang berkata, "Oke, jadi kami menggunakan tautan seperti tautan href Anda." Saya berkata, “Tidak, ini bukan tautan. Ini adalah tombol. Ketika mereka mengkliknya, itu tidak membuka halaman baru. Ini membersihkan semua yang ada di dalam formulir.”

Stephanie: Jadi itu harus secara teknis dari sudut pandang semantik, itu harus menjadi tombol. "Ya. Tapi itu tidak ada dalam kerangka kerja.” Saya berkata, "Baiklah, saya tahu, jadi apa yang harus kita lakukan?" Jadi biasanya Anda mulai mendiskusikan hal-hal kecil ini dan karena saya juga sangat mengganggu pengembang saya dengan aksesibilitas, ini adalah lapisan tambahan lain untuk mencoba memastikan bahwa kami memiliki komponen dasar yang berfungsi dengan baik. Tetapi juga bahwa mereka secara semantik seperti saya tidak ingin memiliki tombol dengan gif di dalam gif di dalam gif. Jika tidak, kita akan memiliki masalah pada akhirnya.

Drew: Saya kira memulai proyek baru yang akan menggunakan kerangka kerja UI, Anda mungkin perlu memulai dengan semacam riset pengguna.

Stefani: Ya.

Drew: Apakah itu adil?

Stephanie: Anda harus. Kamu butuh. Jadi ya, biasanya Anda dapat memiliki semua komponen yang Anda inginkan. Anda masih perlu tahu apa yang dibutuhkan pengguna Anda di halaman, bagaimana mereka akan bernavigasi? Anda perlu membangun aliran. Jadi biasanya bahkan sebelum memutuskan kerangka kerja, yang kami lakukan adalah mendatangi pengguna kami, kami berbicara dengan mereka, kami mencoba memahami kebutuhan mereka. Jadi saat ini saya cukup beruntung karena pengguna internal di dalam bank. Jadi kami melakukan banyak lokakarya dengan mereka dan Anda harus membayangkan antarmuka yang sangat kompleks. Kami bermigrasi dari sesuatu yang dibangun, saya tidak tahu, saya pikir 10 atau bahkan 15 tahun yang lalu ke sesuatu yang baru mengkilap menggunakan Material-UI React. Jadi ini adalah perubahan yang cukup besar dan Anda harus memahami bahwa selama 15 tahun itu, setiap orang yang menginginkan sesuatu dapat pergi ke dukungan dan kemudian mereka meminta tim TI untuk mengimplementasikannya. Jadi saat ini antarmuka saya seperti 400 halaman dengan tabel, di dalam tabel, di dalam tabel, dengan tabel lain, dan hal-hal yang seharusnya tidak ada di tabel.

Stephanie: Seperti kita memiliki banyak hal yang hanya nilai kunci, nilai kunci, nilai kunci. Jadi mereka membangun tabel dengan dua kolom. Saya seperti, "Tidak, mungkin kita bisa melakukan sesuatu yang lebih baik dengan itu." Jadi saat ini yang kami lakukan adalah melakukan riset pengguna untuk memahami berbagai tujuan pengguna. Jadi yang kami identifikasi adalah apa yang mereka lakukan dengan antarmuka, mereka memiliki beberapa tujuan perencanaan. Mereka perlu merencanakan pekerjaan mereka. Jadi saya ingin tahu bahwa operasi ini akan pergi ke pertemuan ini, jadi saya perlu itu pada jadwal itu, hal-hal seperti itu. Mereka ingin memantau sesuatu, mereka ingin melaporkan datanya. Jadi pemantauan seperti melihat data dan memastikan semuanya baik-baik saja. Pelaporan adalah kemampuan untuk mengeksploitasi data, untuk melakukan sesuatu dengannya yang ingin mereka bagikan dan untuk berkolaborasi dengan rekan kerja dan semua yang kami temukan dengan berdiskusi langsung dengan pengguna.

Stephanie: Dan apa yang kami temukan adalah bahwa sebenarnya beberapa hal yang kami rencanakan untuk migrasi pada akhirnya adalah beberapa hal terpenting setiap hari bagi pengguna. Jadi tujuan pengguna perencanaan adalah salah satu yang terbesar saat ini. Jadi kami benar-benar bekerja untuk itu. Jadi ya kami menggunakan wawancara dan sekarang kami berada dalam fase di mana saat ini kami berada di level super tinggi dengan mengatakan oke kami perlu membangun shell, kami perlu memahami navigasi. Tetapi saat ini kami tidak benar-benar memeriksa semua data dan sekarang inilah yang akan kami lakukan. Dan ini menarik karena kami memiliki banyak tabel dan kami mengatakan bahwa kami dapat memilih cara yang tidak cerdas dan hanya meletakkan tabel di antarmuka baru dan selesai, atau kami dapat mengatakan, oke, mari kita coba memahami apa tabel tersebut adalah, Untuk apa pengguna kami menggunakan tabel ini?

Stephanie: Dan kemudian mungkin beberapa tabel dapat ditampilkan sebagai visualisasi data dan kemudian untuk melakukan itu Anda perlu memahami keseluruhan bisnis agar datanya masuk akal. Jadi jika Anda memiliki kerangka kerja yang bagus dan Anda berkata, oke, mari gunakan bagan ini… Saya pikir ini disebut kerangka kerja bagan JS. Anda memiliki banyak hal, Anda dapat memiliki histogram, diagram lingkaran dan grafik dan semuanya, tetapi pada titik tertentu Anda masih memerlukan seorang desainer untuk membantu Anda memutuskan. Oke, data ini, apakah masuk akal jika kita menunjukkannya ke dalam grafik atau lebih masuk akal untuk menunjukkannya sebagai kue karena kita ingin menunjukkan sebagian dari keseluruhan, atau kita ingin membandingkan evolusi untuk satu negara dalam 10 terakhir tahun, maka histogram lebih menarik. Jadi berdasarkan apa yang ingin dilakukan pengguna dengan data, Anda akan menampilkannya dengan cara lain.

Stephanie: Dan biasanya bukan tugas pengembang untuk melakukan itu. Pengembang kami, mereka orang yang sangat pintar. Maaf, tapi jujur ​​saya bekerja dengan pengembang pria, saya berharap saya punya beberapa wanita, tapi tidak. Tak satu pun dari mereka adalah wanita. Jadi orang super pintar tapi mereka tidak super mumpuni untuk mengatakan, oke, data ini harus ditampilkan seperti itu, itu, itu dan itu. Jadi pada akhirnya Anda masih memerlukan beberapa desainer untuk berbicara dengan pengguna, memahami apa yang dapat Anda lakukan dengan data dan ini lebih dari sekadar mengatakan, oke, ini harus berupa bilah tab atau ini seharusnya navigasi di sebelah kiri.

Drew: Dan setelah membuat keputusan semacam itu berdasarkan berbicara dengan pengguna. Apakah Anda biasanya membawa prototipe atau desain yang dihasilkan kembali ke pengguna untuk mengujinya lagi untuk melihat apakah mereka memahami jenis pilihan bagan Anda misalnya?

Stephanie: Ya, sebenarnya kami sering melakukannya, yang sangat bagus karena Anda tidak mengembangkan sesuatu sampai Anda tahu itu akan berguna dan berguna. Jadi itu tergantung. Jika lebih cepat untuk benar-benar mengembangkannya karena mereka sudah memiliki sebagian besar komponen, yang biasanya saya lakukan adalah membuat prototipe kertas dengan sangat cepat dan kemudian kami mengembangkannya karena cepat, bahkan tanpa data. Jika itu sesuatu yang kompleks, sesuatu yang benar-benar baru yang akan membutuhkan banyak waktu untuk dikembangkan, maka kami katakan, oke, kami merancang beberapa layar dan kami melakukan beberapa pengujian langsung di layar. Jadi kami memiliki alat yang disebut InVision, di mana pada dasarnya Anda meletakkan semua desain Anda, Anda dapat membuat tautan di antara bagian-bagian yang berbeda. Masalahnya juga tergantung apa yang ingin Anda uji. Jika Anda ingin menguji ponsel misalnya, adalah mimpi buruk untuk mengujinya di InVision karena orang-orang tidak dapat benar-benar merasakannya dan terutama di ponsel misalnya.

Stephanie: Jadi selalu pintar. Apa cara tercepat dan termurah? Apakah lebih cepat dan lebih murah untuk menguji desain saja. Apa ini cukup? Untuk formulir biasanya, tidak juga karena Anda memiliki auto menyelesaikan semua pekerjaan berat yang Anda letakkan di ujung depan yang telah benar-benar pengguna mengisi formulir jadi untuk formulir, mungkin lebih efisien untuk benar-benar membuat formulir dan mengujinya. Tapi untuk hal-hal baru, ya, kami membuat banyak desain. Kami pergi ke pengguna. Jadi saat ini kami melakukan satu lawan satu, tetapi pengguna saya adalah orang-orang yang sangat sibuk. Ini adalah bank investasi Eropa sehingga mereka tidak punya banyak waktu. Jadi yang biasanya kami lakukan adalah jika kami bertemu satu lawan satu dengan pengguna, kami melakukan beberapa pertemuan kecil, seperti grup fokus. Dan itu juga menarik karena terkadang Anda memiliki semacam konfrontasi. Beberapa orang berkata, "Ya, saya pikir itu berhasil untuk saya karena saya bekerja seperti itu dan itu," dan kemudian akan ada orang lain yang seperti, "Oh, Anda bekerja seperti itu? Sebenarnya tidak, saya melakukannya seperti itu dan itu. ”

Stephanie: Jadi menarik juga untuk memiliki beberapa orang di dalam ruangan dan hanya mendengarkan percakapan, mencatat dan berkata, "Oh, mungkin kita bisa melakukan itu" dan "Komponen ini akan lebih baik berdasarkan apa yang baru saja saya lakukan. mendengar." Dan hal-hal seperti itu.

Drew: Jika Anda bekerja dengan audiens yang lebih umum untuk produk Anda. Jadi mungkin bukan pengguna internal seperti yang Anda miliki, tetapi lebih kepada masyarakat umum, apakah ada cara murah yang dapat dilakukan desainer untuk memanfaatkan penelitian? Apakah ada cara yang lebih mudah jika Anda tidak mengetahui secara langsung siapa pengguna Anda nantinya?

Stephanie: Anda harus tahu siapa mereka nantinya, jika tidak, ini adalah pekerjaan orang-orang pemasaran sebelum membangun produk. Tapi ya, kami melakukan beberapa pengujian pengguna gerilya misalnya, Anda masih dapat menggunakan InVision misalnya. Jadi Anda bisa membangun beberapa prototipe di InVision dan kemudian Anda bisa merekrut pengguna melalui media sosial, misalnya. Saya bekerja untuk produk yang membantu, apa namanya, mekanik dealer mobil yang memperbaiki barang-barang dan kemudian juga memberi tahu klien tentang perbaikan tambahan, hal-hal seperti itu. Jadi kami sudah memiliki komunitas yang berkembang di LinkedIn dan Facebook. Jadi yang bisa Anda lakukan adalah merekrut orang-orang itu. Anda dapat melakukan pengujian jarak jauh, seperti kita sedang melakukan percakapan di alat seperti alat online. Anda dapat melakukan beberapa berbagi layar. Jadi kami melakukannya untuk beberapa proyek juga.

Stephanie: Saya hanya akan memberi Anda satu saran adalah menguji alat itu sebelumnya, karena saya menggunakan, itu disebut muncul.in. Tapi saya pikir mereka mengubah nama menjadi Whereby atau sesuatu, tapi itu benar-benar di browser yang saya katakan, oke, itu bagus karena pengguna tidak perlu menginstal apa pun tetapi pengguna tidak berada di komputer nyata. Mereka menggunakan VM, menjadi Citrix dan mereka tidak memiliki mikrofon, jadi apa yang akhirnya kami lakukan adalah seperti mereka menggunakan alat saya untuk berbagi layar. Mereka mengklik prototipe dan pada saat yang sama saya meminta mereka melalui telepon, seperti telepon rumah, untuk berbicara dengan mereka secara langsung. Jadi selalu, ini cukup murah karena ini adalah hari perekrutan yang luar biasa, saya pikir kami memiliki 10 pengguna atau sesuatu seperti itu. Ya, Anda dapat melakukan banyak hal bahkan jika Anda tidak dapat bertatap muka, saya telah melakukan banyak pengujian kegunaan langsung di Skype atau hal-hal seperti itu. Jadi selalu ada beberapa cara murah untuk melakukannya.

Drew: Ketika memilih kerangka kerja UI untuk digunakan, jika itu rute yang Anda tuju, apakah itu sesuatu yang akan Anda serahkan hanya kepada pengembang atau apakah itu sesuatu yang juga harus melibatkan desainer?

Stephanie: Bagi saya, Anda harus melibatkan seluruh tim. Seperti para desainer, developer, mungkin juga arsitek jika ada, karena bagaimana kerangka kerja yang dibangun mungkin juga mempengaruhi hal-hal semacam ini. Sayangnya, sebagian besar waktu ketika mereka tiba di proyek, kerangka kerja sudah diputuskan. Tidak, sebenarnya lucu, entah itu sudah diputuskan atau mereka meminta saya untuk memvalidasi pilihan kerangka kerja mereka, tetapi saya tidak melakukan ulasan atau penelitian apa pun. Saya benar-benar tidak tahu apa yang ada dalam proyek karena mereka bahkan tidak menunjukkan layar mereka kepada saya. Mereka seperti, “Ya, lakukan tugasmu. Kita bisa menggunakan kerangka kerja ini.” Saya tidak tahu. Nah, apakah kita punya layar? Jadi mereka akhirnya menunjukkan kepada Anda beberapa layar, yang merupakan aplikasi asli Windows yang ingin mereka migrasikan di cloud. Mereka berkata, "Ya, kami hanya membutuhkan tombol dan sebagian besar menyukai formulir dan hal-hal seperti itu."

Stephanie: Tetapi sangat sulit untuk mengatakan, "Ya, gunakan kerangka kerja ini, kami memiliki semua komponen yang kami butuhkan." Atau seperti, "Jangan pergi jika Anda tidak memiliki gambaran kasar tentang konten Anda nantinya, apa navigasinya." Jadi saya pikir Anda masih harus memiliki semacam tinjauan global sebelum memilih kerangka kerja Anda kecuali jika Anda 100% yakin Anda memiliki semua komponen. Tetapi saya merasa bahwa sebagian besar waktu pilihan kerangka kerja pada dasarnya didasarkan pada teknologi apa yang disukai pengembang saat ini, apakah mereka memiliki pengalaman dengan kerangka kerja sebelumnya? Kami menggunakan Ant pada beberapa proyek hanya karena beberapa pengembang memiliki pengalaman dengan itu dan mereka sangat menyukainya dan mereka cukup efisien menggunakan Ant. Dan untuk Material React UI juga sama. Ini seperti karena pengembang sudah menggunakannya di proyek sebelumnya, jadi mereka efisien dengannya.

Drew: Jadi benar-benar harus ada keseimbangan antara apa yang nyaman bagi para pengembang, apa yang mereka ketahui, apa yang akan bekerja dengan tumpukan teknologi mereka dan kemudian apa persyaratan produk dalam hal menciptakan antarmuka pengguna yang baik. Dan Anda entah bagaimana perlu menyeimbangkan keduanya untuk menemukan kerangka kerja yang ideal untuk itu.

Stefani: Ya. Saya memiliki semacam persyaratan khusus untuk beberapa proyek, yaitu… Saya di Luksemburg, kami memiliki banyak institusi Eropa dan hal-hal seperti itu, jadi kami memiliki persyaratan aksesibilitas ekstra untuk beberapa di antaranya. Dan biasanya ketika kerangka kerja diputuskan, mereka tidak benar-benar memeriksa aksesibilitas kerangka kerja mereka dan kemudian mereka kembali beberapa bulan setelah awal proyek dengan mengatakan, “Oh, baru saja memberi tahu kami bahwa ada undang-undang baru ini dan kami harus dapat diakses tetapi kami tidak tahu bagaimana melakukannya.” Seperti ya, ini sedikit terlambat. Jadi bagi saya, untuk memilih kerangka kerja, Anda harus benar-benar mengetahui semua kendala di awal proyek dan jika aksesibilitas adalah salah satunya, Anda perlu menguji komponen Anda dan memastikan bahwa mereka dapat diakses. Tetapi saya bukan pengembang React atau Angular, tetapi saya cukup yakin bahwa mengubah kerangka kerja UI yang tidak dapat diakses menjadi sesuatu yang dapat diakses sangatlah rumit. Saya kira mungkin sedikit rumit untuk membangun kembali semua komponen, jadi hal-hal seperti itu.

Drew: Jika Anda mendapati diri Anda mengerjakan proyek di mana proses itu belum terjadi dan kerangka kerja UI telah dipilih, apakah ada bahaya bahwa antarmuka pengguna dapat mulai dipengaruhi oleh komponen yang sudah ada dalam kerangka kerja itu daripada didorong oleh kebutuhan pengguna?

Stephanie: Sejujurnya, sebagian besar proyek yang saya kerjakan, akhirnya Anda memiliki banyak trade off, bahkan jika Anda benar-benar mencoba untuk mendorong. Jadi kebanyakan tentang keseimbangan dan berdiskusi dengan para pengembang. Jadi biasanya yang saya lakukan adalah membuat beberapa bingkai kawat, bahkan bingkai kawat kertas cepat, katakan oke, di halaman ini kita akan membutuhkan komponen itu dan itu dan itu, hal pertama yang saya lakukan adalah bertanya kepada pengembang apakah kita memilikinya di kerangka saat ini? Seperti apa bentuknya? Dan kemudian kita putuskan bersama, oke, ini adalah komponen yang akan melakukan pekerjaan atau oke ini tidak akan melakukan pekerjaan. Apakah kita men-tweaknya? Seperti apakah kita masih menyimpan komponen tetapi mengubahnya sedikit agar berfungsi, atau apakah kita membangun sesuatu dari awal?

Stephanie: Dan pada akhirnya itu akan tergantung pada anggaran tentunya. Jadi Anda akhirnya melakukan trade off. Seperti saya akan baik-baik saja untuk komponen kecil yang hampir tidak pernah digunakan jika tidak sempurna dan ada beberapa masalah. Tetapi untuk navigasi utama, struktur utama, hal-hal yang Anda lihat sepanjang waktu di layar, misalnya, ini benar-benar perlu berfungsi. Pengguna perlu memahami bagaimana mereka bekerja secara efisien dan ya, seperti yang Anda katakan, menemukan keseimbangan antara pengalaman ideal yang Anda inginkan jika Anda tidak memiliki kerangka kerja dan apa yang Anda miliki dan anggaran dan juga waktu. Jika kita mengatakan, oke, untuk sprint ini, fitur harus diselesaikan di akhir sprint ini, dan kemudian mereka berkata, oke, tetapi jika Anda menginginkan komponen Anda, kami tidak akan pernah menyelesaikan fitur di akhir sprint ini, maka Anda mulai berdiskusi, oke, apakah kita menyelesaikan fitur ini di layar berikutnya, apakah kita membutuhkan lebih banyak waktu untuk melakukannya dengan benar? Dan biasanya itu sangat tergantung.

Stephanie: Hal yang paling membuat saya frustrasi adalah ketika saya tahu bahwa kami menggunakan komponen crop fix dan mereka berkata kepada saya seperti, Oh tidak, jangan khawatir. Kami akan memperbaikinya nanti. Dan saya tahu bahwa sayangnya nanti mungkin tidak akan pernah terjadi. Jadi tergantung tim. Tetapi setelah beberapa saat Anda memiliki pengalaman dan Anda tahu, apakah ini nanti akan tiba dan atau tidak? Ya, ini tentang kompromi. Saat Anda bekerja dengan alat semacam ini.

Drew: Sebagai pengembang sendiri, salah satu hal yang saya suka tentang kerangka kerja UI adalah mereka sering datang dengan gaya default. Jadi itu berarti saya tidak perlu memiliki seorang desainer mungkin untuk membantu saya dengan tampilan dan nuansa dari semua komponen. Apakah itu sesuatu yang harus kita andalkan dalam proyek? Hanya gaya default dan percaya bahwa siapa pun yang membuat kerangka kerja telah melakukan pekerjaan yang sangat baik dalam merancang komponen-komponen itu? Atau apakah Anda akan menata sendiri komponen-komponen itu?

Stephanie: Saya pikir itu benar-benar tergantung. Masalah misalnya dengan Material-UI adalah tampilan dan nuansa aplikasi web Anda pada dasarnya adalah produk Google yang dikonfigurasi. Jadi jika Anda tidak benar-benar mengubah font, mengubah beberapa warna dan jenis membawa identitas merek Anda sendiri dan melakukan itu, Anda akan memiliki produk yang hanya akan terlihat seperti produk Google, yang bisa menjadi hal yang baik karena jika pengguna Anda terbiasa dengan produk Google, ini mungkin membantu mereka memahaminya. Jadi biasanya jika Anda tidak memiliki desainer dalam tim, apakah Anda punya pilihan? Seperti banyak karya berbeda yang pernah saya lihat, mereka datang dengan tema khusus sehingga setidaknya Anda dapat mengubah warnanya. Saya pikir Anda dapat mengubah font juga dengan cukup mudah. Tetapi sekali lagi, seperti jika Anda mengubah warna dan Anda tidak terlalu bagus dalam desain atau bahkan aksesibilitas, mungkin warna yang akan Anda gunakan akan berbenturan, mungkin memiliki masalah kontras.

Stephanie: Misalnya, saya suka oranye, tapi itu salah satu warna yang paling menjengkelkan untuk digunakan karena memiliki oranye yang dapat diakses, misalnya, sebagai tombol dengan teks putih, hampir terlihat kecoklatan. Dan jika Anda ingin memiliki warna oranye yang benar-benar mengkilat ini, Anda memerlukan teks gelap di atasnya agar dapat dibaca tetapi itu membuat antarmuka Anda terlihat seperti Halloween di penghujung hari. Ya, aku melihatmu tertawa. Tapi itu benar. Jadi selalu tentang kompromi semacam ini dan katakan jika Anda seorang pengembang dan Anda ingin menggunakan kerangka kerja apa adanya dan Anda tidak memiliki seorang desainer, saya pikir itu masih lebih baik daripada tidak memiliki apa pun dan membangunnya dari awal dan maka itu sangat rumit untuk digunakan. Tapi masalahnya, hanya karena Anda memiliki komponen tidak berarti Anda akan membangun antarmuka yang hebat. Ini seperti batu bata Lego. Jika Anda memiliki batu bata Lego, tidak apa-apa, tetapi Anda dapat melakukan pesawat luar angkasa yang sangat bagus atau Anda dapat melakukan sesuatu yang tidak dapat disatukan dan akan berantakan karena Anda tidak benar-benar memiliki rencana.

Stephanie: Jadi desain lebih dari itu. Desain adalah tentang benar-benar memahami apa yang akan ditampilkan di layar, bagaimana cara kerjanya. Dan saya tahu beberapa pengembang yang benar-benar memiliki kemampuan untuk melakukan itu. Jadi mereka sangat bagus dengan pedoman kegunaan dan mereka memahami banyak aturan desain, misalnya. Jadi saat memilih komponen, mereka sangat ahli dalam hal itu. Dan saya tahu pengembang yang tidak tahu komponen apa yang harus dipilih dan memilih yang pertama yang melakukan pekerjaan. Tetapi setelah beberapa saat tidak berfungsi lagi. Seperti tab misalnya, kami memiliki antarmuka di mana beberapa pengembang memilih tab. Saya pikir masuk akal di awal ketika Anda hanya memiliki tiga item. Tapi kemudian ada 12 item di layar dan kemudian Anda memiliki tab yang terdiri dari tiga baris tab, dan semuanya adalah tab level satu yang sama, dan ada tab di dalam tab. Jadi mereka memiliki komponen, itu terlihat bagus karena mereka menggunakan kerangka kerja, tetapi tidak benar-benar dapat digunakan.

Stephanie: Dan saya memiliki hal yang sama dengan seperti modal windows misalnya. Di mana mereka membangun proyek tanpa desainer dan setelah beberapa saat saya pikir klien meminta lebih banyak barang ke dalam modal ini. Jadi mereka berakhir dengan layar dengan tabel dan ketika Anda mengklik tambahkan baris, Anda membuka modal, dan dalam modal ini Anda memiliki dua tab, dan kemudian di salah satu tab itu Anda bahkan memiliki tabel lain dan kemudian mereka ingin menambahkan barang ekstra ke dalamnya, saya seperti, oke, mungkin kita bisa meletakkan modal di atas modal. Dan pada titik tertentu perancang akan menjawab, oke, jika Anda memiliki banyak konten di modal, itu seharusnya bukan jendela modal. Ini harus menjadi halaman. Jadi meskipun Anda memiliki komponen tersebut, Anda masih membutuhkan seorang arsitek untuk melakukan perencanaan dan memastikan bahwa semua komponen tersebut bekerja sama dengan baik.

Drew: Jadi jika sebagai seorang desainer, Anda diminta untuk mengubah gaya beberapa komponen, apakah Anda akan mencoba dan mengubah semua gaya? Apakah Anda akan menyesuaikan semuanya atau adakah area tertentu yang akan Anda fokuskan?

Stephanie: Warna Saya pikir karena itu hal pertama yang Anda lihat, warna sebenarnya bisa membawa Anda identitas. Jika Anda menyukai identitas merek yang kuat, setidaknya memiliki warna produk Anda pada tombol atau ikon dan hal-hal seperti itu, sudah membantu Anda menyesuaikan kerangka kerja. Font karena saya pikir itu mudah, jika kerangkanya dibangun dengan baik, biasanya Anda mengubah seluruh keluarga font di suatu tempat dan kemudian itu harus mengalir di seluruh situs. Jadi warna dan font menurut saya adalah dua cara mudah untuk menyesuaikan kerangka dengan cepat. Ikon adalah cara lain yang bagus untuk membawa kepribadian, tetapi mungkin sulit karena dari apa yang saya lihat, sebagian besar kerangka kerja datang dengan ikon khusus atau Font Awesome atau seperti perpustakaan yang sudah ada di dalamnya. Jadi untuk menggantinya, pertama-tama Anda memerlukan banyak ikon jika Anda ingin mengganti semuanya. Jadi mungkin agak rumit. Saya juga telah melihat kerangka kerja yang memungkinkan Anda memilih paket ikon mana yang ingin Anda gunakan. seperti Font Awesome, Glyphicons dan beberapa lainnya. Jadi ini adalah hal-hal yang dapat Anda sesuaikan dengan mudah.

Stephanie: Dan kemudian tentang tampilan dan nuansa, misalnya header, biasanya Anda memiliki berbagai jenis header, footer. Bagaimana Anda menavigasi hal-hal seperti itu. Jadi sudah ada banyak kustomisasi kecil yang dapat Anda bawa sehingga tidak terlihat Material-UI-ish, lebih terlihat seperti merek Anda dan kemudian Anda dapat bermain-main dengan radius perbatasan misalnya. Apakah Anda menginginkan tombol yang benar-benar bulat, atau Anda menginginkan tombol persegi atau Anda juga menginginkan sesuatu di tengah seperti bayangan. Jadi beberapa hal kecil yang biasanya mudah disesuaikan karena sebagian besar kerangka kerja tersebut memilikinya dalam variabel CSS. Ini adalah hal-hal kecil yang dapat Anda sesuaikan tanpa saya pikir banyak usaha, kecuali untuk efek riak ini. Aku benci itu. Aku akan melawannya. Saya agak berharap mereka mengubahnya pada akhirnya.

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. Apakah Anda tahu?

Drew: Yup.

Stephanie: It does. Baik. 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.