19. Спасибо за внимание E-mail: vschenkh@intersog.com Twitter: schenkh Facebook: schenkh9
Notes de l'éditeur
Доброе утро, рад видеть всех на этом событии, очень надеюсь что будет интересно и конструктивно. Хочу заметить, что сейчас я довольно много времени уделяю созданию продуктов для iOS и мой доклад об интерфейсах будет тесно переплетаться с тем опытом, который удалось получить в процессе. Я выбрал такой формат, чтобы максимально сократить использование терминологии и высказать мысли, которые в принципе прямого отношения к интерфейсам не имеют. Если у вас будут возникать вопросы, поднимайте руку, я буду по мере возможности сразу на них отвечать. Eсли будет не интересно - свистите :)
Итак, что же такое интерфейс. Прежде всего интерфейс это средство контроля. Ведь все имеет определенный интерфейс: предметы, программы, даже люди. А людям при взаимодействии с програмами и вещами необходима возможность управления, чтобы получить возможность решить проблему. Человек понимает, для того это сделать - необходимо пройти через определенный набор шагов. Именно этот процесс и заботит его в программе, а не красивый код и стильный дизайн.
Интерфейс важен, потому что он связующее звено между функциональностью и оформлением. Потому что хороший интерфейс обеспечивает удовлетворенность и создает опыт взаимодействия, который побуждает пользователя пользоваться продуктом и платить за него. Второй ключевой момент это вопрос конъюктуры. Рынок мобильных приложений на данный момент создал определенные стандарты. Он изменил представление средних пользователей о ценообразовании, стандартах качества и полезности программного обеспечения. Этот рынок очень жесткий и имет значения каждая деталь. Интерфейс это первая вещь на которую имеет смысл обратить внимание, если вы собираетесь создать конкурентоспособный проект.
1. Важно системное понимание участниками команды целей и задач проекта. “Мы хотим сделать социальную сеть с гео-локацией и элементами entertainment”. А зачем и как вы будете конкурировать с Foursquare или Skout? 2. Затем вам нужно понять, кто же целевая аудитория проекта, потому что от этого зависит множество факторов. Контекст использования (*платформа), ценообразование, стратегия маркетинга, даже размер кнопок в конце концов (*дамы). Пока вы не опишете свою целевую аудиторию и не поймете что она хочет (анализом рынка, созданием персонажей или интервьюированием, неважно) - вы скорее всего не поймете ответа на первый вопрос. 3. “Мы хотим сделать универсальную читалку с удобным интерфейсом и поддержкой разных форматов.” Ок, здорово, а как вы собираетесь сделать деньги? Есть GoodReader, Stanza, сотни других читалок. Кроме того, есть ли спрос на такой продукт, с каким уровнем качества вы можете расчитывать на топ позиции, а главное окупит ли позиция в топе на рынке наши затраты на разработку и за сколько :) Если вы думаете “Мы попадем в топ, там миллионы, все будет круто”, то это плохой старт. Опять же если мы говорим о проектах для клиента, подумайте о том где вы можете сэкономить для клиента, где есть проблемы в его спецификации, как можно сделать проект лучше. Тогда клиент скоре всего придет с еще.
Подготовительные действия, которые необходимы, чтобы правильно поставить задачу и оценить целесообразность тех или иных решений. Узнать что делают ваши конкуренты важно по двум причинам. Первая состоит в том, чтобы взять то, что они сделали хорошо (*), вторая в том, чтобы случайно не взять то, что они сделали плохо. Не поймите меня неправильно, взять готовый проект конкурентов и сделать “чуточку лучше” - не стратегия, на сторах таких приложений - полно. В данном случае я говорю о сформированных паттернах, которые лучше заимствовать в неизменном виде, чем делать с нуля. Так просто проще. Ограничения. Нужно трезво видеть масштабы проекта, способности проектной команды и планы на дальнейшее развитие, ну по крайней мере старатся абстрагироваться и взглянуть на эти факторы со стороны. Чаще всего приходит понимание, что оценить эти данные вы на данный момент не можете. Это еще один вектор для развития. И последнее это бизнес модель. Чтобы нормально работать для клиента и выполнить проект, как и для создания успешного продукта, нужно понимать какие бизнес модели есть, как их использовать и что лучше всего подойдет к вашей конкретной ситуации или как оно работает по плану. 192.168.3.30
Структура. Сделайте mind-map или блок-схемы вашего интерфейса, определитесь с бизнес-логикой и сценариями использования. Чем жестче ваши ограничения в плане спецификации и функционала, тем важнее проработать структуру заранее. В противном случае будут возникать очень неприятные моменты, когда весь функционал отрисовали, а две фичи ну просто не помещаются. В лучшем случае вам удатся убрать их или переструктурировать интерфейс. В худшем случае придется их прилепить там, где им не место. Хотя дело тут не только в логике построения интерфейса и взаимодействиях. Под структурой я понимаю также и методы организации информации во внутреннем пространстве вашего интерфейса. Где будут основные управляющие элементы, кнопки, контент. Здесь важно понимать как будут продуктом пользоваться. Будет ли это человек, который бежит на работу и в метро 1 пальцем нажимающий кнопки или человек сидящий на рабочим местом с чашкой кофе.
Скетчи. Очень удобный инструмент, который имеет смысл применять для начала работы над интерфейсом. На самом деле неважно, это набор примитивов в компьютере или отрисованная руками картинка, важно то, что это самый быстрый способ, чтобы визуально описать вашу идею и то, что такой уровень абстракции оставляет меньше шансов запутаться в деталях. Вы сможете быстро оценить объем функционала и понять что вы упустили. Здесь же можно поэксперементировать с логикой и потребностями пользователей c помощью storyboarding. Когда дело доходит до финализации бумажного интерфейса и переходу к следующему уровню детализации имеет смысл минимизировать случайные ошибки исполнителя и логические недоработки. Это просто, но нужно делать много вариантов. 1 интерфейс и даже 3 вариации не представляют особой проблемы. Однако когда вы дойдете до 7 версии, будет очень сложно надеятся на свежие идеи. Тогда или происходит какой-то инсайт и последняя версия либо ы собираете из уже готовых вариантов некий приближенный к идеалу прототип. Основная проблема такого подхода в том, что подъедает большое количество времени, а показать реально практически нечего, какие-то каракули, шеф может подумать что вы ничего не делаете :)
Масштабируемость. Следующий момент - масштабируемость. Вы захотите новые фичи, заказчик захочет новые фичи и пользователи захотят новые фичи. Вы, конечно, можете бороться до послденего, но скорее всего вас сломает. Поэтому заранее подумайте о том, чтобы ваше масштабирование выглядело как на слайде и тогда все будет хорошо. Еще один важный принцип это постепенное раскрытие функционала. Если провести аналогию с этим слайдом, то пользователь не должен увидеть все ветви. Он должен последовательно пройти от одной к другой ветви, решая свою задачу.
Далее я быстро пройдусь по некоторым классическим ошибкам, которые люди допускают при создании интерфейсов для iOS.
Давайте подумаем чем плох данный интерфейс. Да ладно, что тут гадать - он плох всем. Как мы видим это не первый экран приложения, а один из внутренних, использована навигационная модель. Осмелюсь предположить что на предыдущем экране там тоже все не очень хорошо. Эффект, который такой экран производит на пользователя. На английском это называется paralysis by analysis. Следущая ошибка, микс стандартных и нестандартных иконок и послольку они не подписаны, догадаться что они делают (особенно средние) практически невозможно, в конечно итоге их слишком много. Вверху мы видим скролл, который позволяет сортировать таблицу по определенным параметрам. Решение очень сомнительно, чтобы проскролить и не отсортировать, нужно делать очень точные движения. Очевидно что чем точнее выполняется движение, тем больше коррекции нужно для его выполнения (закон Фитса), а это вызывает когнитивное сопротивление, дискомфорт. Далее размер ячеек слишком маленький, и фактически единственная информация, которая полностью доступна пользователю это зип код. Думаю что это как раз то, что меньше всего его интересует.
Следующая проблема это использование кнопки More в таб-барах. Это радикально ухудшает опыт использования приложения (UX), поскольку замедляет доступ к необходимому функционалу. Если же порядок табов еще и можно менять в настройках, то это мешает созданию паттернов использования приложения, человеку постоянно будет сложно. Заставлять пользователя думать нельзя - это смертных грех в проектировании интерфейсов, потому что самые хорошие интерфейсы это те которые используются бессознательно, так просто быстрее. Еще одна проблема такой разметки в том, что при добавлении полей с помощью (+), если я конечно правильно понимаю этот скриншот :), кнопки send и reset будут менять свое положение. Это опять же противоречит правилам хорошего тона.
Не смотря на сходство, это не стандарнтый календарь iOS, а какая-то подделка. Яркий пример плохо использованного поповера, висящий пикер, маленькая таблица, огромное количество зря занятого места. Вообще, вот такие пикеры, блуждающие в пространстве - плохой тон в UI дизайне.
Далее несколько концепций, которые я считаю полезными. Первая концепция касается фокуса внимания. В когнитивной психологии принято считать что человек способен держать в кратковременной памяти 7+-2 объекта. Исходя из этого посыла на одном экране должно быть не более 5-9 элементов управления, а дальше нужно групировать элементы. На самом деле мне кажется, что если большая часть этих элементов не будет для человека привычными, то все на что вы можете расчитывать это вот эти +- 2. А когда дело касается какой-то информации, контента, то я бы вообще не расчитывал на то, что пользователю удастся что-то запомнить. Лучше отставляйте подсказки. Следующая концепция это “success story”. Суть ее состоит в том, что у человека при использовании приложения должно максимально быстро получится какой-то реальный результат. Он должен суметь очень быстро сделать что-то хорошее с этим продуктом. На самом деле отрезки внимания уделяемого одной сессии использования и одному приложению вообще, они, как правило очень небольшие. Поэтому вам нужно пользователя заинтересовать. Можно показать ему красивый дизайн и он начнет там копаться дальше, а можно сразу показать ему как решить его проблему и это будет вообще мега здорово.
Еще один принцип - постепенное раскрытие функционала. Сделайте все, чтобы информация была логично сгруппирована внутри приложения и ее объем раскрывался для пользователя постепенно. Здесь подходят любые методы, главное избежать раздражения пользователя из-за того, чтобы нужно либо надолго останавливатся чтобы ввести контент или разобратся в каком-то наборе функций. Мы здесь видим модальное окно ввода дополнительной информации о задаче. Вместо того, чтобы показать человеку огромную форму со скроллом, которую он будет заполнять вечно, информация логично разбита по вкладкам, чтобы пользователь мог приоритизировать нужные ему параметры. Парадокс в том, что многие люди когда видят поля ввода - начинают в них что-то вводить и не остановятся пока не закончат, чего бы им это не стоило. А правила маркировки необязательных полей на айпаде нет, такой прием не сформировался. Есть еще одна интересная находка, которая называется “зона колеса”, если взять в руки айпад в лэндскейп ориентации двумя рукам и оценить куда вы спокойно можете дотянутся большими пальцами рук, вы собственное ее и получите. Уделяйте пристальное внимание настройкам по умолчанию. В идеале приложение подходит пользователю as is, у него не должно быть необходимости первым делом бежать в настройки и что-то менять. И напоследок, маленькое пожелание - отностись внимательней ко шрифтам, неправильно направленная тень в 1 пиксель, может испортить впечатление полностью. И как правило, на айпаде шрифт достаточно большой для комфортного чтения, но недостаточно большой для того чтобы комфортно с ним работать тапом, это нужно компенсировать подбором правильных гарнитур и размеров.
