Возвращение

Всем привет! За время отсутствия я сделал две крайне важные для меня вещи — закончил британку и сменил работу. Этим и была обусловлена пауза на канале, но теперь я полон решительности завершить начатое и рассказать чем закончилась история моего обучения.

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

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

Прежде чем продолжить, для самых искушенных быстрые ссылки на прошлые серии:

Про бриф, особенности бизнес модели и большое легаси профиру — https://t.me/bukhtiyar/88

Дальше история продолжается рассказом о том, как мы примеряли сервис на себя и познали проблему курицы и яйца — https://t.me/bukhtiyar/88

Ну и как же без классической истории поиска решения — взяться за все проблемы сразу, чтобы в итоге найти одну самую большую и важную — https://t.me/bukhtiyar/88

А дальше я начал рассказ о том какие исследования мы провели и какие инсайты получили. Успел затронуть историю нашего заказа качестве клиента профиру, а также о том насколько непросто выманить мастеров для интервью — https://t.me/bukhtiyar/112

Закончилось все на предательском «Про полученные инсайты и конкурентов расскажу завтра.» 😂
Ну и вот спустя два месяца пожалуйста — история про конкурентов.

Вы правы, мало кто пройдет по ссылкам, поэтому вот, совсем краткий синопсис предыдущих серий:

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

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

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

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

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

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

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

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

Отмена

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

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

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

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

Командообразование

В итоге, Саша Мемус провел с нами всего два занятия в этом семестре, и все его внимание было посвящено сплочению ребят внутри команды.

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

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

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

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

С каждой новой итерацией мы менялись ролями внутри команды и брифами с другими командами. Чтобы мы не расплавлялись Саша закручивал гайки: сначала на работу отвели 7 минут, потом урезали речь менеджера на защите до 3 предложений, а в самом конце от начала работы до презентации прошло всего три минуты.

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

Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

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

Комментарий — элемент хаоса. Но с ним система устойчивее.

Адам Сильвер написал о всплывающих подсказках (tooltip).

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

Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).

Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.

https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/