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

Однако работать, оставаясь исключительно в рамках своей специализации, не получается. Будучи программистом, я естественно концентрируюсь, в основном, на функциональности сервиса, а о том, как выглядят в этот момент страницы, практически не задумываюсь. И раньше я часто совершал одну ошибку, которую, уверен, совершают и многие другие программисты: показывал заказчику то, что наработано, прямо в таком виде...

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

И показывает ворох нестилизованного HTML с огромными дефолтными шрифтами и без раскладки, когда все блоки идут просто один за другим.

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

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

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

По этой же причине, кстати, очень плохо при показе программы выглядят типичные для программиста тестовые данные типа "foo", "bar", "тестовая запись" и "asdfgh". Для заказчика отсутствие функциональности вообще и наличие тестовой функциональности одинаково бесполезно. Ему интересен готовый результат. И поскольку он, опять-таки, не программист, он не может знать, что с вашей точки зрения само появление на экране хоть чего-то после долгого проектирования модели — это большой шаг вперед.


Итак, показывать неподготовленному зрителю нестилизованный HTML нельзя. Но и дизайнера нельзя заставить приводить в человеческий вид, когда половины системы еще не существует, а то, что существует, может кардинально поменяться.

Я сейчас нахожусь как раз в середине двухмесячной разработки того, что мы с заказчиком условились публично называть "Неким Музыкальным Сервисом". И не далее, как пять дней назад, решение такой проблемы у меня наконец выкристализовалось в четкую концепцию "чернового стайлинга". Это такой компромиссный вариант, который позволяет инженеру без художественных талантов тем не менее достойно представить результаты своего труда.

Строится он по таким принципам:

Ну и ко всему прочему, во время стилизации тут же вылезают все огрехи в структуре HTML (а то и глубже), которую вы напроектировали там вслепую.

И что мне, как не дизайнеру, особенно приятно, реакция тех нескольких людей, которые видели этот черновой стайлинг, была в духе "симпатично!" :-)

Комментарии: 19

  1. Александр Вольф

    Кхм... надо будет взять на вооружение идею :)

  2. Tigger

    Не перестаю удивляться ясности изложения идей и четкой структурности в Ваших статьях! Спасибо, это просто приятно читать :)

  3. Homo-Adminus

    А ведь действительно так лучше! Даже мне, как программисту/админу с аналитическим складом ума, второй вариант нравится в 1000000 раз больше! :-)

    А за статью - спасибо! Как раз недавно наткнулся на такую проблему, когда раскрашивать просто не умею, а нераскрашенное заказчик оценивает как ulgy даже не глядя на функциональность.

  4. rusty_angel

    Спасибо за идею. Хотя мне чаще всего с заказчиками везло и они всё понимали. Чаще всего. Пару раз была такая же проблема, и я на скорую руку что-то страшненькое (нестрашненькое не умею) для них верстал.
    А под виндой это charmap.exe, только он, кажется, не ставится по умолчанию, хотя не помню.

  5. Severus

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

    P.S.
    charmap.exe идёт в стандартной комплектации Windows и ставится по умолчанию

  6. Никита

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

  7. MkDir

    Странно. Я "всю жизнь" сперва получал дизайн и только потом приступал к работе.
    Т.е. разработка софта без "черновиковых" дизайнов. Сразу чистовик и заказчику всегда есть что показать.

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

  8. Stoune

    Сперва готовый дизайн не всегда возможен. Допустим у вас ещё не совсем требования устаканились. Или тот же инженер по юзабилити заставит переделать layout полностью изза смены требований, а так мне такой компромисный вариант больше всего по душе.

  9. Денис Зайцев

    А ты с subversion работаешь? Он (или она? ;) лучше CVS, стоит переходить?

  10. Max Ischenko

    Эхх, к сожалению я с версткой даже в таком минимальном объеме не справляюсь. В итоге для knigoman.com.ua у меня сначала был именно такой вот вариант вообще без верстки (т.к. я заказчик, то мне ОК).

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

  11. hunter

    Спасибо. Очень полезная идея. Забираю.

  12. Сергей

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

  13. Tatyana

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

  14. Иван Сагалаев

    Мне кажется, это вообще большая общая проблема, когда заказчик начинает вмешиваться в технологию производства, причем любого. Но что интересно, идея соваться с советами к собственному зубному врачу, например, любому покажется странной. А вот учить проектировщиков, программистов, дизайнеров — это почему-то совершенно не смущает очень многих заказчиков :-).

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

  15. Андрейка

    Все здорово, и проблема ясна, и решение хорошее найдено. Но есть ньюанс:
    * Процесс поставлен с ног на голову, если юзабилити эксперт будет заниматься "двиганьем" уже имеющихся кнопок. Кнопки должны быть определены этим специалистом. Он делает прототип, тестирует его и отдает в разработку;
    * Гораздо лучше будет, если дизайн (для меня это код страницы + CSS, т.к. стилевое решение тут не интересно) будет сделан профессионально. Для этого есть прототип и по нему легко делаются шаблоны страниц;
    * Разработка ведется по тому же прототипу и реализуются те функции, которые нужны пользователям, а не потому что "так захотелось эту фичу написать"

    Вот тогда не будет возникать проблем:
    * "заказчик не знает что мы делаем", потому что есть прототип и делаем именно то что там показано
    * "куда приделать кнопку и как ее назвать и какая иконка нужна", потому что опять таки есть прототип и там показано куда, как и что
    * "дизайнер не нарисовал", потому что даже если нет шаблона одного, можно делать по аналогии с другими и потом быстро все поправить.

    Вообще, мне кажется, что все пободные проблемы при разработке из-за отсутствия методики как таковой. Потому что багтрекинг это еще не методика. Методика подразумевает, что клиент в курсе где сейчас проект. А хорошая методика еще и позволяет менять курс проекта прямо на ходу. Для веба, сферы столь изменчивой, это ИМХО крайне важно.

  16. Сергей Гоцуляк

    Эту проблему под именем "Айсберг" описал где-то у себя Джоэл. Он утверждает, что при выходе новой версии нужно в первую очередь работать над интерфейсом (верхняя часть айсберга, 1/12 его объема), а не над нутром - тогда пользователи действительно оценят нововведения. Именно поэтому Микрософт каждому ОФису дает новый интерфейс :-)

  17. [...] Черновой стайлинг [...]

  18. Олег Шимчик

    Я практически всегда беру для своих разработок какую-нибудь симпатичную минималистическую тему, дорабатываю слегка под свои нужды (вкуса вполне хватает, чтобы нигде внезапно не появлялись красные ссылки на синем фоне и шрифт на полэкрана) и уже с этим работаю.
    А если, как советовали нам еще Древние, разметку отделить от кода, то привести это потом к виду, вполне удовлетворяющему заказчика, не есть проблема.

  19. [...] Иван Сагалаев пишет об интересном способе построения интерфейса для прототипов: “Черновой стайлинг”. [...]

Добавить комментарий