София Войчеховски написала об объектно-ориентированном дизайне.

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

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

#ooux

Глеб Кушедов показал пример объектно-ориентированного дизайна в приложении для тренировок.

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

#ooux

Глеб Кушедов продолжает рассказывать об объектно-ориентированном дизайне. На этот раз — продумывает и визуализирует список заданий в условной учебной системе.

#ooux

Эдуард Христусь написал об объектно-ориентированном дизайне.

ООД помогает:
1. Понять, с чего начать. Если проектируете приложение для заказа котиков с доставкой, в нём наверняка будут сущности: «пользователь», «заказ» и «котик». С ними будут связаны определённые параметры и способы взаимодействия;
2. Сэкономить. Прототипирование — дорогой и сложный подпроцесс проектирования. Генерировать и отметать идеи в прототипе не эффективно;
3. Создать MVP;
4. Всей команде равномерно двигаться при декомпозиции проекта. Сначала объекты, потом способы взаимодействия с ними.

Процесс:
1. Выявите все объекты системы. Помогут пользовательские истории;
2. Определите параметры объектов и их связи. Помогут: брейншторм внутри команды и с заказчиком, профили пользователей (их сценарии и цели). Надо понять, чего от объекта хотел бы пользователь: какую информацию узнать, какие действия совершить;
3. Определите способы взаимодействия с объектами (функции);
4. Укажите свойства параметров. Например: автоматический параметр (проставляется системой автоматически), фильтруемый (используется для фильтрации списка объектов), ручной (задаётся вручную пользователем или администратором) и так далее;
5. Укажите свойства функций. Например: доступные без ограничений, доступные с ограничениями;
6. Покажите наборы параметров и функций для разных состояний объекта. Например: закрытую вакансию можно только посмотреть.

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

#ooux

Дарья Хуторянская написала, что проверить при передаче макетов разработчикам.

— На момент передачи макетов уже проделана огромная работа, и тем обиднее из-за перегруза задачами, ограниченных сроков или неопытности что-то упустить и затем потонуть в уточняющих вопросах разработчиков;
— Проверьте, все ли сценарии взаимодействия с объектами предусмотрели. Помните о CRUD (create, read, update, delete) — операциях, свойственных всем объектам. Составьте карту объектов, их свойств и действий с ними (концепция #ooux);
— Представьте поведение интерфейса, когда данных нет, мало, много (пагинация или скрол, обрезание длинной фамилии или перенос на вторую строку) или достигнут их лимит (технические ограничения, возможность добавить не более 10 фото в профиль);
— Учтите разные варианты завершения пользовательского сценария: успех, ошибка (пользовательская и на стороне системы), загрузка, пустые состояния, онбординг;
— Сверьтесь с ролевой моделью. Например, как будет выглядеть объект, если пользователь может и не может его редактировать;
— Опишите сложные компоненты-организмы: зона клика, поведение при изменении ширины и высоты, разном объёме данных. Спецификация может быть там же, где вы собираете макеты;
— Покажите адаптивные состояния для разных разрешений экрана;
— Соедините макеты стрелочками, объедините отдельные сценарии в блоки макетов, опишите сценарии текстом;
— Если какие-то макеты не ушли в релиз, добавьте комментарии для тестировщиков;
— Добавьте ссылки на описания сложных компонентов.

#delivery