Содержание
Мобильные офлайн-возможности могут расстраивать пользователей. Вы в поезде пытаетесь открыть статью, которую читали этим утром, но не успели дочитать. Вы загружали его раньше, и у вас даже есть две полосы обслуживания. Однако он просто не открывается. Ваш телефон думает, что он в сети, но на самом деле это не так. Ты не в сети.
То, что вы испытываете изо дня в день по-разному, - это проблема, которую мы все приняли как стандарт, но не видели того, чем она является на самом деле: фундаментально ошибочный опыт.
Независимо от того, являетесь ли вы производителем или потребителем технологий, мы не ожидаем, что что-то будет работать в автономном режиме, и десятилетия необходимости постоянного подключения к Интернету заставили нас не замечать эту проблему.
Таким образом, поддержка офлайнового опыта требует внимания к негативному пространству, которое мы не знали, чтобы искать, пока Алекс Фейерке не познакомил нас с концепцией офлайна первым.
Сначала офлайн
Автономный - это любой сценарий, в котором пользователь ищет информацию или функции, не имея доступа к поддерживающей внешней сети. Это может происходить из-за низкой пропускной способности, отсутствия подключения к Интернету, сбоев сервера или множества других причин.
На первый взгляд может показаться, что проектирование для работы в автономном режиме - это так же просто, как сообщить пользователям, что они не могут получить доступ к приложению или что любые новые данные, которые они вводят, будут потеряны, но этот подход далек от того, что возможно с помощью современных технологий.
Вместо этого мы должны рассматривать это как возможность создать «развернутое» приложение, которое будет настолько же полнофункциональным в автономном режиме, насколько и в режиме онлайн; смешение экспериментальной границы между нативными и веб-приложениями.
Методология offline first направлена на то, чтобы обдумать эти переживания, рассматривая их как нечто большее, чем заплатку. Он рассматривает автономное состояние как проблему доступности, а доступность - как центр продукта.
Он сочетает в себе то, что мы извлекли из опыта в первую очередь мобильных устройств, и адаптивного дизайна, с упором на проектирование в самых ограниченных средах (в автономном режиме) и рассмотрением возможности подключения как прогрессивного улучшения.
Теперь у нас есть автономный Pokedex, инструмент с открытым исходным кодом для больниц в развивающихся странах с HospitalRun, Offline Gmail и даже браузерные игры, такие как 2048, которые могут работать полностью без подключения к Интернету.
Разработчики доказали концепцию автономного дизайна и теперь сумели реализовать с ее помощью реальную ценность.
Уловка
Это круто, но, к сожалению, с такими вещами всегда есть загвоздка. Офлайн-шаблоны UX сохраняют двусмысленность и часто вызывают больше экзистенциальных вопросов, чем мы начали. Вопрос о том, что мы можем (и должны) делать в отношении автономного состояния, похоже, никогда не получает лаконичного ответа, и огромное разнообразие интернет-программного обеспечения, которое нам поручено разработать, определенно не облегчает нашу работу. .
Это не означает, что в этой области не было каких-то интересных разработок, и сейчас формируется фундамент того, какими могут быть первые офлайн-приложения.
С большинством нецифровых продуктов, направленных на улучшение качества нашей жизни, мы имеем невысказанное и точное понимание полного состояния системы. Мы видим, что настольная лампа горит или ящик стола открыт. Мы можем почувствовать запах печенья или почувствовать тепло печи во время ее работы. Если бы мы не чувствовали состояния с некоторыми из этих объектов, это могло бы иметь последствия в реальном мире.
В программном обеспечении такие индикаторы состояния, которые естественным образом регистрируются нашими чувствами, не приходят с территорией. Состояние является ручным, и его сложно сформулировать, и чтобы его хорошо выразить, мы должны уделять должное внимание среде, в которой используется продукт (или ее непредсказуемости), и работать с шаблонами проектирования, которые наши пользователи легко понимают (или могут легко полагаться на них). ).
Хороший дизайн - это не только контекст и надежность, но и простота и удовольствие от его использования. Создание правильного дизайна начинается с понимания контекста и мотивации наших пользователей.
К счастью, когда мы думаем об офлайн-опыте, мы уже в правильном настроении. Мы начали с полного отсутствия связи как нашего контекста и постараемся обеспечить ценность в этих условиях. Однако для этого нам нужно увидеть больше картины. Наши пользователи могут быть офлайн и:
- Запись медицинских данных пациента в полевых условиях
- Чтение в поезде на работу
- Пытаться загрузить фотографию в социальные сети во время отпуска в пустыне (и бороться с гиеной)
Следующие - и часто более сложные - шаги заключаются в том, чтобы понять, какова мотивация каждого использования, а затем связать эти мотивации с контекстами, которые мы обрисовали. Отсюда мы можем выбрать из этих муфт те, которые больше всего выиграют от нашего внимания при проектировании.
Понимание взаимосвязи между мотивацией и контекстом позволяет нам лучше понимать и обслуживать наших клиентов, но также может дать ответы на более общие вопросы о продукте.
Затем мы можем записать контекст и мотивацию в форме истории работы, формы пользовательской истории, которая сосредоточена вокруг контекста и мотивации. Для фармацевта, чья система выполнения рецептов зависит от Интернета, мы могли бы написать одну из следующих историй работы:
- Когда клиент хочет что-то купить, а я не в сети, я хочу иметь возможность в любом случае получать платеж, чтобы мы могли продолжать обслуживать клиентов необходимыми им лекарствами.
- Когда я не в сети и отмечу, что рецепт клиента выполнен, я хочу знать, что система выполнит эту функцию при повторном подключении, чтобы мне не приходилось повторять свои действия и записывать выполнение где-то еще.
Каждая из этих историй представляет собой краткую подробную цель, которая позволяет исследовать команды разработчиков и разработчиков продукта. Они помогают нам в открытии правильного дизайна и хорошо служат при проектировании для работы в автономном режиме.
При правильном понимании контекста и мотивации станет легче судить, какие взаимодействия и пользовательский интерфейс будут эффективными для наших пользователей.
Следующая страница: Модели взаимодействия и примеры автономного UX-дизайна
