Наблюдения

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

Обучение наблюдателей отличается тем, что помимо вводной о проекте к обучению подключается картограф, который подробно объясняет методику наблюдения и принципы работы с картой. Так же, полевиков обучают работе в специальной программе — QGIS.
QGIS — это масштабная открытая геоинформационная система (ГИС), данные которой может использовать любой желающий.

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

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

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

По методологии, на наблюдения выходят обычно 4 полевика. Они работают в разные дни, делается это для того, чтобы каждый из них дал свою оценку и увидел то, что мог не увидеть другой (поэтому так важен опыт и внимательность). Иногда только на четвертом проходе обнаруживается какая-то важная пробема..
Получается, работу наблюдателя можно разделить на две части — работа в поле, где он собирает информацию, и обработка полученной информации за программой.
Благодаря этому, исследователям и аналитикам передается уже готовый проект — файл QGIS, где каждая проблема привязана к координатам, имеет индекс, описание и фотографию. Таким образом, информация уже готова для обработки.

Текстовые поля для Google

Как ребята из команды Material Design пересобрали текстовые поля для Google.
Огромное исследование и куча инсайтов.

Почему поля

Казалось бы, текстовое поле, что думать то? Но не все так просто.

Текстовое поле - один из самых популярных элементов интерфейса. Форма обратной связи, заявки, обязательная информация и т.д. Конверсии, конверсии и еще раз конверсии.

Команда Material Design провели исследование текстовых полей и выяснили, что куча народа, видя поле с чертой и плейсхолдером (серым текстом подсказкой внутри) не понимали, что оно кликабкльное. Как следствие отваливались и не заполняли формы.

Перекладываем на масштаб Google и сразу становятся понятны причины такой дотошности в мелочах. На таком огромном трафике изменение в 1% дает тебе колоссальное бабло.

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

Процесс

Исследование проходило в два этапа:

- сперва участникам оценивали разные варианты дизайна
- потом тюнинг конкретных элементов

Участникам предлагалось взаимодействовать с различными вариантами текстовых полей. Собирались прототипы и задавались уточняющие вопросы. Задействовали 600 человек.

Выводы

Результаты двух исследований показали, что следующие элементы текстовых полей имеют наибольшую ценность:

- Закрытые текстовые поля с прямоугольной формой, лучше, чем те, которые имели подчеркивание в виде линии
- Рамка текстового поля должна быть с полупрозрачной заливкой и нижней линией или без заливки, но с непрозрачной чертой.
- Цветовой контраст линий текстового поля с фоном соответствовал минимальным коэффициентам контрастности 3: 1.
- Текст метки должен быть помещен в пределы рамки текстового поля.
- Текстовые поля должны иметь закругленные углы

После того, как работа была проведена Google обновил у себя все текстовые формы.
Под постом бвдет гифка До и После апдейта.

Брюс Стерлинг о пользе написания дизайн-фантастики

Брюс Стерлинг о пользе написания дизайн-фантастики для дизайна полезных и нужных объектов: «У дизайна мало универсальных научных законов, которые можно было бы предложить нам. Вы можете поразмыслить над многими дизайнерскими текстами, не найдя квадратичного уравнения, тестируемой гипотезы или экспериментального доказательства. Но дизайнерское мышление глубоко и справедливо повлияло на мою научную фантастику.

Я пишу "дизайн-фантастику" уже много лет. Дизайн-фантастика во многом похожа на научную фантастику; на самом деле, нормальному читателю и в голову не приходит разделение этих двух понятий. Основное различие заключается в том, что дизайн-фантастика имеет больше прикладного смысла на странице книги, чем научная фантастика. Научная фантастика хочет использовать величие и достоверность науки для своего собственного фокуса-покуса, но дизайн фантастики может быть более практичным, более полезным. Она приносит в жертву некое чувство магии, но гораздо ближе к пылающему накалу социально-бытового конфликта»

У многих компаний два основателя

У многих компаний два основателя

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

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

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

Еще у меня накопился целый список других проблем, которые мы когда-либо обсуждали с коллегами из других компаний:

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

Знакомо? Ну да, проблемы у всех одинаковые 🙁
Можем разобрать некоторые из этих ситуаций — напишите какие.

Боязнь простых решений

Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.

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

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.

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

В общем, надо стремиться к упрощению.

Dropbox оппубликовала пару новых материалов на своем ресурсе dropbox.design.

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

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

---

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

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

2) Инверсия
Заключается в рассмотрении сценариев ровно противоположных желаемому результату. Формируется образ «антирезультата» и, отталкиваясь от него, формируется путь поиска решения.

3) Лестница абстракций
Используется для поднятия на уровень абстракции выше, чтобы «увидеть лес за деревьями». Начинается с отправной задачи, от которой можно опуститься ниже для детализации, либо подняться выше для поиска альтернативного решения. Для погружения вниз стоит использовать вопрос «Как». Для уход на уровень выше стоит использовать вопрос «Зачем».

Хороший маршрут здесь — подняться от текущей задачи на уровень выше, спросив «зачем», а потом с верхнего уровня пойти в параллельную сторону внизу, спросив «как». (см. примеры в статье)

---

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

Я рекомендую самостоятельно глянуть полную версию статьи, там и с примерами проще понять, о чем речь, и более подробное описание можно почитать — https://dropbox.design/article/mental-models-for-designers