Обзор передачи проекта в разработку
План разработки
- Discovery/постановка задачи
- какую проблему решаем
- для кого
- цели бизнеса
- ценность для пользователя
- какие ограничения
2. Проектирование и сбор требований
- формулируем сценарии, требования, архитектуру, API, технические ограничения
3. Дизайн
- прорабатываем UX, интерфейсы, состояния, прототипы, дизайн-систему
4. Планирование разработки
- разбиваем решение на задачи, оцениваем сроки и зависимости, распределяем работу
5. Разработка
- пишут код: клиент, сервер, интеграции, базы данных
6. Тестирование
- проверяют функциональность, ошибки, совместимость, производительность
В случае проектов на майноре, тестировщиков скорее всего не будет, поэтому будет выполняться implementation review - быстрое ревью дизайнером того продукта, который получается
7. Release/ Deployment
- собирают версию, выкладывают на серверы или в магазины приложений
8. Эксплуатация и мониторинг
- следят за ошибками, нагрузкой, стабильностью и инцидентами
9. Аналитика и улучшения
- смотрим метрики и обратную связь, формируем следующие улучшения
Весь процесс можно разделить на два больших этапа:
- Discovery (первые четыре стадии) - этап, когда мы определяем, что нужно реализовать
- Delivery (4 - 9 стадии) - поставка продукта до конечного пользователя
- Plan
- Do
- Check
- Act
- Дизайнер работает в рамках процесса, а не просто отдельно в вакууме
- При подготовке документации нужно ставить себя на место разработчиков и тестировщиков (задавать себе вопросы: “как это работает?”, “как проверить, что это работает верно?”)
- В документации должны содержаться ответы на всевозможные вопросы, которые могут возникнуть у разработчика в процессе кодинга
- Если ваши разработчики не задают вам вопросов - это ред флаг (скорее всего они недооценили объем работ/ ничего не поняли из документации)
- Требования должны быть достаточно полными и непротиворечивыми
- В процессе написания требований будут белые пятна и дыры в решении, к которым нужно быть готовыми, и исправлять их по ходу работы
- Оценивайте ваши возможности здраво, лучше проработать 1 сценарий, который доставит максимум ценности пользователю, чем пытаться сделать супер-апп с фичами, которые уже качественно реализованы в других приложениях
- UX требования (User Flow, Jobs to be done и др.)
- информационная архитектура (диаграмма состояний и др.)
- хорошо обработанные макеты (состояния интерфейса, сетка, отступы и др.)
- UI-тексты (тональность коммуникации и др.)
- функциональные (что продукт должен делать?)
- нефункциональные (как продукт должен это делать?)
Два основных режима работы в фигме (в dev mode можно посмотреть любой код элемента, посмотреть на элемент глазами разработчика)
Лучше не использовать в макете группы, так разработчик получит меньше информации об элементах, поэтому для объединения элементов стоит использовать фреймы и секции
Наиболее подробными для разработчика являются автолейауты, они показывают все состояния элементов
Наиболее подробными для разработчика являются автолейауты, они показывают все состояния элементов
- посмотреть на проект взглядом новичка
- отрезаем все, что не приносит ценность: если задача решена в других сервисах - сами не делаем
- гайдлайны платформ
- выбираем повторяющиеся элементы, собираем компоненты (или берем из официальных библиотек)
- делаем базовые правила для типографики и отступов (можно по шаблону)
КАК ТЕБЕ КОНСПЕКТ?
Расскажи, чего не хватило. От похлавы мы тоже не откажемся))
