Смърт за обработка на машини!

Намерете своя идеален процес на проектиране, като се придържате към няколко прости принципа, вместо строг сценарий.

Чувате много различни съвети за правилния и грешен начин за проектиране на приложение или уебсайт.

„Трябва да използвате Sketch.“
„Дизайн системи или GTFO.“
„Истинските дизайнери създават 100% код.“
„Кадрите са загуба на време.“
„Ако не създавате прототипи, не го правите правилно.“
„Трябва да започнете на хартия.“

Бихте си помислили, че няма споразумение за правилния начин на проектиране, но има една точка, която до голяма степен е безспорна - процесът ви трябва да е линеен.

Класическият линеен подход изглежда така:
проучване → скица → телена рамка → статични компреси → прототип → код

Подобно на онези машини за производство на Rube Goldberg, които използват за производството на Doritos и Ding-Dongs. Хвърлете идея в машината на процеса и след като стане пюре и оформено във форма, докато се навива през стъпалата, завършен продукт изскача от другата страна! Предсказуем! Ефективно!

Един вид.

Машините за обработка работят, но само когато работят. Те не се адаптират и това ги прави чупливи. Всичко, от което се нуждаете, е един малък Сабот, който да смила процеса на вашата машина.

Ханк, а.к.а „Саботът“

Напоследък гледам как намирам Дори с моето дете и част от кадрите от „създаването на“ продължават да ми изскачат.

Във филма има този октопод на име Ханк:

Disney / Pixar

Септоп, технически. Неговият геройски модел беше толкова обременителен за работа, че те изключиха пипало, за да направят анимацията му изпълнима. Все пак, с 4000 отделни контрола, той беше изключително предизвикателен да работи.

В този момент в процеса те вече са минали скици и изобразявания и аниматика - онези по-ниски етапи на вярност, които ви помагат да проверите куп идеи бързо и евтино. Те също вече имат Реал. Беше изграден персонажът, разработени са технически детайли, отговориха основни въпроси.

Те са в последния анимационен етап - 3D модели в 3D среда. Те можеха да участват в войната за сметка на производствения график и бюджета. Вместо това направиха нещо наистина интересно - върнаха се към скицирането.

Disney / Pixar

Скицирайки сложното движение на пипалата на Ханк на хартия, те можеха да забият перфектната, течна анимация, която търсеха за част от времето. След като са били доволни от последователността, те са анимирали в 3D, за да съвпадат. Те получиха по-добър продукт за по-малко време, тъй като избраха да оценят принципите на процеса вместо предписанието на процеса.

Лекът за предписващ процес

Екипът на Finding Dory направи по-добър продукт по-бързо, като взе решения, които дават приоритет на скоростта и качеството, вместо да се придържат към процес на въртене.

Може да изберете други неща, които да ценят, но ако работите в търговска обстановка, фокусирането върху сладкото място между скорост и качество трябва да е в горната част на списъка ви. Включването на голяма работа бързо е голяма работа за професионални дизайнери и художници в края на краищата.

Дефинирането на принципите, които задвижват вашия процес, е само началото. Ето как можете да ги приложите на практика.

Започнете с големите въпроси

Ако оценявате скоростта, стартирайте проект, като разберете кои са най-големите и най-фундаментални въпроси. В Getting Real това се нарича „епицентър дизайн“:

Започнете от сърцевината на страницата и надградете навън
Дизайнът на епицентъра се фокусира върху истинската същност на страницата - епицентъра - и след това се изгражда навън. Това означава, че в началото пренебрегвате крайниците: навигацията / раздели, долен колонтитул, цветове, странична лента, лого и т.н. Вместо това първо започвате в епицентъра и проектирате най-важната част от съдържанието.
Без значение каквато страница не може да живее, е епицентърът. Например, ако проектирате страница, която показва публикация в блога, самата публикация в блога е епицентърът. Не категориите в страничната лента, не заглавката в горната част, не формата за коментари в долната част, а действителната блог публикация. Без блога за публикации в блога, страницата не е публикация в блога.
Едва когато тази единица е завършена, ще започнете да мислите за втория най-критичен елемент на страницата. След това след втория най-критичен елемент, ще преминете към третия и т.н. Това е епицентър дизайн.
Дизайнът на Epicenter избягва традиционния модел „нека изградим рамката и след това пуснете съдържанието в“. В този процес се изгражда формата на страницата, след това се включва навигацията, след това маркетинговите „неща“
 се вмъква и накрая, основната функционалност, действителната цел на страницата, се излива във всяко място, което остава. Това е обратен процес, който взема това, което трябва да бъде основен приоритет и го запазва за край.

Ето пример защо това е от решаващо значение. Работих върху малко приложение за iOS на страничен проект, което използваше уникален, вероятно неработоспособен аудио интерфейс. Ако не оцених скоростта, можех да прекарам безброй часове, проектирайки безброй детайли, опиращи се в основата на тази една странна идея. В крайна сметка дизайнът идва преди код в класическия линеен процес.

Вместо това започнах в кода, за да разбера дали тази идея е жизнеспособна или не. Не беше! Така коригирах плановете си и си спестих огромно количество време и енергия.

Просто попитайте, WMGMTCATMQITLAOT?

След като знаете първо въпросите, които се нуждаят от отговори, запитайте се:
„Кой носител ми дава най-ясния отговор на въпросите ми за най-малко време?“

В случая на моя страничен проект, отговорът беше код. За страница в Basecamp.com отговорът често е текст или скица. За вас това може да е нещо съвсем друго.

Да знаеш кога да сменяш скоростите

Това ви дава място да започнете, но как да разберете кога е време да преминете към различен носител? Когато ударите съпротива.

Помислете как да шофирате кола. Тръгвате по магистралата - двигателят се мърда като доволно коте. Но след това започвате да карате по хълм. Скоростта, в която сте, беше чудесна за круизи, но не и за изкачване на хълм. За да поддържате скоростта си, превключвате в нова предавка.

Същото нещо тук. Но за разлика от автомобилите, няма непоколебим индикатор, че сте ударили прекалено голямо съпротивление в своя медиа по избор. За щастие, повечето дизайнери и художници имат солидна дръжка, когато трябва да преминете към медиум, който предлага повече вярност. Това е частта, която се съчетава с класическия нисък точност → линейния процес с висока вярност в края на краищата. Знаете, че сте готови да преминете от скициране, когато скицирането спре да ви даде полезна представа.

След като стигнете до този въпрос, измислете следващия най-важен набор от въпроси и се запитайте отново: „кой носител ми дава най-ясния отговор на въпросите ми за най-малко време?“

Вторият случай - преминаването обратно към по-ниска вярност - е по-труден. Както защото хората по-малко се практикуват в това, така и защото е сложно. Вземете работа в код. Работите със 100% вярност, така че няма ограничение в способността на медията да отговаря на въпроси. Но има ограничение в способността му да отговаря бързо на въпроси.

Когато почувствате, че не преследвате пътеки, защото това е твърде много работа, това е наистина добър знак, че трябва да отстъпите. Когато нещата се чувстват така, че просто не щракват, както трябва, време е да преоценявате. Внимавайте и ще започнете да развивате усещане за това.

Използване на медиум във ваша полза

Има трети случай за преминаване към - или залепване с - носител. Този не се грижи за съпротивата, а само за фундаментална истина; процесът влияе на резултата. Точно както рисуването на нещо с молив ще изглежда различно от това да го нарисувате с маркер, така и проектирането в браузъра ще доведе до различен резултат от проектирането в Sketch.

Колкото повече разбирате как даден медиум влияе върху работата ви - видът инструмент, който оставя - толкова повече можете да го използвате в своя полза. Искате вашият дизайн да бъде изразителен? Вероятно е по-добре да работите с визуален инструмент като Sketch, Illustrator или дори * gasp * Photoshop. Искате минимален, лек дизайн? Придържайте се към дизайна в код.

Практически пример

Сега, след като се обърнах към опасностите на предписателния процес, бих искал да споделя с вас ... моя процес. Не за вас да следвате стъпка по стъпка! Само за да ви дам пример от реалния живот как можете да използвате принципи, за да ръководите процеса си.

Стартираме нов начин за работа с клиенти в Basecamp и моята работа беше да създам нова страница в Basecamp.com, за да я пусна на пазара. Ето как се разигра:

Определяне на големи въпроси, избор на медиум

Това не е нов сайт или съвсем ново оформление. Първо, трябваше да разбера целта на тази страница, какво се опитва да каже и общата структура.

„Кой носител ми дава най-ясния отговор на въпросите ми за най-малко време?“

Комплектите и скицирането са навън. Това е залагане на съществуващ дизайн и съществуващ шаблон. Бих могъл да прескоча направо към код, но маркирането е шум в този момент. Текстът е точно така.

Куп полуфабрикат

Увеличаване на вярността

Не се придържах с текст достатъчно дълго, за да завърша цялото копие за страницата. След като имах контур и усещане за това как искам да говоря за функцията, премествах предавки в код.

Защо?

Документът с текст не можеше да ми каже дали един ред ще остави вдовица, дали абзацът „се усеща“ дълго, как изображенията ще се движат и т.н. Имам нужда от по-голяма вярност. На някои от новите въпроси можеше да се отговори от статичен комп, но това не би отговорило на въпроси за съвместимостта на копието, освен ако не пропилях времето, което съвпада точно с кода. Не благодаря.

Работа чрез копиране на редакции в код

Селективно намаляваща вярност

След още няколко кръга редакции на копията, страницата започваше да се оформя. Визуално тя беше механична и подхранваща. Исках да е по-изразителен, затова преминах към Sketch, за да разкажа някои идеи.

Бих могъл да остана в кода в по-голямата си част, но със Sketch бих могъл да пусна куп идеи много по-бързо, отколкото бих могъл да ги кодирам. Също така ми позволи директно да сравнявам тези идеи един срещу друг и не бих оставил гнездо на CSS плъх от цялата буца. Win-печеливши мерки.

Куп полуизпечени Sketch comps

Забележете как никой от тях не е напълно изпечен? Това е защото те нямат значение! Те не са за клиентска презентация или за предаване на програмисти. Те са там, за да ми помогнат да измисля нещо, а след това са боклук. Инвестирането на време за полирането им би било пълна загуба на усилия.

Довършване

След като имах представа за посоката, кодирах останалата част от пътя. Полиране на копие, затваряне на скрийншоти и винаги оценяване спрямо финалния, ключов въпрос: „Готов ли е готов за изпращане?“. Можете да разгледате страницата „Клиенти на живо“ в Basecamp тук.

Така не се изпълнява всеки проект. Понякога ще скицирам нещо в Procreate, понякога ще започна с бърз и мръсен визуален комп, понякога ще напиша копие в Sketch, понякога ще работя 100% в код. Всичко зависи от конкретния проект.

Надяваме се, че това ви дава известна представа за това как можете да използвате принципите, за да ръководите процеса си за всеки отделен случай, без да се чувствате все едно да преоткривате колелото.

Помислете за вашия процес и вида работа, която вършите. Определете важните за вас принципи, първо се съсредоточете върху големите неща и продължете да се питате дали медията, в която работите, е подходяща за момента. Работата ви ще бъде по-добра за това.