Дизайн

В первой части мы разобрали, зачем дизайнеру знать основы вёрстки и как это помогает создавать реализуемые макеты и экономить время. Теперь перейдём от теории к практике и познакомимся с главным языком разметки — HTML.

Если CSS отвечает за то, как выглядит страница (цвета, шрифты, отступы), то HTML (HyperText Markup Language) отвечает за то, что на ней находится и какую смысловую роль играет каждый элемент. Это скелет вашего сайта.

Послезавтра у меня выступление на бизнес-встрече.

И, как это обычно бывает (по крайней мере у меня), за два дня до выступления я решила, что презентация никуда не годится. Причем не в смысле «пару слайдов поправить», а полностью пересобрать фокус выступления.

Часы до дедлайна тикают, времени немного, а перспектива сидеть полночи в Figma вообще не вдохновляет.

И тут я вспомнила простую истину. Лень – двигатель прогресса. Значит, будем искать способ, как сделать быстрее.

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

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

Какие существуют подходы к верификации чертежей и ЦИМ и программные продукты для этого?

Сверка 2D-чертежей с ЦИМ критически важна для точности ведомостей объемов работ. Сегодня эту задачу решают двумя способами, оба из которых имеют ограничения:

1. Ручная верификация: визуальное сравнение модели и чертежей.

Плюсы: не требует ПО и спец. навыков.

Минусы: крайне трудоемка, подвержена человеческому фактору, данные невозможно систематизировать.

2. Верификация через САПР: проверка внутри системы проектирования.

Плюсы: высокая точность и прозрачность.

Минусы: нужны дорогие лицензии и глубокие знания ПО. Кроме того, госсектор ограничен в использовании иностранного софта.

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

История про то, как я сделал себе виртуального аватара для коротких видео — без генерации видео через ИИ.

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

В итоге получилась самодельная полуавтоматическая DIY‑система:

— универсальные графические ассеты персонажа
— ручная озвучка моим голосом
— разметка фраз в аудио через Audacity
— текстовый сценарий с управляющими тегами для событий в ролике
— кастомный JSX‑плагин для After Effects

Система берёт сценарий с управляющими тегами, аудиодорожку с голосом и файл разметки, после чего собирает заготовку ролика: аватар, липсинк, мимику, субтитры и слайды.

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

В конце — немного статистики по первым трём роликам, запущенным с нулевых аккаунтов: YouTube, Instagram, TikTok и ВК.

К моменту, когда заказ доходит до этапа формирования производственной панели, основная проверка данных уже проведена: слои проверены на соответствие технологии, выявлены и исправлены потенциальные проблемы. Теперь перед производителем стоит задача — объединить несколько заказов в одну панель и подготовить её к запуску в производство.

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

An error message is a short message that appears on the screen when a user does something wrong or a software product itself fails to perform and complete a certain action. They are often perceived as insignificant annoying notifications that no one actually reads before clicking “OK”, but in fact they play a vital role in providing information on any problems and issues that users encounter during app use and aiding them in completing tasks successfully. The way error messages are designed impacts user experience heavily: poor design leaves users in confusion on what exactly went wrong and how to fix it, which in its turn leads to frustration and even app abandonment, whereas effectively crafted messages serve as a helpful tool in providing clarity on how to proceed when encountering an issue. 

Видели ли вы, как пользователи объясняют неудачи в продукте собственной глупостью? Может, слышали в кулуарах, как разработчики соглашаются с пользователями и не знают, чем помочь, — ведь «всё предельно понятно», «для дураков сделано». А бизнес-команда между тем опускает руки и задаётся вопросом, не дураки ли они сами, если не могут донести логику продукта до пользователя?

Меня зовут Анастасия Лестова, и я социальный антрополог с инженерным бэкграундом, а сейчас исследую опыт пользователей в Контур.Маркировка. В своём докладе на CodeFest 2026, опираясь на социальные науки и нейробиологию, я рассказала, что жизненный контекст и плохие интерфейсы делают с психикой и мозгом пользователя (спойлер: буквально снижают его когнитивные способности). А в сегодняшней статье раскрою тему более детально. Понимая психофизиологические механизмы происходящего, мы разберёмся, как всё это лечить с помощью конкретных инструментов в интерфейсе. 

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

Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.

На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?

В этой статье поделюсь нашим методом поиска ответов на эти вопросы.

Всем привет! Мы — команда Облака Mail: редактор Наташа, дизайнер Саша и исследователь Лена.

Мы вместе работаем над улучшением сервисов Mail: проводим исследования пользовательского опыта, много дискаверим, проверяем гипотезы, проектируем интерфейсы и пишем тексты, которые помогают пользователям лучше ориентироваться в продукте.

В этой статье подробно разберём, как столкнулись с нетипичной проблемой заметности элементов в интерфейсе и как через исследования, анализ поведения пользователей и системный дизайн пришли к созданию масштабируемой механики фокусировки.

Хочу рассказать об основах вёрстки для дизайнеров. Научить базовым принципам и показать, как проверять реализацию макета в коде. Статья будет полезна начинающим дизайнерам, которые пока не представляют, как их макеты оживают на реальных сайтах.

Прилетаем в Шанхай — в аэропорту встречают трое, помогают с чемоданами. По дороге выясняется: один из них — владелец компании, у которой данные покупают крупнейшие AI-лаборатории мира (OpenAI, Meta, Antropic и др.).

Так начались наши восемь дней внутри китайского AI: SiliconFlow, ByteDance (разработчики TikTok, Seedance), MiniMax, Z.ai (разработчики GLM) — встречи каждый день. Внутри статьи: что ByteDance выпускает 10 июля и почему флагманы дешевеют; как Z.ai уходят с NVIDIA на Huawei; рынок, где серверные видеокарты лежат рядом с айфонами; магазин, где гуманоидов продают по паспорту; и почему пекинские уборщики пока выигрывают у роботов.

Я — сооснователь GPTunneL, китайские модели покупаю и продаю каждый день. Рассказываю, как этот рынок выглядит вблизи.

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

Дело не в том, что они плохие дизайнеры или им всё равно. Дело в том, что доступность невозможно понять головой. Её можно только почувствовать. А пока проблема не твоя — ты её не чувствуешь.

Я долго думала, как это починить. И в итоге перестала объяснять словами. Я сделала штуку, которая даёт побыть тем самым пользователем — на несколько секунд. Расскажу, как она устроена и почему чек-листы не работают.

Мир сильно изменился с начала 21 века. В том числе, что касается систем авторизации. Мы продвинулись от авторизации через обычный логин и пароль к использованию централизованных сервисов вроде Google и Apple. Но так ли хорошо это для пользователя? И можно ли сказать, что его данные принадлежат ему?

Начиная с 2023 года автономные грузовики Navio ежедневно возят коммерческие грузы по главным магистралям страны. За это время мы получили богатый опыт, подробно изучили отрасль и выявили основные трудности с которыми она сталкивается. Ответом на эти вызовы стал прототип автономного тягача Navio L5. Его концепция отражает наше видение ближайшего будущего автономных грузоперевозок. В прошлой статье мы подробно рассказывали о ключевых идеях и о процессе создания дизайна тягача L5.

Однако мы видим долгосрочный потенциал в развитии рынка автономных грузоперевозок, поэтому хотим взглянуть еще дальше — на перспективу 30-50 лет вперед. 

В нулевых у пользователя Windows было две системы.
Первая Windows XP, загружалась с диска, показывала ядовито‑зелёный «Пуск», синюю панель задач, загрузчик браузера и уверенно делала вид, что этого достаточно.

Вторую пользователь собирал сам.
Снизу ставился RocketDock, чтобы было почти как на Mac. Поверх XP натягивалась тема под Vista, потому что сама Vista уже выглядела красиво. В угол попадал CPU‑Meter с температурой процессора, погодой, сетью и другими признаками того, что компьютер не просто работает, а живёт насыщенной внутренней жизнью. По горячей клавише вызывался Launchy. Окна прятались в трей CaptainTay‑ем, с обязательнным Boss‑Key. Раскладку спасал Punto Switcher. Скриншоты делал отдельный скриншотер. Хоткеи держались на AutoHotkey.
Это была не коллекция утилит. Это была функциональная прослойка на условных рефлексах между человеком и системой.

Днем унылые пары, а ночью Vista Transformation Pack на свежепереустановленный ZverXP, потому что хотелось красоты. Дикий рынок, пиратские диски, форумные сборки, доверие на честном «у всех антивирь ругается» и надежда на то, что если программа весит меньше мегабайта, значит, она почти святая.

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

Просто теперь быстрый запуск, поиск, хоткеи, скриншоты, виджеты, command palette и автоматизация живут внутри ОС, браузеров, редакторов, SaaS‑продуктов, PowerToys, Alfred, Raycast, скриптов и AI‑ассистентов.
Классический лаунчер умер не потому, что стал не нужен. Он умер потому, что его разобрали на органы и пересадили в платформы.

Привет! Меня зовут Оля, я ведущий дизайнер в Домклик. Работала в бигтехе (Сбер, Московская биржа).

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

В России продолжается глобальная цифровизация во всех отраслях, в том числе и в архитектурно‑строительном направлении деятельности. Результатом современных архитектурных и объемно‑планировочных решений является высокий уровень точности организации пространства. Традиционные методы разработки и проверки архитектурных решений трудоемки и могут быть субъективными. Развитие технологий уже на текущем этапе позволило достичь геометрического моделирования, но прослеживается переход к семантическому (данно‑ориентированному) моделированию. Совокупность этих методов должна позволить повысить точность разработки и верификации современных архитектурных решений.

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

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

В этой статье мы разберём, что такое зенковка, чем она отличается от цековки, какие параметры важны при проектировании и на что обратить внимание, чтобы избежать проблем при производстве.

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

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

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