Прототипы как предчувствие продукта

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

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

Привет, друзья! Прототипы — это становой хребет продуктового дизайна. Я расскажу, почему мы в команде используем только hi-fi прототипы и отказались от всех прочих.

Ранее мы уже говорили про структуру приложений и определение принципов навигации. Кул. Но что со всем этим делать дальше? Не вопрос! Конечно, нужно разработать прототип. Прототип нужен для раннего тестирования MVP, для снижения рисков проектирования, для проверки пригодности предлагаемых решений, для показа акционерам, для краудфандинга и для экономии времени при общении с разработчиками. Отовсюду мы слышим стоны. Всем нужен прототип. Мы должны протянуть руку помощи, и мы ее протянем.
И тут у меня для вас 2 новости. Сначала хорошая: плохая новость могла бы быть намного хуже…

Проблема выбора

Дело в том, что споры, какой прототип использовать, разгораются с новой силой. И я собираюсь подкинуть дровишек в этот священный костер! В недавно открытом в общий доступ курсе МИТ по пользовательским интерфейсам проповедуют, что прототип вполне можно слепить из говна и палок. Погрузившись в этот курс, можно узнать, например, состав рекомендуемого набора инструментов для бумажного прототипирования, а именно (записывайте): белая доска 11х14”, большие карточки размером 4х6”, клей, белую коррекционную ленту, прозрачную пленку, ручку, ножницы и пр. Стесняюсь спросить: а фломастеры цветные? Или почитайте, например, IBM design thinking. Под музыку из шоу Бенни Хилла идет отлично. Ну, ё-моё! Я не хочу сказать, что там совсем нет полезной обычному проектировщику информации. Отнюдь! Но она там в таких гомеопатических дозах, что эффект от нее тоже гомеопатический. Как говорится, каков стол, таков и стул.
Предлагаю вытрясти двадцатый век из ушей, отказаться от карго-культа и взглянуть на проблему из окопа реального проектирования. Хочу предупредить, что все изложенное отражает наш собственный опыт, который может не совпадать с вашим и ранить чьи-то религиозные чувства. Заранее прошу понять и простить меня. Имеющий уши да услышит хруст шаблона.

Виды прототипов

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

• бумага (бумажные прототипы);
• кликеры (кликабельная последовательность экранов);
• зомби (интерактивные прототипы, созданные при помощи специализированных инструментов типа Axure);
• hi-fi (чистый html+css).

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

Медленно спускаемся с горы

Пара слов про скорость. Ну, чтобы сразу вас остудить и вернуть на грешную землю. Сеть кишит любительскими статьями про «быстрое» прототипирование. На бумаге, на коленке, на смартфоне, в браузере. Главное преимущество, на которое обычно делается упор — время. «Через 5 минут у вас будет работающий прототип вашей гениальной программы!», «Без строчки кода вы получите сложные, анимированные интеракции!». Вот это вот все. Вас ловят на блесну лени и жадности. Вам подсовывают продукцию шит-класса. Вам внедряют мысль, что можно без особых усилий добиться успеха. Люди умудряются даже продавать специальные блокнотики для рисования мобильных приложений. Гхм! Когда я был молодой соплежуй, то верил в эту пургу и, хотя блокнотики не покупал, но прошел полный боли путь, от бумаги до html. Оглядываясь назад, могу сказать: быстро — не значит хорошо. Результат должен быть адекватным задаче, а скорость его получения всегда второстепенна. На кой мне быстро, если неправильно? Особенно, если цикл разработки занимает несколько месяцев. Ну и кроме того, бумага и зомби приносят вред. Почему?

Помните, как в фильме ДМБ:
— Будешь ты, Федя, Бомбой…
— Почему Бомбой?
— Потому что вспыльчивый… Ты, Владик, будешь Штык — потому что стройный… А я буду Пуля — потому что в цель!

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

Не тратьте время на сторонние приложения, лучше инвестируйте его в изучение html. Вы продвинетесь в направлении цели гораздо дальше.

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

Бумага

Начнем с бумаги. Ну и какой может быть вред от бумажного прототипа? Правильно, никакого, потому что бумажный прототип таковым не является. С тем же успехом я могу заявить, что обладаю «нейронным» прототипом — в собственной голове. Прототип, который всегда со мной, аха-ха. У меня их много. Я кручу эти прототипы в голове постоянно — когда иду на горшок утром или гуляя с собакой вечером. А если серьезно, прототип — это то, что работает, что показывают пользователям и на основе чего принимаются решения. Бумага — это эскиз. Бумажные эскизы позволяют зафиксировать идеи, структурировать их и обсудить с коллегой. И только. Показывать их пользователю не стоит. Не-а. Плавали, знаем.

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

Бумага дает ложное ощущение, что решение найдено. Как-то раз мы пытались решить задачу — как показывать табличные данные с разным количеством информации в колонках при недостатке места? Подсмотрели, как это реализовано в Outlook. В 2 минуты набросали эскиз на бумажке. Ну, вот же оно, решение! Быстро провели коридорное тестирование. Успешно!
«Хоп-хей-лала-лей!» — сказали мы с Product Owner и направились было в кассу за премией. Повезло, что решили отрисовать макет в Fireworks, а не сразу верстать.

После нескольких часов работы стало совершенно очевидно, что идея тухлая и не работает в нашем случае. Те же самые люди, которым очень нравилась корявые рукописные эскизы на бумаге (особенно, если они сами черкали поверх), единодушно осудили аккуратный, красивый макет. Было потеряно несколько часов впустую. К сожалению, избежать этого нельзя. Можно сократить потери, если не проводить тестирование бумаги. После пары таких случаев мы твердо решили: место бумаги — в корзине.
Не верьте никому, особенно википедии, которая любит писать красивые статьи про бумажные прототипы, а также про чох, сглаз, хиромантию и уринотерапию.

Просто сделайте себе зарубку — нет никаких бумажных прототипов. Деда Мороза тоже нет. Не-ту. Бумага используется в других местах. Не рассматривайте бумагу, как прототип. Точка.

Кликеры

Берем набор экранов, нарисованных дизайнером, и связываем их друг с другом при помощи image maps. Смотрим в браузере, по-взрослому. Пользы не приносят, но и не особо вредят. Я рассматриваю этот вид как переходный от набора картинок к чистому html. Что они позволяют? Они позволяют сэкономить на текстовых описаниях вида «Эта кнопка ведет на страницу свойств. А если нажать сюда, выскакивает вот это окошко». Можно определить общее количество экранов и проверить, не пересекаются ли сценарии? Но делать это при помощи отрисованных экранов — расточительство. Я через это прошел, и это — не продуктивный путь. Не ходите сюда.



Вернемся к кликерам. Польза от их использования: у «чистых» дизайнеров они снимают страх перед html и приводят в порядок голову. Дизайнеры начинают мыслить, как проектировщики — не одиночными экранами, а сериями. Это окупается очень быстро.
Основная проблема том, что, чаще всего, экраны уже отрисованы. Дизайнер уже инвестировал какое-то время, но вот поддерживать и рифайнить такой прототип обычный человек не сможет. Если, конечно, он не маньяк-педант 80 уровня. Да, можно использовать символы в Fireworks, но очень быстро все захламляется, и абсолютно не стоит времени на поддержку. В общем, через пару итераций система приходит в состояние «Если запить шпроты молоком, то клубнику уже можно и не мыть». Разобраться в таком прототипе становится затруднительно, а чаще всего — невозможно. Отдельный ад, — это когда ты внес изменения в 10 актуальных экранов, а на остальных 40 остался старый вариант (нет времени) и тебя постоянно дергают верстальщики с глупым вопросом: «А почему?..». По кочану!

Поговаривают, что на маке есть некий Sketch в котором все реализовано, как надо. Проверю, когда смогу дотянуться. Эх! Расскажите в комментах про скетч, пожалуйста. Особенно, про чудо-плагины для прототипирования и для работы с данными из json.

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

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

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

Поэтому я недоумеваю, когда hand-sketched кликеры предлагают показывать пользователям. Есть даже специальные шкурки у Expression Blend. Внимание, аргументация следующая: мы проверяем взаимодействие, нам нужно чтобы юзер не обращал внимание на дизайн!
Ну, что тут сказать? Смелость города берет. Но если жизнь и рассудок дороги вам, держитесь подальше от торфяных болот.

Зомби

Выбор специализированных программ для прототипирования огромен. Как говорили в советских магазинах — в ассортименте. Платные и бесплатные. Десктопные и облачные. Монстры и виджеты. Но магазин большой, а товары в нем можно разделить всего на 2 группы: мешки для мусора и мусор для мешков. Вот поверьте!
Это тупиковая ветвь эволюции. Почему? Ограничения архитектуры.
Как владелец взрослого риджбека я знаю, что годовалый щенок гораздо смышлёней годовалого ребенка. Это правда, базара йок. А как быстро растёт! Он легко учится приносить тапочки, бегает за мячиком и хочет вам угодить. Но он никогда не помоет за собой посуду. Never ever, no chance. Ведь вылизанное не считается помытым! Скорее наоборот. Ваш indigo-прототип такой хорошенький, такой дешевый и быстро сделанный. Его так приятно показывать. Но в долгую (а продуктовый дизайн — это игра в долгую) вы проиграете. Упрётесь в стенку. Разумеется, если вам нужен прототип сайта, небольшого приложения, мессенджера — берите зомби и не парьтесь. Но мы же говорим о сложных продуктах, верно?

Кстати, почему зомби? Потому, что «как живой». Потому, что это заразно. И потому, что это труп. Мёртвый труп убитого покойника.

Какие у меня есть аргументы против?
1. Вы не сможете использовать ни строчки кода из вашего прототипа в реальном приложении, несмотря на то, что на выходе генерится html. Двойные затраты времени вам гарантированы.
2. Вы ограничены в своих возможностях теми фичами, которые поддерживает ваш инструмент. Вы смотрите на мир через щелочку Axure или proto.io, и поэтому уже предвзяты в своих прототипах. Решите, нужно ли вам это?
3. Кроме прототипа вам придется писать объемное ТЗ для разработчиков, где подробно описывать детали. Я встречал ТЗ в 60 страниц А4. Ясень-пень, я его не читал, жизнь слишком коротка.
Это отдельный большой геморрой, который способен повлиять на выбор метода прототипирования. Да, периодически появляются плагины-мостики между проектировщиком и разработчиком. Эти плагины вытаскивают информацию из макетов — величины отступов, названия и размер шрифтов, цвета и пр. Но работа с этими плагинами — это дополнительное время, которого хочется избежать. И при изменении какой-либо цифры придется вносить правки в ТЗ. После третьей правки вы узнаете, что ошибкой было думать, будто мягкий человек не может огреть вас доской.
4. Как переносить в продукт микровзаимодействия, анимацию? Скажем, вы 1.5 часа настраивали хитрый bounce для offcanvas панели и куда теперь это все засунуть? Догадаетесь сами?
5. Разработчики не доверяют зомби. В самом деле, кто сказал, что ваш прототип возможно реализовать в продукте при помощи стандартного html? И сколько приседаний для этого придется сделать? Это вносит дополнительное трение в процесс. Хотя, я встречал азартных девелоперов, которые кричали: «Я могу, я знаю, как это сделать!». Встретите таких — носите на руках.
6. Производительность и поддержка. Я немного тестил Axure, indigo Studio, proto.io. Долго не выдерживал. Рано или поздно наступает либо надежная поломка, либо жуткие тормоза.
7. Отсутствие модульности. Можно, конечно, не собирать один супер-пупер-прототип для всех сценариев, а иметь небольшой зоопарк недо-прототипов и ловко жонглировать ими. Но это икотка и трясунец, инструментов для этого нет, никаким ng-include и не пахнет.
8. Время. Вам придется тратить время на изучение интерфейса, тулзов, читать доки и смотреть туторы по сторонним программам. Тратить время, чтобы удаляться от цели! Не проще ли зайти на codeschool и начать движение в верном направлении?
9. Цена. Приличные инструменты стоят денег. Если бюджет ограничен, вам придется довольствоваться урезанными версиями или более простыми open-source решениями.

Отдельно надо напомнить про uncanny valley of prototyping, что можно перевести как зловещая долина. Посмотрите, почему не рекомендуется показывать зомби-прототипы бизнес-ангелу Писькину или инвестбанкиру Какину. Потому, что зомби попадают точно в ущелье, в самую нижнюю точку.

Бывает так, что астма похожа на оргазм, но все понимают разницу, правда?
Hi-fi прототипы «парят» над зловещей долиной по той простой причине, что они похожи не только снаружи. Строго говоря, они и есть продукт. Внутри тот же html, который просто берется и используется «как есть».

Мальчик, водочки принеси, мы домой летим!

Слава богу, всему этому безобразию есть альтернатива. Эволюционное hi-fi прототипирование. Подход, который можно выразить девизом Fake it 'till you make it. В идеале, нужно стремиться к full fidelity прототипу. Full fidelity означает, что невооруженным глазом невозможно отличить прототип от продукта и в нем используется production-ready CSS. Он выглядит, как реальный продукт, он ведет себя, как реальный продукт, он работает в среде реального продукта и он содержит в себе абсолютно все микро- и макровзаимодействия от ховер-эффектов, слайдинга в аккордеонах до анимации смены видов. Единственная фикция — данные. Буржуи называют такие прототипы горизонтальными. В качестве данных используются lorem ipsum, выдуманные тексты (это тренирует воображение), либо яндекс-рефераты. Важно, что данные хранятся в json, а не захардкожены в html. Поэтому, работают все сортировки в таблицах, фильтры, поиски и тп.
Все это абсолютно реально и с каждым днем становится все проще и проще. Уверяю вас.

Чтобы не быть голословным, приведу два скриншота: прототип и реальный билд одного из наших продуктов (Легкий клиент v.7.0), который в настоящее время тестируется и готовится к выпуску. Наши аналитики частенько путают их между собой, что вносит весёлую суматоху в процесс разработки. В общем, всё, как мы любим.


Игра: найди семь отличий на картинках

Такой прототип делается не за полчаса, тут мне возразить нечего. Он «выращивается» из зародыша Denim, и как бонсай постоянно находится в процессе формирования кроны. Тут подрезать корни, там подвязать веточку. Чтобы вы могли оценить затраты времени, скажу, что проработка одного пользовательского сценария (4-5 экранов со всеми взаимодействиями на каждом) занимает 16-24 человеко-часов. Причем, это время быстро сокращается по мере освоения проектировщиком используемого фреймворка, его врастания в процесс и появления набора переиспользуемых контролов.

Предвижу крики «Это безумие! Убей его, Шилов! Проектировщик не должен верстать! Прототип делается, чтобы его выбросить!» и др. Но взрослыми становятся, не когда перестают слушать маму, а когда понимают, что мама была права. Поэтому, я готов предметно обсудить достоинства и недостатки hi-fi прототипирования, а также причины, почему мы пошли по этому пути.

Причины

Причина всех причин — конечно, экономическая.
В вертикальных командах, когда проектировщики, разработчики, тестировщики работают отдельно друг от друга и у вас в разработке находятся 3-4 продукта (или около 20, как у нас), ваш отдел производства превращается в тату-салон: больно, дорого и навсегда. Что-нибудь изменить на лету не получится. Один раз я даже выиграл спор с Product Owner, что он не сможет подойти и вставить пробел в русскую локализацию своего продукта. Через кровь и кишки это сделать можно, но только разово. Дальше вас порвут голыми руками. Поэтому, режим работы такой: семь раз отмерь, один раз передай в продакшн.



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

Но и это не главное.
Главное же в том, что проектировщик, бизнес-аналитик и владелец продукта идут на несколько спринтов впереди команды и пытаются выстроить траекторию к желаемой функциональности и UX так, чтобы:
1. Не пришлось делать лишней работы;
2. Использовать то, что сделано раньше;
3. Обеспечить плавное изменение интерфейса и
4. Продвинуться вперед, несмотря на п.п.1, 2, 3.

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

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

Недостатки

В этот прелестный клуб я хожу уже 2 года и из недостатков могу отметить необходимость постоянного обучения. Вам придется держать руку на пульсе веб-разработки и следить за новинками. Хотя, какой же это недостаток?

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

И третье: атрофируется способность оценивать статичный макет. На мой взгляд, это самое неприятное, с чем пришлось столкнуться. У нас есть продукт, где мы работаем по старинке — рисуем картинки и пишем ТЗ. Так вот, я обнаружил, что уже не могу сказать, нравится мне этот макет или нет? Мне надо поводить мышкой, покликать, поскроллить и тп. Взаимодействовать. Почувствовать продукт. Без этого, никакого мнения не появляется, приходится его выдавливать из себя. Продолжаю наблюдения.

Достоинства

Мне настолько очевидны все многочисленные преимущества hi-fi прототипов, что это вызывает чудовищный боринг. Но перечислить все-таки надо:
1. Прототип не выбрасывается при появлении реального продукта. Ваш труд летит в корзину примерно никогда.
2. Просчеты, когда просто забыл или упустил из виду какую-то мелочь, всплывают уже при верстке прототипа.
3. Ошибки проектирования отлавливаются на этапе тестирования.
4. Эти ошибки и просчеты не попадают в продукт, поэтому экономится время на их фикс.
5. У вас появляется собственный полигон для экспериментов! Можно, например, взять и прикинуть «А что, если сделать эту кнопку в 2 раза больше прочих?». Минимальная правка css и через 2 минуты можно тестировать. И получить результат!
6. Результат юзабилити-тестирования прост и однозначен. Ваши пользователи видят продукт таким, каким он будет в реальности. Не нужны оговорки «сюда не смотри, тут рыбу заворачивали». Вы просто запускаете юзеров на ваш полигон и наблюдаете за ними. Из вашего лексикона исчезнут фразы «прототип хороший, дизайн отстой» или «дизайн модный, в вот проектировщик накосячил». Этот пункт по своей важности перевешивает все остальные, вместе взятые.
7. Не надо помнить или лезть в документацию, чтобы получить ответ на вопрос «А как оно выглядит/работает в этом сценарии?». Не смейтесь, но мы частенько просто открываем прототип в браузере и смотрим, как все должно работать. На этапе проектирования тщательно обсуждаются все мелочи, которые невозможно упомнить через некоторое время. Если их фиксировать на бумаге, то получаются те самые ТЗ на 60 стр. А прототип всегда под рукой, и ты получишь наглядный ответ через 10 сек.
8. Прототип позволяет получить более точные оценки трудоемкости, что снижает риски разработки. Исчезает двусмысленность словесных описаний. Все можно потрогать руками.
9. Отказ от костылей. Если какое-то интерфейсное решение требует сложных костылей, то это становится очевидным уже на этапе прототипа, и сразу отбрасывается. Экономия времени и повышение стабильности продукта.
10. Вы используете простые и свободные инструменты Brackets или SublimeText.
11. Вам становится доступен Git. Это как наградной маузер. Когда вы осознаете всю его мощь, мир станет гораздо дружелюбнее. Вести несколько веток одновременно, переключаться между ними и при этом иметь всего одну папку проекта — это дорогого стоит, можете мне поверить. Откатиться на 3 коммита назад – дай я тебя поцелую!
12. Модульность html позволяет сосредоточиться на конкретной задаче и выбросить из головы все лишнее.
13. Помощь гигантского сообщества. Stackoverflow, github, сотни, тысячи свободных плагинов и модулей, которые постоянно появляются и готовы к использованию немедленно. Вы всегда будете на острие прогресса, а не будете заложником разработчиков Axure.
14. Снижение трения между проектировщиком и разработчиком. Вы начнете понимать проблемы друг друга, что способствует появлению лучшего продукта.
И все остальное, про которое я благополучно забыл.

Living style guide бесплатно, то есть даром

Да, еще одна очень важная вещь. При грамотном построении процесса у вас есть шанс со временем превратить свой вечно-живой прототип в некое подобие living style guide. Что является мечтой многих, особенно в крупных компаниях с большим продуктовым парком под общим зонтиком, типа mail.ru. Причем, без использования сторонних инструментов. Все, что нужно — на отдельной странице выложить все используемые в продукте контролы и следить за актуальностью css. При необходимости вставить, например, выпадающий список, верстальщик заходит на страницу и делает копи-паст кусочка кода. И без всякой документации, которая мгновенно устаревает и поддерживать которую — отдельная печалька.

Матчасть

Чтобы потратить деньги с умом, нужны две вещи.
Чтобы эффективно собирать hi-fi прототипы вам тоже нужны две вещи:

• сss фреймворк
• angular

Я не буду описывать конкретное наше решение и приводить ссылки, чтобы не уводить разговор в сторону холивара bootstrap/semantic UI/skeleton и пр. Это отдельная тема. Скажу, что мы используем zurb foundation for apps и пока довольны результатом. Выбор за вами, но решение должно иметь развитый грид для постройки сложных, адаптивных лейаутов, поддерживать sass или Compass и билдиться при помощи gulp. Плюс нужен angular, если вы действительно хотите иметь по-настоящему интерактивные прототипы. И не пугайтесь, это только звучит устращающе, а мой собственный опыт показывает, что «уверенный пользователь ПК», получив пару ссылок, и вбив 3 команды в Git Bash, легко устанавливает себе все это добро. Менеджеры пакетов рулят неимоверно. Зато, через пару дней вы обнаруживаете у своего стажера в папке файл _variables.scss, а в нем переменные цветов, которые он использует. Шах и мат, Карл!

Mobile first

Честно признаюсь, что этот подход к разработке оказался нам не братан. Либо мы не умеем его готовить, либо это тоже городская легенда. Возможно, дело в том, что для документооборота вопрос мобильности не стоит так уж остро. Вряд ли кто-то будет согласовывать договор хотя бы на пару сотен тысяч левой рукой в айфоне. Но возможность прочитать текст договора, посмотреть атрибуты, исполнителя, сроки и прочее — нужна всем.
Нет, в теории все понятно и довольно подробно описано. Никаких претензий. Но использовать метод в реальной жизни невозможно из-за его неэффективности. Я могу представить себе только одну область, где могут быть оправданы такие затраты — мобильный банкинг. Но для банков наличие удобного приложения сегодня равносильно выживанию завтра. Да и то, честно говоря, там больше оправдан подход mobile only.

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

Почему он неэффективен? Да потому, что у большинства уже есть десктопное приложение! То есть, вы предлагаете вычистить из него всё лишнее, сделать мобильный вариант и постепенно добавлять фичи, чтобы снова получить десктопное приложение. Я вас умоляю! Двойная работа детектед.

На практике все происходит гораздо проще. Если ваш фреймворк поддерживает адаптивную верстку, то все, что нужно сделать — заресайзить окно браузера и посмотреть, что сломалось. Обычно почти ничего не ломается, т.к. современные фреймворки построены на флексбоксах. Всего-то достаточно переопределить порядок блоков и скрыть ненужные. Ну и плюс легкая рихтовка css, чтобы спрятать меню под гамбургер, увеличить размер кликабельных элементов и особо мелких шрифтов. Таким образом, вы получаете мобильную версию своего приложения практически даром. Другой вопрос, насколько ваши мобильные сценарии отличаются от обычных. Но мы и не об этом. Повторяю, если вы банк, то экономить на mobile first смерти подобно.

Сумма прописью

Давным-давно пора закругляться. Тут должен быть какой-то вывод, но я его не придумал. Поэтому, вместо вывода сделаю предупреждение — при работе с прототипом помните про confirmation bias:

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

Поэтому, самый лучший прототип — это реальный продукт. Только он борщ! Только он истина! И на втором месте — тот прототип, который вы способны сделать. Пусть даже это будет зомби.

Happy prototyping!

TL;DR

Автор занимает еретическую позицию «все козлы, я — д’Артаньян» и жестко форсит использование html для построения эволюционных hi-fi прототипов в вертикальных командах, когда цена ошибки слишком велика. Он считает, что сегодня это доступно каждому. На теплоходе музыка играет, и знайте, что никто не будет ради вас дергать стоп-кран. Не опоздайте. Имейте фан.