Yalnızca etkileyen değil, yayına çıkan tasarım.
Araştırmaya dayalı UX ve token temelli UI sistemleri — mühendislik ekiplerinin içinde oturan tasarımcılar tarafından kurulur, böylece tasarlanan ile yayına çıkan aynı olur.
- Keşif
- Yapı
- Sistem
- Yerleşme
Her bileşen, durumları tasarlanmış olarak gelir.
Kurumsal yazılım sessizce, sürtünmeyle başarısız olur: defalarca tekrarlanan fazladan tıklama, yapılan işi kaybettiren form. Tasarımcılarımız mühendislerin içinde yerleşik çalışır — akışlar gerçek kısıtlara karşı doğrulanır ve tasarım sistemi bir PDF değil, koddur.
Alışılmış başarısızlık çirkinlik değildir. API kırk alan döndürürken altı alan varsayan güzel bir prototip, seksen bin satır taşıması gerekirken sekiz satırla tasarlanmış bir tablo ve mevcut sürede kimsenin geliştiremeyeceği bir arayüzü anlatan bir devir belgesidir. Bunu devri reddederek önlüyoruz: ekranları çizen kişiler teslimat ekibinin içinde oturur, o ekranları hayata geçiren pull request’leri inceler ve yalnızca gerçek veri geldiğinde ortaya çıkan durumları tasarlar. Yayına çıkan, tasarlanandır; çünkü tasarım ve geliştirme iki ayrı departman değil, tek bir konuşmadır.
Her bileşen, durumları tasarlanmış olarak gelir — varsayılan, hover, focus-visible, yükleniyor, hata, boş. Güven, uç durumlarda kazanılır.
Dört iş, hakkıyla yapılmış.
Ne geliştirileceğini bilmek için araştırma, tekrar tekrar geliştirilebilsin diye bir sistem, hâlâ ucuzken karara bağlanan erişilebilirlik ve veri yoğun ekranların gerçekten talep ettiği ustalık.
Araştırma ve akışlar
Paydaş ve kullanıcı görüşmeleri, yolculuk haritalama ve mühendislik bir sprint harcamadan önce test edilen prototipler. İnsanları kendi ortamlarında, kendi verileri ve kendi geçici çözümleriyle iş yaparken izliyoruz; çünkü uygulamanın yanındaki elektronik tablo, çoğu zaman binadaki en dürüst gereksinim belgesidir. Bulgular görüş olarak özetlenmez, kanıtı ekli biçimde yazıya dökülür.
Kod içinde tasarım sistemleri
Token’lar, bileşenler ve kullanım dokümanları yaşayan bir kütüphane olarak teslim edilir — mühendisliğin içe aktardığı kütüphanenin aynısı. Renk, tipografi, boşluk ve yükseklik bir kez token olarak tanımlanır ve hem tasarım dosyaları hem de ön yüz derlemesi tarafından tüketilir, böylece bir token değişikliği bir geçiş başlatmak yerine ürünü değiştirir. Bileşenler; prop’ları, durumları ve erişilebilirlik notlarıyla Storybook’ta belgelenir.
Tasarımdan gelen erişilebilirlik
Kontrast, odak sırası, hedef boyutları ve ekran okuyucu anlamları, hâlâ ucuz olduğu tasarım aşamasında karara bağlanır. Erişilebilirliği bitmiş bir arayüze sonradan eklemek yerleşimi, rengi ve işaretlemeyi aynı anda yeniden açmak demektir; bileşende karara bağlamak ise sonraki her ekranın bunu devralması demektir. Tasarımları roller, etiketler ve klavye davranışıyla notlandırır, sonucu WCAG 2.1 AA’ya karşı denetleriz.
Veri yoğun UI ustalığı
Panolar, tablolar ve iş akışı ekranları — kurumsal kullanıcıların bütün gün içinde yaşadığı zor ve gösterişsiz yüzeyler. Sütun önceliği, sabit kalan bağlam, makul boş ve kısaltma davranışı, bir hataya dayanan toplu işlemler, URL’de kalıcı olan filtreler. Bu ekranlar ilk ekran görüntüsünde değil, sekizinci saatte nasıl hissettirdiğine göre değerlendirilir.
İş günlük olarak nasıl yürür?
Tasarım sistemi bir resim değil, bir pakettir.
Yalnızca bir tasarım dosyasında yaşayan tasarım sistemi, bir arayüzün tarifidir. Bizimki, uygulamanın içe aktardığı sürümlenmiş bir paket olarak yayımlanır: CSS custom property olarak token’lar, React ve TypeScript ile yazılmış bileşenler, her durumu görünür biçimde Storybook’ta belgelenmiş. Marka kararları token değerine dönüşür, böylece marka yenileme bir proje değil bir pull request olur. Mühendislik tasarımı çevirmez, kurar — çıktı listesinde bir devir belgesi olmamasının sebebi budur.
- Renk, tipografi, boşluk, köşe yarıçapı, yükseklik ve hareket için token’lar; bir kez üretilir, hem tasarım hem kod tarafından tüketilir
- Prop’ları, durumları ve erişilebilirlik davranışı belgelenmiş bileşenler; diğer bağımlılıklar gibi sürümlenir ve yayımlanır
- CI’da görsel regresyon testleri, böylece bir token değişikliği bu sprint kimsenin açmadığı bir ekranı sessizce bozamaz
Kimsenin tasarlamadığı durumlar, kullanıcının karşılaştığı durumlardır.
Çoğu arayüz en iyi saatinde tasarlanır: veri yerinde, ağ hızlı, yetkiler doğru, bekleyen hiçbir şey yok. Gerçek kullanıcılar ilk gün bakacak hiçbir şey olmadan, yavaş bir bağlantıyla, bir onayın ortasında ya da butonun önerdiği işi yapma yetkisi olmadan gelir. Teslim ettiğimiz her bileşen, durumlarının tamamını çizilmiş ve uygulanmış olarak taşır: varsayılan, hover, focus-visible, aktif, yükleniyor, boş, kısmi, hata, devre dışı ve salt okunur. Boş durum, bir sonraki adımı taşır. Hata, bir şeylerin ters gittiğini değil, ne yapılacağını söyler.
- Her yüzey için ayrı tasarlanmış yükleme davranışı — yerleşim biliniyorsa skeleton, bilinmiyorsa ilerleme
- Veri yokluğu için özür dilemek yerine ilk adımı öğreten boş durumlar
- Kullanıcının ihtiyaç duyduğu sözcüklerle yazılmış, destek ve operasyonla birlikte gözden geçirilmiş hata ve yetki durumları
Erişilebilirlik, son bir denetim değil, bir kural kümesi.
Proje sonunda yapılan bir erişilebilirlik denetimi, bir kusur listesi ve bunları düzeltecek bütçe üzerine zor bir konuşma üretir. Biz kararları öne çekiyoruz. Kontrast oranları, odak sırası, hedef boyutları, hareket tercihleri ve ekran okuyucu anlamları bileşenin özellikleridir; bileşen geliştirilirken otomatik olarak denetlenir, tasarlanırken notlandırılır. Her ekran aynı bileşenlerden kurulduğu için ürün bu davranışı yeniden kazanmaz, devralır. Kamu ve düzenlemeye tabi müşteriler, satın almanın istediği kanıt izini alır.
- Çalışma standardı olarak WCAG 2.1 AA; ilgili kriterler tasarımların üzerine notlanır
- CI’da otomatik denetimler ve her sürümden önce temel akışlarda klavye ile ekran okuyucu geçişleri
- Hareket, kontrast ve yoğunluk tercihleri ayrı bir erişilebilir mod olarak değil, sistem ayarı olarak karşılanır
Sık sık, tur başına beş kullanıcı; bir kerede elli kullanıcı değil.
Kullanılabilirlik testi bir merasime dönüştüğünde başarısız olur: büyük bir tur, uzun bir rapor ve rapor geldiğinde çoktan başka işe geçmiş bir ekip. Biz küçük ve sık yürütüyoruz. Tur başına beş katılımcı, sizinle kararlaştırılan bir ritim, sürtünmenin ne kadar zamana mal olduğuna göre sıralanmış tek sayfalık bulgular. Test edilen prototip, ürünün kurulduğu bileşen kütüphanesinin ta kendisidir, bu yüzden bir düzeltme yeniden çizilmez, sistemde uygulanır. Görev süreleri öncesinde ve sonrasında ölçülür.
- Turlar teslimat ritmine göre planlanır, böylece bulgular kod hâlâ sıcakken gelir
- Yeniden tasarım öncesinde alınan görev süresi ve tamamlanma oranı temelleri, sonrasında yeniden ölçülür
- Kayıtlar ve bulgular sizin çalışma alanınızda tutulur, böylece kanıt çalışmadan uzun ömürlü olur
Masanın her tarafının bundan kazandığı.
Kanıtı ekli kararlar.
Bir sprint’e girmeden önce gerçek kullanıcıların karşısına çıkmış bir akış, neyin test edildiğinin ve sonucunda neyin değiştiğinin yazılı kaydı ve toplantıda en son kimin konuştuğuna değil, görev süresi ile tamamlanma oranına dayanan bir önceliklendirme gerekçesi elde edersiniz. Araştırma sorunun o özellik olmadığını söylüyorsa bunu da getiririz — bunun bir geliştirme bütçelenmeden önce çalışan sürümü için Ürün Keşfi sayfasına bakın.
- İşin gerçekten kaybedildiği anları işaretleyen yolculuk haritaları
- Vekillerle değil, işi yapan kişilerle test edilen prototipler
- Zaman maliyetine göre sıralanmış bulgular, böylece iş listesi sayılarla tartışılabilir
Yorumlanacak bir dosya değil, kurulacak bir kütüphane.
Tasarımcılar teslimat ekibinin içinde oturur, aynı stand-up’a katılır ve uygulamanın pull request’lerini inceler. Bileşenler, durumları ve erişilebilirlik davranışı çoktan kararlaştırılmış tipli paketler olarak gelir, böylece bir ekran çeviri değil montaj işidir. Belirsizlik, bir tasarım dosyasındaki yorum zinciri yerine kısa bir konuşmada çözülür; tasarımdan uygulamaya geçen süreyi kısa tutan da budur.
- Tipli bileşenler, belgelenmiş prop’lar ve ortak referans olarak Storybook
- Pull request’lerde tasarım incelemesi, böylece sapma diff’te yakalanır
- Token’lar doğrudan derleme tarafından tüketilir — ekran görüntüsünden piksel ölçmek yok
İlk ekran görüntüsü değil, sekizinci saat.
Bütün gün ürünün içinde yaşayan kişiler onu başka şeylere göre değerlendirir: klavye akışı fareyi geçiyor mu, filtre sayfa yenilemesinden sağ çıkıyor mu, toplu işlemdeki bir hata geri alınabiliyor mu, tablo seçtikleri sütunları hatırlıyor mu. Öğle arasından önce iki yüz kayıt işleyen operatör için tasarlıyor ve mutlu senaryoyu gösteren bir paydaşla değil, o operatörle test ediyoruz.
- Yüksek frekanslı akışlar için klavye yolları; belgelenmiş ve test edilmiş
- Kalıcı durum — filtreler, sıralama, sütunlar ve taslaklar gezinmeden ve yenilemeden sağ çıkar
- Önizlemeli ve geri dönüşü olan toplu işlemler, çünkü en hızlı arayüzün bile bir geri alma adımına ihtiyacı vardır
Her çalışmada olanlar ve ürüne göre şekillenenler.
Dört aşama; sonuncusu aslında hiç bitmez.
Keşif
Kullanıcılar, işler, kısıtlar. Nasıl olması gerektiğini önermeden önce gerçek işin nasıl yapıldığını izliyoruz. Bu; mevcut sistemi kullanan kişilerle birlikte oturmak, sistemle baş etmek için kurdukları elektronik tabloları ve yan araçları toplamak ve destek kayıtlarını okumak demek — bu üç kaynak bir arada ürünü tanımlandığı gibi değil, gerçekte işletildiği gibi anlatır.
Yapı
Bilgi mimarisi ve temel akışlar tıklanabilir prototipler hâlinde, onları kullanacak kişilerle test edilir. Gezinme, terminoloji ve temel nesnelerin biçimi burada, gerçek veri hacimlerine ve gerçek API’ye karşı netleşir. Bir ekranın farklı bir birincil nesneye ihtiyacı olduğunu şimdi fark etmek, bir sprint harcandıktan sonra fark etmekten çok daha ucuzdur.
Sistem
Token’lar ve bileşenler, yüksek detaylı ekranlarla birlikte kod içinde geliştirilir — tasarım ve geliştirme ayrışmak yerine yakınsar. Kütüphane erkenden, birkaç bileşen ve önem taşıyan durumlarla yayımlanır, böylece ilk teslimat sprint’i eksiksiz bir set beklemek yerine baştan kütüphaneden montaj yapar.
Yerleşme
Tasarımcılar teslimat sprint’leriyle birlikte ilerler: uygulamayı inceler, uç durumları tasarlar, kullanım verisine göre ince ayar yapar. Sizinle kararlaştırılan bir ritimde test turları sürer, kütüphane ürünle birlikte büyür ve kendi tasarımcılarınız bizimkilerle eşleşir; böylece sistem, çalışma bitmeden çok önce sizin tarafınızda bir sahibe kavuşur.
Sonunda elinizde olanlar.
- Yolculuk haritaları ve doğrulanmış etkileşimli prototipler
- Token temelli bileşen kütüphanesi, kod içinde, dokümanlarıyla
- Her temel akış için yüksek detaylı ekranlar, durumlar dâhil
- Erişilebilirlik notları ve inceleme sonuçları
- Kullanılabilirlik testi kayıtları ve bulguları
- Ölçülmüş bir başlangıç noktası — öncesi ve sonrasıyla görev süresi ve tamamlanma oranı
- Ekibinizin sistemi çatallamadan genişletebilmesi için katkı kuralları
Bu ne zaman doğru tercih.
Ürün, zamanının bir bedeli olan kişiler tarafından bütün gün kullanılıyorsa bunu seçin — operasyon konsolları, arka ofisler, bayi ve iş ortağı portalleri, klinik veya lojistik iş akışı ekranları. Birden fazla ekip tek bir ürün gibi görünmesi ve davranması gereken yüzeyler geliştiriyorsa, erişilebilirlik bir tercih değil satın alma şartıysa ya da bir yeniden tasarım bir kez denenip mühendislikle temasa dayanamadıysa bunu seçin. Ayrıca sistemin ilk ekranlar yazılırken kurulduğu bir web uygulaması veya MVP geliştirmesiyle de doğal biçimde eşleşir.
İhtiyacınız bir marka kimliği ya da pazarlama sitesiyse doğru tercih değildir — bu ayrı bir ustalıktır ve uzman stüdyolar bunu yerleşik bir ürün ekibinden daha iyi yapar. Önünde yeniden kullanım olmayan tek bir ekran için de doğru tercih değildir; bir bileşen sistemi maliyetini yüzeylere yayıldıkça çıkarır. Asıl sorun iş akışının kendisinin yanlış olmasıysa, tasarım yalnızca yanlış süreci hızlandırır — bunun yerine keşif ile başlayın.
Sık sorulan sorular
Bu hizmet genelde nereye oturur.
Ne geliştirdiğinizi anlatın.
Bugün elinizde ne olduğunu ve neye ihtiyacınız olduğunu anlatın. Bir mühendis okur ve nasıl yaklaşacağımızı yazılı olarak iletir.