карта интерфейса что это

Русские Блоги

Интерфейс карты (Карта)

В дополнение к набору классов отображение представляет собой набор хранимых пар ключей и значений или пар ключ / значение. Учитывая ключевое слово, вы можете получить его значение. И ключевые слова, и значения являются объектами. Каждая пара ключевых слов / значений называется элементом. Ключевые слова должны быть уникальными. Но значение можно повторить. Некоторые карты могут принимать нулевые ключевые слова и нулевые значения, в то время как другие не могут.

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

Интерфейс карты

Методы, определенные на карте

Для отображения часто используются две основные операции: get () и put (). Используйте метод put (), чтобы добавить элемент с указанным ключом и значением на карту. Чтобы получить значение, вы можете вызвать метод get () с ключевым словом в качестве параметра, и вызов возвращает значение.

Интерфейс SortedMap

Интерфейс SortedMap наследует карту, которая обеспечивает сортировку элементов в порядке возрастания по ключевому слову.

Сортированные карты эффективно обрабатывают подкарты (другими словами, поднабор карт) заранее. Используйте метод headMap (), tailMap () или subMap (), чтобы получить подкарту. Вызовите метод firstKey (), чтобы получить первый ключ коллекции. Последний ключ коллекции можно получить, вызвав метод lastKey ().

Интерфейс Map.Entry

Интерфейс Map.Entry позволяет манипулировать отображаемыми элементами. Метод entrySet () описывается интерфейсом Map, который вызывается для возврата набора (Set), содержащего элементы карты. Каждый элемент в коллекции является объектом Map.Entry.

Метод описания интерфейса Map.Entry:

Классы, которые реализуют интерфейс Map

Несколько классов обеспечивают реализацию интерфейса отображения. Можно суммировать как сопоставленный класс:

Диаграмма отношений классов:

Класс HashMap

Класс HashMap использует хеш-таблицу для реализации интерфейса Map. Это позволяет времени выполнения некоторых базовых операций, таких как get () и put (), оставаться неизменным даже для больших коллекций.

Конструктор:

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

Класс TreeMap

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

Конструктор:

TreeMap реализует SortedMap и наследует AbstractMap. Само по себе не добавляет никаких новых методов.

нота: TreeMap отсортировал ключевые слова. При использовании Iterator для доступа к коллекции ключевых слов, они могут быть доступны в естественном порядке ключевых слов.

компаратор

TreeSet и TreeMap хранят элементы по порядку, и вы можете использовать компаратор, чтобы точно определить, какие правила используются для сортировки. Обычно по умолчанию эти классы хранят свои элементы, используя порядок, в котором Java становится «естественным порядком» (A перед B), и этот порядок обычно является тем, что нужно пользователю. Если вам нужно сортировать элементы по-разному, вы можете указать объект Comparator при создании коллекции или карты. Это дает пользователям возможность точно контролировать элементы, чтобы хранить их в отсортированной карте набора классов.

Интерфейс Comparator определяет два метода: compare () и equals (). Метод compare () сравнивает два элемента и определяет их порядок:

Источник

Создание карты пути пользователя для чайников

Продолжаем наши эксперименты с не совсем программерскими курсами и теперь на очереди в запуск «Проектирование UX/UI» и вот интересный материал, которым мы бы хотели поделиться с вами.

Что такое Карта Пути Пользователя?

Карта пути пользователя (или иногда карта пользовательского опыта) — зеркало взаимодействия клиента с вашим продуктом/сервисом.

В прошлом месяце я написала руководство по Google Analytics для UX-дизайнеров. Полезная статья для владельцев сайтов или продуктов, у которых уже есть трафик. Но что делать, если вы начинаете с нуля? Как создать продукт, которым захотят пользоваться?

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

Образы

Отличный пример образа от Keep It Usable

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

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

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

Почему вам необходима Карта Пути Пользователя

Удивительная карта пути пользователя Emirates Airlines от Robert Dersley

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

Хорошее понимание путешествия клиента дает следующие преимущества:

Создание Карты Пути Пользователя

Целью создания такой карты является выявление и исправление болевых точек ваших клиентов.

Via Visual Paradigm

01 Создание образов

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

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

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

У вас есть обучающая платформа с условно бесплатной бизнес-моделью. Ваша целевая аудитория — школьники и взрослые в возрасте от 35 до 60. Нужно создать образы для каждой из этих групп — одна для молодых школьник, и вторая для взрослых 40+.
Базовый курс бесплатный, но за продвинутый курс или степень нужно заплатить. Основные клиенты — молодая группа.
Вы мотивируете группу 40+ потратить время на перевод бесплатного курса на другие языки.

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

02 Пользовательские этапы

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

Необходимо определить пользовательские этапы. Этап должен иллюстрировать мотив покупателей или цель их пути. Ради чего они оказываются на этой странице/этом шаге? В чем заключается их мотив, и как будет развиваться их путешествие на следующих страницах/шагах?
Каждый этап должен олицетворять целенаправленное путешествие клиента, а не ваши бизнес-шаги. Целью пользователя может быть “найти подарок жене”, а действия будут следующими:
поиск продукта > сравнение > корзина > покупка

Как вы определите эти этапы? Очень просто, определяйте отдельные шаги с самого начала путешествия по покупке вашего продукта/сервиса.

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

Каждая точка взаимодействия клиента с вашим бизнесом называется точкой соприкосновения (touchpoint). Пользователь должен пройти через огромное количество таких точек на пути по достижении своей цели. Точки соприкосновения включают в себя (но не ограничиваются): подписку на новостную рассылку, создание аккаунта, подписку на ваш сервис, покупку продукта.

Touchpoint помехи в карте пользовательского опыта Emirates Robert Dersley

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

04 Пользовательское тестирование

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

Карта пользовательского опыта помогает увидеть общую картину путешествия клиента по вашему продукту/сервису. Вы сможете по-новому взглянуть на образ клиента и его путь.

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

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

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

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

Обсудите все возможные пути решения с вашей командой. Так у вас появится точный способ устранения помехи. Внедрите это в карту пути пользователя.

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

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

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

Заключение

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

THE END

Как всегда ждём комментарии и вопросы или заходите к нам на День открытых дверей.

Источник

Этапы разработки пользовательского интерфейса: как сделать так, чтобы UI не лишил вас прибыли

В ноябре 2018 года студия «Лайв Тайпинг» рассказывала читателям vc.ru, из чего складывается стоимость мобильного приложения. Эта статья посвящена одному из слагаемых: пользовательскому интерфейсу.

За восемь лет существования «Лайв Тайпинг» выработала подход к дизайну интерфейсов и готова поделиться с вами его версией на текущий день. После прочтения вы сможете построить коммуникацию с дизайнерами любой студии разработки и будете знать, в каких примерно темпах протекает этот процесс и какой результат вы получите.

Пользовательский интерфейс, или UI (User Interface) — это внешний вид продукта, способ общения между пользователем и программой. А ещё интерфейс влияет на то, будет ли продукт приносить деньги и пользоваться уважением и любовью аудитории.

Доказывать важность дизайна как магнита для пользователей удобно на примере соцсетей с миллионами пользователей. Резонансным случаем в рунете стал редизайн «Кинопоиска». 96% негативных отзывов на него говорят сами за себя: владельцы сайта, компания «Яндекс», сделала это без оглядки на мнение пользователей.

Новый дизайн фокусировал внимание пользователей на возможности смотреть фильмы платно через партнёров «Яндекса», и это решало только задачи площадки и партнёров. Но пользователи больше всего ценили сайт за рейтинги, оценки, списки фильмов, топ-250, блоги и всё, что создаётся аудиторией.

В итоге новый сайт просуществовал четыре дня и под напором гнева «Яндекс» вернул старый дизайн. Новый же, по мнению сопричастных, нравился только менеджерам.

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

Вы хотите повторить судьбу «Живого журнала» и «Кинопоиска»? Не думаем, поэтому мы и написали эту статью. Вам как клиенту будет полезно знать, как именно создаётся дизайн сайтов и приложений, из каких этапов состоит работа и что вы должны получить. Чувство контроля над этими этапами приблизит ваш проект к успеху.

Итак, разберём особенности разработки пользовательского интерфейса пошагово.

На этом этапе вас ждёт много теории, гипотез и умозрительных заключений, которые предстоит подтвердить или опровергнуть. Эти заключения касаются функциональности продукта и проистекают из вопросов: «Зачем нужен этот продукт?», «Кому он нужен?», «Как с ним будут работать и решать задачи пользователи?» и «Как он будет зарабатывать для своих владельцев?».

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

Ответить на большую часть этих вопросов поможет составление портрета целевой аудитории (ЦА) — тех самых людей, для которых делается продукт.

Главная задача дизайнеров при изучении аудитории — включить эмпатию на максимум и понять, как эта аудитория думает, дышит, видит, слышит и действует. Этому способствуют следующие методы:

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

Ключевые персоны — это характерные представители ЦА. Они могут быть разными по профессии, уровню жизни, мотивации пользоваться приложением и прочим параметрам, но опыт, ожидания и страхи каждой персоны ложатся в основу внешнего вида продукта и его функциональности. Например, типичному пользователю приложения «Киноголик» для покупки абонементов в кино 23 года, он работает в ИТ-компании и любит смотреть фильмы на английском.

Такая персона становится центром user story, или пользовательской истории. Это краткий, в несколько строк, рассказ про персону и то, как она работает с функциональностью приложения и какой цели достигает. User story строится по шаблону:

Поместив нашего 23-летнего фаната оригинальных версий в этот шаблон, получим:

Компания Intercom славится не только комплексным решением по внедрению чатов в сайты и мобильные приложения, но и изобретением подхода Jobs To Be Done. В основе подхода лежит не личное качество ключевой персоны, а обстоятельства и мотивация, которые толкают персону пользоваться продуктом. «Размышления» персоны называются Job story, а шаблон выглядит так:

Ситуация с кинолюбом в рамках такого подхода выглядит иначе:

Подробнее про подход Jobs To Be Done написала в своём блоге платформа Tilda.

От User story и Job story мы переходим к User scenario. Это маршрут взаимодействия пользователя с продуктом и достижения цели.

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

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

Работа над ним начинается с создания макета. Одним из вариантов макета является вайрфрейм (от английского wireframe — «каркасный»). Внешне он выглядит как куча прямоугольных блоков, опоясанных линиями и стрелочками. В этих блоках и стрелочках заложена структура продукта и порядок взаимодействия пользователя с ним.

Будет ли вайрфрейм грубым наброском, который вы сделали с коллегами ручкой на бумаге для принтера, или созданной в графическом редакторе организованной картой экранов — решать вам. Единственное: готовьтесь объяснить клиенту, что визуально вайрфрейм не имеет отношения к финальному продукту.

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

Детализированный прототип — следующий шаг вайрфрейма по лестнице эволюции пользовательского интерфейса. Как и вайрфрейм, это макет, но чуть более конкретный: если в вайрфрейме экран с чатом состоит из окружностей и прямоугольников, только намекающих на свои назначения, то в детализированном прототипе окружность — это ТОЧНО фото пользователя, а прямоугольник — ТОЧНО текст сообщения c прикреплёнными файлами, аудиозаписями и стикерами.

Для презентации прототипа мало показать экраны. Нужно показать, к чему и куда приводит взаимодействие будущего пользователя с элементами интерфейса. Связав элементы линиями с другими экранами, на которые попадёт пользователь, вы получите пользовательские сценарии использования приложения, или user flow.

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

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

В качестве софта для этой задачи мы используем Overflow, чей слоган «User flows done right» даёт понять, что время за этой работой пройдёт продуктивно и с пользой. В Overflow легко импортируются экраны из Sketch или Figma, а сделать flow для 100 экранов можно за час — гораздо быстрее, чем рисовать стрелочки самому.

Нужен дополнительный уровень понимания, как продукт будет работать? С помощью таких сервисов, как Marvel, InVision, POP App и Origami Studio детализированный прототип можно превратить в интерактивный. Его польза в том, что он даёт прокликать (а в случае, если у нас мобильное приложение — прокликать прямо в телефоне) все элементы интерфейса и оценить логику работы продукта до того, как он попадёт в руки конечного пользователя.

Его создание — этап необязательный, так как с презентацией будущей работы справляются макеты и user flow. Но когда нужно показать возможности мобильного приложения и раскрыть перед клиентом предстоящий объём работ в деталях, используйте его.

После утверждения логики и функциональности продукта этап прототипирования можно считать завершённым.

Резюмируем: вы получаете детальный прототип, его кликабельную версию (опционально) и карту экранов. Они соответствуют выработанным и согласованным в рамках этого этапа гипотезам продукта.

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

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

Разработчики получают от дизайнеров прототип и user flow, чтобы максимально точно оценить этап разработки и ориентироваться в логике продукта. Затем на будущий продукт начинают накатывать стиль.

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

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

Уважающий дисциплину дизайнер уже давно оценил прелести работы в Sketch — ведь здесь так удобно вести макеты для iOS и Android в отдельных файлах, превращать в легко читаемые символы повторяющиеся элементы интерфейса, заранее присваивать таким элементам стили и отступы от краёв экрана и делать много чего ещё. Всё это складывается в дизайн-систему.

Как и в случае прототипа, готовый дизайн согласовывается с клиентом. Когда всех всё устраивает, дизайн готовится для передачи разработчикам. Сколько времени и сил можно сэкономить, сделав это грамотно посредством Zeplin (спойлер: очень много), можно узнать из нашей статьи.

Пользоваться продуктом в первую очередь будут простые люди, а не его создатели. Будучи людьми простыми, во время работы с продуктом они прогонят его через фильтр из трёх вопросов: «Что делать?», «Куда идти?» и «Куда нажимать?». Если вы серьёзно отнесётесь к этапам работы над интерфейсом, ваши пользователи получат ясный ответ на эти вопросы и останутся довольны продуктом.

Это вопрос о том, насколько пользователю понятна основная функция продукта. Обозначить её нужно на этапе проектирования — тогда же, когда определяется целевая аудитория.

Путь к цели лежит через взаимодействие пользователя с интерфейсом. Кнопка за кнопкой, поле ввода за полем ввода, экран за экраном — и так до заветной покупки или публикации поста. Грамотно составленный user scenario, отрепетированный на прототипе, уберёт с этого пути все ухабы.

Кнопка с целевым действием отличается от остальных элементов на экране. Чем подчеркнуть отличие — цветом, размером или формой — решать дизайнеру на этапе дизайна.

Не менее важно выбрать подходящее слово, которым нужно подписать кнопку. Будет ли это слово глаголом, существительным, прилагательным или другой частью речи, зависит от функции кнопки. Об этом писал в своём блоге Илья Бирман, а на сайте «Бюро Горбунова» он даёт общий совет.

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

Источник