Tasarımcıların nasıl hayır diyebileceğini öğreten çok sayıda makale var . Bu çoğunlukla serbest çalışanlar ve zor müşterilerle nasıl etkileşim kurulacağı ile ilgilidir. Ürün Yöneticileri ile başa çıkmak için ipuçları içeren makaleler de vardır. Ancak, bir Tasarım Sistemini desteklediğinizde ne olacak? Diğer tasarımcılardan veya geliştiricilerden gelen çakışan taleplerle ne yapılmalı?

Henüz ne yaptığımı bilmiyorum…

Uzman değilseniz ve şirketiniz için sıfırdan bir tasarım sistemi oluşturmaya yeni başlıyorsanız, hangi yöne gideceğinizi bilemeyebilirsiniz. Elbette " nasıl başlanır " üzerine tarifler içeren birkaç makale okuyabilirsiniz , ancak bazen kişisel deneyimden daha iyi bir şey yoktur. Bir şeyler denemek, bazen hata yapmak ve hatalardan ders çıkarmak. Yeni şeylere açık olmak. “Evet, hadi deneyelim” kişisi olun.

Böyle bir durumda mümkün olduğunca esnek olmalısınız. Ancak, başarılı kararların “kara büyü” olarak, başarısız kararların ise bilinmeyen bir tesadüf olarak kalmasını istemiyorsanız, kararlarınızı belgeleyin.

Sadece kararın kendisini değil, sizin (veya diğerlerinin) oraya nasıl ulaştığınızı da yazmak istiyorum. Argümanlar vb. Evet, bu bazen zor olabilir. Özellikle karar sezgisel (içgüdüsel) olduğunda. Ancak, kendinizi ve başkalarını sorgulamayı öğrenirseniz, sonunda fikrin kaynağını anlamaya başlayabilirsiniz.

Bu tür belgeler, neden-sonuç ilişkilerini daha iyi anlamanıza ve neyin işe yarayıp neyin yaramadığını öğrenmenize olanak tanır. Ve bir dahaki sefere, yeni bir teklifin bilinen bir kalıba uyduğunu (veya aynı yöne gittiğini) görürseniz, bunu başkalarına gösterebileceksiniz. Yani riskli çözümlere karşı mantıklı gerekçeler göstermeyi öğreneceksiniz.

Bunu daha önce bir yerde görmüştüm…

Kötü kararlar söz konusu olduğunda topluluktan her zaman örnek isteyebilirsiniz . Tasarımcılar (ve diğer birçok meslek) ne yapılmaması gerektiğine dair listeler yapmayı sever .

“ En Kötü 10 Tasarım Kararı ” ve benzeri kategoride geniş bir makale kesiti var . Bununla birlikte, tasarım sistemleri ile ilgili olarak, en önemlileri “İyi/Kötü” uygulamalar, “Kalıplar”, “Yapılması ve Yapılmaması Gerekenler” vb. açıklamaları olacaktır. Ve bunları açık tasarım sistemlerinin belgelerinde aramak en iyisidir.

Genellikle bu tür belgeler , belirli bir çözümün lehinde veya aleyhinde kısa ama özlü argümanlar sağlar ve sisteminizde ortaya çıkan durumların analizinde büyük ölçüde yardımcı olabilirler. Ve hatta günlük tasarım çalışmalarınızda.

“Yapılması ve Yapılmaması Gerekenler”, herhangi bir sistem tasarımı dokümantasyonunun kilit unsurudur ve sisteminiz için “İyi/Kötü” uygulamaları belgelemeye ne kadar erken başlarsanız, o kadar çok soru ve yanlış anlamadan kaçınabileceksiniz.

“ Belgelenmemişse yoktur ”

Dokümantasyon bir taahhüttür. Ama aynı zamanda “ne yapabilirim/yapmalıyım” konusunda rehberlik. Ne de olsa tasarımcılar, tasarım sisteminde nelerin yapılıp nelerin yapılmaması gerektiğinin farkında olmadıkları için genellikle şüpheli kararlar verirler. Yokluğunda “her şey mümkündür” ifadesi makul bir düşüncedir.

Ancak burada şunu vurgulamak önemlidir: belgeleme yasaklarla ilgili değildir. Dokümantasyon, sistemin nasıl çalıştığını açıklamak ve neyin yapmaya değer neyin değmeyeceğini makul bir şekilde belirtmek için tasarlanmıştır . Buna göre, eğer tasarımcı (veya geliştirici) yalnızca "Bu şekilde beğendim" ile yönlendiriliyorsa ve belgelerle çelişiyorsa, belgelere atıfta bulunarak reddetmek için makul ve haklı bir nedeniniz vardır.

Dokümantasyon, başkalarının fikirlerini tartışmaları için iyi bir örnek oluşturmaya yardımcı olur. Ve fikirleri, tasarım sisteminizi bir sonraki seviyeye taşımanıza yardımcı olacak çözümlere dönüştürün.

Tasarım kitaplığı ≠ Tasarım sistemi

Kullanıcılar (veya katkıda bulunanlar) bir tasarım sisteminin ne olduğunu anlamadıklarında ve onu bir tasarım kitaplığı olarak düşündüklerinde genellikle sorunlar ortaya çıkar. Birçok tasarımcı, kullanıma hazır tasarım kitaplıklarıyla uğraşmaya ve bunları kendi ihtiyaçlarına göre değiştirmek zorunda kalmaya alışkındır.

"Bu UI-Kit'i beğendim, ancak kullanım durumlarım dikkate alınmadan oluşturuldu ve bu yüzden onu özelleştirmem gerekiyor". Kulağa oldukça makul geliyor, değil mi? Evet, sizin (veya bir başkasının) yalnızca küçük bir kısmını kullanacağınız üçüncü taraf çözümlerinden bahsediyorsak. Ancak şirket içi bir tasarım sistemi söz konusu olduğunda, bu kaosa yol açabilir.

Buna benzer bir şey, ama biraz farklı….

Bence en zoru kullanıcıların küçük değişiklikler talep etmesi. Oldukça küçük değişiklikler:

• Başlıklarda simgeleri kullanma yeteneği ekleyin.
• Listedeki blokların sırasını değiştirin.
• 2 yerine 3 düğme göster (bir bileşen tarafından tanımlanır).

• Yaklaşımın diğer bileşenlerle tutarlılığı.
• Kod ve tasarım bileşenlerinde (Figma, Sketch, vb.) uygulamanın karmaşıklığı.

Öncelikle, desenin başka bir bileşenle kesişip kesişmediğini bulmanız gerekir. Bunu yapmak için ya tüm bileşenleri ve davranışlarını ezbere bilmeniz ya da her birini gözden geçirmeniz ve teklifin diğer bileşenlerden herhangi biriyle çelişip çelişmediğine bakmanız gerekir. En ufak bir çelişki varsa, teklifi tek başına değil, birkaç bileşenin davranışı bağlamında tartışmak gerekir. Bu genellikle daha fazla insanı tartışmaya davet etmeyi gerektirebilir.

Uygulamanın karmaşıklığı

Çoğu zaman, tasarımda basit bir çözüm gibi görünen bir şey, geliştirmede büyük bir çaba gerektirebilir. Belki de mevcut mimari yeterince esnek olmadığı için. Belki de geliştirmede kullanılan temel standartlara/yaklaşımlara aykırıdır. Teorik olarak hemen hemen her şey mümkündür, ancak bazı şeyler daha fazla çaba gerektirecektir. Böyle bir durumda, bu değişikliklerin ne kadar önemli olduğunu anlamanız gerekebilir: "Sahip olmak güzel" veya "kritik ihtiyaçlar".

Biz diktatör değil, hizmetkarız

Tasarım sistemi bir üründür . Ama çok özel bir şey. Ürünlerin çoğunluğunun başarısı ne kadar para kazandığıyla ölçülebilirken, bir tasarım sistemi için ana gösterge, onu kaç kullanıcının kullandığı ve hayatlarını ne kadar kolaylaştırdığıdır. Yani bir tasarım sistemi “En dürüst ürün” . Ve bu çok fazla sorumluluk gerektirir. Müşterilerin isteklerinin en iyisini yapmakla kalmıyor, aynı zamanda şüpheli her kararın sonuçlarını anlamalarına da yardımcı oluyoruz:

• beklentide esneklik eksikliği
• çözüm geliştirmede gecikmeler (çözümün karmaşıklığı ve bakımı nedeniyle)
• diğer bileşenlerde veya sözleşmelerde kademeli değişikliklere duyulan ihtiyaç
Yönetim Tasarım Sistemi Katkıları

Nihayetinde, tasarım sistemi kullanıcılar (tasarımcılar ve geliştiriciler) ile ilgilidir. Bu yüzden onlara karşı çok dikkatli olmalısınız. Sonuçta, onlarsız biz hiç kimseyiz. Düzenlemeler makulse ve hiçbir şeyi bozmuyorsa, neden onları yapmıyorsunuz?

"Hayır" demenin tüm nedenleri, kullanıcıların istedikleri ürünü değil, ihtiyaç duydukları ürünü yaratmamızı sağlamakla ilgilidir.

Ford Model T'nin geliştirilmesinde müşteri katkısı sorulduğunda Henry Ford, "İnsanlara ne istediklerini sorsaydım, daha hızlı atlar derlerdi" dedi.

Okuduğunuz için teşekkürler! Arayı soğutmayalım! Tasarımla ilgili daha fazla içerik için LinkedIn'de benimle bağlantı kurun ve beni Dribbble'da ve burada Medium'da takip edin .