Оставаясь на сайте, вы принимаете условия Политики конфиденциальности и использования файлов-cookies

тех задание на проект

Скажи мне, кто твой друг?

201
2

Начать разработку ПО непосредственно с кодинга — это все равно, что приняться шить себе костюм без примерки и выкройки. Cамонадеянно, если не сказать безрассудно. В IT у такого процесса даже есть пренебрежительное название — «ковбой-кодинг».


Есть другая категория — люди, которые мыслят картинками и образами. Они могут подумать, что первым шагом в процессе разработки качественного ПО должна стать разработка дизайна. Так до сих пор делают во многих компаниях. Но у этого метода тоже есть ряд минусов. О них я расскажу чуть позже.

Современная разработка ПО должна начинаться с проектирования опыта взаимодействия, и никак иначе. Здание строят, начиная с фундамента. Проектирование продукта должно происходить от общего к частному.

В случае разработки ПО, фундамент — это потребности пользователей и цели продукта. На втором этаже — набор возможностей, на третьем — структура, на четвертом — компоновка и только на самом последнем уровне идёт визуальный дизайн.

проектирование продукта
Этапы разработки ПО.

Проектировщик взаимодействия — ваш лучший друг. Он проверяет вашу идею на прочность еще до того, как дизайнер создал макеты, а разработчик воплотил их в коде. Проектировщик выявляет сильные и слабые стороны продукта, делает его удобным для пользователя. Конечно, до того, как начать проектировать систему, еще нужно собрать требования, но это уже совсем другая история.

В этой статье я хотел бы поговорить об основных ошибках проектировщиков интерфейсов, которые встречались мне в ходе моего опыта работы над новыми продуктами. Я нашел три наиболее частые ошибки:

  1. Чрезмерное усложнение продукта.
  2. Поверхностное видение продукта.
  3. Слабая взаимосвязь частей продукта.

Разберем по порядку каждую ошибку:

1. Чрезмерное усложнение продукта

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

Алан Купер в книге «Психбольница в руках пациентов» сравнил сложные продукты со швейцарским ножом. Взгляните на такой предмет, как швейцарский нож. Он содержит непосредственно лезвие, отвертку, пилку для ногтей, штопор (что немаловажно) и много чего еще. Проблема в том, что любой продукт из перечисленных, но представленный отдельно, будет более удобен в использовании, чем их совокупность. Если мне нужен нож, то я выберу хорошо сбалансированный нож с удобной рукояткой и острым лезвием, а не пресловутый швейцарский нож.

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

Согласно принципу Парето 20% усилий дают 80% результата. Для программных продуктов этот закон означает, что 80% вашей аудитории будут использовать только 20% продукта. Если в вашем продукте еще не настроена google-аналитика, займитесь этим. Заглянув в нее, вы узнаете, что в продукте есть фичи, которыми вообще никто не пользуется.

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

2. Поверхностное видение продукта

Представьте себе интерфейс вашего собственного продукта. Если у вас нет за плечами многолетнего опыта проектирования, как у вашего друга проектировщика, то вероятнее всего, вы представили себе статичный интерфейс. Вы не увидите у себя в голове ни уведомлений об ошибках, ни диалоговых окон. Это говорит о том, что, думая картинками, мы забываем о контексте. Откуда пришел пользователь? Куда он планирует пойти? Что произойдет, если нажать на эту кнопку? На эти вопросы нужно знать ответы.

Если вам уже отрисовали дизайн, то подумайте о том, чего не хватает в макетах. Возможно, дизайнер забыл о валидации или не подумал о том, как вашим продуктом будет пользоваться человек с медленным интернет-соединением. Важно понимать, что помимо автора идеи с проектом еще будут иметь дело обычные пользователи, которым нужно помочь и задать направление. Дизайн — это не про сферического коня в вакууме. Он должен быть конкретным, здесь и сейчас.

В этом отношении книга Стива Круга «Не заставляйте меня думать»лучший друг вашего друга проектировщика.

3. Слабая взаимосвязь между частями продукта

Интерфейс проектируется не как взаимосвязанная система функций, а как последовательный список кусков хорошо знакомых продуктов. Получается такая страшная гекатомба, состоящая из тухловатых на вид останков чужих интерфейсов. Это даже не швейцарский нож. Часть функций в таком интерфейсе дублируется, а часть вовсе изолирована и запрятана где-то глубоко. Главный признак такого интерфейса — пользователю сложно найти необходимую функцию в продукте.

Причина возникновения такой ошибки проста. Вместо уникального решения задачи мозг подсовывает исполнителю шаблонное. Сам по себе типовой интерфейс — это не всегда плохо, так как у пользователей есть свои привычки, и они не хотят каждый день изобретать велосипед. Проблема в удобстве пользования и негибкой архитектуре. Ежедневная головная боль вашего друга проектировщика — пройти между Сциллой «непонятный интерфейс» и Харибдой «шаблонный интерфейс».

Резюмируя сказанное

Ковбой-кодер — не твой бро. Не отдавай ему свою идею. Она не выстрелит.

Дизайнер — отличный парень, если читал хотя бы Алана Купера и Стива Круга. Расскажи ему о своей идее. Он выслушает тебя и скажет свое мнение.

Проектировщик опыта взаимодействия (иногда он шифруется под аналитика) — твой лучший друг. Выпей с ним рюмку чаю за успех проекта!