Как спроектировать: макет на компьютере своими руками, как нарисовать в Зd – Мой подход к проектированию веб-сайтов / Habr

Мой подход к проектированию веб-сайтов / Habr

Прелюдия

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

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

Всё начинается с…

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

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

2) «Неидеальный вариант» обычно хочет, что бы всё летало, в каждом углу были анимированные часики, но при этом никак не может определиться что же за информацию необходимо разместить на сайте. А нам ведь совсем не нужен вариант, что в середине работы мы вдруг узнаем, что подробный каталог продукции, который мы обсуждали и уже практически реализовали технически, на самом деле будет статической страничкой с прайс-листами, а всё, что нам так усердно рассказывал заказчик — это внутренняя структура прайс-листов, которую мы и не увидим никогда! Для того, что бы избежать данных трений, с такими заказчиками приходится совместно заниматься разработкой технического задания.

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

… И тут на помощь приходят они!

Mindmap, создаем структуру сайта

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

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

Пример 1:

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

Описание схемы:

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

Пример 2:

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

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

БД

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

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

Ну и конечно же не малую роль играет удобство, лично мне намного приятнее слепить БД в софте типа MySQL Workbench и экспортировать результат в SQL, предварительно проставив связи, ключи свойства и визуально проверив результат. В любом случае это намного удобнее, чем самый распространенный способ заполнения БД в phpMyAdmin

Скрин таблицы из MySQL Workbench

Прототипирование, создание wireframe’ов

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

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

Скриншот с tarekshalaby.com по наводке google image search

В качестве инструмента не буду советовать какой-то конкретный, так как сам ещё окончательно не определился. Лично приходилось работать с настольным приложение Balsamic Mockups и веб-сервисом Hotgloo. Hotgloo конечно интересен тем, что можно сделать макеты с переходом по ссылкам и пародиями на такие действия как “положить товар в корзину”, но мне не очень нравится его ценовая политика, а иногда просто удобнее использовать настольное приложение.

Скриншот с оффсайта Balsamic Mockups

В Заключение

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

Спасибо за чтение и желаю Вам интересных и красивых проектов в 2011 году!

Как спроектировать систему уведомлений. Пошаговая инструкция с примерами

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

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

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

Шаг 1: Определяем участников процесса

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

Рассмотрим подробнее, кто принимает участие в системе:

1. Дизайнер — исполнитель задачи. Пусть его работа уже выполнена, но ему важно знать результат: макеты приняли или возвращают на доработку.
2. Арт-директор — принимает выполненную работу и утверждает ее с менеджером-заказчиком. Ему важно следить за ходом голосования и быстро принимать тактические решения.
3. Менеджеры — получают готовую работу на утверждение. Им важно понимать, что их просят проверить и как срочно нужно рассмотреть задачу. И, конечно, принять решение с возможностью его прокомментировать.

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

1. Исполнитель — один или группа людей, на которых назначена задача. Определяется полем «Исполнители» в задаче.
2. Инициатор — пользователь, запустивший процесс утверждения.
3. Утверждающий — один или группа пользователей, назначенных на утверждение.

Часто в системе могут быть неявные роли, о которых не стоит забывать. Например, если требуется высылать уведомления о состоянии происходящего процесса, то полезно будет ввести роль «Робот» — сообщения пользователям от лица вашего продукта.

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

Шаг 2: Строим таблицу «Событие — Уведомление»

Строим каркас

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

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

1. Инициатор — действия инициатора от запуска утверждения до его окончания;
2. Утверждающий — принятие решения и комментарии к нему;
3. Робот — события по состоянию системы.

Верхняя строка. Сюда мы запишем роли, которые должны получать уведомления. На практике используют также разные каналы связи, например, push-уведомления или смс. Для простоты рассмотрим только один канал связи «Входящие» — персональную ленту уведомлений:

1. Утверждающий
2. Исполнитель
3. Инициатор

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

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

Заполняем события

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

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

Шаг 3: Определяем принципы получения уведомлений

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

В нашей модели утверждения выделим следующие принципы:

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

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

Шаг 4: Заполняем уведомления

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

1. Старайтесь переиспользовать формулировки или их одинаковые части. Так уведомления получатся более консистентными. Если вы делаете международный продукт, это облегчит работу команде локализации.
2. В строках уведомлений выделяйте переменные данные среди основного текста. Например, «ПОЛЬЗОВАТЕЛЬ: изменил дату исполнения на ДАТА». Так разработчикам будет легче работать с вашими строками.
3. Не забывайте о правилах хороших уведомлений: краткие формулировки, максимум полезной информации, тон в соответствии с вашим брендом, выбранные принципы получения. Постарайтесь протестировать заранее длину строк в интерфейсе вашего продукта или мобильных пуш-уведомлениях — некоторые формулировки могут сложно считываться или обрезаться многоточием.
4. Ставьте прочерки там, где уведомления не должны отправляться. Когда проект занимает длительное время, легко запутаться, где вы еще не заполнили таблицу, а где решили, что их не должно быть. Это также снимет вопросы команды.

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

Шаг 5: Дорабатываем события

После заполнения всех ячеек таблицу стоит доработать:

1. Привести все подобные строки к одному виду. Иногда бывает, что в большом списке одинаковые по смыслу части отличаются: немного разные падежи, предлоги, глаголы-синонимы.
2. Добавить формулировки для массовых событий, где это возможно, чтобы сократить количество штучных уведомлений. Например, «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»
3. Добавить новые уникальные строки на замену группам последовательных действий. Например, вместо удаления утверждающих с последующим добавлением других можно сделать событие «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ»
4. Обсудить все уведомления с командой разработки. Архитектура продукта может не позволить реализовать некоторые ваши идеи, даже если выглядят они просто и логично. Чем раньше вы покажете черновик вашему бэкэнд разработчику, тем больше времени сэкономите в дальнейшей разработке.

Заключение

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

Несколько полезных советов для дальнейшей работы с таблицей:

1. Для разных сценариев продукта используйте отдельные страницы таблицы. В ней будет легче ориентироваться и находить нужные места.
2. Проведите команде разработки презентацию. Объясните логику и принципы ее построения. Ответьте на вопросы, чтобы у всех было одинаковое понимание в работе.
3. Если в вашем продукте работают с уведомлениями другие дизайнеры, внедрите подход и используйте общую таблицу. Так все события сохранятся в одном месте, и будет видна общая картина.

Серьезное проектирование серьезных сайтов. Часть 1. Аналитика / SECL Group corporate blog / Habr

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

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

Вступление

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

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

Процесс проектирования

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

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

1. Сбор требований (брифинг).

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

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

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

Третье. Спросите про целевую аудиторию (ЦА): кто именно будет пользоваться сайтом, и какую полезность он получит. Ответ «все пользователи интернета» — недопустим, это будет означать, что инициатор проекта не понимает, для кого именно он создает этот проект, а значит и непонятно, как его делать. Это, как играть в дартс с закрытыми глазами: где цель известна, а прицелиться нет возможности. На этом этапе в идеале выяснить стандартные параметры ЦА: пол, возраст, регион и т.д. Обязательно нужно выделить ядро ЦА. Кроме этого нужно понимать какими устройствами и ПО пользуется ЦА. Этап глубокой работы с ЦА будет в одном из последующих этапов, а пока нужно понимать, как это видит инициатор проекта.

Четвертое. Узнайте, кто являются прямыми и косвенными конкурентами. Ответ «конкурентов нет», скорее всего, говорит о том, что человек не изучил конкурентную среду. Почти всегда есть конкуренты. Даже если идея проекта уникальная, ЦА уже пользуется какими-то сайтами, а значит, как минимум, есть косвенные конкуренты.

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

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

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

2. Цели проекта и клиента.

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

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

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

На выходе у нас получается тестовый документ с двумя списками: цели клиента и цели проекта. Этот документ должен утвердить заказчик.

Пример:

Проект: социальная сеть владельцев домашних животных.

Цели заказчика: получение прибыли

Цели проекта:

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

3. ЦА и персонажи.

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

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

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

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

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

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

После подробного портрета ЦА мы можем приступать к персонажам. Это очень полезный прием для дальнейшей генерации идей. Имея понимание, кто наша ЦА в общем, мы её должны разбить на группы типовых пользователей будущего проекта. Исходя из тематики проекта, группы можно объединять по роду деятельности, владению каким-то предметом, потребностям и т.д. Например, для тематической социальной сети ИТ специалистов группы могут быть следующими: системный администратор, программист, директор ИТ компании и т.д. Задача проектировщика создать список основных целевых групп сайта, начиная от самой большой группы пользователей (ядро) и по убыванию. Нужно не забыть, что кроме обычных пользователей могут быть еще собственные сотрудники, партнеры, рекламодатели и многие другие неочевидные пользователи.

Для каждой группы мы придумываем типичного персонажа, некого вымышленного человека, который до мозга костей является типичным представителем именно этой целевой группы. В идеале найти несколько живых людей и пообщаться с ними об их образе жизни. У каждого такого персонажа должно быть: имя-фамилия (использовать известных людей или знакомых – запрещено, чтобы не искажать восприятие), фотография (можно найти красивую аватарку в поиске VK), возраст, город проживания, род занятий, семейное положение, краткое описание его деятельности, привычек, задач, проблем, пользовательского опыта. Описание этого человека должно быть в разрезе его типичной целевой группы, т.е. если он, например, системный администратор, и мы проектируем ИТ портал, то в описании персонажа должна быть информация, какие ИТ порталы он сейчас посещает, что он на них делает, какие у него есть желания и т.д. Пишем без фанатизма, 1000 знаков на одного персонажа хватит с головой. Проектировщику нужно вжиться в роль каждого персонажа, поставить себя на его место. Эта информация поможет нам лучше понять свою целевую аудиторию и в следующем этапе сгенерировать много полезных идей.

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

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

На выходе у нас получается два документа: общий портрет ЦА и описание персонажей для каждой целевой группы. Эти документы должен утвердить заказчик.

Пример:

Проект: социальная сеть владельцев домашних животных.

Рис. 1. Персонаж

4. Исследование конкурентов.

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

Для поиска есть разные методы: опрос участников рынка (мини-исследование), разнообразные рейтинги, статьи по рынку, просто гугление. Очень важно искать проекты не только в рунете, но и в англоязычной части интернета, скорее всего в западной части уже есть аналогичные или близкие проекты, у которых можно позаимствовать интересные идеи.

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

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

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

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

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

На выходе мы получаем файл с полным анализом конкурентов, обычно вполне хватает 5 популярных тематических проектов в рунете и 5 западных. По каждому конкуренту должен быть SWOT-анализ с 4мя разделами. И, конечно, должен появиться первый список идей для проектируемого проекта. Документ с анализом конкурентов должен утвердить заказчик.

Пример:

Проект: социальная сеть владельцев домашних животных.

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

http://www.dogster.com/ — международный, популярный, высокое качество.

http://www.dogster.ru/ — российский, средняя популярность, среднее качество.

http://www.catster.com/ — международный, популярный, высокое качество.

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

5. Задачи-проблемы-решения (для пользователей).

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

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

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

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

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

Пример:

Проект: социальная сеть владельцев домашних животных.

Рис. 2. Задачи-проблемы-решения

6. Сценарии поведения.

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

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

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

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

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

Пример:

Проект: социальная сеть владельцев домашних животных.

Цель: выбрать пса

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

При написании этого сценария были придуманы идеи: рубрикатор в Зоопедии, блок «Читайте также», ссылки на продавцов со страницы определенной породы.

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

В комментариях можно задавать вопросы.

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

P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK, Twitter

P.P.P.S. Совсем скоро в нашей бизнес-школе Digitov стартует курс: Проектирование серьезных сайтов. Подписывайтесь на курс сейчас и сможете купить его со скидкой.

Оригинал статьи тут: http://seclgroup.ru/article-serjoznoe-proektirovanie-serjoznix-saitov.html

Автор:
Никита Семенов (Facebook, VK, LinkedIn)
CEO
Компания «SECL GROUP» / «Internet Sales Technologies»

Как спроектировать кухню самому на компьютере: инструкция, пример

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

Как спроектировать кухню самому на компьютере?

Подготовка к проектированию

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

Форма замера кухни

Шаг 1: обмер помещения

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

Таблица 1. Как правильно измерить комнату

Иллюстрация	Описание
Шаг 1	Стена, вдоль которой будет располагаться кухонный гарнитур, измеряется в трех точках: внизу, в районе кухонного фартука, и в верхней точке навесных шкафов.
Шаг 2	Таким же образом – в трех точках, измеряют прилегающую стену, отступив 600 мм от основной стены. Это расстояние соответствует стандартной глубине напольных шкафов
Шаг 3	Важно учесть расстояние до конца трубы от стены, вдоль которой будет располагаться кухня.
Шаг 4	При наличии газовой трубы, расположенной вдоль основной стены, измеряют расстояние от угла до края трубы и от стены. Также необходимо определить диаметр трубопровода.
Шаг 5	Необходимо определить расположение розеток и включателей, если они пересекаются с мебелью, то придется выполнить их перенос.
Шаг 6	Расстояние от подоконника до основной стены должно составлять не менее 60 см.

Видео — Как правильно произвести обмер кухни

Шаг 2: выбор планировочного решения

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

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

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

1. В первую очередь необходимо определить место для расположения мойки. Расстояние от нее до стояка не должно превышать 250 см. При увеличении этого значения в условиях типовой квартиры может потребоваться установка насоса. При планировании кухни в частном доме оптимальное место для мойки – у окна. Это позволит сэкономить электроэнергию и повысит комфортность помещения.
2. Около мойки располагают стиральную и посудомоечную машину. С точки зрения соблюдения требований эргономики, если владелец кухни правша, то ПММ устанавливают слева от мойки.
3. Плиту устанавливают так, чтобы расстояние между ней и мойкой составляло от 40 до 180 см. Учитывают также расположение вентиляционного отверстия и газовой трубы.
4. Оптимальный размер рабочей поверхности между мойкой и плитой составляет 90 см – этого хватит для обработки и подготовки продуктов к приготовлению. Рабочая поверхность не менее 40 см должна быть и с другой стороны плиты, чтобы была возможность поставить, например, горячую кастрюлю – это требования техники безопасности.

Рабочий треугольник на кухне

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

Таблица 2. Требования эргономики при размещении мебели и оборудования на кухне 

Иллюстрация	Описание
Правило 1	Основной источник освещения – светильник в центре помещения не обеспечит достаточной освещенности рабочей поверхности столешницы. В результате этого работа на кухне станет неудобной.
Правило 2	Дополнительным источником света может служить флуоресцентная лампа, закрепленная под навесными ящиками.
Правило 3	Если дизайн гарнитура не предусматривает наличие навесных шкафов, то в качестве дополнительного освещения можно использовать светильники, размещенные на стене, на высоте над столешницей в 80 см. При этом световой поток должен быть направлен вниз.
Правило 4	Над обеденной зоной рекомендуется повесить локальный источник света на высоте от 48 до 68 см от столешницы.
Правило 5	Высота кухонного фартука (между верхней точкой столешницы и нижней точки навесного шкафа) должна быть не меньше 50 см.
Правило 6	Вытяжку располагают над плитой на высоте не менее 90 см.
Правило 7	Чтобы обеспечить комфортное стояние около напольной тумбы, ее нижние опоры или ножки должны иметь высоту не меньше 7 см.
Правило 8	Барная стойка имеет высоту столешницы от 110 до 115 см, тем самым превышая высоту стандартного стола на 25 см.
Правило 9	При параллельном расположении мебели проход должен составлять не менее 120 см.
Правило 10	Комфортное свободное пространство перед ПММ составляет 120 см.
Правило 11	Свободное пространство перед тумбой с выдвижным ящиком должно составлять не менее 75 см.

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

Шаг 3: выбор конфигурации кухонного гарнитура

Вариант конфигурации кухонного гарнитура выбирают в зависимости от площади и формы помещения.

Таблица 3. Наиболее популярные решения

Способ расположения	Описание
Линейный	Наиболее простой способ: компактный и универсальный, но вместе с тем неудобный из-за несоблюдения правила рабочего треугольника. Идеально подходит для вытянутых помещений небольшой площади. Мойку рекомендуется располагать между холодильником и плитой.
Г-образный	Наиболее удобный и вместительный вариант, позволяющий задействовать свободную смежную стену и максимально сохранить свободное пространство. Подходит для помещений прямоугольной формы небольшой или средней площади.
Параллельный	Отличный вариант для вытянутых помещений. Позволяет реализовать правило рабочего треугольника. Важное условие – наличие свободного пространства между параллельными модулями не менее 120 -150 см. Чтобы помещение не было тесно, над одной из линии не используют навесные шкафы.
П — образный	Удобный, вместительный, но довольно массивный вариант, требующий большое количество свободного пространства. Подходит для больших кухонь квадратной формы. Такую конфигурацию можно выбрать и для маленькой кухни при необходимости разместить все необходимое.
Островной	Позволяет сделать пространство кухни более функциональным. Остров делит кухню на рабочую и обеденную зону. Недостатком является необходимость большого количества свободного места.
Полуостровной	Позволяет эффективно отделить зону кухни от гостиной или столовой. Отличается компактностью и функциональностью. Подходит для квартир-студий и гостиных, объединенных с кухней.

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

Шаг 4: выполнение чертежа на компьютере

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

Интерфейс программы-конструктора

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

Результат работы в Pro100

Существуют разные программы-планировщики. О работе с некоторыми из них рассказано ниже.

Создание кухни в программе «Prodboard»

Таблица 4. Инструкция по созданию проекта кухни в программе «Prodboard»

Иллюстрация	Описание
Работа возможна как в компактном, так и в полноэкранном режиме.	Для приближения и удаления объекта используется мышка. Для удаления объекта используют щелчок правой кнопки и клавишу delete на клавиатуре.
Закрыть объект можно, если щелкнуть мышкой на свободной зоне рабочего окна	При нажатии правой кнопкой мыши на объект появляется окно с указанием его основных параметров.
Шаг 1 Шаг 1	Для создания помещения во вкладке «Помещение» выбирают вторую сверху пиктограмму.
Шаг 2	В выпавшем окне задают габариты комнаты.
Шаг 3	Раздел «Стены и колонны» позволяет установить дополнительные конструктивные элементы.
Шаг 4	Третья снизу кнопка открывает вкладку для установки окна и двери.
Шаг 5	Раздел «Коммуникации» позволяет установить на проекции вентиляционное отверстие, газовую трубу, водопровод, включатели и розетки.
Шаг 6	Выбирают отделочные материалы для основных поверхностей.
Шаг 7	Выбирают уровень естественной освещенности и угол падения света из окна.
Шаг 8	Для добавления техники и мебели используют вкладку «Каталог».
Шаг 9	Помимо нижних и верхних модулей можно установить встроенную технику.
Шаг 10	Вкладка «Материалы» используется для подбора дизайна фасада.
Шаг 11	Для оформления фартука и установки столешницы используют соответствующую вкладку.
Шаг 12	Функциональность проекта можно оценить при помощи кнопки визуализации справа.
Шаг 13	Оценить параметры выбранной мебели можно во вкладке «Элементы»
Шаг 14	Проект сохраняют.

Работа с кухонным конструктором «BPlanner»

С помощью этой программы можно самостоятельно спроектировать кухонный гарнитур.

Таблица 5. Инструкция по созданию проекта кухни в программе «BPlanner»

Иллюстрация	Описание
Шаг 1	Во вкладке «Помещение» задают основные габариты комнаты.
Шаг 2	Там же устанавливают параметры для оконного и дверного проема.
Шаг 3	Во вкладке «Помещение» также выбирают материал отделки стен и пола.
Шаг 4	Во вкладке «Параметры кухни» подбирают модули.
Шаг 5	С помощью значка «Техника» выбирают варочную панель или мойку.
Шаг 5	С помощью значка «Материалы» задают параметры фасадов.
Шаг 6	При установке верхнего ряда кухни предварительно во вкладке «Параметры кухни» устанавливают высоту фартука. При установке навесного шкафа верхний край фартука совпадет с нижней точкой шкафчика.
Шаг 7	С помощью вкладки «Техника» устанавливают вытяжку, плиту, стиральную машину и холодильник.
Шаг 8	Во вкладке «Модули» выбирают барные стойки и полки.
Шаг 9	Во вкладке «Материалы» выбирают материал фасада: МДФ, ДСП, пластик, массив.
Шаг 10	Там же выбирают способ оформления цоколя, столешницы и фартука.
Шаг 11	С помощью соответствующих вкладок подбирают освещение и фурнитуру.
Шаг 12	Проект сохраняют.

Вкладка «Кухни» предлагает воспользоваться в качестве шаблона готовым решением

Инструмент «Stolline»

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

Таблица 6. Инструкция по созданию проекта кухни в программе «Stolline»

Иллюстрация	Описание
Шаг 1	Проект начинают с создания нового чертежа.
Шаг 2	В программе есть функция создания шаблонного чертежа помещения при введении ключевых параметров.
Шаг 3	Все элементы, которые касаются кухни, располагаются справа во вкладке «Кухонные системы».
Шаг 4	Во вкладке «Кухонные системы» расположены категории с мебелью, декором и оформлением.
Шаг 5	При выборе модуля его перетаскивают, зажав левой кнопкой мыши, в рабочее окно.
Шаг 6	Для навигации используют инструменты управления в нижнем левом углу.
Шаг 7	Элементы для оформления интерьера располагаются во вкладке «Спец.Объекты».
Шаг 8	Для сохранения текущего изображения на рабочем экране используют пиктограмму «фотоаппарат».
Шаг 9	Проект сохраняют.

Видео — Проектировании кухни на компьютере

Как спроектировать и написать полноценную программу / Habr

«Инструкция создания функционального приложения», часть 1.

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

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

Сначала, несколько комментариев и предостережений:

• Я буду описывать только один сценарий, а не всё приложение. Надеюсь, будет очевидно как расширить код при необходимости.
  
• Это намеренно очень простая инструкция без особых ухищрений и продвинутой техники, ориентированная на поточную обработку данных. Но если вы начинающий, я думаю, вам будет полезно иметь последовательность простых шагов, которые вы сможете повторить и получить ожидаемый результат. Я не утверждаю, что это единственный верный способ. Различные сценарии будут требовать различных подходов, и конечно с ростом собственной экспертизы вы можете обнаружить, что эта инструкция слишком простая и ограниченная.
  
• Чтобы облегчить переход с объектно-ориентированного проектирования, я постараюсь использовать знакомые концепции такие как «шаблоны», «сервисы», «внедрение зависимости» и т.д., а также объяснять как они соотносятся с функциональным подходом.
  
• Инструкция также намеренно сделана в некоторой степени императивной, т.е. используется явный пошаговый процесс. Я надеюсь, этот подход облегчит переход от ООП к ФП.
  
• Для простоты (и возможности использовать F# script) я установлю заглушку на всю инфраструктуру и уклонюсь от взаимодействия с UI напрямую.
  

Обзор

Обзор того, что я планирую описать в этой серии статей:

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

Приступим

Давайте возьмем очень простой пример, а именно обновление некоторой информации о клиенте через веб-сервис.

И так, наши основные требования:

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

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

Вот диаграмма составных частей процесса:

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

Давайте изменим диаграмму и отметим всё, что может пойти не так.

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

Функциональное мышление

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

Сначала обратимся к различиям между исходным сценарием и функциональным мышлением.

В сценарии мы обычно подразумеваем модель запрос-ответ. Отправляется запрос, обратно приходит ответ. Если что-то пошло не так, то поток действий завершается и ответ приходит «досрочно» (прим. переводчика: Речь исключительно о процессе, не о затраченном времени.).

Что я имею ввиду, можно увидеть на диаграмме упрощенной версии сценария.

Но в функциональной модели,  функция — это черный ящик с входом и выходом,  как здесь:

Как мы можем приспособить наш сценарий к такой модели?  

Однонаправленный поток

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

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

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

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

Управление ошибками

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

Что мы можем с этим сделать?

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

Вот пример возможного определения типа для вывода результата:

type UseCaseResult = 
    | Success
    | ValidationError 
    | UpdateError 
    | SmtpError

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

Упрощение управления ошибками

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

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

type UseCaseResult = 
    | Success 
    | Failure

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

Ещё один момент — в результате, который возвращает функция, совсем нет данных,  только статус успех/неудача. Нам потребуется кое-что поправить, чтобы результат функции содержал фактический успешный или сбойный объект. Мы объявим успешный и сбойный типы как универсальные (с помощью параметров типов).

Наконец, наша итоговая, универсальная версия:

type Result<'TSuccess,'TFailure> = 
    | Success of 'TSuccess
    | Failure of 'TFailure

На самом деле, в библиотеке F# уже есть подобный тип. Он называется Choice. Для ясности я всё же продолжу использовать в этой и последующих статьях созданный ранее тип Result. Мы вернемся к этому вопросу, когда подойдём к более серьезным задачам.

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

Как это сделать — тема следующей статьи.  

Итог и методические указания

Итак, у нас есть следующие положения к инструкции:

Методические указания

• Каждый сценарий равносилен элементарной функции.
  
• Возвращаемый тип сценарной функции — объединение с двумя вариантами: Success и Failure.
  
• Сценарная функция строится из ряда небольших функций, которые представляют отдельные шаги в потоке данных.
  
• Ошибки всех этапов объединяются в единый путь ошибок.
  

Как научиться проектировать ПО? — Хабр Q&A

Проектирование приложений можно условно разбить на 2 уровня:
1. Уровень проекта.
Сюда входит понимание того, как приложение должно выглядеть в целом и из каких компонентов состоять, а также по каким принципам оно собирается взаимодействовать с внешним миром (если есть такая необходимость). Компоненты зависят от выбранной архитектуры — в случае монолитного приложения вам требуется понимать, как разбивать его на слои и в чем ответственность каждого слоя; в случае микросервисов вы также должны понимать, как очерчивать зоны ответственности и определять протоколы взаимодействия между ними.
В вашем случае я думаю вряд ли микросервисы будут актуальны (они для больших проектов), поэтому у вас скорее всего будут небольшие монолитные приложения.
Книги о том, как проектировать приложения на общем уровне:
1. Роберт Мартин. Чистая архитектура — очень короткая и простая книга, рекомендую начать с неё.
2. Эрик Эванс. Предметно-ориентированное проектирование (принципы + стратегические шаблоны).
3. Мартин Фаулер. Архитектура корпоративных приложений (часть 1).

Уровень 2. Уровень модулей (классов).
Когда вы спроектировали компоненты, из которых состоит ваше приложение, теперь надо спроектировать их внутренности — то есть разбить на более мелкие и конкретные модули. Тут вам пригодятся принципы объектно-ориентированное проектирования, принципы SOLID, паттерны.
Книги по уровню 2.
1. Банда четырех. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Тут важно не только сами паттерны, но принципы, по которым они строятся. Концентрируйтесь на принципах.
2. Роберт Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. Тут более подробно рассматривается объектно-ориентированный дизайн и принципы SOLID в сравнении с его «Чистой архитектурой».
3. Эрик Эванс. Предметно-ориентированное проектирование (тактические шаблоны).
4. Мартин Фаулер. Архитектура корпоративных приложений (часть 2).
5. Стивен Макконел. Совершенный код (сконцентрируйтесь на понимании Главного Технического Императива!).

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

Как спроектировать базу данных? — Хабр Q&A

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

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

Может быть, оптимальным было бы решение, когда бы Вы хорошо продумали какие параметры товаров Вам понадобятся для поиска и сделали бы их отдельными индексируемыми столбцами общей таблицы товаров. Для некоторых видов товаров эти поля были бы пустыми. А другие параметры, которые просто описывают товар, но не предназначены для поиска, Вы могли бы объединить и хранить в таком виде в одном столбце. И распаковывать по надобности, когда их нужно выдать пользователю. Туда бы Вы могли класть всякую всячину, абсолютно не заботясь о том, что для какого-то товара эта всячина может измениться. Главное, в виде пар значений хранить, чтобы знать что есть что — захотелось Вам в описание товара добавить, что крокодильчики у него серобурмалиновые, а не фиолетовые, как у всех — так и пишете — Крокодильчики => серобурмалиновые.

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

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