Connect with us

Дизайн и прототипирование

Podlodka #42: Дизайн-системы

В последнее время в сообществе разработчиков все чаще упоминаются некие “дизайн-системы”.

Леонид Боголюбов

Опубликовано

/

     
     

С тем, что это такое и как это применимо к мобильному миру, нам помог разобраться Александр Зимин – iOS-разработчик из Badoo!

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

Победители Material Design Awards 2018

Google объявил победителей Material Design Awards 2018.

AppTractor

Опубликовано

/

Автор:

Google подвел итоги ежегодного конкурса  и выбрал лучшие приложения, выполненные по заветам Material Design.

В категории Выражение победило приложение с рецептами KptnCook:

В Инновациях – Lyft:

Лучшим дизайном в Опыте стало приложение Simple Habit Meditation для мобильной медитации:

Ну а лучшей адаптацией стали кроссплатформенные подкасты Anchor:

 

 

Комментарии
Продолжить чтение

Дизайн и прототипирование

Pandao: волшебная пилюля, от которой конверсия взлетает ракетой

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

AppTractor

Опубликовано

/

Автор:

Pandao — один из крупнейших интернет-магазинов, которые продают товары из Китая с доставкой в Россию. По данным пресс-службы Mail.Ru Group, во втором квартале 2018 года ежемесячная активная аудитория Pandao составляла 6 млн. человек и продолжала расти. Общее количество скачиваний мобильного приложения превысило 20 млн.

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

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

Вот как этот процесс организован у нас в Pandao.

С чего начинали, что изменилось за год

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

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

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

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

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

Как исследуем аудиторию

Знание аудитории и сервис — решают. Когда проект только запускается, тебе нужно понять, какая аудитория у него будет. Чтобы развивать проект, нужно знать, как с этой аудиторией работать.

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

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

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

Эволюция элементов интерфейса — карточка товара приложения год назад и сейчас

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

Если мы видим по конверсии, по переходам между экранами, что выросло число нерезультативных сессий — значит, мы сделали что-то неправильно и изменения надо откатить, так как пользователю стало сложнее. Мы все тестируем достаточно точечно, так что сразу понятно, что вызвало эффект.

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

Pandao — покупай выгодно
Pandao — покупай выгодно
Разработчик:
Цена: Free

Как используем аналитику в дизайне

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

Эволюция корзины покупок

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

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

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

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

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

Где узнать об этом больше

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

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

Комментарии
Продолжить чтение

Дизайн и прототипирование

Дизайн уведомлений для приложений

Шашанк Сахай, продуктовый дизайне в Microsoft Teams, рассказал про различные подходы в  реализации уведомлений внутри приложений и их особенности.

AppTractor

Опубликовано

/

Автор:

TL;DR – в чем смысл:

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

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

Читать: https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

Комментарии
Продолжить чтение

Дизайн и прототипирование

Текст в интерфейсах: проектирование

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

Redmadrobot

Опубликовано

/

Автор:

Привет, меня зовут Оля Сартакова. Я работаю в Redmadrobot и преподаю дизайн мобильных приложений в Британке. Хочу рассказать, как работаю с текстами в интерфейсах.

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

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

1. Понять, кто и в какой ситуации будет пользоваться приложением

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

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

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

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

Давайте разберём пример: проработаем сценарий оформления заказа для приложения доставки пиццы. Наш пользователь — 28-летний Василий. Характер прескверный, не женат. Он живёт во Фрязино, работает в Москве. Сегодня вечер пятницы. Василий после работы выпил немало пива с коллегами. Сейчас он возвращается домой на электричке, в которой не всегда хорошо ловит интернет, и хочет есть.

2. Выписать всё, что может пригодиться

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

С пиццей у меня получилось так.

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

Бизнес (пиццерия) заинтересован в том, чтобы Василий сделал заказ как можно быстрее и оплатил заранее.

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

Если не спросить у Василия время доставки, курьер может привезти пиццу не вовремя и ему придётся ждать под дверью. Про время надо спросить.

Василий хочет оплатить пиццу через Apple Pay, но не все с ними солидарны. Во-первых, не у всех смартфоны поддерживают Apple / Google / Samsung Pay, а во-вторых, при первом заказе люди опасаются предоплат — вдруг вообще не привезут. Получается, что в приложении нужны, как минимум, четыре способа оплаты: Apple / Google / Samsung Pay, картой в приложении, картой курьеру и наличными.

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

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

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

Итого, в форме оформления заказа нужны следующие поля:

  • Имя и телефон клиента.
  • Способ получения заказа: доставка или самовывоз (мы разберем только доставку, потому что Василию нужна именно она).
  • Время доставки: чем скорее, тем лучше, или к указанному времени.
  • Адрес доставки.
  • Способ оплаты.

Так форма будет смотреться на экране. Для начала поделю оформление заказа на 2 шага. На первом проверю, знаком ли нам пользователь, на втором узнаю, как он хочет получить и оплатить заказ.

3. Убираем то, без чего можно обойтись

Лучше не перегружать экран и подбирать максимально лаконичные формулировки. Главное при сокращении — не потерять смысл.

В черновике меня смущают повторы «доставки», «при получении» и формулировка «Способ оплаты» (хоть это и не критично, но выглядит слишком формально). Переформулируем все три подзаголовка в одном стиле, уберем «при получении» из оплаты наличными — всё равно иначе деньги передать невозможно:

Теперь меня смущает только «Укажите адрес». Можно заменить его на подсказку о том, что именно придётся указать:

Я вынесла указание адреса доставки на отдельный экран, чтобы не перегружать текущий.

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

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

Форма получилась большая, но убрать из неё нечего. Что делать?

Один приём мы уже использовали — поделили её на 2 шага. Второй способ сработает при повторном заказе — можно запоминать введённые данные и показывать поля предзаполненными.

4. Заботимся и объясняем

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

Превышен лимит неактивности → Просто верните человека на предыдущий шаг.

Неверный формат данных → Показывайте сразу правильную клавиатуру.

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

Сервер не отвечает →

  1. Если сервер недоступен из-за того, что у пользователя пропало соединение с интернетом, так и говорим → Нет соединения с интернетом. Проверьте настройки сети.
  2. Если сервер недоступен по собственным мотивам, единственный вариант, продумать автоматическое решение проблемы и подсказать, как можно решить её прямо сейчас. → Нет связи с сервером. Не закрывайте приложение, и ваш заказ отправится автоматически, как только мы устраним неполадку. Или позвоните нам по телефону +7 (495) 999-99-99 — и мы оформим заказ.

Неверный номер телефона →

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

5. Перечитываем

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

6. Тестируем на людях

Когда мы довольны результатом, пора проверить интерфейс на целевой аудитории. Лучше всего собрать прототип с нажимаемыми кнопочками в InVision, Marvel или Flinto и дать нескольким людям из целевой аудитории задание пройти целевой сценарий — заказать пиццу с доставкой на дом в 20:00. На что нужно обратить внимание:

  • Легко ли пользователям? Всё ли им понятно?
  • Где у них возникают проблемы? Почему?
  • Нравится ли им тон общения, который вы выбрали?

Что нельзя делать:

  • подсказывать, куда нажать;
  • выражать свои эмоции, когда у человека что-то не получается;
  • задавать вопросы, пока он не закончил.

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

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

7. Определяем правила

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

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

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.