Как проектировать: 118 обучающих уроков для проектировщиков. Как это было

Содержание

118 обучающих уроков для проектировщиков. Как это было

Согласитесь, что весна 2020 была довольно интересным временем. В марте большая часть инженерного мира осталась дома на самоизоляции. Пока все проживали стадии «отрицание-страх-гнев-принятие», мы в «Нанософт» подумали, что мы можем сделать для наших пользователей. А затем собрали команду наших продактов, провели мозговой штурм и буквально за неделю запустили Инженерную online-школу. Мы среагировали первыми.

Использовали ресурсы с пользой для общества

Сначала мы взяли флагманские продукты «Нанософт». Наша школа проводила два урока в день. Спустя неделю, увидев огромный интерес аудитории, мы подключили все остальные продукты портфеля «Нанософт». Количество курсов увеличилось втрое, а число ежедневных online-лекций возросло до четырех. Мы провели обучение по всей линейке nanoCAD, Solid Edge, ARCHICAD, PADS Professional, Femap, Model Studio CS, CADLib, Spotlight, PlanTracer Pro. По окончании курсов nanoCAD слушатели получили сертификаты участников.

Мастер-классы на высоком уровне

В основе курсов лежали тест-драйвы, по которым наши технические специалисты успешно проводят обучение в компаниях, а также в авторизованных учебных центрах. Вскоре они дополнились авторскими курсами руководителей направлений. Так, например, технический директор «Нанософт» Денис Ожигин разработал на базе конструкторской модели серию уроков, посвященных моделированию, специфицированию, документированию и совместной работе в едином комплексе nanoCAD Конструкторский BIM + CADLib. Денис Ожигин и BIM-менеджер Виталина Балашенкова показали в режиме реального времени открытое информационное моделирование в связке «архитектор – конструктор»: продемонстрировали обмен данными между смежными специалистами посредством облачного хранилища, совместную настройку BIM-модели по требованиям заказчика и др. Алексей Гепта, руководитель проекта nanoCAD Машиностроение, выступил с серией 40-минутных уроков по основным инструментам 2D- и 3D- моделирования в nanoCAD.

Лидерами просмотров на YouTube стали вебинары по nanoCAD Электро и nanoCAD ОПС. Это лекции руководителей проектов Дмитрия Щурова «nanoCAD Электро. Электротехнические расчеты. Разложим всё по полочкам» и Максима Бадаева «nanoCAD ОПС. Проектирование пожарной сигнализации». Кстати, недавно авторитетный портал проектировщиков RUBEZH провел интересный опрос «А в чем проектируешь ты?». Согласно рейтингу портала, третье место среди самых популярных программ занимает специализированное решение для проектирования слаботочных систем nanoCAD ОПС.

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

Инженерная школа обросла личными историями. Пользователи делились впечатлениями и оставляли отзывы в соцсетях.

Инженерная online-школа «Нанософт» в цифрах

2,5 месяца непрерывной работы
118 online-уроков по ведущим САПР-системам
29 профессиональных спикеров
26 программных продуктов

Более 12 000 слушателей

Изучайте сегодня самостоятельно

Сегодня все видеоуроки с курсами компании «Нанософт» находятся в открытом доступе на нашем YouTube-канале. Это лекции для специалистов разного уровня подготовки и разных направлений проектирования. Выбирайте курс по душе и прикладной специальности и обучайтесь самостоятельно.

Гражданское строительство

nanoCAD Plus. Урок №1 – Всё про печать в nanoCAD Смотреть>>
nanoCAD Plus. Урок №2 – Работа с полями в nanoCAD Смотреть>>
nanoCAD Plus. Урок №3 — Учимся работать с растрами Смотреть>>
nanoCAD Plus для новичков. Урок №1 – Чертим простую сетку осей Смотреть>>
nanoCAD Plus для новичков. Урок №2 – Чертим простую деталь со штриховкой Смотреть>>
ARCHICAD. Урок №1 – Основные принципы работы в BIM-системе. Панель Навигатора Смотреть>>

ARCHICAD. Урок №2 – Работа с обновленными инструментами «Балка», «Колонна» и новым инструментом «Отверстие» Смотреть>>
ARCHICAD. Урок №3 – Организация коллективной работы над одним проектом с помощью BIMcloud Basic Смотреть>>
ARCHICAD. Урок №4 – Иммерсивная визуализация в Twinmotion Смотреть>>
OPEN BIM. Открытое взаимодействие между архитектором и конструктором на примере ARCHICAD и nanoCAD Конструкторский BIM Смотреть>>
nanoCAD Конструкторский BIM. Урок №1 – Создание пользовательского параметрического объекта Смотреть>>
nanoCAD Конструкторский BIM. Урок №2 – Создание пользовательских таблиц спецификаций Смотреть>>
nanoCAD Конструкторский BIM. Урок №3 – Создание генерируемой 2D-документации из информационной модели Смотреть>>
Работа над информационными моделями в команде по схеме «конструктор – конструктор» и «взаимодействие со смежными отделами» с помощью решений nanoCAD Конструкторский BIM, nanoCAD Инженерный BIM и комплекса CADLib Смотреть>>

Проектирование стального каркаса в nanoCAD Конструкторский BIM Смотреть>>
nanoCAD СПДС. Урок №1 – Оформление чертежей Смотреть>>
nanoCAD СПДС. Урок №2 – Работа с архитектурой Смотреть>>
nanoCAD СПДС. Урок №3 – Создание собственных объектов. Часть 1 Смотреть>>
nanoCAD СПДС. Урок №4 – Создание собственных объектов. Часть 2 Смотреть>>
nanoCAD СПДС Металлоконструкции. Урок №1 – Армирование фундамента Смотреть>>
nanoCAD СПДС Металлоконструкции. Урок №2 – Создание металлической опоры под трубопроводы Смотреть>>
nanoCAD СПДС Стройплощадка. Урок №1 – Менеджер проекта Смотреть>>
nanoCAD СПДС Стройплощадка. Урок №2 – Стройгенплан Смотреть>>

nanoCAD СПДС Стройплощадка. Урок №3 – Построение дорог Смотреть>>
nanoCAD СПДС Стройплощадка. Урок №4 – Подбор техники Смотреть>>
nanoCAD Конструкции – КЖ. Урок №1 – Армирование инструментами схематичного армирования. Арматурные стержни Смотреть>>
nanoCAD Конструкции – КЖ. Урок №2 – Армирование инструментами схематичного армирования. Арматурные сетки и каркасы Смотреть>>
nanoCAD Конструкции – КЖ. Урок №3 – Формирование монолитных и сборных строительных конструкций Смотреть>>
nanoCAD Конструкции – Фундаменты. Урок №1 – Расчет и проектирование столбчатого фундамента. Получение рабочей документации Смотреть>>
nanoCAD Конструкции – Фундаменты. Урок №2 – Расчет и проектирование сборного ленточного фундамента. Получение рабочей документации Смотреть>>

nanoCAD Конструкции – Фундаменты. Урок №3 – Расчет и проектирование монолитного ленточного фундамента. Получение рабочей документации Смотреть>>
nanoCAD Конструкции – Модуль «Оформление» Смотреть>>
nanoCAD Конструкции – Фундаменты + КЖ. Взаимодействие инструментов модулей КЖ и Фундаменты Смотреть>>
nanoCAD ОПС. Урок №1 – Проектирование пожарной сигнализации Смотреть>>
nanoCAD ОПС. Урок №2 – Проектирование оповещения и видеонаблюдения Смотреть>>
nanoCAD Электро. Урок №1 – Электротехнические расчеты. Разложим всё по полочкам Смотреть>>
nanoCAD Электро. Урок №2 – Создание задания на отверстия Смотреть>>
nanoCAD Электро. Урок №3 – Настройка выносок Смотреть>>
nanoCAD Электро. Урок №4 – Расчет освещенности. От создания элемента «Светильник» до изолиний на плане Смотреть>>

nanoCAD СКС. Урок №1 – Проектирование структурированных кабельных систем Смотреть>>
nanoCAD СКС. Урок №2 – Проектирование кабеленесущих систем Смотреть>>
nanoCAD ВК. Создание спецоборудования Смотреть>>
nanoCAD Отопление. Наполнение и обвязка радиатора отопления Смотреть>>
Spotlight. Урок №1 – Повышение качества сканированного чертежа Смотреть>>
Spotlight. Урок №2 – Векторизация сканированного чертежа Смотреть>>
PlanTracer Pro. Урок №1 – Знакомство с интерфейсом. Библиотека шаблонов. Создание поэтажного плана Смотреть>>
PlanTracer Pro. Урок №2 – Создание технического плана помещения Смотреть>>
PlanTracer Pro 7.0. Урок №3 – Создание технического плана здания Смотреть>>
PlanTracer Pro 7.0. Урок №4 – Создание технического плана многоквартирного дома (МКД) Смотреть>>

PlanTracer Pro 7.0. Урок №5 – Создание технического плана многоконтурного сооружения Смотреть>>

Машиностроение

nanoCAD Механика. Урок №1 – Работа с модулем «Валы» Смотреть>>
nanoCAD Механика. Урок №2 – Формирование спецификации Смотреть>>
nanoCAD Механика. Урок №3 – Оформление чертежей, часть 1 Смотреть>>
nanoCAD Механика. Урок №4 – Оформление чертежей, часть 2 Смотреть>>
nanoCAD Механика. Урок №5 – Нанесение размеров и предельных отклонений. Часть 1 Смотреть>>
nanoCAD Механика. Урок №5 – Нанесение размеров и предельных отклонений. Часть 2 Смотреть>>
nanoCAD Механика. Урок №6 – Установка крепежа Смотреть>>

nanoCAD Механика. Урок №7 – Трубопроводная арматура Смотреть>>
nanoCAD Механика. Урок №8 – Оформление технических требований и технических характеристик чертежей Смотреть>>
nanoCAD 3D-модуль. Урок №1 – Основы моделирования Смотреть>>
nanoCAD 3D-модуль. Урок №2 – Параметрическое моделирование Смотреть>>
nanoCAD 3D. Урок №3 – Базовые команды 3D-моделирования в nanoCAD Смотреть>>
Новые возможности в среде «Листовая деталь» Solid Edge 2020 Смотреть>>
Проектирование трубопроводов в Solid Edge Modular Plant Design Смотреть>>
Solid Edge 2020 Wiring & Harness Design. Синхронизация данных электропроводки и жгута Смотреть>>
Симуляция движения в Solid Edge Смотреть>>
Solid Edge 2020 Wiring & Harness Design. Работа в связанном режиме Смотреть>>
Организация распределенной работы в Teamcenter и Solid Edge Смотреть>>
Технические публикации в Solid Edge Смотреть>>

Проектирование электроники

FPGA I/O Optimizer – ПЛИС на борту Смотреть >>
Новые возможности в релизе Xpedition VX.2.7 Смотреть>>
Преимущества решений Xpedition и PADS Professional по сравнению с оркад и аллегро Смотреть>>
Основы работы в Xpedition Designer Смотреть>>
Менеджмент полигонов в PADS Professional Смотреть>>
Основы работы в Xpedition Layout Смотреть>>
Советы и хитрости при настройке системы ввода ограничений Constraint Manager Смотреть>>

BIM-моделирование промышленных объектов

Model Studio CS. Проектирование систем отопления и вентиляции Смотреть>>
Model Studio CS. Проектирование строительных конструкций Смотреть>>
Model Studio CS. Проектирование кабельных систем Смотреть>>
Model Studio CS Трубопроводы. Моделирование систем вентиляции Смотреть>>
Model Studio CS. Проектирование технологических трубопроводов Смотреть>>
Model Studio CS ОРУ. Урок №1 – Создание BIM-модели ОРУ. Компоновка оборудования на площадке ОРУ Смотреть>>
Model Studio CS ОРУ. Урок №2 – Создание BIM-модели ОРУ. Работа с ошиновкой ОРУ Смотреть>>
Model Studio CS ОРУ. Урок №3 – Получение выходной табличной и графической документации Смотреть>>
Model Studio CS ОРУ. Урок №4 – Создание 3D- и 2D-модели высоковольтного оборудования Смотреть>>
Model Studio CS ОРУ. Урок №5 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
Model Studio CS Электротехнические схемы. Урок №1 – Проектирование схем КИПиА и АСУ ТП Смотреть>>
Model Studio CS Электротехнические схемы. Урок №2 – Проектирование схем электроснабжения до 1 кВ Смотреть>>
Model Studio CS Электротехнические схемы. Урок №3 – Проектирование схем электроснабжения выше 1 кВ Смотреть>>
Проектирование в Model Studio CS Электротехнические схемы Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №1 – Создание BIM-модели кабельного хозяйства. Проектирование кабельных конструкций Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №2 – Создание BIM-модели кабельного хозяйства. Проектирование кабельных трасс Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №3 – Создание BIM-модели кабельного хозяйства. Обнаружение и устранение коллизий кабельной раскладки Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №4 – Получение планов, видов, разрезов из BIM-модели кабельной раскладки Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №5 – Получение табличной документации из BIM-модели кабельной раскладки Смотреть>>
Model Studio CS Кабельное хозяйство. Урок №6 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
Model Studio CS ЛЭП. Урок №1 – Проектирование воздушных линий электропередачи 35-750 кВ Смотреть>>
Model Studio CS ЛЭП. Урок №2 – Проектирование воздушных линий электропередачи 0,4-35 кВ Смотреть>>
Model Studio CS ЛЭП. Урок №3 – Проектирование ВОЛС на ВЛ Смотреть>>
Model Studio CS Молниезащита. Урок №1 – Создание BIM-модели молниезащиты Смотреть>>
Model Studio CS Молниезащита. Урок №2 – Получение табличной и графической документации Смотреть>>
Model Studio CS Молниезащита. Урок №3 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
CADLib Модель и Архив. Урок №1 – Получение комплексной модели из различных приложений Смотреть>>
CADLib Модель и Архив. Урок №2 – Проверка и анализ комплексной модели Смотреть>>
CADLib Модель и Архив. Урок №3 – Работа с чертежами, документами и отчетами в базе данных проекта Смотреть>>

Землеустройство

nanoCAD Геоника. Урок №1 – Возможности использования функционала модуля «Топоплан»: от подготовки исходных данных до получения выходной документации Смотреть>>
nanoCAD Геоника. Урок №2 – Возможности использования функционала модуля «Генплан»: от подготовки исходных данных до получения выходной документации Смотреть>>

А если вам нужно прокачать навыки с опытным инструктором, то обращайтесь в наши учебные центры nanoCAD.

Выводы и предложения

Опыт Инженерной школы показал, что online-обучение эффективно и востребовано. Тысячи инженеров и проектировщиков смогли прокачать свои навыки и повысить свою стоимость как специалиста. В свою очередь команда «Нанософт» сплотилась, мы смогли оперативно адаптировать материалы и проявили гибкость в сложный для отрасли, да и для всего мира, период.

А вы проходили обучение в Инженерной online-школе? Нам очень интересна обратная связь. Пишите свои комментарии, рассказывайте понравилось ли, каких тем не хватило, что еще хотели бы изучить?

Создание архитектуры программы или как проектировать табуретку / Хабр

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

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

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

Вообще говоря, не существует общепринятого термина «архитектура программного обеспечения». Тем не менее, когда дело касается практики, то для большинства разработчиков и так понятно какой код является хорошим, а какой плохим. Хорошая архитектура это прежде всего выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным. Программу с хорошей архитектурой легче расширять и изменять, а также тестировать, отлаживать и понимать. То есть, на самом деле можно сформулировать список вполне разумных и универсальных критериев:

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

Гибкость системы. Любое приложение приходится менять со временем — изменяются требования, добавляются новые. Чем быстрее и удобнее можно внести изменения в существующий функционал, чем меньше проблем и ошибок это вызовет — тем гибче и конкурентоспособнее система. Поэтому в процессе разработки старайтесь оценивать то, что получается, на предмет того, как вам это потом, возможно, придется менять. Спросите у себя: «А что будет, если текущее архитектурное решение окажется неверным?», «Какое количество кода подвергнется при этом изменениям?». Изменение одного фрагмента системы не должно влиять на ее другие фрагменты. По возможности, архитектурные решения не должны «вырубаться в камне», и последствия архитектурных ошибок должны быть в разумной степени ограничены. «Хорошая архитектура позволяет ОТКЛАДЫВАТЬ принятие ключевых решений» (Боб Мартин) и минимизирует «цену» ошибок.

Расширяемость системы. Возможность добавлять в систему новые сущности и функции, не нарушая ее основной структуры. На начальном этапе в систему имеет смысл закладывать лишь основной и самый необходимый функционал (принцип YAGNI — you ain’t gonna need it, «Вам это не понадобится») Но при этом архитектура должна позволять легко наращивать дополнительный функционал по мере необходимости. Причем так, чтобы внесение наиболее вероятных изменений требовало наименьших усилии.

Требование, чтобы архитектура системы обладала гибкостью и расширяемостью (то есть была способна к изменениям и эволюции) является настолько важным, что оно даже сформулировано в виде отдельного принципа — «Принципа открытости/закрытости» (Open-Closed Principle — второй из пяти принципов SOLID): Программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.

Иными словами: Должна быть возможность расширить/изменить поведение системы без изменения/переписывания уже существующих частей системы.

Это означает, что приложение следует проектировать так, чтобы изменение его поведения и добавление новой функциональности достигалось бы за счет написания нового кода (расширения), и при этом не приходилось бы менять уже существующий код. В таком случае появление новых требований не повлечет за собой модификацию существующей логики, а сможет быть реализовано прежде всего за счет ее расширения. Именно этот принцип является основой «плагинной архитектуры» (Plugin Architecture). О том, за счет каких техник это может быть достигнуто, будет рассказано дальше.

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

Тестируемость. Код, который легче тестировать, будет содержать меньше ошибок и надежнее работать. Но тесты не только улучшают качество кода. Многие разработчики приходят к выводу, что требование «хорошей тестируемости» является также направляющей силой, автоматически ведущей к хорошему дизайну, и одновременно одним из важнейших критериев, позволяющих оценить его качество: «Используйте принцип «тестируемости» класса в качестве «лакмусовой бумажки» хорошего дизайна класса. Даже если вы не напишите ни строчки тестового кода, ответ на этот вопрос в 90% случаев поможет понять, насколько все «хорошо» или «плохо» с его дизайном» (Идеальная архитектура).

Существует целая методология разработки программ на основе тестов, которая так и называется — Разработка через тестирование (Test-Driven Development, TDD).

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

Хорошо структурированный, читаемый и понятный код. Сопровождаемость. Над программой, как правило, работает множество людей — одни уходят, приходят новые. После написания сопровождать программу тоже, как правило, приходится людям, не участвовавшем в ее разработке. Поэтому хорошая архитектура должна давать возможность относительно легко и быстро разобраться в системе новым людям. Проект должен быть хорошо структурирован, не содержать дублирования, иметь хорошо оформленный код и желательно документацию. И по возможности в системе лучше применять стандартные, общепринятые решения привычные для программистов. Чем экзотичнее система, тем сложнее ее понять другим (Принцип наименьшего удивления — Principle of least astonishment. Обычно, он используется в отношении пользовательского интерфейса, но применим и к написанию кода).

Ну и для полноты критерии плохого дизайна:

Его тяжело изменить, поскольку любое изменение влияет на слишком большое количество других частей системы. (Жесткость, Rigidity).
При внесении изменений неожиданно ломаются другие части системы. (Хрупкость, Fragility).
Код тяжело использовать повторно в другом приложении, поскольку его слишком тяжело «выпутать» из текущего приложения. (Неподвижность, Immobility).

Не смотря на разнообразие критериев, все же главной при разработке больших систем считается задача снижения сложности. А для снижения сложности ничего, кроме деления на части, пока не придумано. Иногда это называют принципом «разделяй и властвуй» (divide et impera), но по сути речь идет об иерархической декомпозиции. Сложная система должна строится из небольшого количества более простых подсистем, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части не будут достаточно просты для непосредственного понимания и создания.

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

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

В этом случае программа из «спагетти-кода» превращается в конструктор, состоящий из набора модулей/подпрограмм, взаимодействующих друг с другом по хорошо определенным и простым правилам, что собственно и позволяет контролировать ее сложность, а также дает возможность получить все те преимущества, которые обычно соотносятся с понятием хорошая архитектура:

Масштабируемость (Scalability)
возможность расширять систему и увеличивать ее производительность, за счет добавления новых модулей.
Ремонтопригодность (Maintainability)
изменение одного модуля не требует изменения других модулей
Заменимость модулей (Swappability)
модуль легко заменить на другой
Возможность тестирования (Unit Testing)
модуль можно отсоединить от всех остальных и протестировать / починить
Переиспользование (Reusability)
модуль может быть переиспользован в других программах и другом окружении
Сопровождаемость (Maintenance)
разбитую на модули программу легче понимать и сопровождать

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

Поэтому большинство определений в той или иной форме сводятся к следующему:

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

«Архитектура — это организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением.
Система — это набор компонентов, объединенных для выполнения определенной функции.«

Таким образом, хорошая архитектура это, прежде всего, модульная/блочная архитектура. Чтобы получить хорошую архитектуру надо знать, как правильно делать декомпозицию системы. А значит, необходимо понимать — какая декомпозиция считается «правильной» и каким образом ее лучше проводить?

1. Иерархическая

Не стоит сходу рубить приложение на сотни классов. Как уже говорилось, декомпозицию надо проводить иерархически — сначала систему разбивают на крупные функциональные модули/подсистемы, описывающие ее работу в самом общем виде. Затем, полученные модули, анализируются более детально и, в свою очередь, делятся на под-модули либо на объекты.

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

Эта мысль, при всей своей очевидности, не так банальна как кажется. Например, в чем заключается суть такого распространенного «архитектурного шаблона» как Модель-Вид-Контроллер (MVC)? Всего навсего в отделении представления от бизнес-логики, то есть в том, что любое пользовательское приложение вначале делится на два модуля — один из которых отвечает за реализацию собственно самой бизнес логики (Модель), а второй — за взаимодействие с пользователем (Пользовательский Интерфейс или Представление). Затем, для того чтобы эти модули могли разрабатываться независимо, связь между ними ослабляется с помощью паттерна «Наблюдатель» (подробно о способах ослабления связей будет рассказано дальше) и мы фактически получаем один из самых мощных и востребованных «шаблонов», которые используются в настоящее время.

Типичными модулями первого уровня (полученными в результате первого деления системы на наиболее крупные составные части) как раз и являются — «бизнес-логика», «пользовательский интерфейс», «доступ к БД», «связь с конкретным оборудованием или ОС».

Для обозримости на каждом иерархическом уровне рекомендуют выделять от 2 до 7 модулей.

2. Функциональная

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

Модуль = Функция + Данные, необходимые для ее выполнения.

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

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

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

3. High Cohesion + Low Coupling
Самым же главным критерием качества декомпозиции является то, насколько модули сфокусированы на решение своих задач и независимы. Обычно это формулируют следующим образом: «Модули, полученные в результате декомпозиции, должны быть максимально сопряженны внутри (high internal cohesion) и минимально связанны друг с другом (low external coupling).«

High Cohesion, высокая сопряженность или «сплоченность» внутри модуля, говорит о том, модуль сфокусирован на решении одной узкой проблемы, а не занимается выполнением разнородных функций или несвязанных между собой обязанностей. (Сопряженность — cohesion, характеризует степень, в которой задачи, выполняемые модулем, связаны друг с другом )
Следствием High Cohesion является принцип единственной ответственности (Single Responsibility Principle — первый из пяти принципов SOLID), согласно которому любой объект/модуль должен иметь лишь одну обязанность и соответственно не должно быть больше одной причины для его изменения.
Low Coupling, слабая связанность, означает что модули, на которые разбивается система, должны быть, по возможности, независимы или слабо связанны друг с другом. Они должны иметь возможность взаимодействовать, но при этом как можно меньше знать друг о друге (принцип минимального знания).
Это значит, что при правильном проектировании, при изменении одного модуля, не придется править другие или эти изменения будут минимальными. Чем слабее связанность, тем легче писать/понимать/расширять/чинить программу.

Считается, что хорошо спроектированные модули должны обладать следующими свойствами:

функциональная целостность и завершенность — каждый модуль реализует одну функцию, но реализует хорошо и полностью; модуль самостоятельно (без помощи дополнительных средств) выполняет полный набор операций для реализации своей функции.
один вход и один выход — на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO — вход–процесс–выход;
логическая независимость — результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
слабые информационные связи с другими модулями — обмен информацией между модулями должен быть по возможности минимизирован.

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

Делая декомпозицию системы желательно проверять ее качество задавая себе вопросы: «Какую функцию выполняет каждый модуль?«, “Насколько модули легко тестировать?”, “Возможно ли использовать модули самостоятельно или в другом окружении?”, “Как сильно изменения в одном модуле отразятся на остальных?”

В первую очередь следует, конечно же, стремиться к тому, чтобы модули были предельно автономны. Как и было сказано, это является ключевым параметром правильной декомпозиции. Поэтому проводить ее нужно таким образом, чтобы модули изначально слабо зависели друг от друга. Но кроме того, имеется ряд специальных техник и шаблонов, позволяющих затем дополнительно минимизировать и ослабить связи между подсистемами. Например, в случае MVC для этой цели использовался шаблон «Наблюдатель», но возможны и другие решения. Можно сказать, что техники для уменьшения связанности, как раз и составляют основной «инструментарий архитектора». Только необходимо понимать, что речь идет о всех подсистемах и ослаблять связанность нужно на всех уровнях иерархии, то есть не только между классам, но также и между модулями на каждом иерархическом уровне.

Для наглядности, картинка из неплохой статьи «Decoupling of Object-Oriented Systems», иллюстрирующая основные моменты, о которых будет идти речь.

1. Интерфейсы. Фасад

Главным, что позволяет уменьшать связанность системы, являются конечно же Интерфейсы (и стоящий за ними принцип Инкапсуляция + Абстракция + Полиморфизм):

Модули должны быть друг для друга «черными ящиками» (инкапсуляция). Это означает, что один модуль не должен «лезть» внутрь другого модуля и что либо знать о его внутренней структуре. Объекты одной подсистемы не должны обращаться напрямую к объектам другой подсистемы
Модули/подсистемы должны взаимодействовать друг с другом лишь посредством интерфейсов (то есть, абстракций, не зависящих от деталей реализации) Соответственно каждый модуль должен иметь четко определенный интерфейс или интерфейсы для взаимодействия с другими модулями.

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

Собственно именно эта возможность работать с различными реализациями (модулями или объектами) через унифицированный интерфейс и называется полиморфизмом. Полиморфизм это вовсе не переопределение методов, как иногда ошибочно полагают, а прежде всего — взаимозаменяемость модулей/объектов с одинаковым интерфейсом, или «один интерфейс, множество реализаций» (подробнее тут). Для реализации полиморфизма механизм наследования совсем не нужен. Это важно понимать, поскольку наследования вообще, по возможности, следует избегать.

Благодаря интерфейсам и полиморфизму, как раз и достигается возможность модифицировать и расширять код, без изменения того, что уже написано (Open-Closed Principle). До тех пор, пока взаимодействие модулей описано исключительно в виде интерфейсов, и не завязано на конкретные реализации, мы имеем возможность абсолютно «безболезненно» для системы заменить один модуль на любой другой, реализующий тот же самый интерфейс, а также добавить новый и тем самым расширить функциональность. Это как в конструкторе или «плагинной архитектуре» (plugin architecture) — интерфейс служит своего рода коннектором, куда может быть подключен любой модуль с подходящим разъемом. Гибкость конструктора обеспечивается тем, что мы можем просто заменить одни модули/«детали» на другие, с такими же разъемами (с тем же интерфейсом), а также добавить сколько угодно новых деталей (при этом уже существующие детали никак не изменяются и не переделываются). Подробнее про Open-Closed Principle и про то, как он может быть реализован можно почитать тут + хорошая статья на английском.

Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство. Они дают возможность модулям взаимодействовать и при этом ничего не знать о внутренней структуре друг друга, тем самым в полной мере реализуя принцип минимального знания, являющейся основой слабой связанности. Причем, чем в более общей/абстрактной форме определены интерфейсы и чем меньше ограничений они накладывают на взаимодействие, тем гибче система. Отсюда фактически следует еще один из принципов SOLID — Принцип разделения интерфейса (Interface Segregation Principle), который выступает против «толстых интерфейсов» и говорит, что большие, объемные интерфейсы надо разбивать на более маленькие и специфические, чтобы клиенты маленьких интерфейсов (зависящие модули) знали только о методах, которые необходимы им в работе. Формулируется он следующим образом: «Клиенты не должны зависеть от методов (знать о методах), которые они не используют» или “Много специализированных интерфейсов лучше, чем один универсальный”.

Итак, когда взаимодействие и зависимости модулей описываются лишь с помощью интерфейсов, те есть абстракций, без использования знаний об их внутреннем устройстве и структуре, то фактически тем самым реализуется инкапсуляция, плюс мы имеем возможность расширять/изменять поведения системы за счет добавления и использования различных реализаций, то есть за счет полиморфизма. Из этого следует, что концепция интерфейсов включает в себя и в некотором смысле обобщает почти все основные принципы ООП — Инкапсуляцию, Абстракцию, Полиморфизм. Но тут возникает один вопрос. Когда проектирование идет не на уровне объектов, которые сами же и реализуют соответствующие интерфейсы, а на уровне модулей, то что является реализацией интерфейса модуля? Ответ: если говорить языком шаблонов, то как вариант, за реализацию интерфейса модуля может отвечать специальный объект — Фасад.

Фасад — это объект-интерфейс, аккумулирующий в себе высокоуровневый набор операций для работы с некоторой подсистемой, скрывающий за собой ее внутреннюю структуру и истинную сложность. Обеспечивает защиту от изменений в реализации подсистемы. Служит единой точкой входа — «вы пинаете фасад, а он знает, кого там надо пнуть в этой подсистеме, чтобы получить нужное».

Таким образом, мы получаем первый, самый важный паттерн, позволяющий использовать концепцию интерфейсов при проектировании модулей и тем самым ослаблять их связанность — «Фасад». Помимо этого «Фасад» вообще дает возможность работать с модулями точно также как с обычными объектами и применять при проектировании модулей все те полезные принципы и техники, которые используются при проектирования классов.

Замечание: Хотя большинство программистов понимают важность интерфейсов при проектировании классов (объектов), складывается впечатление, что идея необходимости использовать интерфейсы также и на уровне модулей только зарождается. Мне встретилось очень мало статей и проектов, где интерфейсы бы применялись для ослабления связанности между модулями/слоями и соответственно использовался бы паттерн «Фасад». Кто, например, видел «Фасад» на схемах уже упоминавшегося «архитектурного шаблона» Модель-Вид-Контроллер, или хотя бы слышал его упоминание среди паттернов, входящих в состав MVC (наряду с Observer и Composite)? А ведь он там должен быть, поскольку Модель это не класс, это модуль, причем центральный. И у создателя MVC Трюгве Реенскауга он, конечно же, был (смотрим «The Model-View-Controller (MVC ). Its Past and Present», только учитываем, что это писалось в 1973 году и то, что мы сейчас называем Представлением — Presentaition/UI тогда называлось Editior). Странным образом «Фасад» потерялся на многие годы и вновь обнаружить его мне удалось лишь недавно, в основном, в обобщенном варианте MVC от Microsoft («Microsoft Application Architecture Guide»). Вот соответствующие слайды:

А разработчикам, к сожалению, приходится заново «переоткрывать» идею, что к объектам Модели, отвечающей за бизнес-логику приложения, нужно обращаться не напрямую а через интерфейс, то есть «Фасад», как например, в этой статье, откуда для полноты картины взят еще один слайд:

2. Dependency Inversion. Корректное создание и получение зависимостей

Формально, требование, чтобы модули не содержали ссылок на конкретные реализации, а все зависимости и взаимодействие между ними строились исключительно на основе абстракций, то есть интерфейсов, выражается принципом Инвертирования зависимостей (Dependency Inversion — последний из пяти принципов SOLID):

Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те, и другие должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Реализация должна зависеть от абстракции.

У этого принципа не самая очевидная формулировка, но суть его, как и было сказано, выражается правилом: «Все зависимости должны быть в виде интерфейсов». Подробно и очень хорошо принцип инвертирования зависимостей разбирается в статье Модульный дизайн или «что такое DIP, SRP, IoC, DI и т.п.». Статья из разряда must-read, лучшее, что доводилось читать по архитектуре ПО.

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

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

В каком-то смысле такое решение следует Принципу единственного выбора (Single Choice Principle), который говорит: «всякий раз, когда система программного обеспечения должна поддерживать множество альтернатив, их полный список должен быть известен только одному модулю системы«. В этом случае, если в будущем придется добавить новые варианты (или новые реализации, как в рассматриваемом нами случае создания новых объектов), то достаточно будет произвести обновление только того модуля, в котором содержится эта информация, а все остальные модули останутся незатронутыми и смогут продолжать свою работу как обычно.

Ну а теперь разберем подробнее, как это делается на практике и каким образом модули могут корректно создавать и получать свои «зависимости», не нарушая принципа Dependency Inversion.

Итак, при проектировании модуля должны быть определены следующие ключевые вещи:

что модуль делает, какую функцию выполняет
что модулю нужно от его окружения, то есть с какими объектами/модулями ему придется иметь дело и
как он это будет получать

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

И тут возможны следующие варианты:

Модуль сам создает объекты необходимые ему для работы.
Но, как и было сказано, модуль не может это сделать напрямую — для создания необходимо вызвать конструктор конкретного типа, и в результате модуль будет зависеть не от интерфейса, а от конкретной реализации. Решить проблему в данном случае позволяет шаблон Фабричный Метод (Factory Method).
«Суть заключается в том, что вместо непосредственного инстанцирования объекта через new, мы предоставляем классу-клиенту некоторый интерфейс для создания объектов. Поскольку такой интерфейс при правильном дизайне всегда может быть переопределён, мы получаем определённую гибкость при использовании низкоуровневых модулей в модулях высокого уровня».
В случаях, когда нужно создавать группы или семейства взаимосвязанных объектов, вместо Фабричного Метода используется Абстрактная Фабрика (Abstract factory).
Модуль берет необходимые объекты у того, у кого они уже есть (обычно это некоторый, известный всем репозиторий, в котором уже лежит все, что только может понадобиться для работы программы).
Этот подход реализуется шаблоном Локатор Сервисов (Service Locator), основная идея которого заключается в том, что в программе имеется объект, знающий, как получить все зависимости (сервисы), которые могут потребоваться.
Главное отличие от фабрик в том, что Service Locator не создаёт объекты, а фактически уже содержит в себе инстанцированные объекты (или знает где/как их получить, а если и создает, то только один раз при первом обращении). Фабрика при каждом обращении создает новый объект, который вы получаете в полную собственность и можете делать с ним что хотите. Локатор же сервисов выдает ссылки на одни и те же, уже существующие объекты. Поэтому с объектами, выданными Service Locator, нужно быть очень осторожным, так как одновременно с вами ими может пользоваться кто-то еще.
Объекты в Service Locator могут быть добавлены напрямую, через конфигурационный файл, да и вообще любым удобным программисту способом. Сам Service Locator может быть статическим классом с набором статических методов, синглетоном или интерфейсом и передаваться требуемым классам через конструктор или метод.
Вообще говоря, Service Locator иногда называют антипаттерном и не рекомендуют использовать (главным образом потому, что он создает неявные связности и дает лишь видимость хорошего дизайна). Подробно можно почитать у Марка Симана:
Service Locator is an Anti-Pattern
Abstract Factory or Service Locator?
Модуль вообще не заботиться о «добывании» зависимостей. Он лишь определяет, что ему нужно для работы, а все необходимые зависимости ему поставляются («впрыскиваются») из вне кем-то другим.
Это так и называется — Внедрение Зависимостей (Dependency Injection). Обычно требуемые зависимости передаются либо в качестве параметров конструктора (Constructor Injection), либо через методы класса (Setter injection).
Такой подход инвертирует процесс создания зависимости — вместо самого модуля создание зависимостей контролирует кто-то извне. Модуль из активного элемента, становится пассивным — не он делает, а для него делают. Такое изменение направления действия называется Инверсия Контроля (Inversion of Control), или Принцип Голливуда — «Не звоните нам, мы сами вам позвоним».
Это самое гибкое решение, дающее модулям наибольшую автономность. Можно сказать, что только оно в полной мере реализует «Принцип единственной ответственности» — модуль должен быть полностью сфокусирован на том, чтобы хорошо выполнять свою функцию и не заботиться ни о чем другом. Обеспечение его всем необходимым для работы это отдельная задача, которой должен заниматься соответствующий «специалист» (обычно управлением зависимостями и их внедрениями занимается некий контейнер — IoC-контейнер).
По сути, здесь все как в жизни: в хорошо организованной компании программисты программируют, а столы, компьютеры и все необходимое им для работы покупает и обеспечивает кладовщик. Или, если использовать метафору программы как конструктора — модуль не должен думать о проводах, сборкой конструктора занимается кто-то другой, а не сами детали.

Более подробно и с примерами о способах создания и получения зависимостей можно почитать, например, в этой статье (только надо иметь ввиду, что хотя автор пишет о Dependency Inversion, он использует термин Inversion of Control; возможно потому, что в русской википедии содержится ошибка и этим терминам даны одинаковые определения). А принцип Inversion of Control (вместе с Dependency Injection и Service Locator) детально разбирается Мартином Фаулером и есть переводы обеих его статей: «Inversion of Control Containers and the Dependency Injection pattern» и “Inversion of Control”.

Не будет преувеличением сказать, что использование интерфейсов для описания зависимостей между модулями (Dependency Inversion) + корректное создание и внедрение этих зависимостей (прежде всего Dependency Injection) являются центральными/базовыми техниками для снижения связанности. Они служат тем фундаментом, на котором вообще держится слабая связанность кода, его гибкость, устойчивость к изменениям, переиспользование, и без которого все остальные техники имеют мало смысла. Но, если с фундаментом все в порядке, то знание дополнительных приемов может быть очень даже полезным. Поэтому продолжим.

3. Замена прямых зависимостей на обмен сообщениями

Иногда модулю нужно всего лишь известить других о том, что в нем произошли какие-то события/изменения и ему не важно, что с этой информацией будет происходить потом. В этом случае модулям вовсе нет необходимости «знать друг о друге», то есть содержать прямые ссылки и взаимодействовать непосредственно, а достаточно всего лишь обмениваться сообщениями (messages) или событиями (events).

Связь модулей через обмен сообщениями является гораздо более слабой, чем прямая зависимость и реализуется она чаще всего с помощью следующих шаблонов:

Наблюдатель (Observer). Применяется в случае зависимости «один-ко-многим», когда множество модулей зависят от состояния одного — основного. Использует механизм рассылки, который заключается в том, что основной модуль просто осуществляет рассылку одинаковых сообщений всем своим подписчикам, а модули, заинтересованные в этой информации, реализуют интерфейс «подписчика» и подписываются на рассылку. Находит широкое применение в системах с пользовательским интерфейсом, позволяя ядру приложения (модели) оставаться независимым и при этом информировать связанные с ним интерфейсы о том что произошли какие-то изменения и нужно обновиться.
Организация взаимодействия посредством рассылки сообщений имеет дополнительный «бонус» — необязательность существования «подписчиков» на «опубликованные» (т.е. рассылаемые) сообщения. Качественно спроектированная подобная система допускает добавление/удаление модулей в любое время.
Посредник (Mediator). Применяется, когда между модулями имеется зависимость «многие ко многим. Медиатор выступает в качестве посредника в общении между модулями, действуя как центр связи и избавляет модули от необходимости явно ссылаться друг на друга. В результате взаимодействие модулей друг с другом («все со всеми») заменяется взаимодействием модулей лишь с посредником («один со всеми»). Говорят, что посредник инкапсулирует взаимодействие между множеством модулей.
Типичный пример — контроль трафика в аэропорту. Все сообщения, исходящие от самолетов, поступают в башню управления диспетчеру, вместо того, чтобы пересылаться между самолетами напрямую. А диспетчер уже принимает решения о том, какие самолеты могут взлетать или садиться, и в свою очередь отправляет самолетам соответствующие сообщения. Подробнее, например, тут.

Дополнение: Модули могут пересылать друг другу не только «простые сообщения, но и объекты-команды. Такое взаимодействие описывается шаблоном Команда (Command). Суть заключается в инкапсулировании запроса на выполнение определенного действия в виде отдельного объекта (фактически этот объект содержит один единственный метод execute()), что позволяет затем передавать это действие другим модулям на выполнение в качестве параметра, и вообще производить с объектом-командой любые операции, какие могут быть произведены над обычными объектами. Кратко рассмотрен тут, соответствующая глава из книги банды четырех тут, есть также статья на хабре.

4. Замена прямых зависимостей на синхронизацию через общее ядро

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

Ядро-посредник может как знать о модулях-клиентах и управлять ими (пример — архитектура apache ), так и может быть полностью, или почти полностью, независимым и ничего о клиентах не знать. В сущности именно этот подход реализован в «шаблоне» Модель-Вид-Контроллер (MVC), где с одной Моделью (являющейся ядром приложение и общим хранилищем данных) могут взаимодействовать множество Пользовательских Интерфейсов, которые работают синхронно и при этом не знают друг о друге, а Модель не знает о них. Ничто не мешает подключить к общей модели и синхронизировать таким образом не только интерфейсы, но и другие вспомогательные модули.

Очень активно эта идея также используется при разработке игр, где независимые модули, отвечающие за графику, звук, физику, управление программой синхронизируются друг с другом через игровое ядро (модель), где хранятся все данные о состоянии игры и ее персонажах. В отличие от MVC, в играх согласование модулей с ядром (моделью) происходит не за счет шаблона «Наблюдатель», а по таймеру, что само по себе является интересным архитектурным решением весьма полезным для программ с анимацией и «бегущей» графикой.

5. Закон Деметры (law of Demeter)

Закон Деметры запрещает использование неявных зависимостей: «Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C«. Java-пример.

Это означает, что все зависимости в коде должны быть «явными» — классы/модули могут использовать в работе только «свои зависимости» и не должны лезть через них к другим. Кратко этот принцип формулируют еще таким образом: «Взаимодействуй только с непосредственными друзьями, а не с друзьями друзей«. Тем самым достигается меньшая связанность кода, а также большая наглядность и прозрачность его дизайна.

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

6. Композиция вместо наследования

Одну из самых сильных связей между объектами дает наследование, поэтому, по возможности, его следует избегать и заменять композицией. Эта тема хорошо раскрыта в статье Герба Саттера — «Предпочитайте композицию наследованию».

Могу только посоветовать в данном контексте обратить внимание на шаблон Делегат (Delegation/Delegate) и пришедший из игр шаблон Компонет (Component), который подробно описан в книге «Game Programming Patterns» (соответствующая глава из этой книги на английском и ее перевод).

Статьи в интернете:

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

Интересные решения и идеи можно найти в материалах, посвященных разработке игр. Game Programming Patterns — большой сайт с подробным описанием многих шаблонов и примерами их применения к задаче создания игр (оказывается, есть уже его перевод — «Шаблоны игрового программирования», спасибо strannik_k за ссылку). Возможно будет полезна также статья «Гибкая и масштабируемая архитектура для компьютерных игр» (и ее оригинал. Нужно только иметь ввиду что автор почему-то композицию называет шаблоном «Наблюдатель»).

По поводу паттернов проектирования:

Есть еще принципы/паттерны GRASP, описанные Крэгом Лэрманом в книге «Применение UML 2.0 и шаблонов проектирования», но они больше запутывают чем проясняют. Краткий обзор и обсуждение на хабре (самое ценное в комментариях).

Ну и конечно же книги:

Советы начинающим проектировщикам | Проектирование электроснабжения

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

В проектирование я попал случайно. У меня уже около 10 лет стажа проектировщика-электрика, поэтому я понимаю и знаю, с какими трудностями сталкиваются начинающие проектировщики.

Основная проблема начинающих проектировщиков – отсутствие знаний и опыта работы. Должен сказать, что проектировщиком может стать практически каждый, даже если у вас не совсем профильное образование.

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

Как проектировать?

Где взять знания и опыт?

Знания и опыт можно получить:

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

Условно-бесплатно. Самый оптимальный вариант. Такой путь прошел я. Мне повезло, что меня взяли в серьезный проектный институт моего города, где был огромный электротехнический отдел. Я всегда мог получить бесплатную консультацию у своих коллег, которые обладали огромным проектным опытом и знаниями. Сейчас многие из них ушли на повышение, кто-то ушел на пенсию, а кто-то еще работает. Как правило, в таких организациях не самые высокие зарплаты. Если бы я там зарабатывал больше, то, не исключено, я бы все еще работал бы в той организации. Когда у тебя нет ничего, ты вынужден искать работу с большей зарплатой, чтобы можно было накопить денег на квартиру. На самом деле, я работу не искал, меня сами нашли и предложили лучшие условия работы. Было очень тяжело переходить на новую работу, расставаться с коллективом, на тот момент я еще не был таким специалистом, как сейчас

Платно. Самый быстрый вариант получения знаний и опыта, но, требует финансового вложения. Я считаю 50-300$ потратить на обучение – не большие деньги, которые окупаются очень быстро.

Если вы решили стать проектировщиком-электриком, то советую вам начать с проектирования частных домов и квартир. Для этого вам подойдет мой курс по проектированию частного жилья. Пройдя этот курс, вы с легкостью сделаете свой первый проект. Также советую, хорошо изучить программу AutoCAD.

Для проектирования наружных кабельных сетей и наружного освещения подойдет «Практический курс проектирования кабельных сетей 0,4/10кВ – All Inclusive».

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

Вы спросите, а какой опыт могут дать такие курсы? Мои курсы основаны на моем личном опыте проектирования и кроме теоретических знаний, я даю практику и делаю обзоры всех проектов, которые делал и делаю лично. В одно видео можно вложить опыт, который накапливался годами. За 20 мин вы получите то, к чему будете идти месяцами и годами.

Есть и другие платные варианты обучения. Я с ними не знаком и не знаю, насколько они полезны.

Поиск работы

Как искать работу?

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

Пройдитесь по всем проектным организациям, возможно, повезет. Спросите у знакомых, вдруг помогут.

Также не стоит пренебрегать объявлениями в газетах и в интернете.

Можно попытаться найти работу удалено, но, будете осторожны.

Где брать заказы?

Если вы работаете в проектной организации, то работой вас обеспечит работодатель.

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

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

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

Делайте свою работу качественно и сарафанное радио само будет находить вам заказы и дополнительную работу.

7 раз подумай, прежде чем стать проектировщиком

Вот так выглядит проектировщик

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

Советую почитать:

Вы можете пролистать до конца и оставить комментарий. Уведомления сейчас отключены.

Free Logo Maker | Неограниченное количество шаблонов логотипов

Зачем нужен логотип?

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

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

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

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

Что отличает хороший дизайн логотипа?

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

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

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

Как сделать дизайн логотипа?

Если вы решите создать логотип, привлекая графический дизайнер или создатель логотипов, основные элементы те же.

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

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

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

Должен ли я использовать производителя логотипов или нанять дизайнера логотипов?

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

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

a .Разместите рекламу или обратитесь к дизайнерам логотипов, которые специализируются в типе дизайна, который вам нравится.

б . Попросите портфолио.

c . Согласуйте цены.

д . Составьте договор.

и . Приступайте к работе.

ф . Доработать дизайн.

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

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

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

Когда я могу использовать свой логотип?

Когда вы загружаете дизайн своего логотипа, вы получаете вектор файлы, такие как PNG, JPEG и PDF, что позволяет мгновенно использовать свой логотип.

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

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

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

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

Как бесплатно сделать логотип компании?

Вы можете бесплатно сделать логотип компании, используя самодельную инструмент для создания логотипа.Программный инструмент для создания логотипов, такой как LogoDesign.net, предлагает множество бесплатных логотипов. шаблоны. Вы можете начать с выбора четырех основных элементов: название компании, шрифт, цвет логотипа и символ (необязательно).

Чтобы начать создание логотипа компании, перейдите на страницу нашей галереи и выполните следующие действия:

Шаг 1 . Выберите символ или букву алфавита из наших логотипов база данных.

Шаг 2 . Настройте логотип вашей компании для цветов, шрифта или текста в студия дизайна логотипов.

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

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

Как зарегистрировать логотип?

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

Есть законный способ защитить их — путем регистрации товарного знака в законном органе, что в США может быть осуществляется через Бюро по патентам и товарным знакам США.

Чтобы зарегистрировать логотип, сначала необходимо убедиться, что аналогичные символы не уже был зарегистрирован кем-то другим. Вы можете сделать это, отметив товарный знак. База данных электронной поисковой системы (TESS).

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

Вы можете зарегистрировать товарный знак на сумму от 275 до 325 долларов США, если это не законно. адвокат задействован.В течение шести месяцев до одного года вы сможете получить подтверждение того, был ли ваш дизайн зарегистрирован как товарный знак.

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

Позволяет ли ваше программное обеспечение создавать логотип без текста?

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

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

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

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

Как создать логотип с буквами?

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

Создайте дизайн логотипа с буквами, сначала определив, какую букву вы хотите представлять свой бренд. У нас есть обширная библиотека буквенных логотипов от A до Z, где логотип каждой буквы разработан с учетом отрасли, бренда и логотипа. Будь ты ищу алфавит для йоги логотип центра или инициал для создания вашего юриста логотип, наш создатель логотипа предлагает тысячи профессионально разработанных буквенных логотипов для вас Выбери из.

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

Выберите буквенный логотип, чтобы приступить к созданию дизайна.
Затем перейдите в дизайн-студию, чтобы настроить цвета, название компании и слоган.
Наконец, загрузите буквенный логотип в векторные файлы, чтобы начать брендинг.

Могу ли я создать свой собственный логотип с лозунгами?

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

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

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

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

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

Как вариант, вы можете создать логотип без символов. У нас есть множество алфавит буквенные логотипы.

Сколько стоит дизайн логотипа?

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

Вы можете использовать инструмент для создания логотипов, например LogoDesign.net, или нанять профессионального дизайнер логотипов сделает эту работу.

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

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

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

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

Является ли создатель вашего логотипа бесплатным для всех?

Это определенно! Наш конструктор логотипов бесплатен для использования всеми и в любом месте.Вы можете использовать его в любое время, из любой точки мира и выбрать любой символ или букву в нашей базе данных. Нет ограничений на использование нашего программного обеспечения для создания логотипов. Если вам нравится дизайн для скачивания, только тогда вы платите. Так что начните пользоваться инструментом уже сегодня!

Родной город

2021 Цветовые тренды

Идеи уютной гостиной

Модернизация кухонного шкафа

Зимостойкие растения

Показывает

Особняки со скидкой
Брат против.Родной брат
Знаменитость I.O.U.
Кристина на побережье
Fixer to Fabulous
Флип или флоп
Листать 101
Good Bones

Как разработать новую программу

Разработка новой программы может быть одновременно сложной и полезной.Сложно, потому что сложно понять, правильно ли вы его спроектировали. Вознаграждает, если ваша программа перестает работать (или обескураживает, если она не работает!).

Существует множество руководств по разработке программ, например, от IFRC и UNDP. Проблема в том, что, хотя большинство руководств подходят для крупномасштабных программ, они могут быть «лишними» для небольших программ или ситуаций, когда у вас ограниченное время и ресурсы.

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

Узнайте, в чем проблема

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

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

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

Также очень важно убедиться, что проблемы в вашем дереве проблем действительно существуют. Это можно сделать путем опроса или сбора других количественных данных.Например, однажды я работала над программой, в которой заинтересованные стороны сообщества считали, что одной из основных причин незапланированной беременности является то, что мужья не позволяют своим женам использовать методы планирования семьи. Однако после того, как мы провели опрос, чтобы проверить это, мы фактически обнаружили, что только 2% женщин имели эту проблему. Поэтому мы удалили его из дерева проблем.

Узнайте, кто заинтересованные стороны

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

Затем проведите встречу с каждой из заинтересованных сторон вместе или по отдельности. К концу встреч вы сможете ответить на следующие вопросы о каждой заинтересованной стороне (вы можете записать ответы в таблице):

Проблема: С какими основными проблемами они сталкиваются?
Мотивация: Что их мотивирует? Что им интересно?
Потенциал: Как они могут внести свой вклад в решение выявленных проблем?
Взаимодействие: Как мы можем лучше всего с ними взаимодействовать? (е.г. через встречи, отчеты, телефонные звонки и т. д.)

Подумайте, какие ресурсы и навыки у вас есть

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

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

Исследование эффективных вмешательств

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

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

Выберите цель и способы ее измерения

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

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

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

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

Определите, какие действия могут привести к цели

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

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

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

Создание документации

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

Логическая структура: описывает, как действия программы приведут к немедленным результатам и как они приведут к целям / результатам и цели.
Система мониторинга и оценки: описывает индикаторы, которые используются для измерения успешности программы.
Рабочий план: показывает все действия, включенные в программу, кто отвечает за каждое действие, и когда действия будут завершены.

Мне лично нравится объединять все эти ключевые документы вместе с деревом проблем, сведениями о заинтересованных сторонах и теорией изменений в единое Руководство по программе. Затем это становится «библией» программы.

Будьте гибкими

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

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

Фото: Городской технический комитет Сиэтла

Как создать руководство по бренду (пошаговое руководство)

Поддержание качества и единообразия контента вашего бренда является сложной задачей, особенно если вы создаете большой объем контента (или работаете со многими создателями контента).Без правильного направления вы можете легко получить контент в стиле Франкенштейна, страдающий от неправильных цветов, неуместных логотипов и сообщений, не связанных с брендом. Это не просто оплошность; это может стать реальной угрозой целостности вашего бренда. Как же тогда создавать контент, который всегда соответствует бренду? С подробными рекомендациями по бренду.

Как рекомендации по использованию бренда помогают вашему бренду

Все, что вы создаете, должно точно представлять ваш бренд. Но чем больше ваша сеть, тем сложнее контролировать контент и следить за тем, чтобы все было в порядке.(Иногда это даже не вина фрилансера; внутренние команды тоже могут немного расслабиться.)

Вот почему правила бренда имеют значение. Они содержат руководящие принципы, необходимые всем создателям контента для точного представления вашего бренда, подробно описывая все, от того, что сказать, до того, как создавать контент. Это не только обеспечивает единообразие, но и приносит пользу вашему бренду несколькими способами:

Более строгий контроль качества: Не у всех есть арт-директор, готовый просмотреть каждый проект, и зачастую вы не успеваете в срок.Эти и многие другие переменные могут привести к тому, что контент будет несвязным и неэффективным. Ваша репутация зависит от качества вашего творческого контента, поэтому наличие хорошо задокументированных правил гарантирует, что вы всегда будете размещать контент, которым гордитесь.
Повышенное понимание: Четкое общение и хороший дизайн облегчают жизнь вашему читателю или зрителю. Рекомендации по таким вещам, как визуализация данных, использование цвета или типографика, помогают создателям создавать более эффективный контент, создавая в целом более удобное восприятие контента.Кроме того, это простое действие — огромная услуга для людей, с которыми вы хотите общаться. Это показывает, что вы цените их время и вкладываетесь в то, чтобы помочь им получить нужную информацию.
Лучшая узнаваемость бренда: Рекомендации по использованию бренда помогут вам обеспечить целостное восприятие бренда, облегчая людям распознавание вашего ценного контента. Когда вы предоставляете постоянный высококачественный контент, люди начинают полагаться на вас и, что еще лучше, искать ваш контент. Они верят, что вы всегда будете делать то, что они хотят, и это доверие является основой любых прочных отношений.

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

Как создать рекомендации по бренду

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

Шаг 1. Выбор формата

В зависимости от ваших потребностей, ресурсов и времени вы можете разработать статические рекомендации, которые можно легко распространить в виде PDF-файла (или разместить где-нибудь на вашем сервере). Или вы можете создать их для печати. (Мы видели множество великолепных печатных руководств, таких как отмеченные наградами бумажные руководства по бренду Fisher и Paykel.)

Вы также можете разработать интерактивные руководства по бренду, как мы.

Руководство по стилю бренда C5 размещено в Интернете, что позволяет нашей команде легко получить доступ в любое время и в любом месте.

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

Шаг 2: Определите все, что нужно включить

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

У разных брендов разные потребности, но все руководства по бренду должны включать следующие основные элементы:

Сердце бренда

Это в основном общее объяснение основных принципов вашего бренда, в частности вашего:

Цель: Почему вы существуете?
Видение: Какое будущее вы хотите помочь создать? Как выглядит будущее?
Миссия: Что ты здесь делать? Как вы создаете это будущее?
Значения: Какие принципы определяют ваше поведение?

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

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

Обмен сообщениями

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

Сущность бренда (голос, тон и индивидуальность)
Ценность prop
Tagline
Столпы обмена сообщениями

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

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

Визуальные инструкции

Дизайн играет огромную роль в успехе вашего бренда. (Фактически, Институт управления дизайном и Motiv обнаружили, что компании, ориентированные на дизайн, за последние 10 лет превзошли S&P 500 на 228%.) Ваши рекомендации должны включать исчерпывающую визуальную идентификацию для создания контента, в том числе:

Цвета
Логотипы
Шрифты и типографика
Иерархия
Фотография
Иллюстрация
Иконография
Визуализация данных
Интерактивные элементы 901 Видео и движение
Веб-дизайн
И т. Д.

Пример. Мы разработали руководство по бренду для The Cove , предприятия UCI Applied Innovation, занимающегося производством рабочих пространств.Чтобы отразить миссию и суть бренда (центр инноваций в Калифорнии), мы разработали визуальный язык на тему океана, включая логотип, цвета, шрифт, иконографию, фотографии и т. Д., Которые будут использоваться во всем творческом контенте.

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

Разные элементы брендинга (если применимо)

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

Шаг 3. Создайте рекомендации по бренду (с примерами)

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

Пример. Руководство по стилю бренда Visage включает в себя все, от макета типографики до фотографии .

Для рекомендаций по обмену сообщениями покажите примеры распространенных вариантов использования, например:

Социальная копия
Пресс-релизы
Маркетинговые электронные письма
Описания продуктов

Пример: руководство по использованию бренда C5 дает простые советы по написанию разных типов копии.

Для визуальных указаний укажите следующие элементы:

Размещение логотипа
Цветовые палитры
Размещение типографики
Иерархия
Рекомендации по изображениям (размер, размещение страницы)

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

Пример. Точно так же руководство Visage также включает направление цвета.

Еще несколько советов, которые сделают ваши рекомендации более эффективными:

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

Помните: даже правила вашего бренда — это часть фирменного контента. Привлекайте индивидуальность бренда везде, где можете.

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

Шаг 4. Облегчите доступ к руководствам по бренду

Одна из наиболее частых причин, по которой люди игнорируют рекомендации по бренду, — это просто потому, что они не знают, где их найти.Если ваши рекомендации труднодоступны и на них регулярно ссылаться, вы можете напечатать 1000 брошюр с вашим старым логотипом. Убедитесь, что ваши рекомендации находятся в удобном для поиска месте (например, на сервере компании или в корпоративной Wiki) и доступны всем, особенно новым сотрудникам или творческим партнерам. Даже если у вас есть бумажная копия, создайте и цифровую копию, чтобы поделиться ею.

Всегда обновляйте правила вашего бренда

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

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

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

Макет веб-страницы: анатомия веб-сайта, которую необходимо изучить каждому дизайнеру

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

Звук невозможен?

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

Трехэтапный процесс разработки макета бизнес-сайта

Шаг 1. Сначала продумайте путь пользователя

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

А у веб-сайта, который не может обеспечить хорошее взаимодействие с пользователем, гораздо меньше шансов привлечь приличный объем трафика — в конце концов, UX и SEO идут рука об руку. Есть выбросы с небрежным UX, которые по-прежнему привлекают множество пользователей — см. Craigslist. Но у компаний с лучшим UX, таких как Uber, Airbnb и Slack, гораздо больше шансов заново изобрести свои отрасли.

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

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

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

Good IA создаст иерархию, которая выделяет наиболее важные элементы и удерживает посетителей. Без прочного «скелета», на котором можно было бы опираться, вы настроите себя на неудачу.

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

Хорошая навигация имеет три основных характеристики:

Простота
Четкость
Консистенция

Вот пример панировочных сухарей в действии (над основной фотографией продукта) в магазине Decibullz .

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

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

Шаг 2. Получите правильную визуальную иерархию

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

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

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

Различные принципы дизайна помогают создать сильную визуальную иерархию.

Использовать сетку

Сетки

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

Дизайн для естественного сканирования узоров

Есть два основных шаблона сканирования глаз, которые люди используют для быстрого сканирования блоков контента:

F-образный узор
Z-образный узор

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

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

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

Вот несколько способов направить посетителей к прочтению наиболее важной информации:

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

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

Примеры F-образных схем чтения. Источник: NNgroup

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

Этот макет веб-сайта отлично подходит, если вы хотите привлечь внимание пользователей к конкретному призыву к действию или контенту на странице.Источник: Basecamp

‍

Визуально расставьте приоритеты ключевых элементов

Используйте пять основных строительных блоков дизайна, чтобы построить визуальную иерархию, понятную с первого взгляда:

1. Размер

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

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

2. Цвет

Помните, что цвет может действовать как организационный инструмент, а также как инструмент брендинга / индивидуальности в дизайне.

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

3. Макет

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

Это ежеквартальное издание Google использует карточный дизайн для организации содержания на странице и поощрения их основной цели: подписки. Источник: Think with Google .

4. Шаг

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

Apple хорошо известна своим использованием белого пространства.Источник: Apple

5. Стиль.

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

Airtable использует сделанные на заказ иллюстрации, чтобы добавить индивидуальности и дружелюбности своему продукту. Источник: Airtable

Примените правило третей

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

Концепция редизайна сайта National Geographic от Гаян Ваматева

Шаг 3. Сосредоточьтесь на кнопках с призывом к действию

Ни один веб-сайт не обходится без кнопок призыва к действию (CTA). Фактически, маркетологи сказали бы, что они — самый важный элемент на странице, и все усилия должны быть сосредоточены на том, чтобы люди переходили по ссылкам.Стратегическое использование хорошо продуманных призывов к действию может значительно улучшить поток страницы и направить пользователя к конверсии, поэтому очень важно понять это правильно.

Вот что нужно учитывать при разработке кнопок.

Убедитесь, что кнопки выглядят интерактивными

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

Использование только призрачных кнопок может запутать пользователя в том, что ему делать дальше. Источник: Visage Вот пример применения визуальной иерархии к кнопкам с призывом к действию. Обратите внимание, как призрачная кнопка зарезервирована для вторичного действия. Источник: Typeform

Четко обозначьте все кнопки

Кнопки указывают пользователям, что им делать дальше.Если копия расплывчата, люди скорее думают, чем действуют. Объясните пользователям, что произойдет, если они перейдут по ссылке. Вот умный пример от Netflix.

Визуально выделите наиболее важные CTA

Есть три важных аспекта при разработке четкого CTA: цвет, контраст и расположение. Используйте привлекательный цвет с достаточным контрастом, чтобы выделить основные кнопки, и разместите их на видных местах, где пользователи не смогут их пропустить.

Что еще вы хотели бы знать о верстке?

Мы хотим копнуть глубже, чем 101 балл по этой жизненно важной теме, поэтому дайте нам знать, что еще вы хотели бы узнать!

Как создать свою собственную жизнь

Нет никаких гарантий, что жизнь сложится так, как вы хотите … но у вас больше шансов на то, что все сложится так, как вы хотите, если вы знаете, как построить свою собственную жизнь.

Мне нравится изображение архитектора, проектирующего здание, сначала выкладывая чертежи.Или писатель, обрисовывающий книгу, начиная с оглавления. Способность творить с нуля — сильное чувство. Дом появляется из листа чертежей. Книга складывается из воображения писателя.

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

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

И у вас могут быть самые продуманные планы, но они все равно идут не так, как надо, сбиваются с пути или сталкиваются с препятствиями. Итак, поскольку мы не можем контролировать прошлое и не можем контролировать будущее, что мы можем контролировать, если хотим спроектировать свою собственную жизнь? Что ж, мы можем составить план сегодня, мы можем работать над нашим планом каждый день, мы можем изменять наш план по мере необходимости, и мы можем сделать лучшее из того, что появляется, даже когда это не то, что мы хотим.

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

1. Чертеж

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

2. Фокус

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

3. Действие

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

4. Техническое обслуживание

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

5. Ремонт

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

6. Опора

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

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