#postprocat
Здесь собраны посты про создание сайтов с разных позиций: новичка, заказчика, дизайнера, разработчика, посетителя и человека, который отвечает за сайт после запуска. Личные наблюдения, профессиональные споры, узнаваемые рабочие ситуации и подробные разборы решений чередуются с короткими репликами и вопросами для обсуждения.
Глазами человека, который делает первый сайт
Первый результат без парадной версии
Для рассказа о начале пути, первых открытиях и небольших победах.
* Покажите конкретный момент, в котором непонятная технология становится личным опытом.
№1. Первый сайт может состоять из заголовка, фотографии и одной работающей кнопки. И все равно это сильное чувство: минуту назад был пустой экран, а теперь по твоему адресу что-то существует.
№2. Самая подозрительная кнопка в начале обучения – "Опубликовать".
Пока страница открыта только у тебя, можно бесконечно двигать карточки, менять фон и объяснять себе, что еще рано. После публикации появляется адрес. Его можно отправить другому человеку. Сайт перестает быть упражнением, которое никто не увидит.
Я за раннюю публикацию небольших учебных проектов без личных данных и лишних обещаний. Не потому, что ошибки прекрасны сами по себе. Просто некоторые вещи становятся понятны только тогда, когда страницу открывают не в твоем окне редактора.
№3. "У меня все ровно" – фраза, которую хочется произносить только с указанием ширины экрана.
На первом сайте легко поверить, что работа закончена: заголовок помещается, фотография красивая, кнопка стоит точно под текстом. Потом окно браузера становится уже. Заголовок занимает четыре строки, фотография обрезает человеку голову, а кнопка уезжает куда-то в сторону.
В этот момент адаптивность перестает быть отдельным пунктом из программы обучения. Возникает простая мысль: страницу будут смотреть не через мое окно.
Мне нравится такой способ учиться. Не заучивать свойства ради зачета, а столкнуться с понятной задачей: сохранить смысл и порядок, когда места стало меньше. Иногда для этого достаточно изменить сетку. Иногда приходится признать, что на странице вообще было слишком много всего.
Первый узкий экран хорошо лечит уверенность в универсальности собственного монитора.
№4. Представьте первую демонстрацию сайта другу.
Вы заранее открываете нужную страницу, поправляете масштаб, убираете уведомления. Рассказываете, почему выбрали именно этот цвет и как долго искали фотографию. Друг кивает, берет мышь и нажимает на название в шапке.
Ничего не происходит.
– Я думал, это на главную.
И вот уже весь разговор не о цвете. Вы впервые видите не свою задумку, а чужое ожидание. Для вас название было красивой надписью. Для другого человека – знакомым способом вернуться в начало.
Такие маленькие столкновения полезнее общего "нормально получилось". Они не обесценивают работу и не требуют переделать сайт по случайному вкусу. Они показывают, где интерфейс обещает действие, которого нет.
Поэтому мне ближе просьба "попробуй найти контакты", чем вопрос "тебе нравится?". Во втором случае человек оценивает впечатление. В первом – действительно пользуется сайтом.
И важно выдержать паузу. Не подсказывать сразу, не тянуться к мышке, не говорить: "Ну тут же очевидно". Именно в этой паузе обычно и начинается настоящее обучение.
№5. Не хочу стыдиться своего первого сайта за то, что он похож на первый сайт.
У начинающего человека еще нет насмотренности на сотни проектов, готовой системы компонентов и спокойного отношения к ошибкам. Зато есть работающая страница, собранная руками, и десяток вопросов, которые вчера даже не возникали.
Сравнивать это с работой большой команды странно. Лучше сравнить с пустой папкой, с которой все начиналось. Разница вполне достойна уважения.
Учеба без бесконечной подготовки
Для постов о самостоятельном обучении и переходе от уроков к своим решениям.
* Стройте текст вокруг выбора, а не списка обязательных технологий.
№6. Можно пройти курс, аккуратно повторить все действия и все равно растеряться перед пустой страницей. Это не обязательно означает, что курс плохой или ученик неспособный.
Повторение по инструкции и самостоятельное решение – разные нагрузки. В уроке уже выбраны порядок, инструменты, размеры, названия. В своем проекте сначала нужно понять, что вообще делать.
Я бы начинал не с "создать большой сервис", а с задачи, которую легко проверить: страница кружка с расписанием, портфолио с тремя работами, сайт семейной мастерской с понятным способом связи.
Ограниченный проект заставляет принимать собственные решения, но не тонет в масштабе. Почему здесь именно эти разделы? Нужна ли форма? Что должно быть видно без прокрутки?
Самостоятельность начинается не в момент, когда перестаешь смотреть подсказки. Она начинается, когда понимаешь, зачем ищешь конкретную подсказку.
№7. Мой любимый учебный проект – тот, у которого есть конец. Не "когда-нибудь огромная платформа", а страница, которую можно закончить, проверить на телефоне и спокойно закрыть ноутбук.
№8. В учебном видео все получается за двадцать минут. У вас – за вечер, с перерывом на поиск пропавшей скобки.
Разница не доказывает отсутствие способностей. В записи часто нет подготовки, неудачных попыток, выбора между вариантами и времени, которое автор потратил до съемки. Вы видите уже найденную дорогу, а идете по ней впервые.
Мне не нравится совет "просто повторяй быстрее". Он превращает обучение в погоню за чужим монтажом. Полезнее остановиться после небольшого фрагмента и изменить что-нибудь самостоятельно: порядок блоков, подпись кнопки, количество карточек.
И посмотреть, что сломалось.
Так появляется понимание связей. Не только "после этой команды получается красиво", но и "этот контейнер управляет расположением дочерних элементов". Объяснение перестает быть чужой фразой и становится собственным наблюдением.
Еще полезно сохранять вопросы. Не переписывать весь урок, а отмечать места, где пришлось действовать наугад. Через неделю такой список честнее покажет пробелы, чем количество просмотренных часов.
Скорость придет не от стыда за медленность. Она появляется, когда знакомые задачи перестают каждый раз выглядеть загадкой. А на это требуется практика, в которой разрешено останавливаться, проверять догадки и иногда начинать небольшой кусок заново. Один самостоятельно разобранный сбой может оказаться ценнее нескольких уроков, просмотренных на автомате.
№9. "Без кода – значит ненастоящий сайт" звучит так, будто посетитель приходит проверять способ сборки.
Новичку вполне можно начать с конструктора. Но полезно сразу замечать границы: можно ли перенести данные, изменить адреса страниц, настроить формы, добавить нужную интеграцию, сохранить доступ к содержимому при смене решения.
Инструмент не обязан подтверждать серьезность намерений. Он должен помогать сделать конкретную вещь и не скрывать цену будущих изменений.
№10. Если бы мне предложили выбрать между еще одним сертификатом и возможностью спокойно объяснить собственный сайт, я выбрал бы объяснение.
Почему в меню четыре пункта? Куда приходит заявка? Что увидит человек, если изображение не загрузится? Кто сможет поменять расписание?
Такие вопросы быстро показывают разницу между "я повторил" и "я понимаю". При этом ответы не обязаны быть сложными. "Здесь нет личного кабинета, потому что посетителю нужно только записаться" – вполне зрелое решение.
Мне нравится учиться через небольшую защиту своей работы перед самим собой. Без экзаменационного пафоса. Просто пройти по странице и назвать причину каждого заметного выбора.
А там, где причины нет, появляется хорошая следующая задача. Иногда разобраться. Иногда упростить. Иногда удалить элемент, который попал на сайт только потому, что был в уроке.
Неловкости, которые становятся опытом
Для узнаваемых постов о сомнениях, ошибках и первых профессиональных границах.
* Оставляйте герою право не знать, но показывайте следующий осмысленный шаг.
№11. У первого сайта бывает секретный второй заказчик – воображаемый опытный разработчик, который якобы все время смотрит через плечо.
Из-за него страшно выбрать простой инструмент, спросить очевидное, оставить спокойный дизайн без сложной анимации. Работа превращается в попытку выглядеть профессионально перед человеком, которого нет в комнате.
А реальному посетителю нужно узнать время приема. Он даже не догадывается, какой внутренний технический совет пришлось пережить ради этой страницы.
№12. Назвать файл "финал" – оптимизм. Назвать "финал_точно_этот" – опыт. Настроить понятную историю изменений – попытка наконец перестать вести переговоры с названиями файлов.
№13. Вообразите вечер перед первой сдачей проекта. Страница почти готова, но хочется добавить еще одну эффектную деталь: появление заголовка, движение фона, необычный переход между разделами.
Проблема не в самой анимации. Проблема в том, что форма пока не проверена, адрес в контактах скопирован из черновика, а мобильное меню открывалось только один раз.
У новичка легко возникает перекос: заметная работа кажется настоящей, проверочная – второстепенной. Новый эффект можно показать. Исправленную отправку формы почти невозможно эффектно продемонстрировать на картинке.
Но именно здесь начинается взросление в профессии. Не в отказе от красивого, а в способности сначала закончить необходимое.
Я бы хотел видеть больше рассказов о таких победах. Не только "освоил сложный прием", но и "проверил все ссылки", "понял, где сохраняются обращения", "попросил другого человека пройти сценарий без подсказок".
В этих действиях нет зрелищности, зато появляется ответственность за результат. И после них декоративный эксперимент уже не выглядит бегством от незавершенной работы. Он становится тем, чем и должен быть: осознанным дополнением, а не способом отложить неприятную проверку.
№14. Первый оплачиваемый сайт пугает не только сложностью. Пугает слово "нужно" вместо слова "попробую".
В учебном проекте можно сменить тему, бросить неудобную страницу, перенести все на потом. В работе для другого человека появляются срок, договоренности и зависимость чужих планов от твоего результата.
Мне кажется разумным начинать с небольшого понятного объема и честно называть границы опыта. Не обещать интернет-магазин со сложным учетом, если до этого была только страница-портфолио.
Честность не отменяет роста. Она делает его управляемым. Можно заранее привлечь более опытного специалиста к проверке, заложить время на тестирование, отдельно согласовать поддержку.
Первый заказ не обязан доказывать, что ты умеешь все. Гораздо важнее выполнить то, за что действительно взялся, и не исчезнуть при первом неудобном вопросе.
№15. Какую ошибку на своем первом сайте вы сейчас вспоминаете с улыбкой?
Не обязательно техническую. Возможно, вы спрятали контакты под названием "Коммуникационное пространство". Или поставили фоновую музыку и искренне считали, что посетители будут благодарны.
Мне интересны именно такие воспоминания: в них видно не только развитие инструментов, но и то, как меняется представление о человеке по другую сторону экрана.
№16. Папку с первой версией сайта хочется спрятать. Я бы все-таки оставил ее.
Не для публичного сравнения "было ужасно – стало прекрасно". В ранней работе видно, какие задачи тогда казались сложными, какие решения принимались случайно, а где уже появлялся собственный вкус.
Через время может обнаружиться неожиданное: технически страница была слабой, но текст – живым. Или сетка разваливалась, зато посетителю сразу было понятно, чем занимается автор.
Прогресс редко идет одинаково по всем направлениям. Можно научиться сложной верстке и одновременно начать писать тяжелее. Освоить эффекты и потерять ясность.
Поэтому старые работы полезны не только как нижняя ступень лестницы. Иногда они напоминают о хорошем качестве, которое случайно исчезло по дороге. Простоте, смелости, человеческом голосе. Его тоже стоит уметь переносить в следующие версии.
Глазами заказчика, который считает деньги
Эти посты про создание сайтов помогают говорить о бюджете, ожиданиях и ответственности без обещаний волшебного результата.
За что я готов платить
Для обсуждения ценности сайта и выбора разумного масштаба проекта.
* Привязывайте расходы к рабочей ситуации, а не к абстрактной престижности.
№17. Дорогой сайт не обязан быть большим. Иногда я скорее заплачу за пять продуманных страниц, чем за пятьдесят разделов, в которых мой клиент не найдет стоимость и условия работы.
№18. Когда мне называют цену сайта, я хочу понимать не только число экранов.
Кто разберется в услуге? Кто подготовит структуру? Входит ли перенос материалов? Что будет с формами, мобильной версией, настройкой доступа? Нужно ли отдельно оплачивать лицензии и дальнейшие изменения?
Одинаковая строка "разработка сайта" может скрывать совершенно разный объем. В одном предложении есть исследование и тестирование, в другом – только сборка по готовому макету.
Поэтому сравнение двух сумм без состава работ напоминает сравнение двух счетов за ремонт без понимания, что именно ремонтировали.
Мне не требуется длинное объяснение каждого движения мышкой. Нужна ясная граница: какой результат я получаю, что предоставляю сам и какие расходы могут появиться позже. Тогда разговор о цене становится нормальным деловым разговором, а не угадыванием чужой наценки.
№19. Допустим, небольшая мастерская решила заказать сайт. В первом списке пожеланий – каталог, блог, личный кабинет, программа лояльности и онлайн-конструктор изделия.
Звучит убедительно. Пока не появляется вопрос: кто будет все это поддерживать?
Фотографии делает владелец по вечерам. Цены меняются в переписке. Заказы рассчитываются индивидуально. Отдельного человека для публикаций нет. Получается, проект уже на старте требует от бизнеса нового режима работы, к которому тот не готов.
Я бы в такой ситуации сначала проверил более скромную версию: показать реальные изделия, объяснить порядок заказа, обозначить сроки и дать понятный способ отправить размеры или фотографию задачи.
Это не приговор сложным функциям. Возможно, они действительно понадобятся. Но сначала стоит увидеть, где возникает повторяющаяся нагрузка и какую часть процесса имеет смысл автоматизировать.
Есть неприятная ловушка: заказать функциональность легче, чем изменить собственную работу под нее. Разработка заканчивается, а обязательства только начинаются.
Поэтому в смете я ищу не максимум возможностей. Я ищу соответствие между возможностями сайта и готовностью бизнеса ими пользоваться. Маленькая рабочая система мне интереснее большой витрины будущих намерений, которую некому наполнять уже через месяц.
№20. "Сайт окупится за месяц" – обещание, после которого у меня возникает больше вопросов, а не доверия.
Откуда придут посетители? Какое предложение они увидят? Кто обработает обращения? Есть ли данные о спросе и цикле сделки?
Разработка может убрать препятствия и сделать путь к покупке понятнее. Но она не управляет всеми обстоятельствами бизнеса. Мне спокойнее работать с тем, кто называет зависимости, чем с тем, кто заранее гарантирует красивое число.
№21. Я хочу иметь право услышать от подрядчика: "Вам пока не нужен новый сайт".
Возможно, проблема в том, что на действующей странице устарели условия доставки. Или заявки приходят, но ответ уходит через два дня. Или реклама приводит людей, которым вообще нужна другая услуга.
Полная переделка выглядит солиднее небольшой правки. У нее есть презентация, этапы, торжественная дата запуска. Но масштаб проекта не делает диагноз точнее.
Для меня профессиональная позиция – сначала выяснить, где находится ограничение. Иногда действительно требуется другая архитектура. Иногда достаточно поправить содержание и наладить обработку обращений.
Я не жду бесплатного расследования на первой встрече. Я жду отсутствия автоматического ответа "нужно все снести". Сохранить работающую часть системы – тоже результат. Даже если его труднее показать эффектным сравнением двух главных страниц.
Договоренности до красивых макетов
Для постов о понятном процессе, материалах, сроках и приемке работы.
* Покажите, какое конкретное недоразумение снимает предварительный разговор.
№22. Самый полезный вопрос перед заказом сайта: "Что вы называете готовым?"
Для одного это утвержденный макет. Для другого – страницы на домене. Для третьего – еще и заполненный каталог, подключенная оплата, обучение сотрудника и месяц наблюдения за ошибками.
Никто не обязан угадывать чужое определение. Я предпочитаю выяснить его до первого платежа. Удивляться составу результата в день сдачи слишком дорого для обеих сторон.
№23. Фраза "материалы пришлем по ходу" звучит безобидно, пока не оказывается, что от материалов зависит весь сайт.
Допустим, в макете предусмотрены короткие названия услуг, а реальные состоят из десяти слов. Для карточек нужны горизонтальные фотографии, а у компании есть только вертикальные снимки с телефона. На странице обещан подробный процесс работы, но никто внутри бизнеса не может согласовать его описание.
Это не обязательно чья-то недобросовестность. Просто текст и изображения ошибочно воспринимаются как наполнение готовых ячеек. Хотя они часто определяют размер, порядок и сам смысл этих ячеек.
Как заказчик я хочу заранее знать, какие материалы нужны, в каком виде и кто отвечает за подготовку. Если текста нет, это отдельная работа. Если фотографии придется переснимать, это влияет на календарь.
И мне важно не соглашаться на удобную иллюзию: будто команда сейчас сделает все основное, а содержание мы потом быстро подставим. Иногда подставить действительно можно. Иногда после этого придется заново принимать ключевые решения.
Честный разговор о материалах менее эффектен, чем просмотр первых экранов. Зато он защищает проект от ситуации, когда красивые страницы уже согласованы, а реальный бизнес в них не помещается. В такой момент поздние правки становятся не капризом, а неизбежной расплатой за слишком раннюю определенность.
№24. Я не хочу быть единственным человеком в компании, который знает пароль от сайта. Но еще меньше хочу, чтобы единственным таким человеком был подрядчик, с которым мы закончили работать.
№25. На встрече легко сказать: "Мне нужно современно". Сложнее объяснить, что именно перестало устраивать.
Поэтому я бы принес не папку модных картинок, а несколько наблюдений. Клиенты не видят филиал рядом с собой. Менеджеры каждый день объясняют порядок возврата. На телефоне невозможно прочитать таблицу размеров. Редактор боится менять цены, потому что после сохранения что-нибудь съезжает.
Такие формулировки не мешают дизайну. Они дают ему опору.
Красивый пример тоже полезен, если назвать, что в нем нравится: спокойный ритм, крупные фотографии, понятная навигация, способ показать сложный товар. Иначе команда вынуждена угадывать, что скрывается за словом "вот так".
Мне кажется, хорошее задание начинается не с уверенного владения профессиональными терминами. Оно начинается с честного описания своей ситуации и готовности ответить на уточняющие вопросы.
№26. Если проект согласуют пять человек, я хочу заранее знать, кто принимает окончательное решение.
Иначе дизайнер получает одновременно "слишком пусто", "слишком плотно", "нужен красный" и "красный исключить". Затем кто-то объединяет все замечания в один документ и называет это обратной связью.
Коллективное участие полезно, когда у каждого есть своя область ответственности. Проверка юридического текста и выбор отступа – не один и тот же тип решения. Смешивать их в общий конкурс вкусов необязательно.
№27. Представим приемку сайта без демонстрации "все работает, я сейчас покажу".
Заказчик сам открывает страницу с телефона. Находит нужную услугу. Отправляет тестовое обращение. Получает его в согласованном канале. Меняет время работы в редакторе. Проверяет, что изменение появилось там, где должно.
Это менее эффектно, чем экскурсия по анимациям, зато многое проясняет.
На приемке хочется увидеть именно свою будущую жизнь с сайтом. Не только результат глазами посетителя, но и действия сотрудника, которому придется отвечать за содержание. Сколько шагов занимает обычное обновление? Что можно случайно сломать? Есть ли инструкция для редких задач?
Я не жду, что любая система будет понятна без объяснений. Но объяснения должны существовать, а доступы – проверяться до завершения сотрудничества.
Для меня сдача проекта заканчивается не аплодисментами главной странице. Она заканчивается моментом, когда результат можно использовать без постоянного присутствия его создателя рядом.
Сомнения, которые нормально произносить
Для честного разговора о выборе подрядчика, рисках и ограничениях бюджета.
* Давайте сомнению конкретный предмет и избегайте образа неразумного клиента.
№28. Меня настораживает не уточняющий вопрос подрядчика, а мгновенная уверенность после двух предложений о бизнесе.
Если человек спрашивает про каталог, оплату, сотрудников и обработку заявок, он не обязательно усложняет продажу. Возможно, он пытается понять, что именно предстоит создать.
Профессионал не обязан сразу знать ответ. Но мне важно видеть, как он добывает недостающую информацию и где проводит границу между известным и предположением.
№29. Хочу сайт "как у конкурента", но без его ошибок, внутренних процессов и бюджета. Когда произносишь просьбу целиком, становится понятно, почему одной ссылки для хорошего задания недостаточно.
№30. Допустим, у компании есть деньги только на первый этап. Это не повод делать вид, что ограничений нет.
Я бы предпочел разговор о приоритетах: какой сценарий нужен сейчас, что можно отложить, какие решения потом придется переделывать, а какие спокойно выдержат развитие.
Например, можно начать без автоматического расчета сложной услуги, но с удобной отправкой исходных данных. Можно не запускать большой журнал, но сразу предусмотреть понятные адреса страниц. Можно ограничить каталог, не превращая его структуру в тупик.
Самое неприятное в экономии – не отсутствие некоторых функций. Неприятно узнать через полгода, что временное решение выдавали за окончательное, а путь расширения даже не обсуждали.
Я не прошу предсказать будущее бизнеса. Мне достаточно честно обозначить несколько вероятных развилок. Если ассортимент вырастет, понадобится это. Если появятся другие языки – изменится то. Если останется нынешний масштаб, текущего решения может хватить надолго.
Так ограниченный бюджет перестает быть стыдной темой. Он становится обычным условием проектирования. И вместо торга за каждую кнопку появляется более полезный разговор: на что сейчас действительно стоит потратить деньги, а что пока останется осознанно нереализованным. Такой выбор проще защищать и внутри компании, и перед собой после запуска.
№31. Я не умею оценивать аккуратность кода по фотографии экрана. Поэтому при выборе исполнителя смотрю не только портфолио.
Мне важно, как человек объясняет ограничения, фиксирует договоренности и отвечает на неудобный вопрос. Что происходит, если сроки сдвигаются? Как оформляются дополнительные задачи? Кто исправляет ошибку после сдачи?
Красивые работы подтверждают одну часть компетенции. Но сайт создается в процессе общения, а потом живет в реальной эксплуатации.
Я скорее доверюсь спокойному объяснению с оговорками, чем речи, в которой любой проект легкий, любой срок реальный, а проблем не бывает.
Не потому, что хочу заранее готовиться к провалу. Наоборот: мне нужен партнер, который замечает риски достаточно рано, чтобы с ними можно было что-то сделать. Уверенность без конкретики не дает такого ощущения.
№32. Что для вас стало бы причиной отказаться от подрядчика еще до договора: непонятная смета, обещание любого результата, отсутствие вопросов о задаче или требование оформить домен только на его аккаунт?
Мне интересно, как меняется этот список после первого собственного проекта. Подозреваю, опыт сильнее всего влияет не на выбор цветов в портфолио, а на внимание к тому, о чем сначала вообще не думаешь.
Глазами дизайнера и редактора
В этом ракурсе посты про создание сайтов раскрывают решения, которые стоят за внешне простой страницей.
Когда красота спорит с задачей
Для профессиональной позиции о визуальном выборе и смысле интерфейса.
* Сопоставляйте эффект на макете с действием реального посетителя.
№33. Большой пустой первый экран может выглядеть роскошно. Особенно если не нужно срочно выяснить, ремонтирует ли компания именно твою модель оборудования.
Я не против воздуха, крупных букв и смелой композиции. Я против ситуации, когда визуальное настроение занимает все пространство, а предмет предложения приходится разыскивать.
У разных сайтов разные задачи. У авторского проекта допустима интрига. У аварийной службы она способна мешать. Один прием не становится хорошим только потому, что красиво смотрится в презентации.
№34. В воображаемом обсуждении макета звучит просьба: "Сделаем кнопку тише, она слишком заметная".
Дизайнер может послушно уменьшить контраст. А может сначала спросить, какое действие на этой странице главное.
Если человек пришел записаться, заметная запись не обязательно портит композицию. Возможно, композицию нужно строить вокруг нее, а не прятать действие ради спокойной картинки. Если же страница знакомит с исследованием и пока ничего не предлагает купить, агрессивная кнопка действительно выглядит чужой.
Мне интересен дизайн, в котором решения можно обсуждать через роль элемента. Не "мне нравится зеленый", а "это действие должно отличаться от второстепенных". Не "давайте крупнее", а "эту информацию сейчас пропускают".
Такой разговор не отменяет вкус. У одной задачи могут быть несколько убедительных визуальных ответов. Но появляется общая точка опоры, помимо личных предпочтений участников встречи.
И еще становится проще отказываться от эффектных находок. Если красивый прием мешает понять порядок действий, его удаление не обязательно означает творческое поражение.
Иногда самое взрослое решение дизайнера – не доказать ценность любимой детали, а заметить, что без нее страница работает яснее. Это трудно показать отдельным слайдом в портфолио. Зато очень легко почувствовать, когда пользуешься результатом без сопровождающего объяснения.
№35. Не каждый пустой участок страницы нужно срочно занимать. Иногда это место, где читатель успевает понять предыдущую мысль, прежде чем на него нападет следующая.
№36. Мне нравится типографика, которую замечаешь не сразу.
Читаешь длинное описание услуги, не теряешь строку, отличаешь примечание от основного текста, быстро находишь нужный подзаголовок. И только потом понимаешь, сколько решений обеспечили это спокойствие.
Размер букв сам по себе ничего не гарантирует. Важны длина строки, расстояния, контраст, иерархия, поведение текста на узком экране. Даже хороший шрифт можно поставить в условия, где читать будет тяжело.
Поэтому я настороженно отношусь к оценке страницы только по уменьшенному скриншоту. На нем виден общий рисунок, но почти не чувствуется чтение.
Сайт нужно рассматривать в реальном размере и с реальным содержанием. Желательно не только свежими глазами автора, который знает текст наизусть. Красота букв раскрывается там, где человек перестает бороться с ними за доступ к смыслу.
№37. "Сделайте необычное меню" – просьба с интересной ценой.
Посетитель приходит за услугой, а получает маленький урок управления интерфейсом. Иногда это оправдано: эксперимент сам является частью авторского высказывания. Но у обычного рабочего сайта такая плата может оказаться лишней.
Я люблю смелый дизайн. Просто различаю смелость в образе и неожиданность в базовом действии. Узнаваемая навигация не запрещает характер.
Текст, который перестает изображать компанию
Для наблюдений о языке сайта, содержании и честных формулировках.
* Сравнивайте слова с вопросом, который человек пытается решить.
№38. "Мы предлагаем комплексные решения" – фраза, после которой я все еще не знаю, куда попал.
Что именно делает компания? Для кого? С какой задачей к ней можно прийти? Иногда ответы есть уже во втором абзаце, но первый занят торжественным выходом на сцену.
Мне ближе начало, которое не стесняется назвать предмет работы: устанавливаем вентиляцию в небольших кафе, ремонтируем деревянные окна, помогаем подготовить документы для определенной процедуры.
Конкретность не делает компанию маленькой. Она делает ее понятной.
На сайте у текста нет гарантированного терпеливого слушателя. Человек может открыть несколько вкладок и сравнивать предложения. Если одна страница объясняет дело, а другая описывает собственную исключительность, выбор иногда происходит еще до знакомства с ценой.
Не каждый первый экран должен продавать. Но хотя бы представиться по существу ему точно не помешает.
№39. Вообразите страницу услуги с заголовком "Индивидуальный подход к каждому клиенту". Ниже – форма на двенадцать обязательных полей.
Посетитель еще не понял, подходит ли ему компания, но уже должен сообщить должность, бюджет, сроки, размер команды и удобный способ связи. Слова обещают внимание к человеку, интерфейс требует внимания к внутренней анкете.
Здесь редакторская работа не заканчивается заменой заголовка. Можно написать теплее, но противоречие останется. Нужно обсудить, какие сведения действительно необходимы для первого ответа, а какие менеджер уточнит позже.
Мне нравится рассматривать содержание и интерфейс вместе. Подпись поля объясняет, что вводить. Пример снимает двусмысленность. Сообщение об ошибке помогает исправить конкретное место. Текст после отправки сообщает, что произойдет дальше.
Все это не мелкие слова вокруг настоящего дизайна. Это и есть часть взаимодействия.
Самая убедительная забота на сайте часто выражается без слова "забота". Например, когда человеку не приходится угадывать формат даты. Когда введенные данные не исчезают после ошибки. Когда обязательное поле действительно нужно, а не просто однажды попало в шаблон.
Мне интереснее такая согласованность, чем идеально отредактированный лозунг над неудобным действием. Потому что посетитель проверяет обещание компании сразу – буквально следующими движениями пальца.
№40. Кнопка "Подробнее" иногда сообщает удивительно мало. Подробнее о цене, составе услуги, доставке или биографии автора? Два дополнительных слова могут избавить посетителя от маленькой лотереи.
№41. В черновике сайта легко написать: "Текст будет позже". Но позже выясняется, что именно текст должен объяснить самое сложное.
Почему услуга стоит дороже соседней? Чем отличаются два похожих тарифа? Что входит в подготовку? Когда компания не сможет помочь?
Я предпочитаю приносить в макет хотя бы рабочие ответы, а не ровные прямоугольники из случайных фраз. Настоящее содержание бывает длиннее, неудобнее и полезнее. Значит, дизайн должен встретиться с ним достаточно рано.
№42. Страница "О компании" не обязана начинаться с года основания.
Иногда важнее показать, кто будет отвечать на запрос. Или объяснить, почему команда работает только с определенными задачами. Или честно рассказать, как устроена проверка результата.
Меня как читателя редко убеждает перечень прилагательных о самой компании. Зато помогают детали, которые можно сопоставить с моей ситуацией: реальные роли людей, понятный процесс, фотографии рабочего места, границы ответственности.
История основания тоже может быть интересной. Особенно если в ней есть решение, которое продолжает влиять на работу сейчас. Но сама по себе давняя дата не отвечает на вопрос, почему мне стоит обратиться сюда.
Мне нравится, когда эта страница не изображает торжественный портрет организации, а знакомит с людьми и способом работы. После нее должно становиться понятнее, с кем предстоит иметь дело, а не только сколько раз компания назвала себя надежной.
№43. Самый полезный кусок текста на сайте иногда выглядит непрезентабельно: "Не работаем с изделиями после самостоятельной разборки".
В нем нет вдохновения, зато есть граница. Она может сэкономить человеку поездку, а сотруднику – сложный разговор у стойки.
Я за заметные ограничения, если они действительно существуют. Не прятать их в подвале ради красивого первого впечатления. Разочарование после обращения обычно обходится дороже честного уточнения до него.
Рабочие решения без конкурса вкусов
Для рассказов о согласовании, системе компонентов и содержательной обратной связи.
* Переводите оценку из "нравится" в наблюдение, которое можно проверить.
№44. Представим, что на согласовании карточку услуги назвали "скучной".
Это может означать совершенно разные вещи: не видна разница между предложениями, изображение не вызывает доверия, заголовок слишком общий, визуально все сливается. А может означать просто личную усталость от спокойных цветов.
Если сразу добавить градиент, получится ответ на невыясненный вопрос.
Мне ближе короткая пауза: что именно человек не заметил или не понял? Какую информацию должен был считать? Где ожидал увидеть отличие?
Разговор после этого обычно становится предметнее. Можно сравнить варианты на одном и том же содержании, проверить контраст, поменять порядок данных, убрать повторяющиеся подписи.
Это не попытка запретить эмоции на согласовании. Первое впечатление важно. Просто его полезно расшифровать, прежде чем превращать в задачу.
Дизайнер тоже не получает права отбиваться словами "так правильно". Если решение нельзя связать с задачей, ограничением или понятным принципом, возможно, это действительно личный выбор автора.
Мне нравится процесс, где у обеих сторон есть обязанность объясняться. Заказчик описывает проблему точнее, дизайнер не прячет вкус за профессиональным словарем. Тогда даже несогласие помогает странице, а не превращает ее в памятник последнему участнику, который громче всех высказался.
№45. Единая система кнопок нужна не для того, чтобы все страницы были одинаковыми. Она нужна, чтобы одинаковое действие не приходилось каждый раз узнавать заново.
№46. У дизайнера есть особый вид боли: идеальная карточка с названием "Стул" встречает реальный товар с названием в три строки.
Потом появляется товар без фотографии. Потом цена по запросу. Потом скидка, старая цена, статус наличия и длинная характеристика.
И оказывается, что проектировалась не карточка, а один удачный пример.
Мне нравится проверять компоненты на неудобном содержании. Самое длинное название, отсутствие данных, несколько меток, нестандартное изображение. Не чтобы испортить красивую картинку, а чтобы найти пределы решения до сборки всего каталога.
Хорошая система не обязана одинаково красиво выдерживать абсолютно любой хаос. Но у нее должны быть понятные правила: что обрезается, что переносится, где показывается запасной вариант, какие данные обязательны.
Реальная жизнь сайта начинается там, где заканчивается специально подобранный контент презентации. Лучше познакомить их заранее.
№47. Я не считаю темную тему обязательным признаком современного сайта.
Для одного проекта она действительно удобна и уместна, для другого создает дополнительный объем проверки без заметной пользы. Нужно заново оценивать контраст, изображения, состояния элементов, поведение встроенных компонентов.
Мне интересен не сам переключатель с луной, а причина его появления. Если причина только "у всех есть", это пока не задача, а наблюдение за соседями.
№48. На сайте с несколькими языками переводится не только текст.
Меняется длина заголовков. Другими становятся привычные форматы дат и чисел. Иногда требуется иное направление письма. Изображение с надписью внезапно оказывается отдельным материалом, который тоже нужно готовить.
Я люблю момент, когда команда перестает считать вторую языковую версию копией первой. Это самостоятельный опыт человека, который не обязан разбираться в исходной логике проекта.
Даже переключение языка заслуживает внимания: останется ли посетитель на той же странице или попадет на главную? Что произойдет, если перевод конкретного материала пока отсутствует?
Такие вопросы не выглядят эффектно на презентации. Зато именно по ним видно, насколько серьезно сайт встречает другую аудиторию. Не просто вывесил приветствие на ее языке, а действительно подготовил путь дальше.
Глазами разработчика за кулисами
Здесь посты про создание сайтов показывают невидимую работу: проверки, технические компромиссы и заботу о будущих изменениях.
То, чего не видно на скриншоте
Для объяснения технической работы через последствия, понятные неспециалисту.
* Начинайте с видимого действия и раскрывайте скрытую зависимость.
№49. Кнопка отправки формы занимает на экране несколько сантиметров. За ней помещается удивительно много вопросов.
Что считать корректными данными? Как защититься от автоматического мусора? Где хранить обращение? Кому сообщать о новом запросе? Что делать, если почтовая отправка временно не сработала? Как не отправить одну заявку дважды?
Поэтому просьба "там же просто кнопочка" не очень помогает оценить работу.
Я понимаю, откуда она возникает: посетитель действительно видит один клик. И хорошо, когда ему не приходится думать об остальном. Но простота действия снаружи часто появляется благодаря вниманию к сложностям внутри.
Мне нравится разработка, которая не демонстрирует свою трудность пользователю. Форма не обязана выглядеть серьезной, чтобы быть надежно спроектированной. Достаточно спокойно принять данные, объяснить результат и не потерять обращение по дороге.
№50. На моем компьютере сайт работает. Теперь осталось проверить небольшой нюанс: все остальные компьютеры, телефоны, скорости связи и способы, которыми люди способны нажать не туда.
№51. Представьте: посетитель заполнил форму, нажал кнопку и увидел бесконечное вращение значка.
Заявка ушла или нет? Нажать еще раз? Обновить страницу? Подождать? Внутри системы могло произойти что угодно, но снаружи возникла одна большая неопределенность.
Вот почему мне интересны не только успешные сценарии. Ошибка соединения, медленный ответ, повторное нажатие, временная недоступность сервиса – это не экзотика из лаборатории. Это нормальная среда, в которой сайт будет жить.
Хорошее поведение не сводится к красному сообщению "Что-то пошло не так". Иногда можно сохранить введенные данные. Иногда предложить повторить действие. Иногда показать другой способ связи. Важно не обещать успех, если его подтверждения нет.
И отдельно – не создавать дублей там, где повторное действие имеет последствия, особенно при оплате.
Я не жду, что сайт победит любую техническую проблему. Но он может перестать перекладывать всю неопределенность на человека. Если система знает, что происходит, пусть объяснит. Если не знает – пусть честно обозначит это и предложит безопасный следующий шаг.
Такая работа почти не видна на красивых экранах. Зато именно она определяет впечатление в тот момент, когда идеальный путь закончился. А в реальной эксплуатации этот момент обязательно наступает, вопрос только в том, насколько подготовленно сайт его встретит.
№52. Фотография может быть прекрасной и все равно оказаться слишком тяжелой для страницы.
Особенно обидно, когда посетитель скачивает огромный исходник ради небольшой картинки в карточке. Он платит временем и трафиком за детализацию, которой даже не увидит.
Мне нравится оптимизация без героизма: подходящий размер, разумное сжатие, современные форматы там, где они поддерживаются, отложенная загрузка второстепенного. Иногда ускорение начинается не с хитрого кода, а с вопроса: зачем мы вообще отправляем столько лишнего?
№53. Самая неприятная особенность кэша – он может честно показывать старую версию, пока ты уже отчаянно исправляешь новую.
Отсюда рождается знакомый разговор: "Я поменял". – "У меня без изменений". – "А теперь?"
Но кэш не враг. Он помогает не загружать заново то, что можно использовать повторно. Проблема начинается, когда никто не подумал, как обновления будут доходить до посетителя.
Мне нравится рассматривать это как часть публикации, а не как случайную неприятность после нее. Изменились стили – как браузер узнает о новой версии? Обновилась цена – где она может задержаться? Есть ли промежуточные слои хранения?
Для человека снаружи не существует оправдания "это у вас закэшировалось". Есть сайт, который показывает не то. Поэтому техническое объяснение полезно команде, но не заменяет продуманного поведения системы.
Выбор инструмента без религиозной войны
Для спокойной позиции о технологиях, готовых решениях и цене сложности.
* Обсуждайте ограничения задачи, а не превосходство любимого инструмента.
№54. Мне не нужен самый модный стек для страницы с расписанием кружка. Мне нужно, чтобы расписание можно было поменять в четверг вечером, не разыскивая автора проекта по всем мессенджерам.
№55. Спор "конструктор или собственная разработка" часто начинается раньше, чем появляется сама задача.
Для небольшого сайта готовая платформа может сократить запуск и упростить редактирование. Для сложного процесса ее ограничения способны стать дорогими. Собственная разработка дает больше контроля, но приносит ответственность за поддержку, безопасность и передачу проекта другим специалистам.
Я не вижу здесь универсального победителя.
Меня интересует другое: кто будет работать с сайтом, какие изменения вероятны, какие интеграции обязательны и насколько критична возможность переноса. Иногда удобство сегодняшнего старта важнее гибкости, которая никогда не понадобится. Иногда зависимость от закрытой платформы недопустима уже сейчас.
Хороший выбор не всегда выглядит технически впечатляющим. Зато его можно объяснить без фразы "мы всегда так делаем". Это, пожалуй, и отличает решение под задачу от привычки, которую выдали за стратегию.
№56. Допустим, для нового сайта предлагают установить готовое дополнение ради одной небольшой функции.
На демонстрации все прекрасно: несколько минут настройки, нужный блок появился, задача закрыта. Но после первого удобного шага начинается менее зрелищная часть выбора.
Кто поддерживает дополнение? Как часто выходят обновления? Какие доступы оно получает? Совместимо ли с остальными частями системы? Что произойдет, если разработчик прекратит работу? Не загружает ли оно на каждую страницу значительно больше, чем нужно ради одной функции?
Это не аргумент писать все самостоятельно. Самописное решение тоже требует времени, проверки и дальнейшего сопровождения. Иногда готовый инструмент действительно разумнее.
Мне просто не нравится считать стоимость только по моменту установки. У зависимости есть будущая жизнь: обновления, конфликты, изменения лицензии, перенос данных, возможная замена.
Поэтому вопрос "можно ли быстро добавить?" я стараюсь отделять от вопроса "стоит ли это добавлять именно так?". Первый про техническую возможность. Второй про ответственность за систему целиком.
Быстрое решение не обязано быть плохим. Но хорошо, когда его скорость не оплачивается неизвестными обязательствами человека, который получит сайт после нас. Иногда самый полезный результат обсуждения – выбрать другой способ. А иногда – оставить готовый модуль, но заранее записать, как его обновлять и чем можно заменить.
№57. Сгенерированный код способен быстро дать рабочую заготовку. Он не снимает с разработчика обязанность понять, что именно оказалось в проекте.
Я бы не отправлял в работу фрагмент только потому, что он уверенно выглядит и прошел один удачный запуск. Нужны проверка зависимостей, обработка ошибок, оценка безопасности и соответствия задаче.
Ускорить набор кода полезно. Ускорить передачу непроверенных предположений посетителям – уже совсем другая история.
№58. Больше всего в чужом проекте я ценю не демонстрацию технической изобретательности, а возможность разобраться без археологической экспедиции.
Понятные названия. Предсказуемая структура. Короткая инструкция запуска. Объяснение необычного решения там, где оно действительно необычное. Актуальный список необходимых доступов без самих секретов в открытых файлах.
Ни один из этих пунктов не делает скриншот красивее. Зато следующий разработчик быстрее поймет, что можно менять, а что связано с важным ограничением.
Мне кажется, поддерживаемость – это форма профессиональной вежливости. Не абстрактной, а очень практичной: не заставлять другого человека заново оплачивать временем все твои незафиксированные догадки.
И этим другим человеком вполне можешь оказаться ты сам через полгода. Собственная память удивительно быстро превращает очевидные решения в загадки с авторской подписью.
Ошибки, проверки и спокойная сдача
Для рассказов о надежности, технических рисках и культуре работы.
* Показывайте не подвиг исправления, а условия, которые уменьшают вероятность аварии.
№59. Красивый сайт может упасть не от наплыва покупателей, а от незамеченного заполнения диска.
Поэтому мне трудно считать наблюдение за системой необязательной роскошью. Логи растут, резервные копии занимают место, сертификаты требуют продления, внешние сервисы меняют условия.
У каждого проекта свой масштаб контроля. Но идея "один раз запустили – дальше само" слишком оптимистична даже для небольшой страницы с формой. Техника не обязана ломаться драматично, чтобы причинить вполне реальное неудобство.
№60. Люблю резервные копии. Особенно те, из которых уже пробовали восстановиться. Остальные пока больше похожи на обещание спокойствия, чем на проверенный план.
№61. Представим, что после обновления сайт начал показывать ошибку. У команды есть две возможные истории.
В первой все меняли прямо на рабочей версии. Никто точно не помнит порядок действий. Резервная копия вроде бы где-то есть, но доступ к ней у человека, который сейчас недоступен. Любая новая попытка исправления добавляет неизвестности.
Во второй изменения сначала проверили отдельно, сохранили рабочее состояние и заранее определили способ возврата. Проблема все равно неприятная, но у нее есть границы.
Мне не нравится романтика ночного спасения сайта, когда она становится постоянной моделью работы. Иногда аварии действительно непредсказуемы. Но иногда героизм просто маскирует отсутствие обычной подготовки.
Отдельная среда для проверки, понятная история изменений, резервное копирование и план отката не гарантируют безошибочность. Они делают ошибку менее разрушительной.
И еще дают команде право действовать спокойно. Не выбирать между "срочно попробуем что-нибудь" и "пусть все остается сломанным", а вернуться в известное состояние и продолжить разбираться.
Для меня профессиональная зрелость здесь измеряется не количеством пережитых бессонных ночей. Скорее тем, сколько таких ночей удалось не устроить ни себе, ни заказчику. Это скучная метрика для эффектного рассказа, зато очень приятная для людей, чей бизнес зависит от доступности сайта.
№62. Тестовая среда становится опасной, когда в нее без необходимости переносят реальные личные данные.
Разработчикам нужны правдоподобные сценарии, а не чужие телефоны и переписка по умолчанию. Часто задачу можно решить обезличенными или специально подготовленными данными.
Я хочу, чтобы вопрос "что мы копируем для проверки?" возникал до переноса, а не после случайно открытого доступа. Удобство команды не должно автоматически перевешивать приватность людей, которые вообще не участвуют в разработке.
№63. "Почти готово" в разработке иногда означает, что все красивые случаи уже работают, а неудобные еще даже не открывали.
Пустой каталог. Слишком длинное имя. Неверный адрес почты. Пропавшее изображение. Пользователь без нужных прав. Внешний сервис, который отвечает медленнее обычного.
Мне помогает отдельно смотреть на такие состояния, а не надеяться, что они сами будут похожи на успешное. Они часто требуют другого текста, другого действия и другого уровня осторожности.
Это особенно заметно в интерфейсах управления. Сотрудник должен понимать не только как сохранить запись, но и почему сохранение не удалось. Что исправить, что уже записано, что безопасно повторить.
Завершенность сайта для меня связана не с отсутствием пустых мест в макете. Она связана с тем, насколько осмысленно система ведет себя, когда реальность перестает соответствовать идеальному примеру.
№64. Какой рабочий ритуал вы бы оставили, даже если никто не проверяет: отдельный просмотр изменений, тест формы после публикации, проверку восстановления или запись причин необычного решения?
Мне нравятся привычки, которые выглядят избыточными ровно до первого случая, когда спасают день. Особенно если их можно выполнить за несколько минут, а последствия пропуска потом приходится разбирать несколько часов.
Глазами посетителя, которому просто нужно решить задачу
Такие посты про создание сайтов смещают внимание с авторских намерений на условия, в которых страницу действительно открывают.
Телефон, спешка и слабая связь
Для узнавания повседневных ситуаций, которые редко видны на презентации сайта.
* Поместите человека в конкретные условия и дайте интерфейсу проявить характер.
№65. Я открываю сайт одной рукой в автобусе. Если для закрытия окна нужно попасть в крестик размером с крошку, наше знакомство уже проходит не в самых дружелюбных обстоятельствах.
№66. Допустим, человек ищет ближайшую мастерскую, стоя у закрытой двери другой мастерской.
Ему не нужен захватывающий первый экран. Нужны часы работы, адрес, понятный номер телефона и подтверждение, что сегодня можно прийти.
Он открывает сайт. Сначала появляется предложение подписаться на новости. После закрытия – окно о специальной акции. Затем страница немного сдвигается, потому что загрузился баннер. Вместо контактов палец попадает на другой элемент.
Каждая отдельная часть интерфейса могла пройти согласование. Все вместе они превращают простую задачу в полосу препятствий.
Я часто думаю о том, что сайт проверяют сидя, в спокойствии, с хорошим интернетом. А пользуются им возле дороги, между встречами, с разряженным телефоном и очень ограниченным терпением.
Это не значит, что любой проект должен стать голым списком ссылок. Это значит, что важная информация должна переживать неидеальные условия.
Если человек пришел с конкретным вопросом, дайте ему сначала получить ответ. Знакомство с брендом не обязано начинаться с задержания у входа. Иногда самое приятное впечатление оставляет сайт, который не заставил заметить собственную сложность, не потребовал лишних решений и помог быстро продолжить день.
№67. На мобильном сайте меня особенно раздражает не длинная страница, а непредсказуемая.
Нажимаешь на ссылку – под пальцем внезапно вырастает блок. Читаешь цену – ее закрывает плавающая панель. Возвращаешься назад – оказываешься не там, откуда ушел.
Прокрутить еще немного обычно несложно. Гораздо тяжелее постоянно восстанавливать контроль. Мне хочется, чтобы интерфейс не менял правила в момент действия.
№68. Слабая связь быстро объясняет, какие части сайта были действительно важными.
Если текст читается, контакты доступны, а изображения постепенно догружаются, я могу решить задачу. Если весь экран ждет тяжелый эффект, я просто смотрю на ожидание.
Мне нравится принцип: основное должно появляться раньше украшений. Не потому, что украшения бессмысленны, а потому, что посетитель не обязан оплачивать знакомство с ними невозможностью пользоваться страницей.
Это особенно заметно в дороге, в загруженной сети, на недорогом устройстве. У команды разработки может быть быстрый компьютер и стабильный канал. У человека снаружи – совсем другие условия.
Поэтому проверка сайта на слабом соединении кажется мне не техническим перфекционизмом, а способом на время отказаться от собственных привилегий. И увидеть, что именно мы отправляем людям вместе с обещанием удобства.
№69. Я не хочу скачивать меню кафе отдельным тяжелым файлом, чтобы узнать, есть ли там суп.
Файл может быть полезен для печати или подробного просмотра. Но на телефоне мне часто достаточно обычной страницы: названия, цены, состав, понятные разделы.
Особенно если документ сверстан так, что приходится увеличивать каждую строку и двигать ее из стороны в сторону. Удобство владельца при загрузке файла еще не означает удобство гостя при чтении.
Когда привычный способ не подходит
Для человеческого разговора о доступности и разных способах взаимодействия.
* Показывайте барьер через действие, не превращая человека в повод для жалости.
№70. Попробуйте мысленно пройти сайт без мыши. Не из спортивного интереса: у человека может быть другой способ управления, временная травма или просто привычка работать с клавиатуры.
Куда попадет фокус? Видно ли его? Можно ли открыть меню, выбрать пункт, закрыть диалог, отправить форму? Не окажется ли посетитель заперт внутри всплывающего окна?
Мне нравится, что такая проверка быстро делает слово "доступность" конкретным. Это уже не отдельная благотворительная функция. Это вопрос, разрешает ли сайт выполнить обычное действие другим способом.
И часто улучшение оказывается полезным гораздо более широкому кругу людей, чем предполагалось. Понятный порядок, заметные состояния, предсказуемое управление не мешают никому.
Доступность начинается не с торжественного заявления о внимании ко всем. Она начинается с того, что кнопка остается кнопкой, даже когда по ней не щелкают мышью.
№71. Бледно-серый текст может выглядеть деликатно. Но если я увеличиваю яркость экрана, чтобы прочитать условия доставки, деликатность досталась дизайну, а усилие – мне.
№72. Представим сайт записи, где обязательные поля отмечены только красным цветом.
Для автора макета различие очевидно. Для другого человека оно может быть слабым или вообще недоступным. А если после отправки появляется лишь красная рамка, приходится угадывать еще и причину ошибки.
Мне кажется важным не полагаться на один способ передачи смысла. Цвет может помогать, но текстовая подпись и понятное сообщение делают состояние гораздо яснее.
То же происходит с иконками. Знакомый разработчику символ не обязан быть знаком посетителю. Особенно если он обозначает не общепринятое действие, а внутреннюю идею проекта.
Доступность здесь не добавляется отдельной кнопкой поверх готовой страницы. Она заложена в том, как названы элементы, связаны подписи и поля, устроен порядок движения, объясняются ошибки.
И я бы не сводил ее к одному автоматическому отчету. Проверка инструментом полезна, но не заменяет прохождение реальной задачи. Можно формально закрыть отдельные пункты и все равно оставить человека перед непонятным выбором.
Хороший вопрос звучит проще профессиональных терминов: сможет ли посетитель понять, что происходит, и продолжить действие без догадки о замысле автора? Чем чаще команда задает его по ходу работы, тем меньше потом приходится исправлять в самом основании интерфейса.
№73. Описание изображения нужно не для того, чтобы механически произнести все видимые предметы.
Если фотография показывает способ крепления детали, важно передать именно это. Если она просто украшает фон, подробный словесный каталог может только мешать. Если на картинке написано существенное условие, спрятать его внутри изображения особенно неудачно.
Мне нравится смотреть на альтернативный текст как на редакторскую задачу: какой смысл потеряет человек, если не увидит картинку? Ответ зависит от контекста, а не только от содержимого файла.
№74. На сайте все движется: заголовки приезжают, карточки подпрыгивают, фон поворачивается вслед за указателем.
Для кого-то это удовольствие. Для кого-то – лишняя нагрузка или физически неприятный опыт. Мне важно, чтобы уважение к предпочтению уменьшенного движения было частью реализации, а не случайным бонусом.
Анимация может объяснять связь между состояниями, показывать результат действия, поддерживать характер проекта. Но ей не обязательно постоянно требовать внимания.
Особенно спорно выглядит движение, которое невозможно остановить, пока читаешь. Получается, автор решает за посетителя, сколько визуальных событий тот должен выдержать одновременно.
Я за право сайта быть выразительным и за право человека воспринимать его спокойнее. Эти интересы не обязаны конфликтовать. Иногда достаточно более сдержанного варианта перехода, отказа от бесконечного фонового эффекта и уважения к настройкам устройства.
Доверие, выбор и право уйти
Для позиции против манипуляций и за понятное взаимодействие с компанией.
* Обсуждайте конкретный прием и его цену для отношений с посетителем.
№75. Если кнопка отказа от рассылки написана как "Нет, я не хочу выгодно покупать", это не остроумие за мой счет. Это причина закрыть окно вместе с доверием.
№76. Я могу спокойно отнестись к просьбе оставить телефон. Но хочу понимать, зачем он нужен именно сейчас.
Для согласования доставки – понятно. Для доступа к обычному прайс-листу – уже вопрос. Для чтения описания услуги – еще больший.
Каждое обязательное поле просит у человека не только данные, но и доверие. Мне нравится, когда сайт объясняет цель без туманных формулировок и не собирает сведения просто потому, что однажды они могут пригодиться.
Чем раньше происходит знакомство, тем осторожнее стоит быть с требованиями. Посетитель еще оценивает компанию, а не вступает с ней в долгие отношения автоматически.
Иногда отсутствие лишнего поля говорит о внимании лучше целого абзаца о заботе. Особенно если рядом есть ясное объяснение, как будет использовано то, что действительно необходимо сообщить.
№77. Представим покупку, в которой до последнего шага все выглядит недорого.
Товар выбран, данные заполнены, способ получения указан. И только перед оплатой появляются дополнительные обязательные расходы, которые можно было назвать раньше.
Технически человек еще может отказаться. Но его уже провели через действия, использовали внимание и создали ощущение почти завершенного решения. Это не тот опыт, который хочется вспоминать как честный.
Я понимаю, что итоговая стоимость иногда зависит от адреса, веса, времени или состава заказа. Не все можно вычислить на первом экране. Но зависимость можно объяснить заранее, а известные обязательные платежи – не прятать.
Тот же принцип относится к подпискам. Разовая оплата и регулярное списание должны различаться не только мелкой строкой. Человек должен понимать, на что соглашается и как затем прекратить услугу.
Мне не близка идея считать удачным интерфейс, который добился действия ценой недопонимания. Сегодня он может улучшить одну цифру в отчете, завтра – увеличить количество споров, возвратов и раздраженных обращений.
Доверие складывается не только из отзывов и фотографий команды. Оно проверяется в расчетах, формулировках и возможности отказаться без квеста. Если сайт честен только до момента оплаты, это очень короткая версия честности.
№78. Страница ошибки может быть смешной. Но сначала пусть поможет выбраться.
Когда я попал по старой ссылке, мне полезнее поиск, понятная навигация и объяснение ситуации, чем одинокая иллюстрация с шуткой. Особенно если за красивым тупиком нет ни одного следующего шага.
Юмор хорош как дополнение. Он не обязан отрабатывать за отсутствующий выход.
№79. Мне не нужен чат, который притворяется живым сотрудником и молчит после первого сообщения.
Если отвечает автоматическая система, лучше назвать это прямо. Если оператор появится только в рабочее время, полезно показать часы. Если вопрос будет передан дальше, хочется понимать, когда и где ждать ответ.
Не каждый сайт обязан поддерживать мгновенный разговор. Иногда обычная форма с честным сроком реакции удобнее мигающего окна "Мы всегда рядом".
Обещание доступности создает ожидание. Когда ожидание не выполняется, раздражает не столько задержка, сколько разница между словами и устройством сервиса.
Мне нравится интерфейс, который знает собственные ограничения и не стесняется их объяснять. В этом больше уважения к человеку, чем в искусственном ощущении круглосуточного присутствия, за которым никто не стоит.
№80. Что вы первым ищете на незнакомом сайте перед оплатой: условия возврата, реквизиты, контакты, способ доставки или независимое подтверждение существования компании?
Интересно, насколько наши личные привычки отличаются от представления команды о "главных блоках доверия". Иногда большой раздел с похвалами уступает одной ясной странице, где без украшений написано, что произойдет, если заказ не подойдет.
Глазами тех, кому жить с сайтом после запуска
Эти посты про создание сайтов посвящены эксплуатации: редакторской рутине, развитию, измерениям и сохранению контроля над проектом.
На следующий день после публикации
Для рассказов о передаче сайта, обновлениях и распределении ответственности.
* Начинайте там, где заканчивается праздничная демонстрация готовых страниц.
№81. Сайт опубликован. На следующий день нужно поменять время работы.
Именно здесь выясняется, что считать удобной системой: не то, насколько эффектно она выглядела на сдаче, а может ли обычный сотрудник сделать обычное изменение без страха.
№82. Мне нравится инструкция к сайту, которую можно открыть в момент конкретной задачи.
Не огромный документ "обо всем", а понятные ответы: как добавить услугу, заменить изображение, изменить стоимость, восстановить случайно скрытую запись. С примерами из самого проекта, а не из абстрактного интерфейса.
Особенно полезны границы: что сотрудник может делать самостоятельно, а где лучше остановиться и обратиться за помощью.
Передача знаний не должна превращать каждого редактора в разработчика. Ее задача скромнее и важнее – дать человеку уверенность в его повседневной работе.
№83. Представим небольшой бизнес, у которого сайт уже несколько лет существует без заметных аварий.
Домен когда-то зарегистрировал знакомый. Хостинг оплачивает бывший сотрудник со своей карты. Пароль от редактора сохранился в браузере на старом ноутбуке. Все работает, поэтому никто не хочет трогать.
Такая стабильность держится не столько на системе, сколько на удачном совпадении обстоятельств.
Проблема может проявиться в самый обычный момент: нужно продлить услугу, изменить платежные данные или дать доступ новому специалисту. И вдруг выясняется, что компания фактически не управляет важной частью собственного присутствия в интернете.
Я бы хотел, чтобы разговор о владении звучал до запуска и повторялся при передаче проекта. На кого оформлены учетные записи? Кто имеет административные права? Где хранятся способы восстановления? Как удаляется доступ человека, который больше не работает с компанией?
Это не паранойя и не недоверие к подрядчику. Это нормальное устройство ответственности.
У сайта есть видимая часть – страницы, тексты, фотографии. И есть невидимая: регистрации, платежи, доступы, договоренности. Вторая редко попадает в презентацию, но именно она определяет, сможете ли вы спокойно распоряжаться первой.
Мне гораздо приятнее видеть скучно заполненный реестр доступов, чем однажды участвовать в срочном поиске человека, который "точно все это когда-то настраивал".
№84. Устаревшая новость на главной иногда говорит громче свежего дизайна.
Человек видит приглашение на мероприятие, которое давно прошло, и начинает сомневаться не в одном блоке, а в актуальности всего сайта. Работает ли компания? Верны ли цены? Ответят ли по указанному номеру?
Поэтому я не считаю новостную ленту обязательным украшением. Если у команды нет регулярных поводов и человека для публикаций, лучше выбрать другой способ показывать жизнь проекта.
Например, поддерживать актуальные услуги, реальные фотографии, действующее расписание и понятные контакты. Это менее похоже на редакцию, зато не создает пустого обещания постоянного потока материалов.
Сайт не обязан обновляться ежедневно, чтобы оставаться живым. Но то, что он показывает как текущее, действительно должно соответствовать настоящему. Иногда удаление заброшенного блока полезнее очередной попытки торжественно начать вести новости с понедельника.
№85. "Кто-нибудь потом обновит" – должность, на которой обычно никто не работает. У цен, расписания, документов и контактов лучше иметь конкретного ответственного, а не общую надежду на внимательность коллектива.
Измерять, не придумывая победы
Для обсуждения аналитики, заявок, поискового трафика и осторожных выводов.
* Разделяйте наблюдение, предположение и доказанный результат.
№86. Посещаемость выросла. Это хорошая новость, но пока не ответ на вопрос, стал ли сайт полезнее бизнесу.
Мог прийти другой трафик. Мог вырасти интерес к одной информационной странице. Могли появиться автоматические посещения. А обращения могли остаться прежними или даже стать менее подходящими.
Мне нравится смотреть на числа через реальные действия: что люди искали, куда переходили, какие запросы оставляли, чем эти запросы закончились.
Не ради усложнения отчета. Ради того, чтобы красивый график не подменял понимание происходящего.
№87. Допустим, после изменения формы заявок стало больше. Команде хочется сразу объявить победу новой версии.
Но в ту же неделю запустили другую рекламу, изменили предложение и начался сезонный рост спроса. Сайт участвовал в результате, однако отделить его вклад по одному сравнению "до и после" трудно.
Я не против радоваться улучшению. Я против слишком уверенного объяснения причины.
Даже эксперимент с разделением аудитории требует внимания: достаточно ли наблюдений, сопоставимы ли группы, не меняется ли одновременно что-то существенное, какую метрику выбрали заранее. При небольшом потоке данных вывод может оставаться неопределенным довольно долго.
Это неприятно, потому что всем хочется простой истории: передвинули кнопку – получили рост. Но иногда честный результат звучит скромнее: заметили изменение, есть гипотеза, продолжаем наблюдать.
Мне кажется, зрелая аналитика умеет говорить "пока не знаем". Эта фраза защищает от случайных решений, которые потом начинают повторять как универсальный рецепт.
И еще важно смотреть дальше самой отправки формы. Если обращений стало больше, но они хуже соответствуют услуге, победа может оказаться бумажной. Число на сайте – только часть рабочего процесса, а не его окончательная оценка.
Хороший отчет помогает принять следующее решение. Если он нужен лишь для красивого подтверждения уже выбранной версии событий, измерения превращаются в декорацию.
№88. Нажатие на кнопку "Позвонить" – еще не состоявшийся разговор. Отправленная форма – еще не продажа. Мне спокойнее, когда названия показателей не обещают больше, чем мы действительно измерили.
№89. Поисковое продвижение не начинается с просьбы повторить одну фразу десять раз.
Я бы сначала посмотрел, отвечает ли страница на реальный запрос. Понятно ли, о какой услуге идет речь? Есть ли существенные условия? Можно ли перейти к связанным вопросам? Не мешают ли технические ограничения обнаружить и обработать страницу?
Текст, который написан только ради повторений, часто ухудшает знакомство с компанией. Человек чувствует, что с ним разговаривают как будто через посредника, которому важнее совпадение слов.
Мне нравится подход, где поисковая видимость и польза не объявляются врагами. Можно ясно назвать предмет, структурировать содержание и дать подробный ответ без словесного шума.
При этом даже аккуратная работа не гарантирует конкретного места в выдаче. На результат влияют конкуренция, спрос, состояние сайта и множество других факторов. Обещание позиции не становится надежнее от того, что произнесено уверенно.
№90. У показателя отказов нет волшебной оценки, которая подходит любому сайту.
Человек мог открыть страницу, сразу увидеть номер, позвонить и закрыть вкладку. А мог долго блуждать, потому что не нашел ответ. Одна продолжительность посещения не различает эти истории сама по себе.
Мне интереснее сначала понять задачу страницы и особенности измерения. И только потом решать, какое поведение считать проблемой. Иначе можно усердно улучшать отчет, одновременно усложняя людям жизнь.
Развивать, переносить и вовремя упрощать
Для постов о долгой жизни сайта, редизайне и профессиональном отношении к изменениям.
* Сопоставляйте новое решение с тем, что уже работает и не должно потеряться.
№91. Редизайн начинается для меня с вопроса: что нельзя потерять?
Не только узнаваемость. Старые адреса страниц, полезные материалы, привычные действия постоянных посетителей, накопленные поисковые переходы, возможность редактора быстро работать с содержанием.
Новый внешний вид легко оценить рядом со старым. Потери замечают позже, когда исчезает нужная страница или сотрудник тратит вдвое больше времени на обычное обновление.
Поэтому я люблю инвентаризацию перед переменами. Какие разделы посещают? На что ведут внешние ссылки? Какие функции действительно используются? Где содержимое устарело, а где его просто давно не пересматривали?
Это не призыв держаться за прошлое. Это способ отличить необходимое обновление от разрушения работающих связей.
Красивое новое начало особенно ценно, когда для посетителя оно не оборачивается внезапным исчезновением знакомого и полезного.
№92. Представим перенос сайта на другую систему. В новой версии чище дизайн, удобнее редактор, быстрее открываются страницы. Все основания для радости есть.
Но старые ссылки больше не работают. Карточки получили другие адреса. Часть изображений забыли перенести. В письмах и сохраненных закладках остались пути, которые ведут в тупик.
Для команды состоялся успешный запуск. Для части аудитории сайт просто сломался.
Мне кажется важным рассматривать перенос не как замену папки, а как сохранение связей. Нужна карта старых и новых адресов, продуманные перенаправления там, где есть соответствующая замена, проверка важных материалов и сценариев.
Отдельного внимания требуют интеграции. Если форма выглядит так же, это еще не значит, что данные попадают в прежнюю систему. Если страница оплаты открывается, это еще не подтверждает корректность всего процесса.
И я бы оставлял время после запуска на наблюдение. Не потому, что команда плохо подготовилась, а потому, что реальный поток обращений обнаруживает сочетания, которые трудно полностью воспроизвести заранее.
У хорошего переноса есть удивительное свойство: значительная часть аудитории почти не замечает, сколько работы произошло. Люди просто продолжают пользоваться сайтом. Для презентации это скромный эффект, но для самой задачи – очень достойный результат. Обновление состоялось, а разрыва в привычной работе не случилось.
№93. Не каждый старый сайт нужно сносить. Иногда ему нужны актуальные контакты, исправленная мобильная форма и нормальные фотографии. Возраст дизайна – повод посмотреть внимательнее, а не автоматический диагноз.
№94. Мне нравится вопрос "что можно удалить?" на встрече о развитии сайта.
Неиспользуемый фильтр. Дублирующий раздел. Баннер, который никто не помнит зачем добавили. Поле, данные из которого не читает ни один сотрудник.
Каждое дополнение когда-то имело объяснение, но объяснения стареют. Если их не пересматривать, сайт становится архивом прошлых обсуждений, через который сегодняшнему посетителю приходится прокладывать дорогу.
Развитие не обязано измеряться количеством новых элементов. Иногда лучшая версия делает меньше, зато понятнее и надежнее.
№95. Что останется от сайта, если завтра изменится любимая платформа, уйдет подрядчик или компания решит работать иначе?
Хочется ответить: содержание, доступы, данные, понятные процессы и возможность двигаться дальше.
Поэтому мне близки решения, которые не запирают проект в одном человеке или одном непрозрачном наборе настроек. Экспорт материалов, проверенные резервные копии, описанные интеграции, понятное владение доменом – все это выглядит скучно ровно до момента перемен.
Я не предлагаю строить маленькую страницу так, будто ей предстоит управлять огромной инфраструктурой. Масштаб подготовки должен соответствовать задаче. Но даже небольшому проекту полезно иметь ответ на вопрос о выходе: как забрать свое и продолжить работу в другом месте?
Для меня хороший сайт – не только удачный сегодняшний результат. Это еще и возможность не начинать с нуля каждый раз, когда жизнь бизнеса меняет условия.
#postprocat
