Комментарии 11
Спасибо за статью!
Мы сразу привлекаем аналитика, дизайнера и техписателя, а потом делаем продажу фичи на 1-3 команды (B2B, не внутренняя разработка). Частенько дообсуждаем нюансы всей командой)))
По возможности показываем прототипы клиентам.
Согласна, в совместном обсуждении часто рождаются интересные идеи. Но хочется при этом не превратить согласование макетов в собрание всех и вся, как на обложке статьи :) Мне кажется, мы все еще ищем баланс, когда согласующих достаточно, чтобы не упустить критичные детали, но при этом на согласование не тратится чрезмерное количество ресурсов
Хотелось бы видеть схемы в виде диаграммы последовательности с нумерацией действий.
В текущем варианте придётся длинный текст читать, который хочется порезать.
Ваш процесс хочется проанализировать, но на статью нужно попасть в момент "ничегонеделания".
Спасибо за комментарий! Надеюсь, еще найдется такой момент для прочтения)
Диаграммы последовательности очень структурируют понимание процесса, согласна. Но статью хотелось преподнести как легкий для чтения материал, поэтому схемы тоже адаптированы под такой стиль подачи. На финальной схеме краткая выжимка, к чему мы пришли на данный момент, если хочется без лишних слов увидеть визуализацию
Касательно "вашего чеклиста". Список хороший, но есть 2 "НО":
Дублируется пункт про 404.
Не отражен, с моей точки зрения, критически важный момент (особенно с точки зрения аналитика) - удобство пользователя в рабочем процессе. Причем как это отобразить в таком списке и как его объективно оценивать - не совсем понятно. А суть вот в чем: когда я, как пользователь какого-то сервисе берусь им пользоваться, то обнаруживаю, что важные мне сейчас вещи находятся не в тех местах, уползают за границы первой страницы, требуют лишних кликов, вообще отсутствуюь, присутсвуют элементы, сейчас не нужные или раздражающие, иконки или шрифтовые выделения вводят в заблуждение, сильно долго ждать открытия динамических списков (это уже не очень к UI, но часто связано).
Причем в чем основная печаль: когда дизайнер, аналитик, разработчик это се делает - кажется, что все красиво, правильно и удобно. Но они, эти дизайнеры, аналитики, разработчики находятся в процессе решения другой задачи. У них в этот момент другие акценты внимания, подсознательно другие критерии оценки.
А как только они же но попытаются пройтись по логике именно применения пользователем, да еще не просто так, а когда от применения зависит или твое время или твоя зарпплата - тогда понимается, что "не на своем месте".
Для этого, для наработки опыта, стоит включать каки-то образом и в процесс тестирования результата, с возможностью правок на следующей итерации. Тогда наработается опыт делать user-friendly интерфейс за минимальные итерации.
Благодарю за внимательность! Убрала дублирующиеся пункты в чек-листе
Вы безусловно правы, что удобство использования очень субъективный критерий, формализовать его до какого-то чек-листа невероятно сложно. Мы в команде пока не подступались к такой задаче. Если у вас есть наработки в этом направлении, буду очень рада, если поделитесь. И читатели Хабра, думаю, тоже :)
Я хотела бы понять, каковы отличия функций системного аналитика от фронтендера в таком сценарии
Хороший, вопрос, спасибо. В статье действительно мало раскрывается роль фронтенд-разработчика.
Системный аналитик смотрит на макеты в первую очередь в контексте пользовательских сценариев. Консистентны ли основной и альтернативные сценарии, все ли неуспешные сценарии учтены. И, безусловно, смотрит, как это ложится на архитектуру решения.
Фронтенд-разработчик смотрит на макеты в контексте верстки (статика) и реакции UI на действия пользователя (динамика). Насколько выполнимы предъявляемые макетом требования в рамках конкретного инструментария фронта.
Представим, что мы смотрим макет по добавлению вакансий в избранное.
Пример комментария от системного аналитика: если вакансию поместили в архив, а она была добавлена у пользователя в избранное, нужно визуализировать такую вакансию в избранном каким-то особым образом (метка В архиве или что-то подобное). Т.е. аналитик нашел неучтенный сценарий.
Пример комментария от фронтендера: на текущем фреймворке будет сложно реализовать динамическую подгрузку элементов при скролле пользователя по списку вакансий, давайте лучше отрисуем пагинацию. Т.е. фронтенд-разработчик подсвечивает технические сложности конкретной выбранной реализации.
Сейчас в компании наблюдаю похожий процесс. Только тут нет выделенных аналитиков, вместо них в данном процессе выступает тимлид или делегированный на фичу разработчик. У них достаточно экспертизы, чтобы сказать "это вот надо делать не так, а иначе". В итоге процесс выглядит так:
Дизайнер с владедьцем продукта рисуют прототипы. Просто на основе блоков, без точных pixel perfect мокапов. Перебирают вариации на чём-то соглашаются.
Потом к этому процессу подключают тимлида. Он смотрит, вместе обсуждают, что можно сделать, что дорого и стоит заменить на другое решение. Договариваются, дизайнер уходит на рисование мокапов.
В конце собираются ещё раз опять, уже с точными мокапами, вносят минорные правки, если ещё есть и мокапы уходят в работу.
Отлично изложено. Спасибо.
Алина, спасибо за интересную статью! хоть у нашей команды совсем другая специфика продукта, но и мы поймали несколько из описанных грабель по пути к идеальной схеме взаимодействия
Как мы выстроили процесс работы с макетами