Я написал о функциональной спецификации интерфейса.
— Это один из артефактов, который полезно создавать при проектировании интерфейсов. Она уточняет показанные в прототипе решения и отвечает на будущие вопросы разработчиков;
— В ней можно описать то, что трудозатратно или невозможно визуализировать в прототипе, и то, что на картинках человек скорее всего не заметит;
— Также она: 1) может стать частью договора, 2) помогает перепроверить и доработать свои решения;
— Во второй половине статьи я рассказал, как её писать: когда приступать, что в неё включать и как это структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа;
— Это, конечно, не подробное руководство с детальными чеклистами, но неплохой материал для старта.
#docs
— Это один из артефактов, который полезно создавать при проектировании интерфейсов. Она уточняет показанные в прототипе решения и отвечает на будущие вопросы разработчиков;
— В ней можно описать то, что трудозатратно или невозможно визуализировать в прототипе, и то, что на картинках человек скорее всего не заметит;
— Также она: 1) может стать частью договора, 2) помогает перепроверить и доработать свои решения;
— Во второй половине статьи я рассказал, как её писать: когда приступать, что в неё включать и как это структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа;
— Это, конечно, не подробное руководство с детальными чеклистами, но неплохой материал для старта.
#docs
Хабр
Функциональная спецификация интерфейса: что это, зачем нужна, как её писать
Функциональная спецификация вместе с прототипом рассказывает, из каких элементов состоит и как работает интерфейс системы. Она описывает то, что трудозатратно, невозможно или бессмысленно показывать в...
👍29
Давид Саргсян написал о требованиях к интерфейсу.
— Постулат методологии Agile: «Работающий продукт важнее исчерпывающей документации»;
— Чтобы уложиться в спринт, часто жертвуют документированием: отдают разработчиком тезисные требования, подкреплённые устными объяснениями;
— Они иногда бывают неполными, и разработчики тратят время на уточнения и предположения;
— Потом при доработке или создании смежной фичи приходится тратить время на повторное исследование логики её работы. Можно упустить какие-то нюансы, что ухудшит итоговое качество продукта;
— Из-за пробелов в логике растёт техдолг, на исправление которого со временем требуется всё больше ресурсов;
— Чтобы этого избежать, аналитик должен 1) выделить отдельные элементы интерфейса, 2) задаться рядом вопросов о логике их работы;
— Давид выписал вопросы к 12 самым популярным элементам интерфейса: текстовый элемент для чтения, таблица, поле ввода, раскрывающийся список, поиск, календарь, кнопка, чекбокс, радиокнопка и переключатель, карта, уведомление, загрузчик файлов, индикатор выполнения;
— Например, поле ввода: обязательно ли, ограничение на количество символов, нужны ли подсказка с маской, реакция системы на дубликаты, может ли пользователь редактировать сохранённые данные;
— Раскрывающийся список: можно ли выбрать несколько значений, будет ли поиск по значениям, можно ли добавлять новые значения, как на список значений влияют другие поля.
Перекликается с моей статьёй о функциональной спецификации интерфейса, там тоже фигурировали вопросы к отдельным элементам интерфейса. #docs
— Постулат методологии Agile: «Работающий продукт важнее исчерпывающей документации»;
— Чтобы уложиться в спринт, часто жертвуют документированием: отдают разработчиком тезисные требования, подкреплённые устными объяснениями;
— Они иногда бывают неполными, и разработчики тратят время на уточнения и предположения;
— Потом при доработке или создании смежной фичи приходится тратить время на повторное исследование логики её работы. Можно упустить какие-то нюансы, что ухудшит итоговое качество продукта;
— Из-за пробелов в логике растёт техдолг, на исправление которого со временем требуется всё больше ресурсов;
— Чтобы этого избежать, аналитик должен 1) выделить отдельные элементы интерфейса, 2) задаться рядом вопросов о логике их работы;
— Давид выписал вопросы к 12 самым популярным элементам интерфейса: текстовый элемент для чтения, таблица, поле ввода, раскрывающийся список, поиск, календарь, кнопка, чекбокс, радиокнопка и переключатель, карта, уведомление, загрузчик файлов, индикатор выполнения;
— Например, поле ввода: обязательно ли, ограничение на количество символов, нужны ли подсказка с маской, реакция системы на дубликаты, может ли пользователь редактировать сохранённые данные;
— Раскрывающийся список: можно ли выбрать несколько значений, будет ли поиск по значениям, можно ли добавлять новые значения, как на список значений влияют другие поля.
Перекликается с моей статьёй о функциональной спецификации интерфейса, там тоже фигурировали вопросы к отдельным элементам интерфейса. #docs
Хабр
Требования к графическим интерфейсам: одна памятка ответит на все ваши вопросы
Противоречие, с которым сталкивается каждый аналитик в Agile Большинство IT-команд работает по методологии Agile, основной постулат которой гласит: «Работающий продукт важнее исчерпывающей...
👍28❤3👎2