Örnekler: Kodlama ve Çizim mi?


9

Bu web tasarımı ile değil genel olarak arayüz tasarımı ile ilgilidir. Interface Mockup'ları kodlamak veya GIMP, Photoshop vb. Gibi bir grafik programında "çizmek" daha mı iyidir?


3
Ben her zaman söylenirim "arayüzünüzü çizin, bunu photoshop'ta yaparsanız ya da insanlar gerçekten sizden daha uzakta olduğunuzu düşünürse. Mockup'larınızı kabataslak görünün, temelleri indirin, böylece müşteriniz ne bekleyeceğini bilir ve sonra genişler daha sonra kullanıcı arayüzünüzde "
Hanna

1
Tamamen projeye bağlı. Evrensel bir 'en iyi' cevap yoktur.
DA01

Yanıtlar:


14

Kendinize şu soruları sorun:

  • Kodlayarak 30 dakika içinde kaç tane UI düzeni / seçeneği keşfedebilirsiniz? Çizim yaparak kaç tanesini keşfedebilirsiniz?

  • İlk denemede tam olarak ne kadar UI tasarımı elde edersiniz? Çok sık değilse, bir çizimi kodlanmış bir maketle değiştirmek ne kadar hızlı / kolaydır?

  • Bir rengi sadece onaltılık / rgb koduna bakarak tanımlayabilir misiniz (sadece bir basketbol sahası tahmini değil, aynı zamanda tam renk / renk)? Aklınızda bir renk çizdiğinizde, bunu hemen onaltılıya çevirebilir misiniz? Gerçek renk seçiciyi kullanmak yerine onaltılı kodlar yazarak renk düzenini ne kadar hızlı seçebilirsiniz?

Bu soruyu sorduğunuz gerçeği, bana muhtemelen bir tasarımcı değil, bir programcı olduğunuzu söyler. Bir tasarımcı olsaydınız, sınıf yapısını, veritabanı tasarımını, uygulama mimarisini vb. Planlamadan ve sadece kodlamaya atlamaksızın bir uygulama geliştirmek kadar saçma olurdu - ve deneyimli bir geliştiriciyseniz, o zaman bilirsiniz bu tür aşağıdan yukarıya gelişimin ne tür problemlere neden olduğu.

Benzer şekilde, önce kullanıcı arayüzünüzü tasarlamadan doğrudan koda atlarsanız, sonuçlar iyi olmaz, çünkü sadece körü körüne kodlayarak iyi bir tasarımı mükemmelleştirmek pratik değildir.


OP bir WYSIWYG kod editörü kullanma hakkında konuşabilir, bununla birlikte renkleri seçebilir veya nesneleri "çizebilirsiniz" ...
jackJoe

2
Aslında, önce UI tasarlamadan kodlama oldukça geçerli bir tekniktir. Tabii ki, "kodlama" UI veya UX parçaları anlamına gelmezse :). Çoğu API ve kitaplık aslında UI dikkate alınmadan tasarlanmıştır - bu sadece pratik değildir.
thebodzio

1
@lese, bir şelale yöntemi kullanıyorsunuz. Bu iyi olabilir, ancak bu günlerde eğilim, ilk günden itibaren kodda çalışmanızın muhtemel olduğu çevik olmaktır.
DA01

@ DA01: İlk günden itibaren kod üzerinde çalışıyorsunuz, ancak yine de yukarıdan aşağıya bir yöntem uyguluyorsunuz. Agile'da kodlamadan önce veri mimarinizi planlayamayacağınızı veya UI-ilkini tanımlayamayacağınızı söyleyen hiçbir şey yoktur (bence çoğu çevik firmanın UML, sınıf diyagramları vb.
Lèse majesté

2
@thebodzio: Evet, elbette, endişelerin ayrılması bunun için. Ama arka ucu kodlamaya değinmiyorum. Sorunun tasarım kısmı açısından kodlama dediğimde (noktayı göstermek için kullandığım programlama benzetmesi değil - biliyorum, biraz kafa karıştırıcı), mockup'u (CSS + HTML veya UI diliniz ne olursa olsun) ).
Lèse majesté

5

Önce "çizmek" için oy verirdim. GUI'de uygun düzen / sunum anahtardır ve görsel araçların tasarlanmasını gerektirir. GUI tasarlamak görsel olarak tasarımınızı her değişikliği "hayal etmek", "koda çevirmek" ve son olarak test etmek zorunda kalmadan hızla değiştirmenizi sağlar. Diğer yol da mümkündür, ancak nadiren daha iyidir (örneğin, proje sadece birkaç düğme gibi son derece küçüktür ve "kod" düzeyinde çalışmaya alışkınız ve alışıksınız; tasarım sırasında bazı desenler ortaya çıkabilir, bu sadece hafif bir değişiklikle yeniden kullanılabilir).

Belirli bir widget araç seti için tasarlıyorsanız, bazı "GUI tasarımcısı" uygulamasını da kullanabilirsiniz. Daha fazla GUI tasarım sürecini hızlandıracaktır, çünkü her ikisi de tasarlanmış GUI'nin programda nasıl görüneceğini tam olarak gösterir ve kullanıma hazır GUI açıklamasını sunum düzeyinde dışa aktarabilir.


2
"ve sen sizsiniz, tanıdık ve çalışma için kullanılan 'kod' düzeyinde" -> O UI / UX ekibi önemlidir edebilirsiniz kodu düzeyinde çalışır. Her tasarımcı bir kodlayıcı olmak zorunda değildir, ancak ekibin tasarladığı her şeyi inşa edebilmesi ve mühendisliği görsel tasarım kadar anlaması gerekir.
DA01

Bir bütün olarak bir takım demek istediğiniz sürece katılıyorum. Bence, sadece UI / UX tasarlarken, kodlamadığınızda, kod iç çalışmalarının bilgisi sizi geri tutabilir, çünkü bazı potansiyel çözümlerden kaçınma eğiliminde olacaksınız çünkü "uygulamak. Bu, tasarımlarınızın bazı parlak fikirlerden arındırılabileceği anlamına gelir, çünkü "araç kiti düşünme" hayal gücünüzün parçalarını kilitler. Sonra tekrar… bıçağın sadece bir tarafı :) Ayrıca, soru sadece "maketler" ile ilgiliydi.
thebodzio

1
'Seni geri tut' argümanını çok duyuyorum, ama bunu sadece sunum katmanı kodunu öğrenmeye karşı inatla karşılayan görsel tasarımcılardan geliyor. Bu insanlar Flash'ta her şeyi yapmaya yöneliyorlar. :) Baskı tasarımından farklı olmadığını öne sürmek istiyorum. Baskının nasıl çalıştığını bilmek, bir baskı tasarımcısı olarak sizi geride bırakmaz. Aksine, RIP'yi boğacak veya yazıcının% 300 mürekkep kapsamı için size çığlık atmasına neden olacak dosyalar oluşturmanızı engeller. Sadece aracı ve bununla ilgili kısıtlamaları anlamakla ilgilidir.
DA01

1
WYSIWYG 'görsel düşünceyi' kolaylaştırmak için değildir. Birlikte bir şey öğrenmek istemeyen insanlara izin vermek içindir. ;) Kısıtlamalara gelince, ortamı tanımlarlar. Harika resimler çizebilen, ancak yüklerin ve açıklıkların temellerini anlamayan bir mimar, geri çekildikleri hiçbir şey inşa edilemediği için büyük ölçüde geri tutulur.
DA01

1
(ve benim görüşümün büyük kısmı UX ekipleri ile ya da UX ekipleri üzerinde çalışarak nasıl bir şey oluşturacaklarını bilmiyorlardı. uygulama, zaman çizelgeleri, kullanıcılar veya bütçeler açısından pratik olmayan çözümler [hepsi 'duvarlar olmaktan ziyade tasarım çözümünün tanımlanmasına yardımcı olan ek kısıtlardır ”] PS: iyi tartışma!
DA01

3

UI tasarımı için farklı hedefleri olan üç aşamam var:

  1. Eskiz. İlk olarak, hangi öğelerin olacağı ve bunların nasıl bir araya getirileceği hakkında temel fikri aşağıya çekmek istersiniz. Bu aşamada herhangi bir ince detay veya estetik mükemmeliyetçilik bir oyalamadır. Bir beyaz tahta ve yağ silinebilir kalem kullanıyorum, bu yüzden çok fazla ayrıntıdan dikkatinizi dağıtmak ve birçok farklı fikirleri karalamak ve istediğiniz zaman yeniden başlamak kolay değil. Sadece küçük post-it notları üzerinde çizim yapan ya da sadece estetiğe hiç dikkat etmemeleri ve% 100 odaklanmamaları için kendilerini zorlamak için (örneğin sağ elini kullanıyorsanız sol eli) kullanan insanları duydum. fikir ve işlev üzerine. (görüntü benim değil, Frank Prendegast'tan )

Beyaz tahta tel kafes fotoğrafı

  1. (2!) Simülasyon.İkincisi, zaman alıcı uygulama çalışmalarına başlamadan önce insanların sezgileri ve beklenmedik yanıtları hakkında olabildiğince fazla bilgi edinmek ve geri bildirim almak ve geri bildirim almak istersiniz. Bu, en verimli şekilde çalıştığınız her şeyde olmalıdır, çünkü eğer doğru yaparsanız, sık sık 'çizim tahtasına geri dönmelisiniz, eleştiri arayınız ve mümkün olduğunca erken beklenmedik sorunları tanımlamayı hedeflemelisiniz. Çılgın bir kodlama makinesiyseniz ve en rahat çalıştığınız şeyse, kodlama iyidir, ancak çoğu insan Fireworks, Photoshop, özel tel çerçeve yazılımı veya belki de Flash Catalyst gibi UI tabanlı bir arayüz oluşturucuda daha hızlı çalışacaktır. (son ürün Flash değilse, amaç uygulamaya başlamadan önce iyi geri bildirim almaktır).

  2. (3!) Uygulama. Son olarak, şeyi uygularsınız ve bunu erken ve sık sık daha fazla geri bildirim almanızı sağlayacak şekilde yaparsınız.

Proje döngüsünün bu üç bölümünün farklı amaçları vardır, bu yüzden büyük bir proje ise her aşamada iş için en uygun aracı kullanmak mantıklıdır.


2

Bu soru biraz belirsiz ve cevaplar gibi.

Bunun da ötesinde, projeler gibi takımlar da çılgınca değişecektir.

Bununla birlikte, 'en iyi' yoktur. Tüm araçları sizin ve ekibiniz için en anlamlı iş akışında kullanmakla ilgilidir.

Genel olarak konuşursak, bunun hedeflemeniz gereken iş akışı türü olduğunu söyleyebilirim:

  1. Kroki. Kalem + kağıt. Beyaz Tahtalar. Uygulayın. Mümkün olduğunca çok sayıda ekip üyesi ile çalışın.
  2. düşük-fi maketler. PSD olabilir, visio olabilir. Kağıt olabilir. Kullanıcı bunları test eder.
  3. Prototipler oluşturun. Bu, çalışma kodunda mümkün olduğunca yapmaya başlamak istediğiniz yerdir. İstediğiniz kadar Photoshop'a atlayın ve bunları olabildiğince hızlı bir şekilde koda dönüştürün. Kullanıcı testine / yinelemeye devam edin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.