3) Скорость работы

Следующая мысль – про скорость работы. Самые главные основные функции должны быть не просто доступны, они должны быстро работать. Обычно скорость работы не рассматривается как функция проектировщика. На самом деле именно проектировщик должен продумать не только внешний вид и поведение системы, но и то, как это поведение может быть достигнуто. Потому что решение, что вот сейчас мы тут что-нибудь, значит, наберем и у нас это мгновенно все обновится, ничего не стоит, пока ты не сможешь объяснить разработчику интерфейса, как этого добиться.

4) Обратная связь в интерфейсах

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

5) Отсутствие режимов предсказуемости

В чем проблемы режимов? Режим – это такое состояние системы, при котором ваши привычки не работают. Т.е. какие-то привычные действия, какая-то функциональность, которой вы привыкли пользоваться, она не работает так, как вы привыкли к этому, и при этом система сама вам никак не подсказывает, что что-то изменилось.

6) Минимизация ошибок при пользовании интерфейсом

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

7) Информативность интерфейса

Информативность интерфейса – что это вообще такое? На самом деле, это из всех принципов – такой, самый необязательный. Т.е. информативные интерфейсы лучше, чем интерфейсы неинформативные, но это не какая-то необходимость. С другой стороны, зачастую, когда вы смотрите на какой-то интерфейс – вспомните вот эти картинки, которые мы смотрели раньше, где было очень много окошек, каких-то графиков – проблема совсем не в том, что информации много, проблема в дизайне, в том, что информация подана неправильно. Поэтому каждый раз, прежде, чем какую-то информацию выбросить, вы все-таки попытайтесь ее как-то передизайнить, попробовать на нее взглянуть иначе, потому что во многих случаях это действительно положительно скажется на интерфейсе.

Процесс проектирования интерфейсов

Как вообще его правильно бы построить, и какие этапы он в себя включает?

Собственно, процесс очень простой: Анализ – Концепт – Детальный дизайн – Сопровождение и внедрение. Здесь показаны еще результаты выхода из каждого этапа. Конкретно рассмотрим каждый из этапов.

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

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

Для того, чтобы продемонстрировать концепт, как правило, достаточно самое небольшое количество экранов, т.е. это может быть главная страница сайта и две-три внутренних; либо, если мы говорим про какое-то устройство, терминал, мобильный интерфейс – может быть вообще один-два основных экрана, плюс навигационная концепция, т.е. как эти экраны между собой связаны. Самое главное, чтобы здесь была вот эта главная идея – в чем суть нашего интерфейса, почему им удобно пользоваться, почему он предоставляет быстрый доступ к информации, к функциональности, которая важна. На следующем этапе прорабатываются все остальные этапы, выбирается фотографическое оформление, если этого не было сделано раньше, и на выходе мы получаем огромную стопку картинок уже графически оформленных плюс какие-то наборы пиктограмм, плюс какие-то графические элементы, описание поведения. Например, можно нарисовать не все экраны, а нарисовать половину экранов, а половину каким-то образом описывать текстом, говорить, что этот экран получается из такого, будет работать так-то. Т.е. на выходе из детального дизайна – у нас готовый дизайн продукта. И после этого идет самый важный, самый сложный этап, который сейчас игнорируют, но на самом деле – это единственный по сути… Т.е. если все этапы – они очень классные и интересные и важные для результата, то какой бы крутой дизайн у нас не получился на выходе из третьего этапа, если мы не проводим сопровождение и внедрение, то все наши труды абсолютно ничего не стоят. Т.е., единственное, что важно – это тот продукт, который получится, когда с ним закончат работать программисты. Потому что исключительно дизайнер интерфейсов несет ответственность за тот результат, который получится у программистов. И это правильно – брать на себя ответственность, потому что иначе результат будет очень сильно отличаться. Дизайнер будет говорить, что: «Я нарисовал такую красивую штуку, это программисты все зарубили», а программисты будут говорить: «Что он нам такое нарисовал вообще, как оно должно работать? Мы все переделали так, как мы понимаем».