Статьи про UX‑дизайн и не только

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

Альтернативный взгляд на то, как построить работу дизайн-команды. Нормальные люди пишут статьи по мотивам своих выступлений, но мы не из таких. Эта статья противоречит всему тому, что мы рассказывали на прошедшей в конце октября конференции «РИФ Воронеж». На конференции мы обсудили три важные темы: аналитику, планирование работы дизайн-команды и тексты в интерфейсе. Во время доклада слушатели голосовали и выбирали развитие сюжета. Большинство выбрало следующий подход к дизайну. Во-первых, перед началом проектирования нужен основательный аналитический этап...

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

Распространенное заблуждение заказчика — если у нас есть брендбук или UI-kit, дизайнерам будет проще и удобнее разрабатывать интерфейс. Это же почти конструктор. Поэтому ничего не придется разрабатывать с нуля — достаточно собирать страницы из готовых компонентов. Увы, это не так. Парадокс, но правда. Чаще заказчик сперва выбирает фреймворк, а потом — UI-кит. Это логично, потому что кодить продукт сложнее и дороже, чем разрабатывать дизайн. Так что заказчик сперва определяется с подходящей средой разработки, а затем уже смотрит на готовые UI-киты, которые к выбранной среде прилагаются...

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

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