Евген Эсану прочитал обновлённую версию «Не заставляйте меня думать» Стива Круга и сформулировал рекомендации, которые могут пригодиться даже опытным дизайнерам.

1. Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова.
2. Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные.
3. Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение.
4. Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1.
5. Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться.
6. Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого.
7. Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт.
8. Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях.
9. Учитесь задавать правильные вопросы.
10. Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».

В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь:
— Перевод: https://usabilitylab.ru/blog/10-melkih-oshibok-v-dizajne-kotorye-my-po-prezhnemu-sovershaem/
— Оригинал: https://uxplanet.org/1cd5f60bc708

С вялым заказчиком каши не сваришь

Иногда пишу зарисовки из проектной деятельности. Вот и сегодня такая зарисовка.

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

Если вам говорят: "С вами будет работать Ира, она в курсе всех процессов, а если надо – будет привлекать ещё кого-то!", то есть повод насторожиться. У заказчика должна быть команда, в которой Ира руководитель проекта, тогда норм.

Из жизни. На заре моего проектного менеджмента (в 2008-2009 году) у меня был проект внедрения системы автоматизации в транспортно-логистической компании. 

Большой проект, большое ТЗ. И один человек на стороне заказчика, который "активно" занимается проектом.

Этот один человек всегда загружен (работу же работать надо), поэтому обратная связь по релизам/вопросам идёт с задержками.

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

Мы сделали 30% проекта, потом была долгая пауза, потом попытка воскресить проект, потом заказчик обанкротился.

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

Заказчика в тонусе держать надо, а то на шею сядете и соскользнёте с неё очень быстро.

Немного о том, есть ли жизнь после британки

Как я говорил ранее, я уже больше трех месяцев работаю в hh.ru. За это время мы неплохо поработали и полностью изменили навигацию в приложении. Теперь там удобный таббар (ура). На протяжении нескольких месяцев мы отбирали разные варианты, спорили, тестировали. В итоге остановились на компромиссном решении, со своими плюсами и минусами.

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

Удобная навигация — залог счастливого пользователя, поэтому особенно хочется похвалить нашу версию под android, далеко не каждый продукт может похвастаться столь продуманной навигацией под эту платформу (привет, системная кнопка «назад»).
Также крайне важно не столько сделать классно, сколько донести до пользователя о новой пользе, поэтому мы стали разными способами рассказывать о новых функциях (как, например эта сторис👇).

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

UX-редактор как пчёлка

UX-редактор как пчёлка

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

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

Нормально ли это? Да, нормально! Не нужно бояться сказать дизайнеру: «А знаешь, что они делают по-другому?». Если вы дизайнер — не нужно бояться ничего.

Принесла вам новый обзор на книжку Blitzscaling от Reid Hoffman, основателя LinkedIn.

Reid очень крутой и умный, у него отличнейший подкаст Masters of Scale, и на книгу у меня были высокие надежды.

Ну что сказать… Начали за здравие, кончили за упокой. Основная мысль довольно интересная – если хочешь стать глобальным стартапом, то в какой-то момент нужно ставить все на карту и инвестировать в взрывной рост: тогда приходят в действие network и virality effects, которые, в свою очередь, еще больше ускоряют рост и выручку.
С идеей можно, конечно, поспорить: например, Harvard Business Review в последнем выпуске восхваляет стартапы, которые фокусируются на постепенном и контролируемом росте https://hbr.org/2020/03/beyond-silicon-valley (https://hbr.org/2020/03/beyond-silicon-valley), – но о подходе, о котором рассказывает Reid, почитать тоже интересно, тем более, что его использует большинство стартапов в Долине. Понравились примеры с AirBnb и Dropbox.

Про это рассказывается на первых 100 страницах, все остальное (еще 200 страниц) – вода водой. Сначала Рид говорит, как успешно задизайнить бизнес-модель: по сути, это все те же старые-добрые постулаты из книжек 80-х годов про размер рынка, дистрибуцию, высокую маржинальность, (не)возможность масштабирования операционки, product market fit + из относительно новенького network effects. Если с network effects вы раньше не особо встречались, то эта часть, возможно, покажется интересной.

Части 3-6 – такие относительно философские рассуждения на тему, с пересказом идей из других книг или предыдущих глав. Мне очень это все напомнило The Hard thing about hard things https://t.me/proproduct/681 (https://t.me/proproduct/681), где автор под конец уже явно выдавливал из себя главы на немного рандомные темы. Знаю, что обе эти книжки многим нравятся: возможно, если вы заценили The hard thing, Blitzscaling вам тоже зайдет. Как говорится, на вкус и цвет :)

Вот здесь лежат отзывы на другие продуктовые книжки (не поверите, там даже есть позитивные))
https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe (https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe) ^_^

Семантика и синтаксис интерфейса

Семантика — то, как элементы интерфейса сочетаются, группируются и как их воспринимает человек.

Cемантика опирается на ожидания от продукта и привычки. Например, что в форме регистрации есть кнопка «Зарегистрироваться», а в соцсетях — лента новостей.

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

Элементы без текста — чаще всего просто иконки и фреймы. С них не так-то легко считать информацию.

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