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

22 апреля в рамках UX-Марафона пройдёт онлайн-конференция «Грабли и кейсы UX-дизайнера», на которой смелые дизайнеры и проектировщики расскажут о самых страшных фейлах и факапах в своей практике. В числе спикеров — Алексей Бородкин, Product Lead компании Ozon, глава Гильдии вольных проектировщиков и автор ТГ-канала Who_X. Сегодня мы хотим познакомить вас с подборкой провальных кейсов по созданию прототипа из доклада Алексея на нашей онлайн-конференции «7 навыков UX-проектировщика».

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

Кейс 1. Гордыня

Заказчику нужен был сайт, посвящённый (условно) яхтингу. Он очень хорошо и подробно рассказал о своём проекте, по итогам встречи записали требования, составили техническое задание и передали дизайнеру. Но когда заказчик увидел готовый дизайн-макет, выяснилось, что он «ожидал не то». Дизайн отвечал всем зафиксированным требованиям, но совершенно не соответствовал представлениям клиента о результате работы! Случилось самое страшное — разрыв ожиданий.

Почему так вышло? Дело в том, что прототип — это в первую очередь отличный инструмент по подготовке клиента к тому, что он увидит на дизайне. Здесь этого этапа не было. И вот, пока дизайнер рисовал, а команда воодушевленно подсчитывала будущие прибыли — клиент сидел и фантазировал. Он нафантазировал себе некий классный проект, и когда дизайнер показал ему что-то совершенно другое — заказчик был разочарован и зол.

В итоге денег команда не получила, дизайнер был демотивирован, клиент — разгневан. Этот случай научил двум важным вещам: во-первых, прототипы нужны; во-вторых, — прототипы нужно показывать всем участникам процесса.

Кейс 2. Жадность

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

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

Кейс 3. Лень

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

Результат показали представителю компании-заказчика, подробно рассказали, что к чему, и всё было замечательно, пока через три месяца этот человек не уволился из компании. Его преемник открыл прототип и сказал — ребята, вы работаете над этим три месяца, но я ничего не понял! И снова пришлось тратить ресурсы на то, чтобы довести прототип до ума.

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

Из этого следует два вывода:

• прототип должен быть наглядным, то есть, говорить сам за себя;
• прототип должен быть опрятным.

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

Кейс 4. Беспечность

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

Клиент, вне себя от восторга, попросил прототип на денёк, чтобы изучить его более детально. А на следующий день он пришёл и попросил внести одну-единственную правку… но эта правка переворачивала весь проект с ног на голову. Чтобы её внести, нужно было переосмыслить и перерисовать 70% спроектированных экранов. В итоге это вылилось в месяц работы проектировщика.

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

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

Кейс 5. Тщеславие, или Проигранный тендер

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

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

Результат клиентам не понравился. Претензий было две: делали слишком долго и «прототип у вас некрасивый». А всё потому, что в своём стремлении сделать ещё круче команда вышла за границы прототипа, но так и не дошла до дизайна. Получился довольно уродливый «недодизайн» или непонятный «перепрототип». Тендер был со свистом проигран, заказчики ушли к конкурентам.

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

Выводы

1. Прототип должен быть, он реально облегчает восприятие.
2. Прототип выполняет свою чёткую задачу; клиент не должен воспринимать его с точки зрения стиля.
3. Прототипу должны предшествовать аналитика и архитектура.
4. Прототип должен выглядеть опрятно и солидно.

***

Полностью посмотреть выступление Алексея Бородкина можно в разделе «Доклады». А 22 апреля глава Гильдии вольных проектировщиков выступит с новым остроумным и полезным докладом «Доводим UX-специалиста до Кондратия вместе!» на нашей новой онлайн-конференции.