html текст
All interests
  • All interests
  • Design
  • Food
  • Gadgets
  • Humor
  • News
  • Photo
  • Travel
  • Video
Click to see the next recommended page
Like it
Don't like
Add to Favorites

Как передать макет программистам так, чтобы дизайн не “протух” и проект запустился в 2 раза быстрее

12.05.2018

Источник:  turbo>

Если вы web-дизайнер, то наверняка сталкивались с ситуацией, когда после «прикрутки к движку» ваш макет довольно сильно ломался. Вам часто приходится говорить фразу: «В макете всё было красиво, но клиент всё сломал», ставить в портфолио изображения вместо скриншотов сайта и убирать прямую ссылку, чтобы потенциальные заказчики не видели - во что в итоге превратился ваш макет.

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

Вот несколько примеров того, что могут сделать с вашими макетами программисты:

  • названия товаров оказываются значительно длиннее одной строки. Иногда строк оказывается целых три - а на такое издевательство ваши макеты уже не рассчитаны
  • в фильтре товаров появились новые элементы, например - ползунки, которые вы не рисовали и появились они в самом неприглядом месте, в самой “вырвиглазной” форме
  • появлялись разные поп-апы про которые вы даже и не думали, например, поп-ап с выбором города
  • при заполнении формы вылезает страшненькое сообщение об ошибках, которое вы забыли нарисовать
  • картинка товара вместо сочного красочного изображения на белом фоне содержит куда менее сочное и - без белого фона
  • на макете детальной страницы товара вам удалось разместить изображение 800х600, но у клиента есть картинки только 300х300, поэтому программисты просто растянули маленькую картинку и обрезали

Список далеко не полный, это - лишь пара примеров, когда из своего красивого и опрятного макета вы получаете франкенштейна, которого стыдно показать даже своей маме, не то что потенциальным клиентам! Мы в компании turbo> называем это «протуханием дизайна» - процессом, в результате которого дизайн увядает и портится.

Конечно, можно откреститься от проблемы и своей ответственности фразой: «Мне никто не сказал что картинки есть только в плохом качестве, в брифе про это не писали, а я не телепат…» или «клиент утвердил мой макет, а ведь он должен был знать, что у него картинки в плохом качестве». Но давайте попробуем снять эту боль с клиента и подумаем, как решить проблему самостоятельно.

Вариант №1: заранее всё досконально продумать, проанализировать и прописать в техническом задании. К сожалению, этот вариант не работает: на анализ и уточнение уходит слишком много времени, а на выходе получается ТЗ на 100+ страниц, которое никто не читает.

Мало того, невозможно предусмотреть всё: аналитик всё равно что-нибудь забудет, даже если на этапе написания ТЗ у него будет полный доступ к внутренней базе товаров с картинками. А это - фантастика, потому что картинки хранятся в 1С (или другой внутренней системе), которая “святая святых” – финансовая система, где хранится информация “про бабки”! Чего уж говорить, если контента нет и его планируется готовить параллельно с разработкой сайта…

Вариант №2: программисты могут дозапросить у дизайнеров все недостающие материалы. Этот вариант имеет смысл, но только для критичных ситуаций. Обычно, когда подключаются программисты, дизайнеры уже работают над другими проектами, у них полностью забронировано время и не хочется возвращаться к работе, которую они сдали 2 месяца назад. Поэтому, программисты или менеджеры проектов предпочитают дорисовывать мелочи самостоятельно и на свой вкус. Кроме того, в некоторых случаях, придётся вносить колоссальные правки. Например, чтобы сжать лаконично вписанную в сетку детальной страницы картинку 800х600 до размеров 300х300, потребуется переделать всю сетку. А это - уже новый макет, который потребуется заново апрувить с клиентом.

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

Решение
Я хочу рассказать ещё об одном методе, который позволяет полностью избавиться от “протухания дизайна” на этапе программирования. Используя его, вы станете реже говорить «это клиент испортил», сэкономите уйму времени, нервов и сил, а клиент получит качественный результат без напряга своих аналитических способностей.
Итак, в большинстве дизайн-студий по разработке сайтов есть три глобальных этапа: дизайн, вёрстка и программирование, которые водопадом идут друг за другом, примерно так:

Забегая немного вперёд скажу, что такая схема идеально подходит для сайтов, не требующих сложной технической разработки с большим количеством данных и интеграций. Используйте на здоровье на промо и корпоративных сайтах. Но, если у вас много данных и сайтом будут пользоваться как сервисом, и вы не знаете, как именно (например - стартап с не понятной механикой), то можно пойти другим путём.

Programming-first подход

Это немного радикальное изменение, но не пугайтесь. Дальше я на примере, подробно, объясню, как это работает. Смысл в том, чтобы стартовать программирование технически-сложной части без вёрстки и без дизайна. Эту часть можно запрограммировать в чёрно-белом варианте, реализовав все интеграции и получив все данные из 1С/Axapta/CRM/ERP/клиента, дать всем участникам проекта покликать настоящие данные в настоящей механике. В это время, дизайнер может разрабатывать дизайн-концепцию, цветовую схему, шрифты и всё остальное. А когда приступит к сервисному разделу, то сможет делать это на живом рабочем примере, учитывая весь объём настоящих данных, а не то, что написано в брифе.

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

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

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

Пример
Чтобы было понятно, расскажу как мы делали сайт https://kdl.ru который мы в turbo> сверстала и запрограммировали по заказу агентства ONY, разработавшего дизайн, креатив и стратегию.

KDL (клинико-диагностические лаборатории) - это компания с федеральной сетью офисов, где можно быстро сдать и получить результаты самых разных медицинских анализов. Компания быстро растёт в конкурентной среде и от нас требовался свежий, удобный и понятный сайт в максимально сжатые сроки.

На этапе брифа стало ясно, что раздел «каталог анализов» является технически сложным, в нём будет много данных и вначале никто не мог сказать каких именно - требовалось анализировать информацию в ERP-системе. Кроме того, совершенно непонятен требуемый функционал: с одной стороны, он похож на каталог товаров с корзиной, но с другой стороны, анализы – это услуги, а не товары. Это значит, что фактически нет количества (нет остатков по складам), зато есть наличие (в некоторых регионах не делают редкие анализы). Также на этапе брифа присутствовала непонятная механика: при добавлении в корзину услуги «общий анализ крови» в корзину автоматически должна была добавиться услуга «взятие крови из вены», как неотъемлемая часть общего анализа.


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

Таких непонятных нюансов было много, но так как это не классический интернет-магазин, мы не могли просто сделать “как у всех”. Дело в том, что конкурентов у KDL не так много и у них подобный функционал не автоматизирован: они просто сделали “приписку под звёздочкой”, «* - если вам нужен другой тип, предупредите медсестру». Было очевидно, что если мы пойдём классическим способом “дизайн->вёрстка->программирование”, то наш дизайн однозначно “протухнет” на последнем этапе. Что же делать?

Мы предложили рабочей группе начать разработку с программирования! Это звучало странно для дизайн-агентства, но нам удалось договориться, и мы распараллелили процесс: дизайнеры принялись разрабатывать концепцию дизайна главной страницы, тогда как программисты начали интеграцию с внутренней ERP-системой, агрегацию и нормализацию получаемых из неё данных и разработку всей механики.

Мы очень быстро сделали всё что описано в ТЗ, но без дизайна в простом чёрно-белом варианте: категории анализов, фильтры, морфологический поиск с учётом ошибок и синонимов, комплексы анализов, мультирегиональные цены, наличие в регионах, взятие биоматериалов, корзина и оформление заказа. Всё это выгружалось из ERP-системы, то есть, все данные были настоящими. Выглядело это так:

Главная страница раздела:

Страница одного комплекса:

Страница одного анализа. Показан выбор региона:

Корзина с несколькими анализами и биоматериалами:


 

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

Мы отправили этот вариант клиенту, чтобы он мог проверить всю механику и весь функционал и… у вас когда-нибудь были макеты без правок? Вот и наша механика не обошлась. Точно так же, как клиенты просят “поиграться со шрифтами” на макетах, наш клиент попросил “поиграться с механикой”, прислав несколько корректировок. Сделать их на этом этапе ещё было достаточно просто. Например, выяснилось, что на детальной странице некоторых анализов нужно показать PDF-файл с инструкцией; некоторые услуги не имеют артикула; в фильтре «для детей» не оказалось ни одного анализа! И тогда нас попросили изменить фильтры:

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

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

Параллельно с программированием, дизайнеры разработали и утвердили макеты главной страницы:

 

Здесь тоже не всё получилось с первого раза, но я не буду подробно рассказывать про этап утверждения макетов - вы и сами всё знаете. Тем не менее, на момент, когда была утверждена концепция дизайна, также была утверждена вся механика и мы просто попросили дизайнера «раскрасить» весь наш чёрно-белый функционал утверждённым стилем.

Дизайнер в процессе создания макетов для «каталога анализов» мог сам кликать, смотреть - что и как работает, очень быстро получать всю интересующую информацию прямо у сидевшего рядом программиста. Пример диалога между ними:
- Сколько у вас категорий?
- 34
- Какое самое длинное название?
- Сейчас поищу в базе… Вот, нашёл: 371 символ вот это: «Предварительное определение наркотических, психотропных и сильнодействующих веществ (качественно): Опиаты (героин, морфин, кодеин), Опиоиды (метадон, фенциклидин, трамадол), Амфетамин и его производные (амфетамин, метамфетамин и др.), Каннабиоиды, Кокаин, Бензодиазепины (диазепам, феназепам, нитразепам и т.д), Барбитураты (фенобарбитал, циклобарбитал, барбитал и т.д)»
- А много таких? Если откинуть 1% самых длинных, то какой останется самый длинный?

В итоге, из этого:

После работы дизайнера стало красиво:

Кстати, на этом проекте у нас было ТЗ всего на 18-ти страницах. В них мы описали только глобальные задачи, не пытаясь всё проанализировать и детально расписать каждую кнопочку и поля всех сущностей. Все детали мы выясняли прямо во время программирования и, при необходимости, вносили правки.

Такой подход требует немного перестроить мышление: если вносить правки легко, то не нужно пытаться от них отгородиться с помощью подробнейшего ТЗ. Нет смысла выставлять доп. косты клиенту за каждый “чих”. Для нас правки - это неотъемлемый этап получения качественного результата и мы сделали его проще.

Итого

  • Мы значительно ускорили срок разработки сайта, потому что на момент утверждения макетов, у нас уже была готова интеграции с пятью системами и вся механика. Весь функционал был оттестирован и отлажен. Оставалось только обернуть её дизайном
  • Дизайн не успел “протухнуть” и теперь нам не стыдно указывать ссылку на сайт в своем портфолио
  • ТЗ на 18 страницах
  • Клиент мог легко корректировать работу и вносить изменения
  • Клиент получил идеальный дизайн, а не просто - красивую картинку
  • Мы сэкономили бюджет проекта, так как снизили объём правок (не количество, а именно объём) за счёт того, что все правки были простыми

Применимость

На самом деле, ничего нового мы не придумали. Для многих дизайнеров описанный в статье метод является обыденным. Например, в компаниях-интеграторах, при разработке сложных технических систем о внешнем виде никто не думает или думает в самый последний момент. При разработке CRM/ERP систем всегда в первую очередь создают функционал, пытаются получить максимум данных при минимуме усилий и свести их в аналитических отчётах, как признак того, что система работает правильно. И, только когда весь функционал готов, просят дизайнера поработать над внешним видом.

Классический подход design-first (дизайн->вёрстка->программирование) появился не просто так. Если к вам приходит клиент, для которого важнее всего внешний вид проекта, то готовьтесь больше работать над дизайном: играть со шрифтами и переставлять телефон из “подвала” в “шапку” - то есть, вносить много правок на этапе дизайна.

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

На проекте KDL нам удалось соединить оба этих подхода в разных разделах: на главной странице нет технически сложных элементов, поэтому был применён design-first; в разделе “каталог анализов” функционал был неким абстрактным “конём в вакууме”, поэтому мы применили programming-first.

Не пытайтесь использовать programming-first при разработке промо-сайтов – там просто нечего программировать, пока нет дизайна. А на корпоративных сайтах обычно мало данных, и те, что есть являются достаточно тривиальными и понятными: список новостей, список вакансий, список сертификатов, и так далее, поэтому, дизайн там имеет бОльшее значение и именно на этапе дизайна правок будет больше всего.

Programming-first - это не панацея, а скорее ещё один инструмент в вашем наборе. Применяйте его правильно и вам станет значительно проще, а ваши клиенты будут счастливее.

Материал подготовил: Роман Бобров (CEO turbo>)

Читать дальше
Twitter
Одноклассники
Мой Мир

материал с cmsmagazine.ru

1

      Add

      You can create thematic collections and keep, for instance, all recipes in one place so you will never lose them.

      No images found
      Previous Next 0 / 0
      500
      • Advertisement
      • Animals
      • Architecture
      • Art
      • Auto
      • Aviation
      • Books
      • Cartoons
      • Celebrities
      • Children
      • Culture
      • Design
      • Economics
      • Education
      • Entertainment
      • Fashion
      • Fitness
      • Food
      • Gadgets
      • Games
      • Health
      • History
      • Hobby
      • Humor
      • Interior
      • Moto
      • Movies
      • Music
      • Nature
      • News
      • Photo
      • Pictures
      • Politics
      • Psychology
      • Science
      • Society
      • Sport
      • Technology
      • Travel
      • Video
      • Weapons
      • Web
      • Work
        Submit
        Valid formats are JPG, PNG, GIF.
        Not more than 5 Мb, please.
        30
        surfingbird.ru/site/
        RSS format guidelines
        500
        • Advertisement
        • Animals
        • Architecture
        • Art
        • Auto
        • Aviation
        • Books
        • Cartoons
        • Celebrities
        • Children
        • Culture
        • Design
        • Economics
        • Education
        • Entertainment
        • Fashion
        • Fitness
        • Food
        • Gadgets
        • Games
        • Health
        • History
        • Hobby
        • Humor
        • Interior
        • Moto
        • Movies
        • Music
        • Nature
        • News
        • Photo
        • Pictures
        • Politics
        • Psychology
        • Science
        • Society
        • Sport
        • Technology
        • Travel
        • Video
        • Weapons
        • Web
        • Work

          Submit

          Thank you! Wait for moderation.

          Тебе это не нравится?

          You can block the domain, tag, user or channel, and we'll stop recommend it to you. You can always unblock them in your settings.

          • cmsmagazine.ru
          • бизнес
          • стартап
          • домен cmsmagazine.ru

          Get a link

          Спасибо, твоя жалоба принята.

          Log on to Surfingbird

          Recover
          Sign up

          or

          Welcome to Surfingbird.com!

          You'll find thousands of interesting pages, photos, and videos inside.
          Join!

          • Personal
            recommendations

          • Stash
            interesting and useful stuff

          • Anywhere,
            anytime

          Do we already know you? Login or restore the password.

          Close

          Add to collection

             

            Facebook

            Ваш профиль на рассмотрении, обновите страницу через несколько секунд

            Facebook

            К сожалению, вы не попадаете под условия акции