Зачем рендерить дизайн?
Как вы используете мокапы, особенно высококачественные (а не каркасные), в процессе разработки и почему / порекомендуете их?
Я разработчик, в прошлом владельцы моих продуктов иногда выдавали требования в виде макетов, но даже тогда меня вообще поразило, что об этом можно было бы сообщить без всякой дополнительной работы (0 художественных способностей с ручкой и бумажного эскиза хватило бы).
На прошлой неделе я смотрел несколько видеороликов на YouTube, чтобы вдохновиться дизайном для побочного / хобби-проекта, над которым я работаю, и обнаружил, что имитирую кое-что из того, что они делают, но остановился, когда понял, что усилия не переносятся. Большая часть программного обеспечения для дизайна, которое я видел, больше похоже на Photoshop, чем на веб-браузер, поэтому обычная работа с холстом / палитрой не всегда переводится в (S) CSS - я никогда (* не с начала 2000-х) работал над проект, в котором использовалось фоновое изображение, поэтому я не уверен, какую роль эскиз играет в жизненном цикле дизайна / разработки?
Я не стучу дизайнеров или работу, которую вы делаете - я помню Интернет в конце 90-х и не хочу возвращаться, я просто изо всех сил пытаюсь понять, почему компании тратят так много времени / денег на создание высококачественного цифрового искусства - что затем нужно перевести в изображения, HTML и CSS?
Ответы
Я думаю, что в идеальном сценарии есть дизайнеры, которые пишут интерфейс. Но в действительности большинство дизайнеров этого не делают. Однако появляется все больше и больше мест, где это является нормой.
С точки зрения дизайнера, дизайн служит трем основным целям:
- Критика внутри команды
- Тестируйте с пользователями
- Обсудить с клиентами
Бумажные эскизы нельзя использовать ни для чего из вышеперечисленного, даже макеты трудно понять клиентам и некоторым пользователям. Поскольку каждый предмет имеет свое предназначение, наброски на бумаге (например, наброски на доске) лучше всего подходят для быстрого обсуждения чего-то незначительного или идеи, они не могут представить такие вещи, как брендинг, внешний вид и ощущения.
Еще одно место, где он сияет, - это отображение первоначальных грубых идей, которые нужно быстро исправить. Есть вещи, называемые бумажными прототипами или картонными моделями продуктов и т. Д. Они часто используются, чтобы просмотреть сценарий и понять, каково это использовать продукт, и есть ли в видении какие-либо большие дыры. Очень легко упустить важные вещи, если не разыграть их.
Теперь и прототипы hifi, и прямой html / css удовлетворяют указанным выше пунктам. Это просто зависит от дизайнера и внутренних процессов компании. Нет правила, согласно которому прототипы Hi-Fi являются обязательными.
То, что вы используете, зависит от того, что вам нужно, и от ограничений проекта. Вам нужно сообщить что-то, что можно сделать, сделав набросок на бумаге? Пожалуйста, сделайте это, не теряйте время зря. Делайте это в любое время и в любой момент проекта. Нужно протестировать с пользователями? клиенты понимают только хифи? Есть ли дизайнеры, живущие в html / css? Не стесняйтесь пропустить фотошоп / фигму / эскиз и т. Д. Есть ли у клиента просьба изучить 2 совершенно разных направления? стоит меньше использовать инструменты для создания прототипов? Затем немного пропустите html / css.
Во многих отношениях поток кода wireframe> photoshop> унаследован. Инструменты теперь смешивают каркасы и фотошоп с логическими правилами. Некоторые из этих инструментов для создания прототипов начинают настолько усложнять его (они в основном становятся визуальным представлением кода), что заставляет задуматься, быстрее ли это просто делать непосредственно на javascript (что, если вы технический). Я уверен, что эта эволюция будет продолжать двигаться все больше и больше только кода. Эта область развивается, появляется много новых людей, не обладающих техническими знаниями. И инструменты, которые вы видите, предназначены для них, а не для фронт-разработчиков.
Есть еще такое понятие верности. Чем больше похоже на конечный продукт, тем больше людей считают, что они не могут дать обратную связь и внести изменения. Они будут сдерживаться, даже если вы скажете им, что давать можно. Таким образом, каркас, естественно, привлекает больше, чем что-то, что выглядит отполированным и законченным. Показ клиенту безупречного дизайна может не дать вам желаемой обратной связи. Но опять же, вместо этого вы можете закодировать каркас. Никто не говорит, что нельзя.
Потому что дизайнеры делают это не исключительно для общения с разработчиками, а скорее для общения с пользователями и стейкхолдерами.
Как вы тестируете дизайнерское решение, которое рисовали ручкой и бумагой? Как узнать, какое решение обеспечивает лучшую конверсию? Как узнать, нужно ли адаптировать решение, потому что пользователям сложно понять и т. Д.?
Дизайнеры делают это для того, чтобы что-то разработать вместе со стейкхолдерами, которые обычно являются людьми визуального типа, а также для проверки своей работы, тестируя ее с пользователями.
В конце проектное решение передается разработчикам, а такие инструменты, как sketch, adobe xd и т. Д., Предоставляют возможность с довольно небольшими усилиями передавать разработчикам атрибуты стиля и т. Д. Из уже проделанной вами работы.
Несколько лет назад мы отказались от визуализации дизайна в моей работе. мы перешли к быстрым прототипам, используя прокси / mock json в качестве бэкэнда. наши заинтересованные стороны ощущают настоящее приложение и могут критиковать его на ранней стадии без разработки внутреннего кода. Мы все тоже достойные UI-дизайнеры и используем бутстрап как основу. После того, как наш прототип готов / одобрен, мы запускаем бэкэнд, потому что интерфейс буквально уже готов. Мы используем специальный фреймворк javascript, называемый атомным стеком, написанный Тайри Джексоном. Проверьте это!