Спрашивали про точки развития для дизайнера.

Спрашивали про точки развития для дизайнера.

Точек роста для дизайнера четыре:

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

— Творческое развитие. Создание индивидуальной творческой траектории независимости и автономной работы. Частный проект в котором дизайнер один на один со своей личной задачей. Создание личного проекта с осознанными и глубокими мотивами самореализации.

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

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

Олег Большаков написал о проектировании системы уведомлений.

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

2. Создайте каркас: первый столбец таблицы — для событий, остальные столбцы — для уведомлений для каждой пары «задействованная роль и канал связи» (пуш-уведомления, письма, персональная лента). Например: «Персональная лента: Исполнитель».

3. Выпишите события, которые могут произойти в рамках процесса. События группируйте по ролям, которые их создают.

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

5. Заполните ячейки с уведомлениями по каждому событию для каждой пары «канал связи: роль». Ставьте прочерк там, где уведомления не будет.

— Старайтесь переиспользовать формулировки;
— Выделяйте переменные среди основного текста;
— Не забывайте о правилах хороших уведомлений: краткость, максимум полезной информации, тон соответствует бренду.

6. Доработайте события. Добавьте формулировки:

— Для массовых событий. Например: «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»;
— Для последовательностей действий. Например: если пользователь удалил одного утверждающего и добавил другого, пишите «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ».

Команда это важно

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

У нас этого не произошло, и на это было две причины.

Первая, и самая большая — я не хотел делиться работой. Я поставил себе глобальную цель использовать учебу как трамплин для раскачки своих навыков (я писал об этом ранее https://t.me/bukhtiyar/152), поэтому мне было в кайф брать на себя как можно больше нагрузки, а не быть менеджером команды. В итоге ребята, увидев мой запал, вместо того, чтобы включиться в конкуренцию за работу над проектом, отступили и дали мне полный карт-бланш.

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

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

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

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

Работа в офисе

Что думал в начале 2019:
- По-настоящему эффективно работать можно только вместе, лицом к лицу с людьми.
- Самые крутые продукты создаются в офисах. Apple, Google, Facebook, Spotify, Tesla, SpaceX, что угодно — у всех есть Главный Офис, где и придумывается всё самое интересное.
- Удалённо работать могут только фрилансеры над отделяемыми неважными задачами.

Что думаю в начале 2020:
- Будущее за распределёнными компаниями и удалённой работой.
- Если у компании несколько офисов — это уже распределённая компания. Если на большинстве встреч ты созваниваешься с людьми по видеосвязи, то не так уж и важно, сидят ли они в другом офисе, в кафе или у себя дома.
- Figma, Slack, Notion, Miro, Loom и многие другие инструменты позволяют работать совместно, как будто вы сидите за соседними столами, даже если на самом деле вы в разных концах Земли.
- В работе бывают моменты, когда вы что-то придумываете, формируете — и тут правда есть ценность в том, чтобы быть физически в одной комнате, рисовать на одной доске. А есть моменты, когда основы придуманы и надо просто сфокусированно фигачить. И вот тут офис нередко может больше мешать, чем помогать.
- Города не резиновые. Если стремиться перевозить высокооплачиваемых айтишников со всего мира в один город, качество жизни там падает для всех. Посмотрите на Сан-Франциско. Дублин, кстати, рискует повторить ту же историю. В будущем всё больше людей будут жить вообще вне городов, потому что для работы достаточно хорошего интернета.

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 эмоций, которые испытываете и подумать, почему именно они выделились сейчас.

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

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

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

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

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

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