Про формальный vs реальный дизайн-процесс

Про формальный vs реальный дизайн-процесс

Цитата про формальный vs реальный дизайн-процесс из эссе Майкла Бейрута —дизайнера и сейчас партнера Pentagram, команда которого работала над новыми логотипами Mastercard, Slack, Yahoo, Verizon и дизайном предвыборной компании Хиллари Клинтон.

-----

Уже более 20 лет я пишу предложения по проектам. И почти в каждом из них есть пассаж, который начинается примерно так: «Проект включает четыре этапа: ориентирование и анализ, дизайн-концепция, разработка дизайна и реализация». Все клиенты хотят этого.

Интересно, как бы все обернулось, если бы я рассказал правду о том, что происходит в процессе дизайна?

Это могло бы звучать примерно так:
«Работая над дизайн-проектом, я поначалу внимательно слушаю, как вы рассказываете о вашей задаче, и читаю все найденные справочные материалы по проблемам, с которыми вы сталкиваетесь. Если вам повезет, у меня случайно окажется личный опыт работы в ситуации, похожей на вашу. Идея дизайна появляется в моей голове по ходу процесса, из ниоткуда. Я не могу это объяснить; это сродни магии. Иногда это случается даже раньше, чем вы успеваете рассказать мне о вашей задаче! Если идея хороша, я стараюсь придумать стратегическое обоснование такого решения, чтобы объяснить его вам, не полагаясь на хороший вкус, который у вас может отсутствовать. По ходу я могу предлагать другие идеи либо потому, что вы заставили меня согласиться на это, либо потому, что не уверен в первой идее. Во всяком случае, надеюсь, на ранних этапах я сумею заручиться вашим доверием и к этому моменту вы будете готовы принять мои рекомендации. Понятия не имею, как вы собираетесь проверять их пригодность, за исключением того, что в прошлом другие люди — по крайней мере те, о которых я вам рассказал, — последовали моему совету и преуспели. Иными словами, не могли бы вы просто, ну, знаете... верить мне?»

-----

Конец цитаты.

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

Сегодня хочется перейти к самим протоколам. Но не хочется пересказывать 100% того, что вы и сами можете прочитать в статьях и книжках, а хочется подсветить части протоколов, которые кажутся наиболее интересными.

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

Иногда мы испытываем недовольство ситуацией в проекте, или у нас есть какие-то опасения, которые мы боимся или стесняемся высказать всей команде. Мы замалчиваем такие вещи или делимся с парой человек, но формально они остаются скрытыми от команды. В результате с каждым днем мы все дальше сдвигаемся от идеального пути. И только когда уже все становистя совсем плохо, начинаются разборы в духе «Я знал, что так и будет».

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

Ребята выделили именно эти 4 базовые эмоции, потому что считают, что они понимаются всеми однозначно, что снимает вопросы по поводу разного толкования одних и тех же слов разными людьми.

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

Интересно было бы посмотреть на запись какого-нибудь реального чек-ини, но сходу найти не удалось. В целом, можно по разному относиться к этой практике, но выделение 4 базовых эмоций для описания своего текущего состояния, кажется рабочей штукой.

Вы можете даже сами с собой зачекиниться прямо сейчас, попытавшись описать свое текущее состояние по поводу вашей работы/проекта/ситуации, выделив те из 4 эмоций, которые испытываете и подумать, почему именно они выделились сейчас.

Боязнь простых решений

Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.

Бояться надо сложных решений.
Любое решение, в котором есть куча "если" — бомба замедленного действия.

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.

Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".

В общем, надо стремиться к упрощению.

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

Молодой фрилансер постоянно фигачит, учится, весь такой на подрыве.

Я всегда думал, что взросление обязательно связано с переключением в роль управленца — стать арт-директором или CTO, растить команду, учить, брать больше ответственности. «Солдат, что не мечтает стать генералом» казался мне неправильным. Ребят, которые попробовали руководить и откатились до исполнителей, я считал слабаками и дауншифтерами.

Но теперь я думаю, что это необязательно именно так. Ну то есть да, кто-то действительно тупо не затаскивает, но есть и другая штука.

Есть эффективность-продуктивность, а есть удовольствие от работы. Эти две ценности иногда конфликтуют. Не всегда — тут от человека зависит, от того, в каком личном мифе он живёт, какую он себе про себя рассказывает историю. Иногда продуктивность и удовольствие связываются в комплекс, но иногда нет.

Потому что для продуктивности надо постоянно себя мониторить: то ли я вообще делаю? не пора ли это уже бросать и делать другое? я кого-то сейчас блокирую? я по джипегу или закопался в деталях? Надо постоянно удерживать фокус на чём-то, что ты там себе надумал.

А удовольствие от работы — это когда ты в потоке. Это когда сииидишь себе и делаешь штукенцию. И так её повернёшь, и эдак, и никто тебя не трогает, и не спрашивает, сколько процентов уже готово, и главное ты сам у себя это не спрашиваешь. Ты просто знаешь, кому она нужна и зачем, и ты её делаешь как-то, как ты сам хочешь.

И вот мне кажется, что «быть старым фрилансером» — это иметь возможность работать в потоке. Конечно, старый фрилансер умеет делать и всё остальное. Если надо, он встрепенётся, спроектирует, декомпозирует, раздаст всем по хорошему совету, разрулит конфликт. Но у старого фрилансера есть возможность ничего этого не делать и личное время для медленной работы в удовольствие.

Не знаю, об этом ли ты спрашивал — я как-то на себя больше спроецировал, ну и ладно.

Денис Ломов #1 - о номинации «Агенство года» и процессах.

Креативный директор Red Collar.
http://redcollar.ru/

— Привет, давай начнем. Вы стали первой студией из России, которая выиграла в номинации «Агенство года» по версии CSS Design Awards. Почему так сложилось и что было залогом успеха?

Я сам был удивлен, и до сих пор не могу это осознать. После того, как мы взяли первый «Сайт дня» с нашим сайтом, начали стараться делать на высочайшем уровне для клиентов. И последние 2 года старались не выпускать проходных проектов. В каждый вкладывались по максимуму. За год выиграли 10 наград на CSS Design Awards. Видимо это огромный скачок, и жюри решили что мы достойны называться лучшими в мире по итогам 2017 года.

— Круто ) Что-нибудь изменилось в жизни агенства после?

В жизни агентства пока не знаю, а в моей да. Поскольку это было на праздниках, то после выходных была сложная неделя — меня просто разрывали на всякие интервью, передачи и радио. Ну и вот неделя только закончилась, надеюсь на следующей будет проще. Хочу спокойно поработать 🙂

— Воронеж наверное гордится вами ) А какой может быть твоя следующая цель?

Да, Воронеж гордится! А следующая цель — хочу монетизировать это достижение. Хочу привлекать крупные западные бренды для работы с нами. Ведь когда тебе признали Агентством года, то доверие у клиентов будет больше.

— Желаю удачи! Давай поговорим про процесс. Большинство твоих работ — промо с крутым дизайном и качественной разработкой. Как у тебя происходит процесс поиска дизайн-решения?

Мы собираемся на обсуждение креативной концепции командой, привлекая даже разработчиков. И самое важное, что придумываем концепцию до скетчей и прототипов. Ну а в процессе брейншторма стараемся максимально изящно решить задачу, которая стоит перед сайтом.

— Интересно ) А как ты налаживаешь взаимодействие дизайнеров и разработчиков?
Я пишу в фейсбуке про Creative Frontend Developer. Так вот у нас именно такие. Дизайнер и фронтенд-разработчик совещаются, обсуждают, предлагают решения. Нет такого, что все, что предложил дизайнер должно быть реализовано 1 в 1. От некоторых вещей можно отказаться, а другие изменить. И разработчик часто сам предлагает очень интересные решения, о которых дизайнер и не думал даже. А возможные конфликты между ними решаются арт-директором.

Энтони из UX Movement написал о таком состоянии кнопки как «загрузка».

Его стоит показывать, когда пользователь нажал на кнопку, но система ещё не обработала запрос. Так пользователь понимает, что система работает, и не жмёт на кнопку повторно.

Если между нажатием кнопки и ответом системы проходит больше 2 секунд, показывайте индикатор загрузки:
— Его лучше расположить на кнопке, так как на ней сосредоточено внимание пользователя при нажатии;
— Он не должен менять размер кнопки;
— И не должен перекрывать текст кнопки. Если индикатор не влезает, вся кнопка или её грань может стать индикатором, постепенно заполняясь цветом.

Сама кнопка в состоянии загрузки может выглядеть неактивной (например, полупрозрачной), что логично, так как она заблокирована для нажатий. Но индикатор на ней должен быть виден хорошо.

Чтобы пользователь лучше понимал, что происходит, текст на кнопке можно менять, например: «Отправить» → «Отправка…»

https://ux.pub/v-kakih-sluchayah-neobhodimy-knopki-s-indikatorom-zagruzki/