Защита

Самое время рассказать пару слов о защите. Вот несколько важных вещей, которые я понял на своем опыте.

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

Второе, нужно максимально упростить повествование не уходя в детали, потому что на выступление дается всего 10-15 минут. Было непросто выбрать логику повествования — когда ты работаешь над проектом полгода, становится сложно выкинуть какие-то части. Но чтобы вас поняли, это необходимо сделать, ваш рассказ должен понять даже ребенок. Мы выбрали одну самую большую боль пользователя и обернули её в историю этого пользователя — от момента, когда он сталкивается с проблемой, до её решения. Одна проблема — одно четкое решение, тогда вас точно услышат и осознанно оценят.

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

По возможности, попробуйте свое выступление в бою с микрофоном и зрителями. Может казаться, что вы супер готовы, знаете тему, у вас классная презентация, но на выступлении вы вдруг обнаруживаете, что микрофон странно передает ваш голос, вы начинаете нервничать и забывать текст. У меня так и случилось на последней защите — я так погрузился в подготовку материалов к презентации, что самонадеянно не репетировал речь, но когда вышел на сцену понял, что это совсем непривычное для меня состояние: микрофон жутко изменял мой голос, он становился гундосым, я начинал нервничать и думаю уже не о презентации, поэтому первые минуты моего выступления ушли на адаптацию к этим неожиданным условиям.

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

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

Перед защитой всегда очень волнуешься, так как относишься к этому со всей серьезностью. Особенно сильно переживаешь за то как тебя оценят. Когда мы готовились к защите, то чувствовали себя аутсайдерами из-за того, что долго и сложно работали над UI. Но по мере подготовки презентации я понимал, что у нас получается очень крепкая история. Так и получилось — пятёрку получили только две команды: мы и qlean. И нас обеих оценили в первую очередь за то, что мы нашли боль и осознанно попытались её решить. Вы можете сами оценить наш кейс, который сверстан практически в точности по сценарию рассказа презентации.

Хочу Молиться На Самостоятельных Людей

Очередной зашквар. Партнёр по бизнесу ругает меня за то что я много делаю руками или переделываю за другими людьми.

Приведу парочку примеров, где для меня было очевидно «хули ты стонешь? пойди и сделай!», а для человека было «а я вот не могу и жду»

Задача: сделать презентацию клиенту
ЦА понятная, есть примеры, структура и часть контента.
Что получаем: набросанные заголовки, бардак и отсутствие оформления, нормального текста.
Что имеем:
— вот преза, я писать текст нормально не могу, может ты его напишешь?
— оформлять я тоже не могу, у нас же куча дизайнеров — давайте им задачу дадим. не вижу смысла это делать мне.
— я сижу без работы два дня и жду от вас действий, что мне делать?

Да ты, сука, сядь и изучи keynote или figma, у тебя есть пример того «как надо» перед глазами, посмотри уроки какие-то. Хули ты сидишь без работы и чего-то ждёшь, если на презе всё завязано?

Мы не корпорация, а студия в 20 человек, ты реально ждёшь чтоб за тебя кто-то хорошо написал текст и подвигал блоки в keynote?

Ещё пример: сделать таблицу проектов, ресурсов и команд в notion, чтоб каждую неделю синхронизироваться.
Что имеем
— Я сделал документ в excel, потому что notion непонятный, мне проще в excell, я так привык.
Всё это плохо грузится, найти в гугл-диксе сложно, потому что база знаний и дашбордов у нас в notion и все там работают.

Давай ещё open office внедрим потому что тебе так привычно? Будем все устанавливать его и страдать каждую неделю, лишь бы тебе удобно было.

Ну и третий: написать инструкцию про внутренний процесс.
Что имеем:
— Я вот вроде написал, но есть моменты, где я не понимаю как написать, потому что я в этих процессах сам не участвовал, это арт-дир делает, поможешь мне — напишешь как надо?

Господи ты боже мой! Подойди к арт-диру и спроси, зачем ты мне пишешь? Я запрещаю тебе с людьми общаться? Привязываю к креслу и рот кляпом затыкаю?

Люди, искусственно создающие себе барьеры — беспомощные люди. Не надо так.

Все ситуации выдуманы, любое совпадение с реальностью случайно 🙂

Текстовые поля для Google

Как ребята из команды Material Design пересобрали текстовые поля для Google.
Огромное исследование и куча инсайтов.

Почему поля

Казалось бы, текстовое поле, что думать то? Но не все так просто.

Текстовое поле - один из самых популярных элементов интерфейса. Форма обратной связи, заявки, обязательная информация и т.д. Конверсии, конверсии и еще раз конверсии.

Команда Material Design провели исследование текстовых полей и выяснили, что куча народа, видя поле с чертой и плейсхолдером (серым текстом подсказкой внутри) не понимали, что оно кликабкльное. Как следствие отваливались и не заполняли формы.

Перекладываем на масштаб Google и сразу становятся понятны причины такой дотошности в мелочах. На таком огромном трафике изменение в 1% дает тебе колоссальное бабло.

Цель состояла в том, чтобы определить, как улучшить текстовое поле. Сделать его заметнее, читабельнее и понятнее – с более четкой целью касания.

Процесс

Исследование проходило в два этапа:

- сперва участникам оценивали разные варианты дизайна
- потом тюнинг конкретных элементов

Участникам предлагалось взаимодействовать с различными вариантами текстовых полей. Собирались прототипы и задавались уточняющие вопросы. Задействовали 600 человек.

Выводы

Результаты двух исследований показали, что следующие элементы текстовых полей имеют наибольшую ценность:

- Закрытые текстовые поля с прямоугольной формой, лучше, чем те, которые имели подчеркивание в виде линии
- Рамка текстового поля должна быть с полупрозрачной заливкой и нижней линией или без заливки, но с непрозрачной чертой.
- Цветовой контраст линий текстового поля с фоном соответствовал минимальным коэффициентам контрастности 3: 1.
- Текст метки должен быть помещен в пределы рамки текстового поля.
- Текстовые поля должны иметь закругленные углы

После того, как работа была проведена Google обновил у себя все текстовые формы.
Под постом бвдет гифка До и После апдейта.

Брюс Стерлинг о пользе написания дизайн-фантастики

Брюс Стерлинг о пользе написания дизайн-фантастики для дизайна полезных и нужных объектов: «У дизайна мало универсальных научных законов, которые можно было бы предложить нам. Вы можете поразмыслить над многими дизайнерскими текстами, не найдя квадратичного уравнения, тестируемой гипотезы или экспериментального доказательства. Но дизайнерское мышление глубоко и справедливо повлияло на мою научную фантастику.

Я пишу "дизайн-фантастику" уже много лет. Дизайн-фантастика во многом похожа на научную фантастику; на самом деле, нормальному читателю и в голову не приходит разделение этих двух понятий. Основное различие заключается в том, что дизайн-фантастика имеет больше прикладного смысла на странице книги, чем научная фантастика. Научная фантастика хочет использовать величие и достоверность науки для своего собственного фокуса-покуса, но дизайн фантастики может быть более практичным, более полезным. Она приносит в жертву некое чувство магии, но гораздо ближе к пылающему накалу социально-бытового конфликта»

Иногда нужно обойти дерево узлов

Например, чтобы найти родительский элемент и заменить его содержимое, или найти соседний элемент и переключить на него фокус.

Для этого есть набор методов:

let el = document.querySelector(".someClass")
el.childNodes // дочерние элементы
el.nextSibling // сосед справа
el.parentNode // родительский элемент

Подробнее в видео: https://youtu.be/MoEWUWIDFDs

И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO


✨Домашнее задание ✨

Взять пример из урока: https://codepen.io/detepr/pen/rQYYbx
1. Посчитать сумму цен всех подарков и вывести её в консоль
2. Отсортировать подарки по цене

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.

Человек, который внутренне уверен в себе и своих знаниях, вряд ли будет когда-нибудь кого-нибудь буллить, так что я бы поставил под сомнение компетентность первого, как разработчика.

Подумайте внимательно, насколько поведение первого программиста совместимо с профессионализмом на работе в вашем представлении? Как далеко он заходит в своём буллинге? Если недалеко (хотя мне сложно такое представить) — отправьте его на месяц или два в отпуск, посмотрите как команда поживёт через него. Если сильно — немедленно увольняйте, иначе второй просто сбежит или, ещё хуже, превратится в фикус, и вы в любом случае останетесь без двух программистов.