Александр Овчаренко написал, почему работа дизайнером несовместима с чёткими формулировками.

Деятельность по достижению целей сводится к решению задач и решению проблем.

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

Решить проблему — достичь цели при условии, что путь решения не известен, либо конечная точка не понятна или их множество, а может её и нет вообще.

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

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

Почти любая трудовая деятельность сочетает в себе и проблемный, и задачный подходы, отличия лишь в их соотношениях и ожиданиях.

Дизайн и искусство работают с концепциями и их реализацией в конечном продукте или произведении. Обе деятельности сочетают проблемный подход.

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

https://9dots.ru/2020/05/12/мутная-суть-дизайна/

Евгений Игнашов написал для начинающих об этапе анализа, который идёт перед проектированием интерфейса.

— Что надо спросить у заказчика;
— Какие показатели посмотреть в Яндекс Метрике (если есть);
— Как составить карточку пользователя и описать сценарий;
— Что смотреть у конкурентов;
— Две карты интерфейса: как сейчас (если есть) и как надо;
— Как подбирать примеры стилистики.

«При анализе конкурентов выписываю только то, что можно у них почерпнуть. Нет смысла выписывать слабые стороны. Клиенты с небольшой иронией в голосе говорили что-то вроде: „А, ну нормально. Просто взял, что увидел у кого-то, и к нам применяешь“. После этого я специально в презентацию добавил фразу „Можно почерпнуть у конкурентов“, сходу говоря, что если надо, то именно это я и возьму, не стесняясь».

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

https://habr.com/ru/post/500796/

Михаил Кравченко написал о создании интерфейса для игры.

Обзорно рассмотрел шаги:
— Описание проблемы;
— Работа с референсами;
— Пользовательский сценарий;
— Согласование с командой (особенно важно в самом начале, посмотрите примеры обратной связи от команды);
— Набросок структуры интерфейса;
— Создание и тестирование прототипа (желательно, если есть время);
— Оформление интерфейса, сбор из UI Kit’а;
— Подготовка материалов для программистов;
— Контроль качества сборки;
— Тестирование на игроках.

Если UI Kit’а нет, то перед оформлением интерфейса надо сделать:
— Визуальный стиль интерфейса под сеттинг игры;
— Работа с референсами визуального стиля;
— Наброски визуального стиля интерфейса;
— Чистовая отрисовка интерфейса;
— Сборка UI Kit’а.

Есть примеры артефактов.

«Хороший пример соответствия оформления интерфейса сеттингу игры в StarCraft II. Когда играем за людей, интерфейс состоит из металлических панелей, пластин, проводов и заклёпок. Когда играем за зергов, интерфейс представляет собой аморфную биомассу с прожилками из когтей, хитиновых пластин и подобного».

https://habr.com/ru/post/498600/

Павел Шерер написал об учёте требований информационной безопасности при проектировании интерфейса. Например:

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

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

Для предотвращения этого достаточно сделать ещё одну ветку сценария и отрисовать ещё один типовой макет. Через сутки мы деактивируем ссылку из письма с восстановлением доступа. Дизайнер собирает один макет, на котором показывает сообщение типа «Ссылка устарела».

Пользователь даже не заметит изменений — чаще всего ссылка используется в первые несколько минут после запроса.

https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ebea1e37f5192548fb25a63

Дмитрий Ваницкий поделился краткими выводами из монументальной «Биологии добра и зла» Роберта Сапольски.

Роберт рассуждает о природе наших самых хороших и плохих поступков. Труд охватывает все ныне известные факторы влияния на наши решения: от эволюционных и генетических до культурных и социальных. Всё это с подтверждениями в виде сотен экспериментов.

Книгу можно рекомендовать всем, кто увлекается или хочет увлечься нейробиологической основой нашей модели принятия решений.

«Давайте представим, что вы участвуете в эксперименте по определению длины отрезков вместе с другими испытуемыми. Всё идёт хорошо, пока вам не показывают отрезки, 1-й из которых явно длиннее. Вы думаете: «Изи!». Но вот все остальные говорят, что длиннее 2-й отрезок. Настаёт ваша очередь. Что вы сделаете? Пойдёте против большинства или дадите заведомо неверный ответ, чтобы не выделяться? Я скажу, что с вероятностью 75% — второе.

Социальный конформизм, обнаруженный в экспериментах Аша с принятием мнения большинства, наглядно демонстрирует нашу жажду принадлежности».

https://medium.com/design-spot/e4b9bcd9d03a

Автомобильный дизайнер Артём Степанов рассказал об интерфейсах систем автомобиля.

Мы сейчас на этапе развития автомобильных технологий «Это ужасно, но все привыкли» и тихонечко его перескакиваем. 80% автомобилистов пользуются 10% функций автомобиля.

Из-за унификации в пределах больших концернов (например, Volkswagen-Audi Group) владельцы дорогих машин садятся на кожаные сидения, но видят те же панели (например, управления кондиционером), что и владельцы машин в 2 раза дешевле.

Маркетологи тоже думают, как сделать круто, ведь нельзя же покупателям новых моделей предлагать старые добрые крутилки. Так в БМВ 7-й серии мультимедиа можно управлять 5 способами:
— Крутилка на передней консоли;
— Касание экрана;
— Тач-панель на крутилке (вместо использования экранной клавиатуры можно рисовать буквы);
— Жесты рукой в воздухе (изменение громкости, переключение каналов);
— Голос.

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

https://www.youtube.com/watch?v=DR9a9t-cGug

Николай Бабич написал, как сообщить пользователю о состоянии системы.

— Выделить в меню раздел, в котором пользователь сейчас находится;
— Показать количество шагов, которое необходимо для завершения процедуры;
— Обратная связь на действия пользователя — нажатия на кнопки и переключатели;
— Показать индикатор загрузки; с прогресс-баром, если операция занимает больше 10 секунд;
— Анимированные экраны-заставки для мобильных приложений;
— Отобразить скелет страницы, пока загружается её содержимое (паттерн skeleton page/screen);
— Уведомления об изменениях в системе;
— Моментальная обратная связь о неправильно заполненном поле.

https://ux.pub/4-metoda-vizualnogo-fidbeka-v-interfeysah/

Матвей Правосудов написал, зачем дизайнеру уметь кодить.

«Когда работаешь в режиме концептов на дрибл, не видишь материала: делаешь статичные или анимированные картинки с летающими конями, параллаксом и эффектами. Работа уходит на сайт, собирает лайки и комменты и погибает в пучине одинаковых дрибловских шотов.

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

Так вот, понимание принципов работы технологий (HTML/CSS/JS/API для веба, Swift для iOS и Kotlin/Java для Android) помогает сразу делать макеты более жизнеспособными, а иногда, при возникающих сложностях у разработчиков, ухищряться и выдавать оптимизированное решение, которое достигает того же эффекта, но заметно дешевле».

https://designpub.ru/f728cb8c1e39

Пол Боаг написал, почему тёмные паттерны — плохой выбор для компании, играющей в долгую.

Раньше потребители в основном не знали, что ими манипулируют, но всё изменилось. СМИ пишут о манипуляциях, пользователи становятся опытнее, чаще видят тёмные паттерны, и их это раздражает. Потребители избалованы выбором и легко уходят к конкурентам.

Недовольные клиенты делятся своими эмоциями: отзывы остаются в интернете навсегда, а отдельные истории становятся вирусными (Хасан Сайед и British Airways).

Обманутые клиенты могут создавать группы для защиты своих интересов. Иногда их аргументы доходят до государства, и оно включает регулирование (Великобритания и рынок онлайн-бронирования отелей).

Всё это в долгосрочной перспективе уменьшает выручку, количество повторных заказов, затрудняет привлечение новых клиентов.

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

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

https://ux.pub/kak-ubedit-drugih-ne-ispolzovat-temnye-patterny/

Павел Шерер написал о создании концепции — предварительном этапе перед проектированием.

Концепция предполагает базовые исследования и аналитику уже на самом старте проектного процесса. Её задачи:

1. Сформировать у команды единую картинку продукта. Сильно влияет на стабильность дальнейшей работы над ним.

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

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

Сколько усилий уйдёт на создание внутренней арбитражной системы? При этом она не является функциональным ядром сервиса, и стартап спокойно запустится без неё. Умный проектировщик кратко опишет арбитраж как „следующие этапы развития“, предложит ввести рейтинг, а спорные вопросы первое время решать через поддержку».

3. Предусмотреть базовые риски, описать векторы развития, примерно представить, что может воспрепятствовать развитию продукта, — и подумать, как обойти такие препятствия.

4. Первично оценить проект и проектирование. Не придётся в середине проектирования столкнуться с тем, что продукт нежизнеспособен без какой-нибудь его части, а стоимость её создания сопоставима со всеми остальными работами.

— Задачи концепции: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed3f26b709fb133f9734d4a
— Состав и структура: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed67a182cf6c679060463e3

Константин Солодянников законспектировал книгу «Спроси маму».

«Ненужная информация бывает такой:
— Комплименты;
— Болтовня (общие фразы, гипотетические рассуждения, разговоры о будущем);
— Идеи.

Любой из пунктов — признак того, что мы получаем социально-желаемые ответы».

«Важные вопросы — неудобные. Типа, когда думаешь, да как я это вообще спрошу. Вдруг там что-то такое страшное скажут, и всё пропало, паника. Лучше не спрошу.

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

https://www.it-agency.ru/academy/summary-the-mom-test/

Тарас Бакусевич написал о дизайне текстовых полей и форм. Вот некоторые из его рекомендаций (не самые распространённые):

— Подчёркнутое поле ввода — не лучший стиль для текстового поля. Он распространился с появлением Material Design, но потом Гугл от него отказался;
— Длина поля должна быть пропорциональна вводимой информации. Формы с такими полями будут менее аккуратными, но более удобными;
— Заполняйте поля адекватными значениями по умолчанию, но только не при выборе размера или цвета товара;
— Отображайте полезные подсказки, которые помогут принять правильное решение или избежать ошибки. Например, показывайте баланс при совершении платежа;
— Не отображайте сообщение о некорректном заполнении поля, пока пользователь не закончил ввод;
— Иногда можно добавить индикатор корректного заполнения поля. Пользователь будет видеть прогресс и радоваться позитивной обратной связи;
— Если форма разделена на несколько шагов, показывайте пользователю ключевую информацию с уже пройденных шагов;
— Не отображайте такие формы в маленьких всплывающих окнах.

https://ux.pub/podrobnoe-rukovodstvo-po-dizaynu-tekstovyh-poley-i-form/

Кирилл Славецкий написал, как слепота невнимания и слепота к изменениям влияют на взаимодействие с интерфейсом и как с ними бороться.

Между этими эффектами есть разница. Способы борьбы с ними различаются и иногда противоречат друг другу.

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

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

Уровень подготовки пользователя на эффект особо не влияет.

Чем вызывается: объект малозаметен, находится далеко от фокуса внимания; наблюдатель не знаком с объектом, не ожидает его увидеть в этом контексте, невнимателен (например, устал), сильно нагружен текущей задачей.

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

В интерфейсе так можно не заметить изменений, отвлёкшись на другую задачу, переходя с экрана на экран, переводя взгляд с одной части экрана на другую, моргая.

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

https://medium.com/slavetski/e18ff53bace5

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

Один из советов — сбивайте ваших коллег с толку профессиональным жаргоном.

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

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

Запишите несколько жаргонизмов:
— Аффорданс;
— Карта эмпатии;
— Карточная сортировка — как ни странно, означает именно сортировку карт;
— MVP — это используют менеджеры проектов, чтобы уничтожить ваш дизайн;
— Карта пользовательского пути…

Почему мы так повернулись на этих картах, может быть, мы потерялись?»

https://www.youtube.com/watch?v=CT1PE5FruNM

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

Процесс создания цифровых продуктов в корне отличается от любой традиционной деятельности. Успех проекта зависит от того, насколько удастся побороть фактор неопределённости.

В главе разбираются источники неопределённости и подходы, с помощью которых её можно контролировать. Текст можно показывать заказчикам, чтобы объяснить, как лучше строить работу и избежать традиционных проблем.

«Необходимо перестать считать всех, кто работает в ИТ-отрасли, „программистами“. Это всё равно, что считать всех, кто занимается возведением зданий, „строителями“. Также необходимо отказаться от мысли, что программисты отличаются друг от друга „сообразительностью“ и при её достаточном уровне способны решить любые задачи. И наконец, не стоит рассчитывать, что программистам можно поставить задачу, просто „объяснив на пальцах“».

Почему сложную систему нельзя построить с нуля: «Компаниям стоит смотреть на цифровые сервисы как на истории, которые они рассказывают своим клиентам и сотрудникам. А хорошие истории невозможно быстро придумать, к тому же не узнав поближе тех, кому они адресованы. Для этого нужно время, внимательное отношение и диалог друг с другом».

https://mityakin.ru/paranoid-method-book-03

Некоторые тезисы и цитаты из 3-й главы книги Вадима Митякина, о которой написал ранее:

— Причины провала цифрового проекта не всегда очевидны.
— Бизнес уверен, что привлёк плохих разработчиков, а они уверены, что бизнес нечётко поставил задачи, выделил мало времени и денег. Все они отчасти правы.
— В начале, когда о проекте известно меньше всего, проблематично спланировать работы и рассчитать бюджет.
— Создание цифровых продуктов отличается от традиционных услуг степенью неопределённости.
— В начале есть только ожидание того, как проект повлияет на бизнес, и иногда смутные образы интерфейса.
— Техническое задание не вносит ясности, так как обычно оно таковым не является.
— Всё, что произойдёт в проекте, зависит от его участников и их способности разобраться, что же нужно получить в итоге.
— Создание нового продукта — создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).
— Ключевой вопрос — кто платит за риск.
— Закон Галла: «Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все эти связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».
— Популярный приём переноса риска на бизнес — продавать процесс, а не результат.
— Гибкие методологии в основном не снижают неопределённость, а переносят риск на бизнес.
— В проектах надо снижать или локализовывать неопределённость.
— Она исходит из содержания задач (например, исследовательские задачи, не гарантирующие решения) и организационной стороны проекта (от получения требований до поиска подходящих исполнителей).
— Хорошо, если компании подходит типовой продукт. Плохо, если её бизнес-модель отличается. Тип проекта меняется с «Седины» на «Мозги», и процесс становится непредсказуемым.
— Иногда на вопрос о стоимости нельзя ответить из-за природы процесса создания сложных систем.
— Компания не может постоянно менять модель работы и радикально обновлять используемые инструменты. Проект типа «Мозги» или «Седина» должен завершиться и уступить место проектам типа «Процедуры».
— Ложные цели приводят к запуску проекта неподходящего типа: прорывной продукт вместо доработки существующих инструментов и наоборот.
— Чтобы запустить онлайн-продажи, надо пересмотреть почти все составляющие существующей бизнес-модели. Разработчики веб-сайта не могут решить эти вопросы.
— Для проектов разного типа процедура выбора исполнителей должна отличаться принципиально.
— Если это проект типа «Мозги», бизнес должен заинтересовать им потенциальных исполнителей.
— Если это «Процедуры», обязательно наличие подробного технического задания.
— Надо не только привлекать правильных специалистов, но и задавать правила и строить работу так, чтобы у каждого участника был мотив и возможность реализовать свой потенциал.
— Руководители должны участвовать в принятии важных решений на протяжении всего проекта, чтобы неопределённость не накапливалась скрытно.
— Опасный источник неопределённости — отсутствие сильного лидера проекта.
— При переходе незримой границы сложности невозможно создать продукт без предварительного проектирования.
— Начинающие разработчики и просто дилетанты, современная модель обучения, готовящая узких специалистов, непонимание, чем является проектирование, — всё это подпитывает скептическое отношение к проектной документации.
— В результате современные методы создания продуктов больше напоминают модные диеты, основанные на предрассудках, чем полноценные системы питания.
— Чем тщательнее к своей работе подходят проектировщики интерфейсов, тем чаще сталкиваются с тем, что реализовать всё задуманное не получается.
— Для кого-то это может показаться странным, но проектирование сокращает бюджет и сроки проекта.

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

Usethics написали о частых ошибках при проектировании интерфейса терминала. Вот часть из них:

1. Тач-панель несоразмерна пользователю. Если одна часть большой тач-панели находится на уровне глаз, другая её часть будет на уровне колен. Пользователь её не увидит или увидит искажённой. Лучше разместить там наименее важную информацию, например, баннеры. Проверяйте прототипы и макеты на реальном устройстве.

3. Не обеспечена безопасность личных данных. Вводить данные карты или номер телефона не комфортно, если за спиной — посторонние. Запрашивайте как можно меньше данных, по умолчанию маскируйте то, что пользователь ввёл (например, часть номера карты), проработайте процесс завершения сеанса (кнопка «Выйти» и автоматический выход по истечению времени).

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

6. Сценарий прерывается. Например, в торговом центре пользователь построил маршрут до магазина, но не может сбросить его себе на телефон и поэтому фотографирует. Продумывайте такие моменты. Можно показать QR-код со ссылкой на страницу с этим маршрутом.

7. Нет приглашения к взаимодействию. Люди воспринимают тач-панель как рекламный стенд. Напишите, что можно с её помощью сделать, покажите строку поиска.

https://medium.com/usethics-doc/6ae5f09169d6

Анастасия Куриленко написала о локализации мобильных приложений, то есть переводе и адаптации для других рынков.

Исследуйте рынок, для которого собираетесь добавить локаль, в том числе местных конкурентов (успешных и провалившихся). Убедитесь, что ваш продукт хорошо там примут, и инвестиции в локализацию окупятся. Возможно, придётся изменить дизайн и платные функции.

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

Обратите внимание на культурные различия. Могут отличаться термины, шутки, цветовая гамма, числа, меры и целые изображения.

Перед началом перевода создайте глоссарий — список терминов и имён, которые должны остаться неизменными в процессе локализации.

Есть системы управления переводами вроде Crowdin и GitLocalize. Например, они помогают находить повторяющиеся и частично совпадающие тексты и обеспечивать стопроцентное единообразие.

При создании элементов интерфейса имеет смысл закладывать минимум 30% дополнительного пространства для других языков. Особенно актуально для коротких строк: пунктов меню, форм и так далее.

Например, немецкая версия текста в среднем на 30% длиннее английской, а русская — на 10%. То же самое обычно справедливо для арабской локализации. Традиционные китайские иероглифы требуют на 30% меньше места, чем латинский алфавит.

https://habr.com/ru/company/alconost/blog/507734/

Александр Всехвальнов написал, как устроен отбор дизайнеров в Ситимобиле. Несколько интересных моментов:

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

По резюме можно проследить, как развивалась карьера, и предположить, насколько кандидат амбициозен, как быстро хочет развиваться, какие цели ставит. Не стоит делать поспешные выводы по резюме, но если появились вопросы, их стоит задать.

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

Для тестового задания нет ограничений по времени для кандидата. У всех есть работа, личные дела, семья. Я прошу человека самостоятельно оценить срок выполнения тестового. Именно в этот день я и буду ожидать результат. Здесь проверяется очень многое: мотивация, ответственность, умение соблюдать сроки.

https://habr.com/ru/company/citymobil/blog/499882/

Ирина Красильникова написала о дизайне для детей.

— Для ребёнка неочевидна связь между иконкой-гамбургером и меню. Если иконка необходима, тестируйте её понятность;
— Говорите на одном языке: «Придумайте имя пользователя» → «Как тебя зовут?»;
— У детей нет баннерной слепоты. Часто они не отличают рекламу от содержимого продукта и отвлекаются. Если у вас образовательный продукт, откажитесь от баннеров в учебном интерфейсе;
— Дети ожидают немедленной реакции на любое своё действие. Хвалите после каждого правильного ответа;
— Ребёнок не понимает абстракций, используйте в дизайне узнаваемые предметы из реальной жизни. Чем реалистичнее картинка, тем лучше;
— Несколько однотипных заданий подряд могут демотивировать. Чередуйте типы активности, закладывайте время на отдых;
— Восприятие в 6 и 10 лет сильно отличается. Для 6-летних контент более мультяшный и игровой, с озвучкой для тех, кто не умеет читать. Для 10-летних — более сдержанный;
— Лучше сделать проще, но быстрее и надёжнее. Подростков сильно раздражают любые баги и зависания;
— Не забывайте об экстремальных пользователях: детях не читающих, с недостаточным опытом взаимодействия с компьютером, с низкой концентрацией внимания, с нарушениями зрения.

#young