{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

"Психбольница в руках пациентов" Алан Купер

Так как сейчас ушёл полностью в приложение и все что с ними связанное, начал подкупать книги которые могут как то прокачать меня в этой нише. И в руки попала интересная книга об проектирование интерфейсов.

Проблемы разработки программного обеспечения:

- это началась не так давно, и настолько быстро все развивается, технологии появляются и исчезают. Что какого то стандарта разработки нету.

- все кто стоят у истоков разработки продукта, вполне прокаченные люди в плане технологий и им не составит труда разобраться в какой то задаче, а большинство из таких людей получают удовольствие при решении СЛОЖНЫХ задач. Из этого получается что интересы массового пользователя не учитываются, которые заключаются в простоте использования продуктом.

- Когнитивное сопротивление юзера сложно оценить и оцифровать. (тут конечно я считаю мы продвинулись дальше и можно строить воронки прохождения юзера и упрощать интерфейс)

- Не правильная расстановка приоритетов, мало внимания уделяется проектированию взаимодействия а если и уделяется то после написания кода, когда уже продукт сложно переделывать. Проектировать взаимодействие надо до написания кода

Дешевизна добавления функционала в приложения играет не в сторону продукта. Добавляются малонужные функции в которых теряются основные. Это легко увидеть на примере физического продукта, например автомобиль. Наверное можно было присобачить к нему 5 колесо для облегчения параллельной парковки, но даже считать не надо чтоб понять что затея обернётся очень дорого. А реализовать в коде 5 колесо всегда пожалуйста:) И вроде полезная функция пусть будет.

На выходе мы получаем продукт спроектированный программистами или людьми с похожим мышлением с кучей функций, в котором обычный юзер просто с ума сойдет, потому что не поймет куда жать чтоб достичь своих целей.

Вспомните пульты от телевизора лет 20 назад, кнопок слишком много было. Я даже помню у меня можно было вынимать из панели пульт и переворачивать, там ещё кнопки были. И что все эти кнопки значили знал только я из всей семьи, потому что мне было любопытно) Сейчас у меня на пульте меньше 10 и стало явно удобнее.

Во время прочтения вспоминался Эйпл и его продукты, в которых минимализм и удобство стоят на первом месте. Стив Джобс когда делал первые компьютеры очень сильно настаивал на том чтоб на мышке была только 1 кнопка, тут очень хорошо чувствуется его любовь к упрощению. И как мы видим это работает, я лично влюбился в iPhone и возвращаться на Андройд особо не хочется. Т.е. когда мы делаем удобно для массового пользователя и он остается доволен, он не перейдет на другие продукты, даже если услышит что там лучше. К этому я считаю надо стремиться.

Основная тема книги была про то что надо проектировать взаимодействие с продуктом в самом начале до написания кода, не в коем случае не доверять это программистам, по крайне мере тем которые будут писать код для этой программы иначе возникнет конфликт интересов.

Книга интересная, хотя немного устаревшая по времени. Но точно не помешает кто развивается в сфере разработки мобильных и ПК продуктов.

TG:

0
Комментарии
-3 комментариев
Раскрывать всегда