Недавно слушала лекцию о производстве кино. В нем еще до ИТ появилось то, что называется раскадровка (storyboard), а мы называем мокапом или каркасом (wireframe). То есть отрисовка каждого кадра в кино, а в нашем случае отрисовка страниц. Оказалось, что сложности эта самая раскадровка создает те же, что и прототипы в разработке. Если она слишком тщательно и красиво отрисована, то отвлекает от смысла кадра и динамики кино. Если слишком точно следовать раскадровке, которая на самом деле не отражает динамики переходов между кадрами, то ничего хорошего не получится.
Ровно так же и с работой ИТ команды. Прототип не может быть основным способом описания ожидаемого решения, самой по себе визуальной модели для этого не достаточно.
В одном из моих первых проектов, по совпадению разных организационных и географических факторов, сбор требований поручили дизайнеру. В качестве описания требований мы получили набор детально отрисованных в MS Visio прототипов со словом storyboard в названии каждого файла. Именно по ним велась разработка. В получившемся продукте полностью отсутствовала передача данных между логическими компонентами системы. То есть можно было ввести данные об объекте «Книга» и указать автора на форме ввода, но потом нельзя увидеть эти данные в списке книг автора или в алфавитном указателе на странице «Библиотека». Визуальная модель никак не передавала связи между объектами данных, вот их и не создали. После нескольких суток подряд переписывания и тестирования этого приложения, я твердо запомнила, что прототип не может претендовать на необходимое и достаточное описание требований.
Красивый прототип не заменит работу профессионального дизайнера. Многие команды не привлекают профессиональных дизайнеров и аналитики стараются восполнить пробел, но лучше много раз подумать браться ли за такую задачу? Сделать дизайн и сделать иллюстрацию к разговору с заказчиком - далеко не одно и то же. Дизайн подразумевает проработку всех элементов интерфейса во всех состояниях или адаптацию существующих дизайн-систем под особенности вашего приложения. Как бы качественно вы ни представили десяток экранов, это не заменит необходимости проработать 3-4 состояния (Default, Hover, Active, Disable) для каждого поля, кнопки и иконки, понять оставшиеся состояния экранов, особенности каждого перехода между страницами и сделать много другой работы. Может получиться, что аналитик покажет клиенту красивую картинку и договорится о реализации, а разработчик окажется перед необходимостью адаптировать картинку во что-то пригодное к реализации: переделывать *.png в *.svg, менять размеры, придумывать внешний вид для разных состояний. Аналитик рискует потратить кучу времени и не услышать благодарностей.
В работе аналитиков случается переоценка возможностей прототипирования. Часто приходится слышать что-то вроде «вот картинку нарисуем и все-все будет понятно». А еще бывает, что аналитику просто интересно рисовать картинки, так как они вызывают положительные эмоции и у него, и у заказчиков. При этом заказчикам нужен продукт, а не только эмоции. Нужно понимать какие вопросы ожидается решить с помощью прототипа и не тратить сил больше, чем требуется. Если аналитик умеет работать в графических редакторах вроде Figma или Sketch, это большой плюс - он быстрее сможет подготовить материалы к обсуждению. Если не умеет, то может обходиться каркасным проектированием (wireframe)
По аналогии с кино, если режиссер кино умеет рисовать, то ему проще набросать эскиз кадра и поставить задачу съемочной команде, а если не умеет, то нарисует как сможет. Кажется, эти рисунки режиссеров называют огурцами 😉
О чем еще подумать при выборе прототипа можно найти в Телеграмм
