Pull to refresh

Comments 22

У вас есть конкретный пример проблемы, ее прототип и решение?
спасибо за вопрос, я как раз собираюсь своими статьями расширить видение прототипов, рассказать, что это не только «решение вот такой конкретной проблемы», но что прототипирование содержит в себе и тонкие вещи, влияющие на весь процесс. Понимаю, что раздражаю философствованиями и абстракциями. Могу ответить так: пример проблемы — устоявшееся узкое представление о прототипах, я опишу несколько схем получения дополнительных побочных продуктов (помимо визуализации и использования прототипов в юзабилити-тестировании) от использования прототипов; решение — например эта статья может подсказать вам решение, ходы в ситуации, когда свойства мышления дизайнера обнаружатся у кого-нибудь из вашей проектной командыи вы будете знать, чем этого человека лучше нагружать. Конкретика будет позже, т.к. она обычно задавливает собой тему, кот. я собираюсь раскрыть.
Довольно интересная статья, но недостаточно живая в силу отсутствия примеров. Теория хороша, но интересна бывает только с примерам из практики или, если в процессе читатель сопоставляет её со своей личной практикой.
спасибо, учту, я ставил целью привлечь ваше внимание исключительно к почве, на кот. прототипы вырастают, чтобы можно было её рассмотреть за прототипами, обычно, когда приводишь конкретный пример — всё внимание достаётся только ему
Лично для меня в статье не хватает практических примеров.
в следующей приведу пример организации коммуникации на проекте спомощью прототипов, эта статья задумывалась как рассказ о мышлении, а не о его продуктах
Ок, пусть будет так. Ждем-с.
Полезная статья. Хотя и многословна да заумна. Но хоть что-то.
Давно уже пора отказаться от разработки «снизу — вверх» (от кода или *sic* базы к пользовательскому интерфейсу) в пользу разработки «сверху — вниз» (от интерфейса к исполняемому коду).
Но пока будут финансироваться пустые обещания и стартовые фазы проектов типа: «1. создания структуры базы данных, 2. настройка движка и классов, 3. оптимизация под многомильенную посещаемость ...» вряд ли что изменится.
спасибо, я очень боялся перенести язык первоситочников (загляните как-нить в них) в пост, недофильтровал язык
Еще неплохо было бы сделать обзор используемого инструментария.
А можно ещё добавить сюда программистов и тестеров, а не только дизайнеров? Ну чтоб полная команда получилась.
Да, и как обеспечить их взаимодействие при создании прототипа.
в следующей статье я как раз собираюсь рассказать, как организовать общение на почве прототипов
описанное «мышление дизайнера» может быть свойственным кому угодно, а «мышление аналитика» вполне может оказаться у дизайнера
+1 за этот комментарий.
Нет, скорее — наоборот. ) Многое добавило к пониманию написанного.
Ценность этой статьи для *этих пользовательских интерфейсов* в первую очередь я вижу в том, что предпринята попытка посмотреть на дизайнеров не просто как на рисовальщиков графики и участников обсуждений, а как на людей со своеобразной организацией мышления при решении трудовых задач.
Хотелось бы, конечно, увидеть какие-то более практические выводы.
И да. Я бы назвал подобного рода прототипы набросками (как-то более по-дизайнерски=)). Всё-таки под прототипами в контексте этого блога понимается несколько иное.
практический вывод — обратить внимание и на то, что люди с таким мышлением могут оказаться не только среди дизайнеров и что было бы неплохо дать им возможность выражать себя в прототипах (каких угодно)
Мне контекст слова «дизайн» не очень понятен. Всё равно мозг «сползает» на рисование и прочие подобные вещи.

А в целом статья очень ценная. Качественной актуальной русскоязычной информации о процессе requirements analysis и смежных областях очень мало. Практических примеров ещё меньше.
спасибо, дизайн здесь как проектирование, интерпретация замысла
Sign up to leave a comment.

Articles