Представляя бэту или прототип продукта, хочется его вылизать, чтобы он понравился клиентам. Это, наверно, на уровне инстинктов.
Такое редко бывает, но один пост перевернул мои представления о том, как должна выглядеть бэта версия. Точнее, даже не перевернул, а сформировал, т.к. я даже никогда не думала о проблеме бэта версий с такой точки зрения.
Клиенты воспринимают степень готовность ПО по степени готовности интерфейса.
Картинка из поста "Don't make the Demo look Done"
Вроде бы очень простая мысль, но она просто не приходила мне в голову раньше.
Если интерфейс выглядит законченным, то пользователи считают что продукт готов. В результате каждая последующая бэта будет восприниматься как затягивание релиза, а это неизбежно породит отрицательные эмоций в сообществе пользователей.
Интерфейс должен совершенствоваться в ногу с функционалом, тогда прогресс будет виден невооруженным взглядом, а пользователи будут довольны видимыми изменениями.
Конечно, можно сказать: "А на что history list? Все изменения можно посмотреть там". Но нравится / не нравится - это эмоция, которая возникает не зависимо от того, что написано в history list. Да и сам history list даже профессионалы при использовании сторонних продуктов не всегда читают. Обычные пользователи практически никогда ничего не читают - все должно быть понятно из интерфейса.
Но и оставлять долго интерфейс в одном и том же зачаточном состоянии тоже плохо. В этом случае пользователи, опять же, не видят изменений, а в сочетании с разобранным интерфейсом это дает ощущение, что проект стоит на месте и никаких положительных изменений не происходит. В результате опять недовольство.
Готовность интерфейса должна соответствовать функциональной готовности продукта.
В постепенном совершенствовании интерфейса есть еще один плюс: На ранних стадиях, когда есть только основные элементы интерфейса, внимание пользователей будет сосредоточено на функционале, соответственно их замечания и пожелания будут относится, в основном, к функциональной области. Это позволит не "закопаться" в интерфейсных проблемах, а также, если потребуется, изменить концепцию интерфейса без крупных затрат. Ближе к релизу, когда функционал готов, отзывы будут относится, в основном, к интерфейсной части, что позволит ее сделать наиболее удобной для пользователей.
Новых вам интересных и успешных проектов в наступающем 2007 году!
RSS Feed / Subscribe
7 comments:
Отличная мысль. В краткой форме ее можно занести в "законы Мерфи" для программистов! ))
Михаил, а я не согласен )
Это не шутка в стиле Артура Блоха, а весьма и весьма ценное замечание (речь, естественно идет о продукте для заказчика, а не собственной разработке, последние бывают весьма долго не выходят из стадии беты). Соответственно, и планировать сдачу этапов надо с учетом этого момента.
%)
С Новым Годом!
Все абсолютно верно. Добавлю, что все вышесказанное лишь подтверждает еще одну закономерность: не стоит делать прототипы приложений, особенно за 2-3 дня или, не дай бог, на глазах заказчика. Этим самым у заказчика создается впечатление, что с него взяли чересчур много денег за проект, и никакие доводы, что это только интерфейс, а еще есть back-end, его не убедят...
Наталия Елманова
У Джоела есть подобная история http://www.joelonsoftware.com/articles/fog0000000356.html .
Один коллега мне рассказывал, что однажды у него была начальница непрограммист. Она оценивала работу программиста строго по изменениям в интерфейсе программы. Можно было увеличить производительность приложения в разы, но если это никак не отразилось на главном окне, значит ничего не было сделано. Жаль конечно, но это правда жизни.
А заказчики, они как дети, им только красивую картинку подавай. Интересно, смотрят ли заказчики на функциональность? Если нет, то можно было бы нанять двух дизайнеров вместо целой армии программистов и рисовать интерфейсы с утра и до вечера... И все довольны.
DenisM, согласна с тем, что в основном подход относится к "продуктам для заказчика". Для "коробочных" продуктов он, просто, слабо применим. У "коробочных" продуктов другой цикл производства и, по большому счету, когда выпускается бэта – это уже практически готовый продукт, а до этого он долго "живет" в недрах компании и его никто не видит.
Однако есть компании, которые ведут разработку "на глазах" у пользователей (выпускается несколько альф, потом несколько бэт). При таком цикле разработки видимый прогресс в интерфейсе очень полезен – позволяет долго удерживать внимание возможных потребителей и увеличивать аудиторию. Но такой длинный публичный цикл имеет смыст только для уже известных продуктов, т.к. сырой неизвестный продукт не может привлечь к себе внимание.
Наталья, прототипы делать надо. Они помогают и заказчику и разработчику не только понять друг друга, но и определиться что же, в конце концов, надо заказчику и что из этого реально может сделать разработчик. Но выглядеть прототип должен именно как прототип. Да и за 2-3 дня (вообще то в крупном проекте и за месяц) нормальный интерфейс все равно сделать не удастся.
А чтобы не было ощущения что это готовый продукт вместо функционала можно выдавать сообщения – здесь будет реализовано то-то, а здесь то-то.
Да, в большинстве заказчики действительно оценивают продукт только по внешнему виду.
Но идея об искусственной задержке развития интерфейса мне кажется очень хорошей. Ибо велико искушение сделать всё сразу(в идеале усадить за разработку дизайнера), а потом лишь добавлять функциональность к уже готовым окнам/формам/кнопкам.
Post a Comment