{"id":13637,"url":"\/distributions\/13637\/click?bit=1&hash=6eb6f4cc0fd514248f67334eed9cf9b381eca4ced68925ecf0d4e37273ec5a7a","title":"Ozon \u0440\u0430\u0437\u0432\u0435\u043d\u0447\u0438\u0432\u0430\u0435\u0442 \u043c\u0438\u0444\u044b \u043e \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0445 \u0440\u0430\u0441\u043f\u0440\u043e\u0434\u0430\u0436\u0430\u0445","buttonText":"\u041f\u043e\u043a\u0430\u0436\u0438\u0442\u0435","imageUuid":"7d00f3f0-9073-5cd7-b901-ee3a06a62041","isPaidAndBannersEnabled":false}
Дизайн
Ensi by Greensight

Аналитика для дизайнера. 5 вопросов про ограничения

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

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

Где границы нашего проекта?

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

В качестве примера приведу наши идеи для сайта https://www.tmktools.ru/. В 2017 году нам показалось хорошей идеей дать себе волю и придумать для интернет-магазина инструментов «игру» на 404 странице, анимированную корпоративную газету, модно раскрывающееся меню и т.д. Стоит ли говорить, что из-за этого увеличились сроки разработки и понадобились дополнительные ресурсы. Менеджер и разработчики не были нам за это благодарны.

Какой бизнес-процесс мы реализуем?

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

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

Какие системы будут участвовать в этом процессе?

Процессы так или иначе реализуются с помощью IT-систем. Под IT-системой можно иметь в виду широчайший спектр решений: управление публичной частью сайта (CMS), взаимодействие с данными пользователей (CRM), управление товарным контентом (PIM), управление данными о товарах, остатках и доставках (ERP и WMS) и так далее.

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

Например, не все платформы для ecommerce «из коробки» поддерживают поисковые подсказки для пользователей.

Как это работает сейчас?

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

В качестве примера можно привести желание сделать заполнение пользовательских данных более юиксовым: объединить три отдельных поля ФИО в одно и сделать отчество необязательным. Может оказаться так, что в текущей модели данных ФИО — три разных поля, а отчество обязательно для заполнения. Тогда нужно понять — меняем модель данных под новый интерфейс, разбиваем ФИО на три поля и обрабатываем пустое отчество или делаем что-то еще.

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

Можем ли мы так сделать?

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

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

Автор материала: Мария Созонтова

0
Комментарии
Читать все 0 комментариев
null