Tasarımcılar ve Geliştiriciler Arasındaki Boşluğu Kapatmak

Bu makale, prototiplerinize hak ettikleri süper güçleri veren bir UI tasarımı ve prototip oluşturma aracı olan UXPin'deki arkadaşlarımız tarafından desteklenmektedir: durumlar, JS ifadeleri, değişkenler, koşullu etkileşimler, Git senkronizasyonu. Ancak bu makale hiçbir şekilde UXPin'den etkilenmemekte ve yazarın bağımsız görüşünü ifade etmektedir. Teşekkür ederim!

Son birkaç yılda tasarım araçlarımızın katlanarak geliştiği bir sır değil. Birçoğunun harika bileşen yönetimine ve prototiplemeye sahip olmasıyla, bir sonraki büyük sıçramanın ne olabileceğini merak ediyor olabilirsiniz?

Tipik bir ikileme bakalım:

Bileşenler, varyantlar yarattığınız ve değiştirilebilecek veya değiştirilemeyecek tüm kullanım durumlarını ve özellikleri belgelemek için saatler harcadığınız tasarım sistemleri ekibi için bir tasarımcı olduğunuzu varsayalım. Sonunda büyük bir karmaşık bileşeni bitirir ve geliştiricilere teslim edersiniz.

Kodun aynı kullanıcı arayüzü olduğunu nasıl bileceğiz? Her bir bileşeni gerçekten denetlememiz gerekiyor mu? Sürekli gözden geçirme yükü olmadan tasarlanan ile geliştirilen arasındaki bu boşluğu nasıl kapatacağız?

Tüm bunlar ve insanlara bileşenleri kullanmanın farklı yollarını , duyarlı web için uygun boşlukları ve tasarımı öğretmeye yardımcı olmalısınız ve elbette, bileşenin gelecekteki kullanım durumları için güncellenmesi gerekecektir.

Katılan çok fazla temas noktası, insan var. Tasarım sistemlerinde ne kadar ileri gidersek, herkes için o kadar fazla ek yük varmış gibi geliyor! Şimdi, tünelin sonunda bir ışık parlıyor gibi görünüyor ve bir sonraki büyük şey yolda.

Tüm Kaos İçinde Gizli Bir Mücevher

Kısa bir süre önce, uzun süredir kullanmadığım bir aracı tekrar ziyaret etme fırsatı buldum - bu boşluğu doldurmayı ve tüm bu ek yükü en aza indirmeyi amaçlayan bir araç: UXPin. Ekiplerimizin beklediği çevikliği ve kaliteyi geliştirirken tasarım ve geliştirmedeki uçurumları aşmaya yardımcı olmak için "Birleştirme" adlı yeni bir özellik kullanıma sunuldu. Bu yeni teknoloji, bazılarının tüm tasarım ve mühendislik ekiplerinin kullanım senaryoları ve yapı bileşenleri aracılığıyla nasıl işbirliği yaptığını ve nasıl çalıştığını yeniden düşünmesine neden olabilir.

Eski Süreçle Çıktı

Çoğu şirketin bugün kullandığı mevcut sürece bakarsak, bazı bariz kusurlarla oldukça sıkıcı olabilir. Sıfırdan yeni bir bileşen oluşturduğumuzda, bileşenin temel seviyesini tasarlayacağız, varyantlar ekleyeceğiz, dokümantasyon yazacağız, kütüphaneye yayınlayacağız ve geliştiricilere teslim edeceğiz. Süreci listelemek uzun soluklu, ancak neyse ki sadece bir kez yapılması gerekiyor (umarız):

Şimdi, bir bileşeni güncellememiz gerektiğinde ne olur? Yeni bir kullanım durumu geldi veya belki de sınırlarımızı yuvarlaktan jilet keskinliğine değiştirmeye karar verdik? Şimdi varyantları kütüphaneye eklememiz, (muhtemelen) belgeleri tekrar güncellememiz, yayınlamamız ve geliştiricilerimize teslim etmemiz gerekiyor. Vay! Bileşenin tüm bu yeniden düzenlenmesiyle tasarımcılarımız için yol boyunca hiçbir şeyin bozulmadığını umalım .

Neredeyse unutuyordum, hala geliştirme kitaplığındaki güncellemeleri yayınlamamız gerekiyor! Ürün ekipleri son teslim tarihlerini karşılamak için kendi yollarına gitmeden önce bitirebileceklerini umalım.

Yeni Süreçte

Peki, merak ediyor olabilirsiniz, UXPin Merge'in teknolojisi, bugün hepimizin uyguladığı bu üst düzey sürece nasıl yardımcı oluyor? Peki, aşağıdaki şemaya bir göz atın. Bir bileşenin yaratıldığını ve varyantların gerekli olmadığını fark edebilirsiniz (çoğu durumda). Bu yeni süreç, geliştiricilerle artık sinerji yaratan ilişkimiz nedeniyle, otomatik mizanpaj araçlarıyla uğraşma miktarını azaltıyor :

Yalnızca belgeleme ve uygulama için gereken ayrıntı düzeyini tasarlamamız gerekiyor. Düğme veya diğer atomik düzeydeki bileşenler gibi basit bileşenlerin tasarlanmasına gerek olmayabilir. Geliştirme, küçük bir ek masrafla hemen başlayabiliyorken , işi iki katına çıkarmak için neden zamanınızı boşa harcıyorsunuz ? Bir bakıma tam bir çember oluşturduk; statik bileşenlerin belgelerde yalnızca birkaç etkileşim gösterdiğinde eski yöntemlere dönüyoruz.

Kütüphaneye yayınlamanın artık sürecin sonunda olduğuna dikkat edin. Bunun nedeni, geliştirici bileşeni bitirdiğinde, artık onu UXPin'deki tasarımcıların kullanımına sunmak için Birleştirme'yi kullanabilir ve elbette tüm ürün geliştiricileriniz aynı anda buna sahiptir!

Bileşenleri güncellerken, senaryoya bağlı olarak ilk adımı atlamanın mümkün olması dışında, temelde yenisiyle aynıdır. Örneğin, düğmelere simge eklemek için bir seçenek eklemek istediğinizi varsayalım; bu tasarım gerektiren bir şey değil, bunun yerine geliştirme aşamasındaki yeni en iyi arkadaşlarınızla iletişim kurmanız gerekiyor.

Geliştiricilerinizle bu yeni ilişki oluşurken, bileşenleri tasarımcılara resmi olarak sunmanın yeni yolu yalnızca geliştiriciler tarafından piyasaya sürüldükten sonra olabilir. Ürün tasarımcılarının, ürün geliştiricileri için bir bileşenin mevcut olup olmadığını sorduğu günler geride kaldı. Kitaplıkta varsa, geliştirme aşamasındadır ve tasarımcıların hemen üzerinde çalışması için hazırdır .

Ancak süreç hakkında yeterli. UXPin Merge'in nasıl çalıştığına bir göz atalım.

Kitaplıkları Yönetme

En iyi yanı, kitaplıkların doğrudan GitHub, Bitbucket, GitLab (yalnızca React bileşenleri için çalışır) ve hatta Storybook'tan kod deponuzdan içe aktarılabilmesidir. Bir kitaplık oluşturulduktan sonra, kitaplığı adlandırmak için seçenekleriniz olacaktır.

Storybook ile içe aktarırken, süreç oldukça basittir. Sadece kütüphane URL'sini alın ve UXPin gerisini sizin için halledecektir. React bileşenleriyle, CLI'yi kullanarak, UXPin kitaplığının benzersiz belirtecini belirterek yayınlanan bileşenler üzerinde kontrol sahibi olursunuz.

Sürüm Kontrolü ve Testi

Tasarımcılar ve tasarım sistemleri ekipleri arasındaki en büyük endişelerden biri sürüm kontrolüdür. Çoğu endişe, bu UXPin'in Birleştirme özelliği ile çözülebilir. Hızlı bir resim çizelim:

Bugün, bir bileşeni yükseltmek için yola çıktığımızda, her zaman yeniden adlandırılıp temizlenebilecek bir bileşeni veya katmanları kırma korkusu vardır. Bileşenin tamamen yeniden yapılandırılması bile meydana gelebilir ve bu da çoğu zaman (tasarımcı tarafında) bir bileşeni yükseltmeleri mi yoksa eskisini mi kullanmaları gerektiği konusunda endişeye yol açar.

Bununla birlikte, bir bileşen geliştirildiğinde, özellikler aynı kaldığı sürece, bileşen düzeninin nasıl değiştiği veya bileşenin gerçek işaretlemesinin önemi yoktur. Bu da tasarımcıların bileşenlerini güvenle en son sürümlere yükseltmelerine olanak tanır .

Tabii ki, bir bileşenin tamamen bozulduğu ender bir anda, tıpkı herhangi bir kodlama projesinde olduğu gibi, kolayca geri alınabilir ve bileşenin eski sürümünü yeniden yayınlayabilir.

Güncellemeleri Test Etme

Yeni bileşenleri veya güncellemeleri test ederken, bugün o kadar kolay değil. Yanlışlıkla yayınlanabileceğinden ve kullanıma hazır diğer güncellemeleri engelleyebileceğinden, mevcut tasarım kitaplığını test etmek için düzenleyemiyoruz. Ayrıca yeni bir dosyada bir bileşen oluşturmak, onu test etmek ve ardından katmanları bozmadan mevcut kitaplığa geri birleştirmeyi halletmek çok zahmetlidir.

Neyse ki bizim için geliştiriciler bu sorunu uzun zaman önce çözdü ve bu, UXPin'in Birleştirme teknolojisine tam olarak uyuyor. Yeni bileşenleri test ederken , kodu çatallamak veya dallandırmak zaten en iyi uygulamadır ve bu yeni dal UXPin içindeki bir test ortamında yayınlanabilir. Ekibiniz bunu test edebilir veya şirketinizdeki küçük bir beta testçi grubuna erişim izni verebilirsiniz. Bileşen test edilip denendikten sonra, bileşen hızlı bir şekilde tanıtılabilir ve dikişsiz olarak birincil tasarım kitaplığına yayınlanabilir.

Kodla Tasarlama

Peki, ekip üyelerimiz zemin tasarımı konusunda nasıl ve bu teknoloji onlar için ne anlama geliyor? Peki, sorduğuna sevindim! Bir ürün tasarımcısının bakış açısından - pek bir fark yok. Bir tasarımcı, Merge'i kullanan geliştirme kitaplığından bir bileşen kullandığında, her bileşen için turuncu bir altıgenle işaretlenir . Yeni olan her şey, geliştiricinin kitaplığıyla tamamen aynı şekilde davranmaya devam edecektir.

Geliştiricilerin bileşenleri, tanımlanmış kısıtlamalara sahip olabilir, ancak iyi bir şekilde. Sık görülen bir sorun, simgeyi bir düğme bileşenine sarmak yerine simgeleri bağlantı olarak kullanmaktır . Kitaplıktan yalnızca bir simge kullanacak olsaydık, kilitlenir ve kullanıcı etkileşim ekleyemez:

Alternatif olarak, aşağıdaki simge düğmesi etkileşimlere izin verir. Bu, hangi bileşenlerin etkileşime girip hangilerinin etkileşime girmemesi gerektiğini gerçekten hassaslaştırmamıza ve kontrol etmemize olanak tanır; hem standartlar hem de erişilebilirlik açısından.

Bu tür kısıtlamalarla, Tasarım Sistemleri ekibine, bileşenlerin uygun şekillerde kullanılması gerekeceği konusunda kolaylık sağlar ve eğer geçersiz kılınırsa, bir şeyin özel olarak yapılmış olduğu katman panelinden açıkça anlaşılır.

Dokunma

Geliştiricilere teslim etmeye hazır olduğunuzda, bitmiş prototip, kopyalayıp geliştiricinin araçlarına yapıştırmak ve projeyi hızlı bir şekilde oluşturmak için her bileşeni ve yapılandırmasını görüntüleyebilir. Ekibinizin henüz bir bileşen kitaplığı yoksa, UXPin varsayılan bir kitaplıkla birlikte gelir veya doğrudan UXPin'de bulunan bazı genel kitaplıkları kolayca içe aktarabilirsiniz .

Ulaşılabilirlik

Erişilebilirlikten bahsetmişken, çoğu zaman gözden kaçar veya tüm meta etiketler, aria etiketleri vb. hakkında belge oluşturmak için yeterli zaman yoktur. Tasarımcılar hangi etiketleri girmeleri gerektiğini bilmiyorlar ve geliştiriciler bu güçlükle uğraşmak istemiyor.

UXPin ile, ARIA etiketleri gibi arayüz tarafından asla görülemeyen meta-seviye verileri bile birden fazla özelliği açığa çıkarabiliriz . Tasarımcılar daha sonra gerekli tüm bilgileri (veya ekibinizde bir tane olacak kadar şanslıysanız bir metin yazarı) girebilir ve ürün geliştiricilerin uygulaması için çok az veya hiç ek yük olmayacaktır.

Düzenler, Şablonlar ve Izgaralar

Sadece başlığı okuyarak, neyin geleceğini biliyorsunuz ve şu anda koltuğunuzda zıpladığınızdan eminim - öyle olduğumu biliyorum. Izgaralar, düzenler ve hatta sayfa şablonları, kullanıcıların bileşenleri bir sayfanın aktif alanına getirmesine ve tüm boşlukların geliştirme kitaplığı tarafından işlenmesine izin veren bir 'bileşen' olarak kitaplığa alınabilir.

Ortak şablonların (örneğin oturum açma ekranları, tamamlama sayfaları, formlar, profil sayfaları vb.) tümü de bir sürükle ve bırak bileşeni olarak kullanılabilir. Süreci hızlandırmak ve tasarımda insan hatasını azaltmak hakkında konuşun!

Kapanışta

Sıçramaya hazırsanız, iş akışınızı iyileştirmek için yeni yazılımları ve yeni süreçleri denemek için asla geç değildir. Sonuçta, hepimiz mümkün olduğunca çevik ve benimseyen olmak istiyoruz. Ekiplerimiz arasında daha güçlü ilişkiler kuralım, iş yükümüzü azaltalım ve daha verimli çalışalım. UXPin Merge gibi araçlarla çok daha sorunsuz bir çalışma ortamına yaklaşıyoruz.