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

Битрикс24

www.bitrix24.ru

16
Tados

Tados

tados.ru

15
YAGLA

YAGLA

yagla.ru

13
myPreza

myPreza

mypreza.ru

12
Devicerra

Devicerra

devicerra.com

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

9
Reader

Reader

Интернет-журнал о современных технологиях.

9
THE NN

THE NN

thenn.ru

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк во ВКонтакте

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

191 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
Надежные и удобные программные решения
Елена Поликанина
Спасибо за живой комментарий!
Ответить
toBotOrNot.com
Создадим веб-страницы, с которыми можно поговорить
Paul Ivanov
Спасибо за статью! Про ковбой-кодера - это то, что все знают, но редко вспоминают (особенно, если сами кодеры) и снова, и снова вляпываются...
Ответить
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать