Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты
Рекомендуем
Продвинуть свой проект
196 3 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

Как найти себе друга в запутанном и сложном мире IT-технологий? Ищем ответ вместе с менеджером проектов Дмитрием.

Автор Дмитрий Полозов, менеджер проектов INOSTUDIO.

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

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

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

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

b_5718e2d10c13c.jpg

Этапы разработки ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошего дня!

Ставь +1 и подписывайся на блог INOSTUDIO!

Оригинал статьи читайте на страницах блога компании и не забывайте подписываться на наш блог!

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Подбираем рекоммендации...
Комментарии
Первые Новые Популярные
Foreseer
Data Mining для вашего бизнеса
Ван Гугенхайм
Проектировщик опыта взаимодействия -
В следующей статье попрошу указать места обитания этого редкого зверя и краткый опросник для отсеивания псевдоспециалистов, а то алмаз среди говна искать приходится обычно.
Ответить
INOSTUDIO
Надежные и удобные программные решения
Крук Мария
Спасибо за живой комментарий!
Ответить
MageAI - Chatbot 4 IFTTT
Facebook-чатбот, присылающий уведомления с IFTTT-сервиса
Paul Ivanov
Спасибо за статью! Про ковбой-кодера - это то, что все знают, но редко вспоминают (особенно, если сами кодеры) и снова, и снова вляпываются...
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать