Comments 10
Основной тезис книги — нужно создавать интерфейс для того, кто будет им пользоваться. Метод персон — хороший старт. Но разрабатывать интерфейс нужно в плотной связи с теми, кто будет им пользоваться. Если у вас в голове есть возможность моделировать поведение этих персон достаточно точно — то это хорошо. Но если вы этим и ограничитесь — то уже рискуете.
Выстраивание обратной связи, и чем теснее — тем лучше, со своей аудиторией, с пользователями, с фанатами, с заказчиками, с хейтерами — всё это очень важно для получения информации, которую замыленный взгляд не видит. Двигаться вперёд вслепую крайне глупо. Поддерживая связь ты всегда знаешь куда дальше ведёт твоя дорожка.
Но это вектор. Его тоже надо уравновешивать неким «режиссёром» проекта, иначе можно завалиться в сторону капризов пользователя, и прошляпить новые сильные решения, к которым пользователи не привыкли. Как говорил Форд «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.»
Держать правильный баланс между этими противонаправленными векторами требует и опыта, и понимания, и силы воли.
Выстраивание обратной связи, и чем теснее — тем лучше, со своей аудиторией, с пользователями, с фанатами, с заказчиками, с хейтерами — всё это очень важно для получения информации, которую замыленный взгляд не видит. Двигаться вперёд вслепую крайне глупо. Поддерживая связь ты всегда знаешь куда дальше ведёт твоя дорожка.
Но это вектор. Его тоже надо уравновешивать неким «режиссёром» проекта, иначе можно завалиться в сторону капризов пользователя, и прошляпить новые сильные решения, к которым пользователи не привыкли. Как говорил Форд «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.»
Держать правильный баланс между этими противонаправленными векторами требует и опыта, и понимания, и силы воли.
Если у вас в голове есть возможность моделировать поведение этих персон достаточно точно — то это хорошо
У нас такой возможности нет. Потому, я думаю что нужно выстраивать персоны на основе реальных людей и не придумывать поведение и ситуации, а узнавать, какие они бывают в реальной жизни.
Его тоже надо уравновешивать неким «режиссёром» проекта
А, как вы думаете, кто может стать таким режиссёром? Менеджер проекта? Или кто-то, опять же, из команды проектировщиков интерфейса?
Вот про более быструю лошадь вы верно подметили. Люди редко видят нешаблонные решения своих задач. И не зря об обратной связи и ориентированности на пользователя говорят сейчас практически везде, только так можно почерпнуть хоть что-то о реальных (истинных) потребностях человека. И здесь очень важно работать с любыми мыслями и отзывами, в том числе — негативными. Ведь так люди проговаривают то, что их реально волнует, и этим надо суметь воспользоваться, чтобы улучшить свой продукт/услугу.
Благодарю, укрепилось желание таки дойти до чтения этой книги
Книга давно лежит на полке. Теперь точно прочитаю
Программисты обычно заостряют внимание на исключительных ситуациях
Сложно с этим согласиться. Заостряют, но тогда, когда первые два пункта реализованы. И не заостряют, а стараются реализовать, хотя это редко бывает обязательным.
В общем, вы про каких-то сферических программистов пишете. Если нет в ТЗ задачи сделать экранную клавиатуру для кейса, когда у пользователя клавиатуры/нужной раскладки нет — программист ограничится обработкой исключения — выведет сообщение «подключите рабочую клавиатуру». Разумеется, если реализация не от безделия и бесконечного времени.
Я бы скорее даже ситуации реформатировал. Есть повседневные ситуации (собственно, основной функционал) и исключительные ситуации, которые происходят редко. При этом есть исключительные ситуации, которые необходимо реализовать (например, восстановление пароля) и исключительные ситуации, которые реализовывать не обязательно (например, пользователи с ограниченными возможностями или под IE6).
Конечно, в самом лучшем случае должно быть реализовано всё, но тут уже встаёт вопрос планирования и разумного разбиения на итерации. Ну и профит, конечно.
Конечно, в самом лучшем случае должно быть реализовано всё, но тут уже встаёт вопрос планирования и разумного разбиения на итерации. Ну и профит, конечно.
Пишу не я, а Алан Купер, но я с ним согласен. Когда программисту дали недостаточно подробное ТЗ, он начинает делать так как считает нужным. Не являясь хорошим проектировщиком взаимдействия он наделает неудобных штук.
А ещё бывает когда ТЗ пишет программист. Это совсем плохо, потому что пока он пишет ТЗ он думает о реализации, что неизбежно вносит ошибки с точки зрения UX.
Основная идея Купера в том, что проектирование взаимодействия должно быть ДО программирования. Соответственно, если в ТЗ отражено всё то, что задумали проектировщики, то вот оно настоящее программистическое счастье. Остаётся только выполнить задуманное.
Фраза, которую вы совершенно справедливо выделили больше относится к неправильному процессу. Если же в ваш процесс сразу включены хорошие UX-специалисты, то у вас всё хорошо и читать книгу можно по-диагонали.
А ещё бывает когда ТЗ пишет программист. Это совсем плохо, потому что пока он пишет ТЗ он думает о реализации, что неизбежно вносит ошибки с точки зрения UX.
Основная идея Купера в том, что проектирование взаимодействия должно быть ДО программирования. Соответственно, если в ТЗ отражено всё то, что задумали проектировщики, то вот оно настоящее программистическое счастье. Остаётся только выполнить задуманное.
Фраза, которую вы совершенно справедливо выделили больше относится к неправильному процессу. Если же в ваш процесс сразу включены хорошие UX-специалисты, то у вас всё хорошо и читать книгу можно по-диагонали.
Sign up to leave a comment.
Выжимки из «Психбольницы в руках пациентов»