Comments 33
Извините, с вами можно пообщаться на тему дизайна интернет магазина?
После нескольких проектов с первоначальным детальным прототипированием (Axure) сложилось мнение, что хорошо сделанный, откомпентированный прототип заменяет большую часть технического задания на сайт. Интересно, что на этот счет думают профессионалы. :)
Заменяет.
Вцелом — да. Но за счет банальной человеческой невнимательности, они часто остаются без внимания, по-этому предпочитаю дублировать их в ТЗ.
Еще есть такой момент, что некоторые вещи проще описать в ТЗ, чем реализовывать в прототипе. В общем, на мой взгляд, нужно сочетать оба подхода таким образом, чтобы сократить общее время на разработку и, чтобы не оставалось неясных моментов.
Еще есть такой момент, что некоторые вещи проще описать в ТЗ, чем реализовывать в прототипе. В общем, на мой взгляд, нужно сочетать оба подхода таким образом, чтобы сократить общее время на разработку и, чтобы не оставалось неясных моментов.
Профессионалы считают, что прототип — единственное средство UX-специалиста. Все остальные не дают представления о юзабилити будущего продукта. И да, прототип заменяет ТЗ. Если построить архитектуру таким образом, что прототипы будут ее неотъемлемой частью, то разработка будет приносить массу удовольствия при минимуме ошибок.
Зачем себя ограничивать? Одно другому не мешает.
На ранних стадиях обсуждения фичлиста и техрешения нужна хотя бы условная визуализация, блочной схемы на этом этапе вполне достаточно. А прототип можно и нужно делать параллельно, чтобы он был готов к моменту старта разработки.
В условиях разработки сервисов для уже существующего продукта это точно лучше работает.
На ранних стадиях обсуждения фичлиста и техрешения нужна хотя бы условная визуализация, блочной схемы на этом этапе вполне достаточно. А прототип можно и нужно делать параллельно, чтобы он был готов к моменту старта разработки.
В условиях разработки сервисов для уже существующего продукта это точно лучше работает.
Блочная схема не отвечает ни на один вопрос. На картинке может быть все красиво, начинаешь пользоваться — ужас просто. Юзабилити не заканчивается на расположении, его максимум проявляется как раз в динамике.
Не согласна, блочная схема дает верхний уровень представления об устройстве интерфейса.
Вы говорите исключительно про использование, но при реальном старте разработки интерфейса гораздо больше факторов, влияющих на итоговое решение. Блочная схема нужна как минимум для того, чтобы свести верхнеуровневую картинку про бизнес-цели, дизайн и основное техрешение. Еще раз — это не замена, это просто первый уровень погружения.
Кстати, блочную схему вполне можно сделать с простой динамикой — тот же balsamiq дает такую возможность.
Вы говорите исключительно про использование, но при реальном старте разработки интерфейса гораздо больше факторов, влияющих на итоговое решение. Блочная схема нужна как минимум для того, чтобы свести верхнеуровневую картинку про бизнес-цели, дизайн и основное техрешение. Еще раз — это не замена, это просто первый уровень погружения.
Кстати, блочную схему вполне можно сделать с простой динамикой — тот же balsamiq дает такую возможность.
Вы говорите все верно. Это действительно верхний уровень представления об устройстве интерфейса. Я же говорю про то, что в реальной жизни это высокоуровневое представление не особо нужно, потому что это часть прототипа. Для меня цель не нарисовать расположение элементов, а сделать удобным их использование. Поэтому я не зацикливаюсь на схемах, а сразу рисую прототип.
Ну, вот в нашей реальной жизни in-house дизайнеров это очень удобная и важная штука :) Потому что на этапе продумывания общего концепта нужны именно наброски, которые можно крутить очень быстро, параллельно обсуждая с разработчиками и бизнесом. Удобство — это самое важное, но если думать только о нем, то можно сделать прототип, который в итоге не будет реализован по бизнесовым или технологическим причинам.
Я понимаю, что это важно для вас. И понимаю, что мы с вами говорим на совершенно разных языках.
Я недавно пытался пояснить, почему рисовать дизайн по требованиям заказчика — ущербная логика. Меня не поняли. Основной мой постулат был таковым: «Заказчик описывает требования, которые у него были пол года назад, и проблемы, которые он видит через призму своего опыта. Но это не значит, что нужно реализовывать его видение, нужно решать его реальные проблемы, а не бороться с симптомами.»
Я тоже однажды попался на крючок, пытаясь создать систему, которая повторяла требования заказчика, его процессы. Я потерпел фиаско. Сейчас я понимаю, что вместо сложных интерфейсов, что я пытался им предоставить, в большинстве случаев можно было обойтись вообще без этого. Например, отчеты можно присылать на почту, единожды настроив их. Человек вообще не будет иметь доступ в систему, потому что ему это не нужно.
Я недавно пытался пояснить, почему рисовать дизайн по требованиям заказчика — ущербная логика. Меня не поняли. Основной мой постулат был таковым: «Заказчик описывает требования, которые у него были пол года назад, и проблемы, которые он видит через призму своего опыта. Но это не значит, что нужно реализовывать его видение, нужно решать его реальные проблемы, а не бороться с симптомами.»
Я тоже однажды попался на крючок, пытаясь создать систему, которая повторяла требования заказчика, его процессы. Я потерпел фиаско. Сейчас я понимаю, что вместо сложных интерфейсов, что я пытался им предоставить, в большинстве случаев можно было обойтись вообще без этого. Например, отчеты можно присылать на почту, единожды настроив их. Человек вообще не будет иметь доступ в систему, потому что ему это не нужно.
Мы действительно говорим на разных языках. Вы не понимаете, почему для меня это важно, мотивация совершенно не та. Смысл не в том, чтобы выполнить требования заказчика (я сама себе заказчик зачастую), а в том, чтобы как можно раньше понимать, где могут быть подводные камни с точки зрения реализации и вложений.
Речь не о том, чтобы проектировать, исходя из ограничений. Речь о том, что еще до разработки финального прототипа хорошо бы осознавать, как его будут реализовывать. Иначе модель может оказаться красивой, но настолько дорогой и/или долгой, что ее не выпустят. Или выпустят, но по дороге оторвут что-нибудь (особенно если вы аутсорсер). Если вы понимаете условия реализации, то можете и работать с ними по-человечески. Например, сделать в нужный срок разумную часть того, что хотелось бы, а потом прикрутить остальное. Качество только выигрывает в таких случаях.
И потом — вы же начинаете с архитектуры в любом случае. Да, детали взаимодействия вы продумаете потом, но что мешает бэк-энду посмотреть на вашу блочную схему и начать пилить внутренности?
Речь не о том, чтобы проектировать, исходя из ограничений. Речь о том, что еще до разработки финального прототипа хорошо бы осознавать, как его будут реализовывать. Иначе модель может оказаться красивой, но настолько дорогой и/или долгой, что ее не выпустят. Или выпустят, но по дороге оторвут что-нибудь (особенно если вы аутсорсер). Если вы понимаете условия реализации, то можете и работать с ними по-человечески. Например, сделать в нужный срок разумную часть того, что хотелось бы, а потом прикрутить остальное. Качество только выигрывает в таких случаях.
И потом — вы же начинаете с архитектуры в любом случае. Да, детали взаимодействия вы продумаете потом, но что мешает бэк-энду посмотреть на вашу блочную схему и начать пилить внутренности?
Зависит от сложности процессов, которые протекают на сайте. Мы сейчас закончили прототип для одного из проектов и теперь на очереди техническое задание. Хотя прототип и показывает большую часть функционала сайта, этот функционал всё таки следует описать в ТЗ. Многие ситуации не видны на прототипе и их нужно продумывать во время составления ТЗ.
Многие не понимают «как это работает», если показывать просто картинки (блочная схема). Даже, если там реальный контент.
А если у клиенты был старый полустатичный сайт тремя колонкам, а вы предлагаете что--то новое с динамикой, то без прототипа не обойтись.
Конечно, вечен холивар насколько сильно детализировать (я за что-то среднее, а вот Нимакс — за дизайнерскую проработку), но в любом случае без прототипа никуда. У Горбунова вроде была выдержка из договора, где прописано, что прототип имеет главный приоритет, потом тз, потом еще что-то…
А если у клиенты был старый полустатичный сайт тремя колонкам, а вы предлагаете что--то новое с динамикой, то без прототипа не обойтись.
Конечно, вечен холивар насколько сильно детализировать (я за что-то среднее, а вот Нимакс — за дизайнерскую проработку), но в любом случае без прототипа никуда. У Горбунова вроде была выдержка из договора, где прописано, что прототип имеет главный приоритет, потом тз, потом еще что-то…
Так любой Axure и иже с ним позволяет делать связки «блочных схем» в прототип без кодинга, так что грань между ними довольно тонкая
Кстати, видел много тулзов для создания блочных схем, но не видел продуктов для прототипирования. Подскажите?
Для семейства MS, например Expression Blend.
Продукты для прототипов есть, но они ориентированы на программистов (и, соответственно, называются фреймворки, например twitter.github.com/bootstrap/. Из gui утил на ум приходит только www.axure.com — там есть переходы по страницам и вроде бы еще что-то.
Статья отличная, спасибо!
А вы не могли бы к каждому пункту добавить рекомендуемые инструменты для создания? Ну или не к каждому, а к 1-му и 3-му :)
А вы не могли бы к каждому пункту добавить рекомендуемые инструменты для создания? Ну или не к каждому, а к 1-му и 3-му :)
Помогите: habrahabr.ru/qa/22004/
Sign up to leave a comment.
Прототип, блочная схема, макет – что выбрать?