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