Враги хорошего дизайна
Существует простая, непротиворечивая и эффективная система, позволяющая не только объяснить неудачи многих дизайнерских проектов, но и увеличить успешность проектов будущих.
Любой дизайн, чтобы быть успешен, должен удовлетворять каким-либо поставленным перед ним целям. Цели могут быть совершенно произвольными, например, дизайн должен:
1. понравиться заказчику или самому дизайнеру
2. быть максимально "юзабелен"
3. быть выполнен в серобуромалиновой гамме и быть покрытым пятнушками
4. нормально выводиться на RIPе
5. быть сделан вчера, а ещё лучше позавчера
6. удобно ложиться в руку
7. быть выставочного уровня
8. легко программироваться
9. быть выполненным кеглем 7 на 7.3, поскольку иначе нифига не влезает
и так далее. Повторяю: цели, как правило, совершенно произвольны. При этом они бывают однофакторными, например, "дизайн должен быть выполненным 7 на 7 с половиной", и многофакторными, например, "дизайн должен понравиться заказчику" (т.е. заказчику нравятся дизайны, которые "и ..., и ..., и ..., и ... и даже ..."). Фактически, многофакторные цели являются наборами некоторого числа целей однофакторных.
Проблема заключается в том, что при увеличении числа целей снижаются вероятность непротиворечивости набора целей и вероятность того, что вообще удастся сделать дизайн этим целям удовлетворяющий (в имеющееся время с имеющимися ресурсами).
Теоретическая составляющая первой неприятности понятна. Со второй несколько сложнее. Изначально, без каких либо целей, дизайнер обладает почти ничем не ограниченным пространством для маневра (в реальности ограничений уже полно, например, ограничивает среда, технические возможности, имеющийся набор навыков, культурный уровень дизайнера и аудитории и т.д.). Каждое новое требование это пространство ограничивает: некоторые требования сильнее, некоторые слабее. С ростом количества входных требований пространство для маневра съёживается всё больше, рано или поздно от бескрайней равнины остается крошечный пятачок. При этом в начале работы дизайнер не знает путь к этому пятачку, он должен идти к нему фактически наощупь. Хуже, однако, то, что путь к этому пятачку может занимать слишком много времени.
Тут необходимо сделать два уточнения. Во-первых, эти две неприятности не являются "собственностью" дизайна, они применимы к любой созидающей человеческой деятельности. Во-вторых, этот закон не является абсолютным: есть много примеров, когда огромное число целей не помешало появлению прекрасного дизайна. Обилие входных требований только снижает вероятность того, что результат будет этим требованиям удовлетворять.
Вот два простых и наглядных примера действия этого закона. Стандартным цветом ссылок в интернете является синий. Поскольку его использование увеличивает качество интерфейса сайта, синие ссылки вполне могут попасть в список требований. Однако если другим требованием к дизайну является наличие яркого синего фона (например, сайт пропагандирует отдых на море или же синий фон до судорог нравится заказчику) от оптимального цвета ссылок придется отказаться. Это был пример противоречивости целей. А вот пример снижения вероятности. Если логотип заказчика плох (обладает убогой эстетикой, чересчур яркой стилистикой, неправильной формой), размещение его на артефакте является значительной проблемой. В таких случаях существует всего несколько вариантов решения, при котором дизайн получается успешным. Поиск идеальных вариантов как минимум труден, а при лимите времени и невозможен. Фактически, плохой логотип добавляет ещё и требование "логотип и дизайн должны хорошо работать вместе". Если же логотип хорош, второе требование выполняется самопроизвольно.
Как уже сказано выше, понимание этого закона часто позволяет объяснить причины неуспеха дизайна. Самым жизненным примером является известное утверждение "если бы не заказчик...". У дизайнера один набор требований, у заказчика - другой. Если один из них не отбрасывается, с дизайном происходит непоправимое. Другой пример - ужасающее качество дизайна нарочито "юзабельных" сайтов (дизайн имеет свой набор требований, интерфейс √ свой, и не малый). Напротив, этот же закон объясняет, почему дизайнеры, делающие личные проекты, чаще всего делают очень хороший дизайн - собственные проекты редко обладают большим количеством входных требований.
Обратите внимание, что я вовсе не ратую ни за игнорирование потребностей заказчика или дизайнера, ни за плохой (или хороший) интерфейс, ни за что-либо другое. Любое из этих действий отдаляет от золотой середины. Я ратую за тщательный отбор целей, поскольку без отбора, независимо от наших желаний, от части целей всё равно придется отказаться. По традиции, чаще всего дизайнеры отказываются от требования сдать работу в срок - но в каждом конкретном случае требования, от которых можно отказаться, разные. Сознательное знание этого закона помогает отбросить требования, менее важные в настоящий момент.
Кроме того, этот закон показывает нам, какие действия можно предпринять, чтобы увеличить количество удовлетворяемых дизайном требований. Главная мера здесь - сделать так, чтобы требования были "внутри" дизайнера - если требования внешние, так что с ними нужно постоянно сверяться, время создания успешного дизайна становится слишком уж велико. Например, когда один человек является исполнителем дизайна (дизайнер), а другой - постановщиком требований (худруком), переделки дизайна происходят почти в обязательном порядке (дизайнер делает - худруку не нравится). Если худрук с самого начала формулирует для дизайнера большую часть целей, эта проблема становится значительно менее острой (другой разговор, что сбор такого списка целей труден весьма и весьма). По этой же причине неразумно лишать дизайнера возможности коммуницировать с заказчиком. Но это ещё не всё. Знание этого закона дает дизайнеру возможность более точно планировать работу над дизайном - количество требований является основным фактором, оказывающим воздействие на сроки выполнения проекта.
Дайджест новых статей по интернет-маркетингу на ваш email
Новые статьи и публикации
- 2024-11-26 » Капитан грузового судна, или Как начать использовать Docker в своих проектах
- 2024-11-26 » Обеспечение безопасности ваших веб-приложений с помощью PHP OOP и PDO
- 2024-11-22 » Ошибки в Яндекс Вебмастере: как найти и исправить
- 2024-11-22 » Ошибки в Яндекс Вебмастере: как найти и исправить
- 2024-11-15 » Перенос сайта на WordPress с одного домена на другой
- 2024-11-08 » OSPanel 6: быстрый старт
- 2024-11-08 » Как установить PhpMyAdmin в Open Server Panel
- 2024-09-30 » Как быстро запустить Laravel на Windows
- 2024-09-25 » Next.js
- 2024-09-05 » OpenAI рассказал, как запретить ChatGPT использовать содержимое сайта для обучения
- 2024-08-28 » Чек-лист: как увеличить конверсию интернет-магазина на примере спортпита
- 2024-08-01 » WebSocket
- 2024-07-26 » Интеграция с Яндекс Еда
- 2024-07-26 » Интеграция с Эквайринг
- 2024-07-26 » Интеграция с СДЕК
- 2024-07-26 » Интеграция с Битрикс-24
- 2024-07-26 » Интеграция с Travelline
- 2024-07-26 » Интеграция с Iiko
- 2024-07-26 » Интеграция с Delivery Club
- 2024-07-26 » Интеграция с CRM
- 2024-07-26 » Интеграция с 1C-Бухгалтерия
- 2024-07-24 » Что такое сторителлинг: техники и примеры
- 2024-07-17 » Ошибка 404: что это такое и как ее использовать для бизнеса
- 2024-07-03 » Размещайте прайс-листы на FarPost.ru и продавайте товары быстро и выгодно
- 2024-07-01 » Профилирование кода в PHP
- 2024-06-28 » Изучаем ABC/XYZ-анализ: что это такое и какие решения с помощью него принимают
- 2024-06-17 » Зачем вам знать потребности клиента
- 2024-06-11 » Что нового в работе Яндекс Метрики: полный обзор обновления
- 2024-06-11 » Поведенческие факторы ранжирования в Яндексе
- 2024-06-11 » Скорость загрузки сайта: почему это важно и как влияет на ранжирование
Когда человек счастлив, он всегда хорош. Но не всегда хорошие люди бывают счастливы. О. Уайльд «Портрет Дориана Грея» |
Мы создаем сайты, которые работают! Профессионально обслуживаем и продвигаем их , а также по всей России и ближнему зарубежью с 2006 года!
Как мы работаем
Заявка
Позвоните или оставьте заявку на сайте.
Консультация
Обсуждаем что именно Вам нужно и помогаем определить как это лучше сделать!
Договор
Заключаем договор на оказание услуг, в котором прописаны условия и обязанности обеих сторон.
Выполнение работ
Непосредственно оказание требующихся услуг и работ по вашему заданию.
Поддержка
Сдача выполненых работ, последующие корректировки и поддержка при необходимости.