ДИЗАЙН-ДОКУМЕНТАЦИЯ Ч.2

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

Разобрать задачу экрана

Вопросы:

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

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

Разделить сценарии и ответственность экранов
вопросы:
  • какое основное (дополнительное) целевое действие экрана?
  • какие действия второстепенные?
каждый экран должен иметь понятную основную задачу. Если он пытается делать все и сразу, сначала разбираемся с этим

Найти системные паттерны

вопрос:

  • как эта функция обычно решается на платформе?

Если не знаете, какой элемент подойдет скидываем скриншот и мини-описание функции и спрашиваем ИИ (потом перепроверить по гайдам платформ)


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

Собрать функциональный макет на системных компонентах
вопрос:
  • можно ли эту задачу выполнить ТОЛЬКО системными компонентами? (в 90% случаев можно)
Экран будет скучным и дефолтным - это нормально для этого этапа

Проверить поведение и устойчивость верстки экрана с разными данными

вопросы:

  • как это должно работать?
  • как перестраивается экран при разном количестве текста и контента на экране?
  • работает ли верстка? или организация информации не учитывает некоторые кейсы
  • что происходит: при тапе; при вводе; при увеличении/ уменьшении; если значение пустое; если стоит 0; есть ли Save вообще или autosave; что происходит при Back и т.д. в зависимости от контента и контролов на вашем экране

Если нашли несостыковки в решении - переверстываем и находим другое решение (шаги 3-4) 

Найти визуальное направление и стилизовать системные элементы, собрав компоненты
вопросы:
  • функционально интерфейс работает…а каким продуктом он должен быть визуально?
  • есть понятная модель поведения системного input. Как этот компонент выглядит внутри моего продукта?
Визуальный язык:
  • dark/ light
  • характер палитры
  • контраст
  • акцентный цвет
  • поверхности
  • типографическая иерархия
  • radius
  • плотность
  • характер элементов управления
Состояния: default - focused - filled - error - disabled
И уже на этих состояниях:
  • background
  • border
  • label
  • text

Зафиксировать систему, собрав компоненты и прилинковав к ним стили (text styles, variables)

вопрос:

  • какие решения у меня повторяются?

Не надо сначала придумывать 2-3 цвета и пытаться их впихнуть везде. Система появляется из повторяющихся решений продукта


цвета - variables

semantic colors - variables

typography - text styles

spacing - variables

radius - variables

input, кнопки - component

состояния - component variants


делаем это с каждым экраном (шаги 1–8), применяем систему, заменяем черновые элементы на компоненты со стилями

Собрать сценарий
Вопрос:
Если завтра этот файл откроет разработчик, который никогда со мной не разговаривал, сможет ли он понять, что надо сделать?
Перепроверить себя
  • Актуальные фреймы
  • Логичный порядок
  • Названия
  • Стрелки
  • Действия
  • Состояния
  • Состояния
  • Исключения
  • Комментарии и заметки там, где поведение нельзя считать с картинки
  • Компоненты, стили и переменные связаны
  • Никакого случайного локального оформления

Финальный чек-лист

  • структура понятна;
  • Auto Layout работает;
  • адаптация не ломает интерфейс;
  • повторяющиеся сущности — компоненты;
  • instances не оторваны от библиотеки без причины;
  • компоненты имеют нужные states;
  • цвета связаны с variables;
  • текст связан со styles;
  • размеры и отступы систематизированы;
  • слои читаются;
  • нет мусора;
  • экран находится внутри понятного flow;
  • разработчик понимает его поведение.

КАК ТЕБЕ КОНСПЕКТ?

Расскажи, чего не хватило. От похлавы мы тоже не откажемся))

Made on
Tilda