Три правила организации процесса дизайна

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

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

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

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

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

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

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

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

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

Шейн Дойл написал о неидеальных состояниях интерфейса.

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

  1. Пустое: контент ещё не добавлен, нулевые результаты поиска, пользователь удалил контент.
  2. Загрузка: когда загружается контент или выполняется какое-то действие. Важно донести до пользователя, что программа не зависла.
  3. Частичная наполненность: когда есть только часть контента. Подумайте, как помочь пользователю сделать так, чтобы получить идеальное состояние.
  4. Неидеальное: слишком длинный или короткий текст, изображения в неправильном формате или отсутствуют, нет части контента. Пользователь не должен думать, что программа сломалась.
  5. Интерактивное: фокус на элементе, заполнение поля и другие изменения интерфейса после взаимодействия с пользователем.
  6. Ошибка: нет подключения к сети, пользователь сделал что-то не то, системная ошибка. Важно, чтобы пользователь понимал суть ошибки и что ему делать.
  7. Выполнение действия: когда пользователь справился со своей задачей. Состояние может отличаться для разных пользовательских задач.

https://ux.pub/proektirovanie-razlichnyh-sostoyaniy-interfeysa/

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

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

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

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

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

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

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

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

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

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

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

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

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

Нашла интервью (https://www.thatexplainsthings.com/the-invisible-voice/) о нейтральном голосе с Сарой Ричардз. Сара руководила контент-дизайном gov.uk, сайта правительства Великобритании. Интервью вот о чем:

«Нейтрально» — хорошее описание стиля gov.uk. Правительству легко звучать снисходительно или покровительственно, этого важно было избежать. Никто не приходит на сайт правительства, чтобы вдохновиться: это почти неприятность — здесь приходится платить деньги или разбираться с неинтересными делами. Нужно было как можно незаметнее и дать посетителям выполнить их задачи, не пытаясь превратить это в приятное занятие и не давая советы.

Команда никогда не писала «для всех». При том, что аудитория всего сайта — миллионы, аудитория каждой странички достаточно узкая. Вы не знаете свою аудиторию, если думаете, что пишете для всех.

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

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

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