Прототипирование сложных интерфейсов с точки зрения того, как оптимизировать и учесть всё

Прототипирование сложных интерфейсов с точки зрения того, как оптимизировать и учесть всё

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

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

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

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

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


За 10 лет работы с самыми разными дизайнерами и в самых разных продуктах и проектах я такого подхода не видела ни разу!

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

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

Я считаю, что это полная чушь.
И уровень 99% дизайнеров в России сейчас именно такой — я за красоту, а ты лучше знаешь свой продукт — продумывай всё сам.


В статье (https://bit.ly/2XG2B7V) те критерии качества дизайна интерфейсов, которые я начинала писать здесь.

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

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

О таланте

О таланте

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

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

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

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

Илья Александров написал о дизайне предсерийного прототипа «Симкомата Х».

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

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

Мы провели быстрый „коридорный“ тест этого варианта со случайными людьми на картонном прототипе. Даже тем, кто понимал, что сканер „должен где-то быть“, требовалось визуальное подтверждение, и некоторые пытались заглянуть снизу.

В то же время решения со сканером, направленным вверх, встречаются в природе, например, для сканирования билетов на турникетах. И похоже, они привычны для людей».

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

«Стенки корпуса и стойку сделали с помощью фрезерования из МДФ. Для прототипа этого достаточно, но было понятно, что на серии нужно будет делать из металла».

https://vc.ru/design/80772

Отмена

Из этой заметки вы узнаете, почему кнопка отмены действия не должна иметь цвет.

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

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

Выводы
Делайте кнопку «Отмена» темно-серой, чтобы пользователь воспринимал ее как возврат в безопасную зону, а не призыв к действию. 

Полезная привычка: всегда обьяснять правки

Нет ничего хуже редакторских правок без объяснений.

Лучше всегда рассказывать, что вы там натворили в макетах (или где вы там работаете). Устно или письменно на полях — без разницы. Вот почему это в ваших же интересах:

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

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

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

Короче, объяснения — часть товара, который продаёт редактор.