Дизайн интерфейса программы – 10 советов по дизайну интерфейса / Habr

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

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

2.      Знайте целевую аудиторию сайта

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

Вам нужно иметь четкое представление о том, какие потребности приведут людей на сайт и удержат там, позволят конвертировать ЦА из обычных зевак в лояльных клиентов.

Теряетесь в догадках? Тогда начните с просмотра конкурирующих проектов. Используют ли конкуренты похожие макеты или цвета? Придерживаются ли они подобного стиля?

Помните: использование визуально приятных веб-шаблонов поможет привлечь ЦА.

При этом отличайте вкусы аудитории от своих собственных. Определившись с ЦА, можно провести тестирование и получить отзывы посетителей. Фидбэк – залог успеха.

3.      Простой и понятный UI-дизайн

Отличительной особенностью хорошего интерфейса является простота.

Мы не имеем в виду приклеивание кнопки здесь и там с примитивной анимацией.

Мы говорим об интерфейсе, который просто понять и освоить даже новичку.

Пользователь не должен нуждаться в карте и компасе для ориентирования по разделам сайта – дизайнер сам направляет его куда нужно! Для этого используются цвета, типографика, обратная связь и визуальные иерархии, которые мы рассмотрим ниже.

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

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

4.      Внедряйте визуальную иерархию сайта

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

Самый простой пример – укрупнение элемента, превращение его в центр страницы (вот почему никто не игнорирует Годзиллу!). Возьмем популярный веб-сайт Netflix, где при открытии главной страницы вас сразу встречают выделенные рекомендации.

Более оригинальный способ реализовать визуальную иерархию – использование пробела для выделения важных частей интерфейса. В качестве альтернативы появление неожиданного элемента со вкусом способно творить чудеса. Удивляйте пользователей!

Как мы уже говорили, согласованность в интерфейсе имеет решающее значение. До такой степени, что появление «нарушителя» привычного шаблона мгновенно привлечет внимание.

5.      Правильно используйте типографику

Другим элегантным способом создания визуальной иерархии является типографика.

Это не так просто, как выбрать хороший шрифт (три из четырех дизайнеров выбирают Comic Sans). Каждый шрифт имеет, так сказать, индивидуальность, и влияет на ЦА по-разному.

Размер играет ключевую роль при использовании шрифтов в вебе.

Важная информация, такая как заголовки, выделяется крупным и элегантным шрифтом (будьте осторожны – не выделяйте слишком много информации). И не забывайте о контрастах.

6.      Цвета и контраст в дизайне интерфейса

Некоторые комбинации, такие как синий на красном, читаются ужасно.

Хороший UI-дизайнер никогда не допустит появления такого «салата» на мониторе.

Выбор правильных цветов для дизайна интерфейса – это целая наука.

Если вы читаете данный материал, наверняка вы уже знакомы с психологией цветов.

Цветовая схема должна быть не только красивой, но и эффективной.

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

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

Есть хорошее эмпирическое правило при подборе цветов: темные цвета несут больше «визуального веса», и разбавлять их следует светлыми цветами.

7.      Настройте обратную связь

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

Идет загрузка? Почему бы не вывести в этот момент анимацию с полезным сообщением для пользователя? Человек неверно заполнил форму – почему сразу не сообщить ему?

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

Обратная связь – лучший способ научить людей правильно пользоваться продуктом.

8.      Упрощайте формы для заполнения

Формы – один из основных методов взаимодействия пользователя с вашими веб-проектами. Именно там они будут что-то кликать, проклиная время от времени вас и компьютер.

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

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

Спросите себя: «Действительно ли эта форма необходима?».

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

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

9.      Дизайн интерфейсов – командная работа

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

10. Объедините результаты UI-дизайна

Как мы уже говорили, дизайн интерфейсов – сложный процесс.

Вы должны учитывать множество факторов, обладать достаточными техническими знаниями и понимать аудиторию сайта. Только предвидя потребности ЦА, можно создать дизайн, который будет соответствовать, и даже превышать текущие потребности.

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

Есть личные правила UI-дизайна? Делитесь ими в комментариях.

sdvv.ru

Проектирование пользовательского интерфейса Windows 95 / Habr

Статья описывает некоторые общие проблемы оболочки Менеджера программ в Windows 3.1 и рассматривает варианты разработки отдельной оболочки для «новичков». Я склоняюсь к мнению, что она предположительно создавалась в духе программы At Ease от Apple, довольно популярной во времена System 7. Я хорошо помню, как мы запускали At Ease в начальной школе, так что детишкам не приходилось возиться с жёстким диском в Finder.

Итак, вот что Кент дословно написал в своей статье под названием «Пользовательский интерфейс Windows 95: конкретный пример проектирования функциональности» (The Windows 95 User Interface: A Case Study in Usability Engineering). Публикуем её, чтобы документ никогда не потерялся.

Дизайнерский отдел

Цели дизайна

• Сделать проще изучение Windows для людей, которые только начали пользоваться компьютерами и Windows.
• Сделать проще использование Windows для людей, которые уже работали с компьютерами — как для обычных пользователей Windows 3.1, так и для продвинутых, опытных пользователей Windows 3.1.

Процесс дизайна

В каскадной модели проектирование системы разделяется на части (обычно ограничено фазой написания спецификаций), а тестирование юзабилити, как правило, происходит ближе к окончанию процесса, во время мероприятий по контролю качества. Мы поняли, что этого недостаточно для создания дизайна, его проверки на пользователях (возможно, в сравнении с другими дизайнами), произведения изменений и сбора отзывов. К счастью, наше желание отказаться от каскадной модели в пользу итеративной разработки совпало с аналогичными попытками в других отделах компании, так что у нас имелись конкретные примеры её преимуществ и применимости.

Наш процесс итеративной разработки проходил в три основных этапа: изучение, быстрое прототипирование и тонкая настройка.

Рис. 1: Процесс итеративной разработки Windows 95

Этап изучения

На рис. 2 показан прототип дизайна рабочего стола Windows 95, юзабилити которого мы тестировали в январе 1993 года. Дизайн основан на Cairo и включает в себя первый проход исправления некоторых известных проблем Windows 3.1 (в частности, управления окнами).

Рис. 2: Ранняя версия рабочего стола Windows 95 (с выносками для ясности)

Верхняя иконка File Cabinet открывала вид в стиле менеджера файлов Windows 3.1 (слева иерархия, справа контент). Вторая иконка World показывала элементы в сети. Третья иконка Programs — это папка с другими папками, полными ссылок на программы, установленные в системе. Вдоль нижей части экрана располагается системный трей с тремя кнопками (System, Find и Help) и областью хранения файлов. Другая иконка Wastebasket представляет собой контейнер удалённых файлов.

Исследования юзабилити этого прототипа рабочего стола проводились в лаборатории юзабилити Microsoft, также как и последующие тесты. Мы провели типичные итеративные исследования юзабилити. От трёх до четырёх пользователей, каждый из которых представлял отдельную интересующую группу (обычно начинающие и средние пользователи Windows 3.1) выполняли задачи на прототипе. Во время тестирования мы хотели получить ответы и на очень широкие вопросы (например, нравится ли интерфейс пользователям), и на очень конкретные (например, обнаружит ли пользователь в течение 10-ти минут возможность копирования файла путём перетаскивания мышкой). Мы собрали типичные данные для итеративных исследований: вербальные протоколы, время выполнения задачи, количество ошибок, типы ошибок и оценки.

Первые результаты

Сравнение с Windows 3.1

Ключевые результаты:

• В Windows 3.1 новичкам требовалось в среднем 9,5 минут для поиска и открытия программы, которая не видна сразу на экране. В нашем прототипе Windows 95 результаты оказались ненамного лучше. Такие результаты явно неприемлемы с учётом того, что данные рыночных исследований (и здравый смысл) говорили о том, что запуск программ у пользователей является задачей номер один.
• Новые и некоторые средние пользователи испытывали большие проблемы при использовании мыши, особенно двойного щелчка. В результате они часто не могли найти элементы в контейнерах, доступ в которые открывался только по двойному щелчку.
• Начинающие и многие средние пользователи для поиска команд полагались почти исключительно на визуальную информацию. Они полагались на строки меню и панели инструментов, но не использовали всплывающие (контекстные) меню даже после обучения.
• Все, кроме самых продвинутых пользователей, не понимали, как эффективно управлять множеством перекрывающихся окон. Больше всего проблем возникло у новичков — при сворачивании окна они думали, что оно «ушло», если оно было закрыто другим окном. От преподавателей мы слышали много историй (и наблюдали это в лаборатории), как пользователи исчерпывали всю оперативную память на компьютере, запуская многочисленные копии программы вместо переключения на первую запущенную копию. Средние пользователи проявили больший опыт, но тоже испытывали проблемы, особенно с приложениями Multiple-Document-Interface (MDI), такими как Менеджер программ и Microsoft Word. Данные рыночных исследований подтвердили проблему: оказалось, что 40% средних пользователей Windows не запускали больше одной программы одновременно, потому что испытывали какие-то трудности с этим.
• Начинающих пользователей сбивала с толку иерархическая файловая система. Средние пользователи обычно справлялись с иерархией, но зачастую делали это с трудом и сохраняли все свои документы в директорию по умолчанию для той программы, которую использовали. Эта проблема (особенно у новичков) наблюдалась и у пользователей Macintosh.

Смена направления

Однако данные, собранные в прототипе Windows 95 и в Windows 3.1, показали невозможность сохранения текущего дизайна. Результаты начинающих пользователей в выполнении базовых задач оказались неприемлемо плохими, а многие средние пользователи выражали мнение, что Windows 95 просто другая, но не лучшая система.

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

По сути мы осознали, что жизнеспособное решение необязательно должно выглядеть как Windows 3.1, но определённо должно быть привлекательным для пользователей любого уровня, потенциально по разным причинам. Мы поняли, что по-настоящему удобная система будет масштабироваться в соответствии с нуждами разных пользователей: её легко освоить и изучить, и в то же время она обеспечит эффективность (через ярлыки или альтернативные методы) для более опытных пользователей.

Этап быстрых итераций

Эволюция процесса спецификаций UI

После некоторых споров группа выбрала второй вариант. Хотя такое изменение в чём-то затруднило сторонним группам возможность следить за нашей работой, но позволило проводить итерации на максимальной скорости. Изменения также привели к неожиданному эффекту: они сильнее сплотили команду, потому что бóльшая часть спецификаций существовала в устной форме и обсуждалась в беседах и на белой доске в кабинетах сотрудников. Последовало много «коридорных» разговоров, которые продолжались на протяжении всего проекта.

Чтобы все заинтересованные стороны всегда были в курсе актуального дизайна, мы организовали следующие мероприятия:

1. Регулярные собрания сотрудников дизайнерского отдела. На еженедельных (иногда чаще) собраниях каждый сверял свою работу с общим проектом и все обсуждали, как работа каждого сотрудника может повлиять на других.
2. Рассылка графиков и результатов тестирования юзабилити по электронной почте. Сотрудники дизайнерской группы получали регулярные уведомления о предстоящих тестах юзабилити и результатах завершённых тестов, чтобы быть в курсе, как продвигается дизайн.
3. Формальное отслеживание проблем юзабилити. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях. Этот процесс более детально описывается в главе «Отслеживание открытых тикетов».
4. Регулярные презентации дизайна для внешних групп. По мере продвижения проекта всё больше и больше групп (внутри и за пределами Microsoft) хотели посмотреть, что мы делаем, так что мы проводили такие презентации. Они эффективнее, чем рассылка документов, потому что презентации проще поддерживать в актуальном состоянии и они позволяют своевременно обсуждать дизайн.

Отдельный UI для новичков

1. Если в оболочке для новичков не поддерживалась всего одна нужная функция, то пользователю приходилось отказываться от использования оболочки (по крайней мере, временно).
2. По идее, большинство пользователей после набора опыта должны оставить оболочку для новичков и перейти в стандартный интерфейс. Но опыт, который они получили в оболочке для новичков, необязательно переносится в стандартную оболочку.
3. Оболочка для новичков вообще не похожа на все остальные программы, которые запускает пользователь (текстовые редакторы, электронные таблицы и др.). В результате пользователям приходилось изучать два способа взаимодействия с компьютером, что вносило путаницу.

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

Примеры быстрой итерации

1. Запуск программ: меню «Старт». Хотя мы отказались от идеи отдельной оболочки для новичков, мы сохранили её самые полезные функции: доступ по однократному щелчку, хорошая различимость, взаимодействие через меню. Мы набросали много вариантов в Visual Basic и проверили их на пользователях всех уровней, не только на новичках, потому что это дизайнерское решение должно было хорошо восприниматься пользователями любого уровня. Рис. 5 показывает окончательный вариант меню «Старт» и подменю «Программы». Это меню служит не только для запуска программ, но сочетает в себе и другие функции. Все они открываются нажатием одной кнопки.

Рис. 5. Меню «Старт» и подменю «Программы»

2. Управление окнами: панель задач. Наша первая идея по улучшению управлением окнами была не очень амбициозной, но мы не знали, сколько работы понадобится для решения проблемы. Первой идеей было изменить внешний вид свёрнутых окон из иконок на «плитки». (рис. 6).

Рис. 6. Свёрнутые окна в виде «плиток»

Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись! Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1. Результаты тестирования показали, что основная проблема в том, что окна не отображаются постоянно, так что пользователи не видят, какие окна открыты, и не могут быстро получить к ним доступ. Поняв это, мы быстро пришли к идее панели задач, показанной на рис. 7. У каждой задачи есть собственное место на панели, которая отображается поверх всех окон. Тестирование на пользователях показало, что это приемлемое решение проблемы.

Рис. 7. Панель задач с кнопкой «Старт», программами и часами

3. Работа с файлами: диалоги «Открыть» и «Сохранить как…». Информация из службы поддержки и результаты лабораторных тестов показали, что новички и средние пользователи испытывают много проблем с системными диалогами открытия и сохранения файлов (рис. 8).

Рис. 8. Диалоговое окно открытия файла в Windows 3.1

Проблемы вызваны тем, что поля диалогового окна находятся не в логическом порядке и имеют сложную методологию выбора. Команда Cairo взяла на себя инициативу в решении этой проблемы и разработала всесторонний прототип на Visual Basic, в том числе макет файловой системы. Мы протестировали несколько вариантов, пока не остановились на окончательном варианте, показанном на рис. 9.

Рис. 9. Диалоговое окно открытия файла в Windows 95

4. Печать: мастер установки. Информация из службы поддержки говорила о том, что установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера (рис. 10).

Рис. 10. Основное диалоговое окно установки принтера в Windows 3.1

Найти нужный принтер сложно, потому что все они находятся в одном длинном списке. Для выбора порта, особенно в сетевом окружении, требовалось спуститься на 4-5 уровней с нестандартными и сложными вариантами выбора. Примерно в то время, когда мы начали решать эту проблему, сотрудники дизайнерского отдела начали рассматривать мастер (визард) как решение для многоэтапных нечасто выполняемых задач. Установка принтера отлично вписался в это определение, и созданный визард показал хорошие результаты в тестировании на пользователях. На рис. 11 показан экран выбора принтера из окончательного варианта визарда.

Рис. 11. Экран мастера добавления принтера в Windows 95

5. Помощь: диалог поиска и вкладка с индексом. Лабораторное тестирование Windows 3.1 показало, что пользователи испытывают проблемы с поисковом диалогом в справочном разделе (рис. 12).

Рис. 12. Диалог поиска по справочной информации в Windows 3.1

Люди с трудом понимали, что диалоговое окно по сути состоит из двух частей и что нужно сначала выбрать что-нибудь из первого списка, а потом из второго, используя разные кнопки. Мы проверили несколько идей, прежде чем пришли к окончательному варианту вкладки с индексом (рис. 13). На этой вкладке только один список, а ключевые слова с более чем одной темой вызывают всплывающее окно диалогом, которое трудно не заметить.

Рис. 13. Вкладка индекса в справочном разделе Windows 95

Этап тонкой настройки

• Итоговые лабораторные тесты. Используя 20 основных задач из рыночного исследования мы провели комплексное тестирование всего UI. Пользователям разного уровня подготовки предлагали изоморфные наборы задач для измерения скорости обучения и уровня использования после освоения. Мы сравнивали эффективность работы с базовым уровнем Windows 3.1. После проведения собственного пилотного теста для выяснения возможных проблем с процедурой окончательное тестирование осуществил посторонний подрядчик, так что эти результаты можно использовать в официальных документах [3]. Результаты оказались весьма обнадёживающими — пользователи завершали выполнение задач примерно вдвое быстрее, чем в Windows 3.1 и в 20 из 21 категорий показали большее удовлетворение работой Windows 95.
• Длительное полевое исследование. Двадцать человек приняли участие в полевом исследовании на бета-версии Windows 95. Сначала мы изучали, как они работают в Windows 3.1, а затем наблюдали за установкой Windows 95. Дополнительные тесты проводились через неделю и через месяц для проверки уровня обучения и произошедших изменений. Мы не нашли никаких серьёзных пробелов в юзабилити продукта, но подкорректировали формулировки в UI и темах справочного раздела. Некоторые из собранных данных впоследствии использовались при планировании следующей версии Windows, а также сотрудниками службы поддержки, в том числе краткий перечень тем, которые можно ожидать с началом звонков в службу поддержки.

Для этого мы разработали реляционную базу данных (рис. 14).

Рис. 14. Образец записи в базе данных с тикетами

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

Рис. 15. Образец отчёта в базе данных с тикетами

Отчёт

Лабораторные тесты

Выявление проблем

• Уровень 1: Пользователи не могут продолжать выполнение задачи или серии задач.
• Уровень 2: Пользователи испытывают значительные сложности с выполнением задачи или серии задач, но всё-таки способны продолжить её выполнение.
• Уровень 3: Пользователи испытывают незначительные сложности с выполнением задачи или серии задач.

Резолюции по проблемам

• Решено. Команда исправила проблему и успешно испытала решение на пользователях.
• Запланировано. Команда разработала исправление проблемы и мы ожидаем его реализации.
• Под вопросом. Команда не уверена, нужно ли решать проблему, или не знает, возможно ли её решение.
• Частично. Команда разработала решение и оно протестировано на пользователях с удовлетворительными результатами, но всё равно остаются некоторые вопросы.
• Не решено. Команда не собирается решать проблему.

Итеративная разработка

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

Процесс спецификации

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

Тестирование юзабилити

Отслеживание проблем

Все тикеты с пометками «частично» и «не решено» перенесли в новую базу. Они стали начальной точкой для проектирования следующей версии Windows. Специалисты по планированию и дизайнеры ежедневно работали с этой информацией, а также анализировали отчёты из службы поддержки.

2. Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.

3. Usability Sciences Corporation. (1994). Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity.

4. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction (стр. 791-817). Amsterdam: Elsevier Science Publishers, B. V.

5. Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.

habr.com

Разработка интерфейса приложения

 Выявление идеи и создание ТЗ. Мы детализируем идею приложения и набрасываем пути перемещения пользователя в будущем интерфейсе. Затем составляем точное ТЗ для дизайнеров и программистов.

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

Создание графики. Дизайнеры отрисовывают элементы интерфейса в соответствии с разметкой. Кроме основного пакета графики, рисуется 2 альтернативных.  

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

Тестирование на фокус-группе. Мы собираем фокус-группу и просим скачать приложение на смартфон. Многие элементы интерфейса, которые кажутся очевидными на этапе разработки, на деле не понятны сразу. Идеальный интерфейс вообще не требует обучения и разъяснений.  

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

Повторное тестирование и релиз. Проводится еще один тест, если он успешен, то создание интерфейса приложения завершается и оно готово к релизу.

koloro.ru

Дизайнеры : дизайн интерфейса, интерфейс приложения, фриланс, FL.ru

www.fl.ru