Comments 22
У вас есть конкретный пример проблемы, ее прототип и решение?
+1
спасибо за вопрос, я как раз собираюсь своими статьями расширить видение прототипов, рассказать, что это не только «решение вот такой конкретной проблемы», но что прототипирование содержит в себе и тонкие вещи, влияющие на весь процесс. Понимаю, что раздражаю философствованиями и абстракциями. Могу ответить так: пример проблемы — устоявшееся узкое представление о прототипах, я опишу несколько схем получения дополнительных побочных продуктов (помимо визуализации и использования прототипов в юзабилити-тестировании) от использования прототипов; решение — например эта статья может подсказать вам решение, ходы в ситуации, когда свойства мышления дизайнера обнаружатся у кого-нибудь из вашей проектной командыи вы будете знать, чем этого человека лучше нагружать. Конкретика будет позже, т.к. она обычно задавливает собой тему, кот. я собираюсь раскрыть.
+1
Довольно интересная статья, но недостаточно живая в силу отсутствия примеров. Теория хороша, но интересна бывает только с примерам из практики или, если в процессе читатель сопоставляет её со своей личной практикой.
0
Лично для меня в статье не хватает практических примеров.
+1
Полезная статья. Хотя и многословна да заумна. Но хоть что-то.
Давно уже пора отказаться от разработки «снизу — вверх» (от кода или *sic* базы к пользовательскому интерфейсу) в пользу разработки «сверху — вниз» (от интерфейса к исполняемому коду).
Но пока будут финансироваться пустые обещания и стартовые фазы проектов типа: «1. создания структуры базы данных, 2. настройка движка и классов, 3. оптимизация под многомильенную посещаемость ...» вряд ли что изменится.
Давно уже пора отказаться от разработки «снизу — вверх» (от кода или *sic* базы к пользовательскому интерфейсу) в пользу разработки «сверху — вниз» (от интерфейса к исполняемому коду).
Но пока будут финансироваться пустые обещания и стартовые фазы проектов типа: «1. создания структуры базы данных, 2. настройка движка и классов, 3. оптимизация под многомильенную посещаемость ...» вряд ли что изменится.
0
Еще неплохо было бы сделать обзор используемого инструментария.
+2
www.amazedev.com/prototipirovanie-web-proektov-sobiraya-voedino/
fresh.gui.ru/2009/03/30/16_design_tools_for_prototyping_and_wireframing/
и ещё одну статью я обещаю, это будет обзор + информация о HolyGrail
fresh.gui.ru/2009/03/30/16_design_tools_for_prototyping_and_wireframing/
и ещё одну статью я обещаю, это будет обзор + информация о HolyGrail
+1
А можно ещё добавить сюда программистов и тестеров, а не только дизайнеров? Ну чтоб полная команда получилась.
0
Ценность этой статьи для *этих пользовательских интерфейсов* в первую очередь я вижу в том, что предпринята попытка посмотреть на дизайнеров не просто как на рисовальщиков графики и участников обсуждений, а как на людей со своеобразной организацией мышления при решении трудовых задач.
Хотелось бы, конечно, увидеть какие-то более практические выводы.
И да. Я бы назвал подобного рода прототипы набросками (как-то более по-дизайнерски=)). Всё-таки под прототипами в контексте этого блога понимается несколько иное.
Хотелось бы, конечно, увидеть какие-то более практические выводы.
И да. Я бы назвал подобного рода прототипы набросками (как-то более по-дизайнерски=)). Всё-таки под прототипами в контексте этого блога понимается несколько иное.
0
Мне контекст слова «дизайн» не очень понятен. Всё равно мозг «сползает» на рисование и прочие подобные вещи.
А в целом статья очень ценная. Качественной актуальной русскоязычной информации о процессе requirements analysis и смежных областях очень мало. Практических примеров ещё меньше.
А в целом статья очень ценная. Качественной актуальной русскоязычной информации о процессе requirements analysis и смежных областях очень мало. Практических примеров ещё меньше.
0
Sign up to leave a comment.
Прототипирование для ИТ: мышление дизайнера, метафоры среди алгоритмов