lsp тестирование что это
Влияние протокола языкового сервера (LSP) на будущее IDE
С момента своего появления Visual Studio Code в одиночку так сильно повлиял на экосистему разработчиков, что возврата назад уже не будет. Это общедоступный бесплатный инструмент с открытым исходным кодом и это очень мощный инструмент.
Что такое Протокол языкового сервера?
Это взаимодействие происходит с помощью набора правил, заданных протоколом. Протокол языкового сервера можно рассматривать как урезанную модификацию HTTP взаимодействующую только по JSON-RPC протоколу.
Зачем нужен LSP?
Вы заметили, что в VSCode постоянно появляются изобретательные сообщения об ошибках и предложения автоподстановок? И как же легко, просто установив расширение из магазина VSCode, вы получаете всю мощь IntelliSense для совершенно разных языков, таких как C, Python, Java и т.д.? Все это происходит благодаря LSP.
Поддержка автозавершения и IntelliSense для HTML/CSS/JavaScript идет сразу вместе с VSCode (так же, как PyCharm идет сразу с поддержкой Python). Однако такая же поддержка других языков может быть реализована с помощью протокола LSP для этих языков.
Что такое JSON-RPC?
Это простой пример для JSON-RPC:
В этом примере мы посылаем запрос в кодировке JSON в соответствии со спецификацией RPC. Если сервер настроен на корректную работу с JSON-RPC, то он выполнит метод runThisFunction с переданными параметрами и вернет результат в том виде, как показано выше.
LSP + JSON-RPC
LSP использует JSON-RPC для связи с удаленным сервером. Для этого используется следующий формат:
Почему все это так важно?
С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме M + N.
M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).
N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).
Раньше для того, чтобы M редакторов поддерживали N языков, вам нужно было иметь M*N решений. То есть каждый редактор кода должен был реализовать поддержку каждого языка самостоятельно.
С появлением LSP в редактор оставалось лишь внедрить поддержку протокола языкового сервера. После этого любой, кто делает языковой сервер (следуя стандартам LSP), может легко интегрироваться в редактор кода, при этом редактор никогда не будет «знать», с каким языком он работает!
Будущее IDE
По мере того, как языковые сервера реализуются для различных языков программирования, у разработчиков появляется возможность выбирать редактор на свой вкус. Без привязки к конкретному языку. Нет больше необходимости ограничивать себя, например только XCode для разработки на Swift или PyCharm для Python. И не только это, LSP можно внедрить прямо в JavaScript для поддержки IntelliSense в браузере! Настало потрясающее время для программистов!
Как протокол языкового сервера LSP влияет на будущее IDE
В 2016 году компания Microsoft сделала две очень важные для разработчиков вещи — выпустила редактор Visual Studio Code, который разом изменил всю экосистему для программистов, а также представила протокол языкового сервера LSP. Мы перевели статью сервиса FreeCodeCamp — о том, как LSP меняет будущее IDE, в том числе и Visual Studio Code, и почему этого никто не замечает.
Что такое LSP?
Протокол языкового сервера (LSP) — это способ (или протокол) общения с языковыми серверами, такой же как HTTP или FTP. Языковые серверы — это специальные программы, которые работают на обычных серверах. Они принимают мета-состояние редактора, в котором пишется код: например, где находится курсор в редакторе и на что он наведён прямо сейчас. После анализа они возвращают набор инструкций, какое действие можно выполнить на текущем токене, если пользователь использует специальные сочетания клавиш.
Эта связь происходит с использованием набора правил, определенных протоколом. Протокол языкового сервера можно рассматривать как урезанную версию HTTP, который обменивается данными только через JSON-RPC.
Зачем нужен LSP?
Вы постоянно видите сообщения об ошибках и автопредложения для изменения кода, которые появляются в VSCode? Как так получается, что просто добавив расширение из магазина VSCode, вы получите всю мощь технологии автодополнения IntelliSense для совершенно другого языка, такого как C, Python, Java? Как раз это и происходит из-за LSP.
Поддержка автозаполнения и IntelliSense для HTML/CSS/JavaScript поставляется с VSCode (так же, как PyCharm поставляется с поддержкой Python). Однако такая же поддержка других языков может быть реализована с использованием протокола языкового сервера для этих языков.
Что такое JSON-RPC?
JSON-RPC означает удаленный вызов процедуры JSON. Эта архитектура аналогична архитектуре REST, в которой основной единицей является вызов процедуры, а не конечная точка API, как в случае с REST.
В этом примере мы отправляем полезные данные в кодировке JSON в соответствии со спецификацией RPC. Если сервер корректно настроен для обработки JSON-RPC, он выполнит метод runThisFunction с переданными параметрами, после чего вернет результат, как показано в примере выше.
LSP + JSON-RPC
LSP использует JSON-RPC для связи с удаленным сервером. Это должно соответствовать такому формату:
Почему это вообще важно?
С введением протокола LSP компания Microsoft свела знаменитую M*N проблему к M+N проблеме.
M — это разные языки (C, C ++, PHP, Python, Node, Swift, Go и т. д.)
N — разные редакторы (VSCode, Eclipse, Notepad ++, Sublime Text и т. д.)
Раньше, чтобы редакторы M поддерживали N-языки, нужно было реализовать M*N решений. При этом поддержка языков должна была быть нативной. Сделав это однажды, кто угодно сможет интегрировать поддержку своего языка в редактор кода, даже если тот его «не знает». При этом во время работы с LSP редактор даже не будет знать, с каким языком сейчас работает пользователь.
Будущее IDE
По мере того, как все больше и больше языков переходят на свои языковые серверы, люди получат большое количество редакторов и смогут выбрать наилучший для себя
В будущем пользователям больше не придется использовать только XCode для разработки на Swift, или PyCharm для Python. И не только это, ведь LSP может быть реализован на JavaScript для поддержки прямо в браузере! Прекрасное будущее уже почти наступило!
Как тестировать сайты
Допустим, вы сделали сайт, но у вас нет тестировщика, который может всё проверить. Вот короткая инструкция, на что смотреть, чтобы с большой вероятностью после запуска всё было в порядке.
Когда тестирование полезно
В больших компаниях каждым пунктом из этой статьи могут заниматься целые отделы, сотрудники которых досконально проверяют каждую мелочь — руками или автоматически. Но представим, что сейчас под рукой нет IT-департамента. Что можно сделать самостоятельно и быстро, чтобы проверить, что всё работает как задумано.
Предупреждение: статья не претендует на академическую полноту, но точно поможет что-нибудь не упустить.
Всё посмотреть и прокликать
Сначала нужно проверить, что всё выглядит, как задумано заказчиком — сайт совпадает с макетом, кнопки работают и ссылки ведут, куда нужно.
Что проверять:
Иногда используют автоматические тесты, которые сравниваются отрендеренный результат кода аля интерфейс с рендер-версией приложения. Фактически, это сравнение скриншотов. Конечно, автотесты можно подготовить и для тестирования интерактивных элементов.
Фрагмент реального сайта о том, что тестирование полезно
Инструменты:
Ошибки JavaScript
Если в коде есть ошибки, их будет видно в консоли разработчика. Также там можно обратить внимание на запросы (время и коды ответов) и посмотреть размер загружаемых файлов. И если размер большой, обсудить с разработчиками оптимизацию кода на JavaScript, шрифтов и изображений.
Валидность кода
Нужно убедиться, что код удовлетворяет стандартам HTML/CSS, для этого есть специальные валидаторы. Узнайте, как проверить валидность HTML.
Веб-формы
Формы — кладезь пользовательских данных и одновременно потенциальный источник уязвимостей. Формы должны быть удобными для пользователя и безопасными для сайта.
Что проверять:
Неправильные ссылки
Проверьте, что все ссылки ведут на настоящие сайты и не ведут на 404. Для этого тоже есть несколько инструментов. На главной не должно быть ссылки на главную.
Уберите ссылку на главную с главной
Локализация
Если пользователи сайта говорят на разных языках, сайт локализуют — готовят тексты на разных языках и добавляют переключалку с флагами.
Но недостаточно проверить перевод текстов в интерфейсе, ошибок и документации — есть ещё ряд нюансов. Например, нужно проверить представление дат и времени, поддерживает ли шрифт локальные символы, и есть ли режим RTL для стран, где текст читается справа налево.
Производительность сайта
Пользователи уходят, если сайт грузится медленно. Поэтому нужно проверить, что ваш сайт не такой.
Что проверять
Иногда скорость загрузки зависит от контента, который используется на странице. Вот советы, как его оптимизировать.
Критерии качества
На курсах HTML Academy сайты верстают и готовят к публикации на основе критериев качества — длинного списка правил, который нужен, чтобы делать сразу хорошо. Критерии включают не только то, что написано в этой статье — там гораздо больше мелочей, которые должен знать хороший фронтенд-разработчик.
Делать сразу хорошие сайты
Всё, что нужно фронтендеру — на курсах HTML Academy. Научитесь всему, чтобы у тестировщиков закончилась работа.
Юзабилити-тестирование: как проводить и для чего оно нужно
Любой бизнес завязан на клиентах, и понимание своей аудитории всегда ведет к успеху. Ранее мы рассказывали про анализ трафика аудитории в Яндекс.Метрике и Google Analytics, сегодня же поговорим о другом инструменте изучения аудитории.
Юзабилити-тестирование — это способ оценки интерфейса сайта (или мобильного приложения, ПО) с позиции удобства и эффективности. Для этого приглашаются представители целевой аудитории (респонденты), с которыми очно и удаленно проводится тестирование интерфейса. Затем анализируется обратная связь и формируются выводы о проблемах в проекте.
Почему важно проводить юзабилити-тестирование
В целом юзабилити-тестирование показывает клиентам, что вам важно их мнение и оно может помочь в формировании лояльности к бренду.
Основные этапы юзабилити-тестирования
Чтобы понять, как применять метод, разберемся в основных этапах проведения юзабилити-тестирования.
1. Определение цели
В первую очередь нужно понять, для чего мы проводим тестирование и какую информацию хотим получить. Например, мы пытаемся выяснить, почему сайт приносит мало заказов, или необходимо понять, в какой обстановке клиенты используют приложение, либо же нужно получить обратную связь по новому разделу и т.д. В зависимости от задач подбираются соответствующие инструменты и способы оценки результатов.
При необходимости рекомендуем определить исходные метрики, например, показатель конверсии, количество звонков в месяц, время на сайте, в зависимости от поставленной цели.
2. Определение плана тестирования
На данном этапе конкретизируем нашу цель, например, мы хотим оценить процесс оформления заказа. Предварительно формируем сценарии, по которым, как нам кажется, оформляют заказ пользователи, чтобы на него ориентироваться.
Пример одного из сценариев:
Также стоит рассмотреть варианты, когда пользователь зашел не с Главной страницы, сначала авторизировался, оформил заказ через форму «заказ в 1 клик» и т.д.
Сценарии следует протестировать самостоятельно перед проведением исследования, чтобы пользователи не натыкались на очевидные ошибки, например, неработающую форму заказа или пустой раздел.
Далее, на основе сценариев, готовим задания для пользователей. Необходимо продумать формулировку задания, в каких случаях мы будем считать его выполненным и какие гипотезы мы будем проверять. Например:
Задание: выбор стиральной машины
Описание: вы собираетесь купить стиральную машинку. Подберите и положите в корзину похожий товар.
Критерии выполнения:
Дополнительные вопросы (которые можно задать после выполнения задания):
Следующие задания можно сконцентрировать на странице товара, странице корзины, форме заказа и т.д.
На этапе формирования сценариев и заданий для пользователей хорошо виден объем работ. Рекомендуем не перегружать пользователей и дробить задачи — например, тестирование десктопной версии отделить от тестирования мобильной версии или провести отдельно тестирование для юридических и физических лиц. Это поможет и вам не запутаться в результатах, и провести более качественную оценку интерфейса.
3. Выбор инструментов
Теперь определяемся с форматом тестирования. Существуют модерируемые и немодерируемые тестирования.
Модерируемое юзабилити-тестирование — данное тестирование проводит специалист (модератор): дает задания, следит за ходом проведения тестирования, задает уточняющие вопросы. Дополнительно можно пригласить независимого наблюдателя, который будет также фиксировать результаты.
Плюсы модерируемого юзабилити-тестирования:
Минусы модерируемого юзабилити-тестирования:
Дополнительно модерируемое тестирование можно разделить на очное (когда респондент и модератор находятся в одном помещении) и удаленное (модератор связывается с респондентом по видеосвязи). Более качественную обратную связь дает очное тестирование, но оно более дорогостоящее и времязатратное.
Немодерируемое юзабилити-тестирование — в данном случае вместо специалиста модератором выступает сервис, который в автоматическом режиме дает задания, собирает обратную связь и выдает статистическую информацию.
Специалисту необходимо лишь загрузить шаблоны задания и указать целевую аудиторию (часто такие сервисы сами подбирают целевую аудиторию, но можно привести и своих пользователей).
Какое тестирование лучше выбрать?
Если у вас новый сайт или прототип, то лучше всего начать с модерируемого тестирования. Модератор сможет дополнить недостающую информацию.
Если же у вас уже готовый сайт, то можно начать с немодерируемого тестирования, особенно если бюджет ограничен.
В идеале правильно сочетать модерируемое и немодерируемое тестирование, чтобы получить более полную информацию.
4. Выбор респондентов
Для начала рекомендуем изучить вашу целевую аудиторию и определить основные группы клиентов. Дополнительно рекомендуем проводить тестирование на новых пользователях (видят сайт в первый раз), чтобы в тестировании также участвовала «холодная» аудитория.
Количество респондентов зависит от вида тестирования и количества найденных групп клиентов. Рекомендуем начинать с 5 человек для каждой группы, например, опросить 5 новых посетителей сайта и 5 постоянных клиентов. Если результаты тестирования будут спорными, то вы всегда сможете привлечь дополнительных пользователей.
5. Проведение тестирования и анализ результатов
Перед проведением тестирования важно поговорить с пользователем, объяснить цель исследования и донести, что будут проверяться не его способности, а понятность и информативность интерфейса или прототипа. Обязательно попросите респондента комментировать свои действия. Это поможет вам лучше понять, что происходит в каждый момент выполнения заданий.
На что еще обратить внимание при проведении юзабилити-тестирования?
Старайтесь не задавать наводящих вопросов, не комментировать действия пользователей. Помните, вы сторонний наблюдатель, а не участник выполнения заданий.
Ведите видео- и/или аудиозапись, чтобы была возможность пересмотреть спорные моменты тестирования. И не забываем предварительно взять с респондента согласие.
Записывайте свои мысли, инсайты после проведения интервью или во время просмотра записей. Тестирование — долгий процесс, полезно будет периодически перечитывать свои записи. При респонденте лучше не отвлекаться на записи, так как чаще всего это смущает пользователя.
Для модерируемого тестирование проводите не более 3-х интервью в день. Чем больше интервью, тем больше вы устаете и можете пропустить важные детали.
Структурируйте результаты. Составьте три списка идей: те, что сработали, спорные моменты и то, что не работает. По тем моментам, что вызывают сомнения, отдельно стоит выписать идеи и предложения респондентов.
Не затягивайте интервью. Выделяйте час-полтора на каждого респондента, в целом 5-10 заданий будет достаточно.
6. Внедрение изменений после юзабилити-тестирования
Полученные ошибки и недочеты стоит разделить на три группы:
Серьезные ошибки, когда что-то не работает и это препятствует выполнению сценариев. Сюда же относятся фэйлы, которые приводят к потере больших средств (уходит большой процент клиентов).
Крупные недочеты, которые не всегда мешают взаимодействию с сайтом, но могут отталкивать пользователей — например, долгая загрузка формы.
Мелкие недостатки, которые могут раздражать, но не помешают пользователю выполнить целевые действия. Например, отсутствие сообщения подтверждения после отправки заявки или неряшливая верстка текста.
Конечно же, рекомендуем исправлять все найденные проблемы. Для экономии времени и средств начать стоит с серьезных ошибок, чтобы не терять клиентов.
После внедрения доработок стоит подождать несколько месяцев и повторно замерить метрики, которые определили на этапе формирования цели. Сравниваем результаты и делаем выводы. А затем можно снова начинать тестирование для поиска новых проблем.
Какое оборудование необходимо для проведения юзабилити-тестирования
Для модерируемого очного тестирования лучше выделить отдельное тихое помещение (лабораторию), чтобы посторонний шум не мешал общению, даже если тестирование проводится удаленно.
Минимальный комплект оборудования:
Из ПО понадобится программа для записи видео и аудио, а также приложение для съемки экрана респондента.
Для проведения немодерируемого тестирования рекомендуем такие сервисы, как UXCrowd и Fabuza (Фабрика юзабилити). В каждом из данных сервисов можно бесплатно провести пробное исследование.
Вот пример интерфейса от UXCrowd:
Идеальный сервис для первого тестирования с небольшим количеством респондентов. Много разных типов вопросов, которые можно добавлять в любую часть сценария. Все на русском языке. Есть возможность как набрать респондентов из базы сервиса, так и привлечь своих.
Скриншот из личного кабинета сервиса Fabuza:
Более функциональный сервис, где можно проводить различные виды тестирования (опросы, интервью, тесты баннеров и т.д.) и больше инструментов для анализа данных. Интерфейс также на русском языке. В качестве респондентов могут выступать как ваши клиента, так и люди, подобранные сервисом.
На самом деле сервисов намного больше (UsabilityHub, Loop11, Userlytics, Userfeel и др.), но будьте готовы встретиться с интерфейсом на английском языке.
Заключение
Проведение юзабилити-тестирования поможет вам увидеть, как на самом деле пользователи взаимодействуют с сайтом (прототипом), и позволят лучше понимать ваших клиентов. На основе полученной информации вы не только сможете доработать интерфейс, но и наверняка у вас появятся новые идеи по расширению и улучшению продукта.
Если вам нужна помощь в проведении тестирования сайта, то вы всегда можете обратиться к нам за помощью.
Usability Testing от А до Я: подробный гид
Непрерывный процесс получения и обработки обратной связи от пользователей, а также своевременная реакция на нее — ключ к успеху проекта. Такой процесс необходим при любых сценариях: будь то разработка ПО с нуля или улучшение уже существующего.
Я хотела бы рассказать о том, как эффективно спланировать процесс юзабилити-тестирования и получить качественную обратную связь. Этот материал затрагивает деятельность UX-дизайнеров и будет полезным для продакт-оунеров, продакт- и проджект-менеджеров, а также всех, кто тесно связан с разработкой программного продукта.
Юзабилити-тестирование — это метод оценки интерфейса со стороны удобства и эффективности его использования. Чтобы получить ее, нужно привлечь представителей целевой аудитории программного продукта.
Зачастую юзабилити-тестирование проводится в два этапа: прохождение пользователем N-го количества задач (количественные или качественные тесты), а также беседа, заполнение опросников или глубинные интервью с пользователем (качественное исследование).
Как правило, его стоит проводить, когда уже сформирован интерфейс в виде бумажного или цифрового прототипа либо готовый программный продукт, и вы хотите понять, какие проблемы возникают в работе и насколько продукт соответствует ожиданиям пользователей.
Процесс тестирования занимает в среднем от месяца до трех. Это зависит от множества факторов: наличия разных типов продукта, сложности сценариев и наличия их альтернатив, количества пользовательских ролей.
В проведении юзабилити-тестирования выделим следующие этапы:
Определение цели
В каждом исследовании должна быть цель. Вы должны точно понимать, какую информацию хотите получить. Важно для себя ответить на следующие вопросы:
Создание плана тестирования
Для формирования плана тестирования нужно прежде всего определить:
Для наблюдения я, как правило, готовлю документ для каждого пользователя — дорожную карту, которая рассказывает, что и как делать и на какие вопросы отвечать. Документ называется UX testing plan & script и состоит из таких элементов:
Обычно при формировании задач провожу их декомпозицию. Что это такое? Я заменяю решение одной задачи на серию мелких простых и связанных между собой подзадач с конкретной целью в каждой.
Давайте рассмотрим пример. Сценарий задачи «Как пользователь я могу забронировать понравившийся отель» на самом деле состоит из ряда мелких подзадач:
Сценарии задач должны быть конкретными и отражать реальные потребности целевой аудитории. Не просите потребителя купить мясо, если он вегетарианец.
Не стоит забывать, что задачи для качественных и количественных методов разные. Давайте рассмотрим примеры задач для каждого из них.
Задача для качественных исследований: найдите на сайте отчет за первый квартал 2019 года.
Задачи для количественных исследований:
А. Используя глобальный поиск на сайте, найдите отчет за первый квартал 2019 года.
В. Используя раздел Reports на сайте, найдите отчет за первый квартал 2019 года.
В качественных исследованиях мы поймем пользовательское предпочтение user-flow, а в количественных — разъясним, все ли шаги конкретного user-flow понятны пользователю. Качественные и количественные исследования должны дополнять друг друга, а не противопоставляться.
Как может выглядеть задача, связанная с авторизацией на сервере.
Пример сценария: клиент попросил вас подготовить отчет, и вы хотите начать с поиска информации в рамках сайта www.sample.com.
Задача: пожалуйста, войдите в систему, используя свой логин и пароль.
Стоит заранее прогнать выполнение сценариев на пробной аудитории, чтобы удостовериться в актуальности тайминга сессии и понимании пользователем всех инструкций. Обычно я закладываю в бюджет «обкатку» сценариев с тремя пробными пользователями.
Определение количества исследователей
Для качественного проведения наблюдения необходимо иметь следующие роли:
В первую очередь вы должны любить задачу, над которой работаете, а не ее решение. Только так сможете эволюционировать в проектировании интерфейса конкретной задачи. Далее привлеките три независимых мнения в лице интервьюера, наблюдателя и модератора, которые помогут в спорных моментах разъяснить ситуацию суммарно верно.
Однако не всегда есть возможность вовлечь троих исследователей для каждого сеанса тестирования. Часто функции, перечисленные выше, возлагаются на одного интервьюера, что делает процесс исследования для него тяжелым испытанием.
Если вы проводите тестирование один, лучше всего проводить не более трех тестирований в день с максимальной продолжительностью сеанса 1,5 часа. Если же тестирование выходит за рамки указанного времени, разбейте его на две части.
Определение целевой аудитории
При работе над ПО из узкой предметной области демографических показателей обычно недостаточно. Здесь важно разобраться в ролях и их функциях.
Например, вы работаете над финансовым продуктом и планируете изучить деятельность брокера в рамках создания CLO (collateralized loan obligation) бизнеса на американском рынке. В данном случае нужно понять алгоритмы взаимодействия инвест-банкира с другими финансовыми ролями.
Определиться с целевой аудиторией помогут предварительные опросники. Их создают как в бесплатных сервисах, например Google Forms, так и в платных — SurveyMonkey, Typeform и других.
Расспросите кандидатов об их роде деятельности, территориальной принадлежности, на какие функции приложения они подписаны, если подписка существует вообще. Спросите, как часто и для чего они используют продукт. Если их цели по использованию сервиса совпадают с целями исследования — это ваши люди.
Сопоставив план тестирования и предварительный опросник, вы сможете правильно выбрать потенциальных кандидатов для исследования.
Правила создания таких опросников очень просты:
Задавайте вопросы с градацией, если хотите измерить степень суждения. В основном для этого применяют шкалу Ликерта либо скользящую шкалу. Рекомендую использовать шкалу Ликерта, так как она более удобна для восприятия респондентом. Поскольку во скользящей шкале варианты ответа записаны цифрами и респонденту приходится определять значение оценок самостоятельно.
В случае скользящей шкалы варианты 6-9 принадлежат категории «частично согласен», однако нет возможности понять, чем они отличаются. Здесь стоит избегать большого количества ответов без надобности.
Если хотите узнать, согласен или не согласен пользователь с чем-то, используйте четное количество оценок. Если же вас интересует также нейтралитет — применяйте нечетное количество оценок.
Выборка пользователей зависит от многих факторов:
Другая история получается, если только половина участников сталкивается с определенной проблемой. Тогда нужно как минимум три человека для ее выявления. Однако есть вероятность, что у всех троих проблема не будет проявляться. Придется продолжать тестировать, пока пользователь не обнаружит проблему.
На сегодня есть калькуляторы для вычисления количества пользователей. Они базируются на средней вероятности обнаружения ошибки в одном исследовании. Однако проблема в том, что разные исследователи получают разные показатели этой вероятности. К примеру, Якоб Нильсен в свое время получил значение, равное p=0.31, в то же время исследования Спула и Шредера приводят к результату p=0.16.
Выбор вероятности — это всегда большой риск. Вы можете полагаться на свои исследования и провести расчет своей вероятности или использовать значения p=0.31 для простых сценариев и p=0.16 для сложных и разнообразных, полагаясь на исследования других.
При анализе различных исследований вытекает один бесспорный факт — чем больше пользователей вы протестируете, тем более точные получите результаты. Но что делать, когда вы ограничены количеством конечных пользователей?
До сих пор в мире спорят о том, какое же минимальное количество участников подходит для тестирования. По мнению Якоба Нильсена, это 5 человек, а по мнению Лауры Фолкнер — 10.
Я рекомендую начинать с 5-10 тестирований одного прототипа для проверки гипотез в качественных исследованиях и 10-20 тестирований — для количественных. Если ошибки начинают повторяться, это свидетельствует о том, что выборка пользователей однородная. Также допускается использовать метод итеративных изменений RITE, когда правки вносятся в интерфейс по мере обнаружения проблем. Проводится тестирование одного пользователя.
Если группа исследователей уверена, что понимает суть обнаруженных проблем, то она принимает решение исправлять их или нет. Если же нет, она продолжает тестировать текущий интерфейс, пока суть не будет ясна. После внесения правок тестирование начинается заново. Обычно подход RITE требует 5-6 итераций.
Если же мы говорим о поиске новых идей для развития продукта или нахождения закономерностей поведения, то большая выборка здесь крайне необходима.
Получение пользовательского согласия
Перед началом теста необходимо получить разрешение на участие пользователя в конкретном исследовании. Важно прописать абсолютно все условия, по которым оно будет проводиться (примеры условий ниже). Это будет хорошей страховкой на предмет использования всех данных, которые вы получите в процессе исследования.
Я стараюсь делать в своих наблюдениях видео- и аудиозаписи. Это позволяет максимально точно зафиксировать все ответы и реакцию пользователя на выполнение задач. Как организатор тестирования вы должны всегда уведомлять человека об осуществлении записи в письменной или электронной форме.
Между тем в нескольких случаях у меня был отказ со стороны пользователей на применение каких-либо записей и приходилось документировать сессию вручную.
Я даю свое согласие (название компании) на участие в пользовательском тестировании с использованием ноутбука/веб-сайта. Я проинформирован(а) и понимаю свою роль в проведении исследования. Во время сеанса меня попросят найти информацию или выполнить задачи, используя сайт-прототип, и попросят заполнить анкету после тестирования. Сеанс будет снят, но только для целей записи моих ответов (записи голоса) и для проверки моего поведения (видео), например, что я нажимаю и где на веб-сайте. Мое лицо будет видно интервьюеру и исследователям во время физического присутствия, но не будет присутствовать на видео.
Я понимаю, что информация, которую я предоставляю, предназначена только для исследовательских целей, и что мое имя и контактные данные не будут использоваться для каких-либо других целей и не будут переданы третьим лицам.
Я понимаю, что участие является добровольным, и согласен немедленно задать любые вопросы, которые у меня могут возникнуть.
Я понимаю, что вся информация об исследуемом приложении конфиденциальна и обязуюсь не разглашать людям, которые не являются сотрудниками компании.
У меня было достаточно времени для принятия решения, участвовать ли в этом исследовании.
Я понимаю, что могу принять решение отказаться от участия или прекратить участие в любое время.
В такой шаблон обязательно нужно добавить информацию, как долго будет сохраняться полученная информация от респондента, а также его персональные данные (дает ли он согласие на то, чтобы компания контактировала с ним после проведения опроса, а если да, то для каких целей).
В такой шаблон смело добавляйте: дату и время, адрес проведения тестирования, к примеру, ссылку на виртуальную встречу или физический адрес помещения.
На мой взгляд, получать согласие пользователя нужно всегда, однако есть редкие случаи, когда его можно заменить соответствующим информационным знаком. Например, если необходимо посчитать статистику вошедших и вышедших мужчин и женщин из магазина, можем поместить знак о наблюдении у входа.
Организация доступа
Организуйте доступ к нужному ПО, установите оборудование для записи сеанса. Наблюдение должно проходить в естественной среде для пользователя. Анализ рабочего пространства важен, а в конкретных случаях крайне необходим.
К примеру, вы можете провести наблюдение за работой электромонтера на электрической распределительной подстанции, так как повторить рабочие условия в «лаборатории» будет нецелесообразно и сложно. В ходе исследования вы поймете, какие факторы и как влияют на работу инженера: типы устройств, ПО и его индивидуальная настройка, сезонность, температура, свет, организация рабочего пространства и так далее.
Так в одном из исследований мы выявили, что электромонтер не мог выполнять свою работу на планшете летом, поскольку температура в помещении доходила до 50 градусов и планшет периодически отключался. При работе на открытом воздухе на устройство попадал луч солнца и давал блики, что также мешало выполнению задач. Разрешить ситуацию помогло использование специализированных промышленных планшетов с матовым дисплеем и защитным чехлом, предназначенных для работы при высоких температурах.
В результате анализа реального рабочего пространства вы сможете проверить, подходит ли выбранные тип и конфигурация оборудования в данном контексте или нет.
Бывают случаи, когда нет возможности провести наблюдения в естественной среде, например, из-за сложного получения доступа в периметр или его отсутствия совсем. Тогда убедитесь, что конфигурация оборудования, настройки ПО, а также обстановка максимально похожи на рабочее пространство человека.
Проведение наблюдения
Важный момент во время всего процесса тестирования — наблюдение за пользователем. Существует множество причин, для чего это может понадобиться, но выделим две основные:
Перед началом наблюдения важно объяснить пользователю, какая цель исследования, как оно будет проходить и какая его роль. Важно объяснить, что в процессе тестирования мы не будем проверять его способности, а лишь протестируем прототип системы, чтобы понять, что стоит улучшить.
Во время выполнения задач попросите участников комментировать свои действия и делиться мыслями вслух. Это позволит точнее понять их действия. Не кивайте, если респондент дает правильный ответ и тем более не демонстрируйте отчаяние, если он не справляется с задачей.
Не используйте профессиональные термины в беседе, так как пользователь может не понять, что такое, к примеру, «кастомные контролы», «нативный алерт» или «мегаменю». Слушайте, что он говорит, и употребляйте понятные слова и объяснения.
Избегайте наводящих вопросов. В них содержатся подсказки, и вы можете неосознанно влиять на результаты. Уточните все детали, если человек не понял задачу сразу.
Не спешите сразу делать выводы или записывать за пользователем. Важно уточнять, что он имеет в виду, и верифицировать с ним свои мысли, чтобы точнее зафиксировать ответ.
Видео-, аудиозапись для фиксации ответа не исключает личного протоколирования сессии на случай, если записи потеряются или сотрутся.
Делайте заметки с помощью предварительно подготовленной структуры. В UX testing plan & script обычно использую колонку для записи пользовательских комментариев к каждому шагу сценария. Во время выполнения задач делаю небольшие заметки в виде «прошел/не прошел сценарий», «возникали/не возникали сложности». Эти заметки можно привязать к соответствующим моментам видео, и вы сможете легко вернуться к ним позже.
Просмотрите заметки сразу после наблюдения. Убедитесь, что вы можете разобрать свой почерк, дополните наблюдения, если не успели это сделать.
Если во время тестирования человек отвлекается на исследователя с блокнотом, то в беседе могут возникнуть сложности. Исходя из своего опыта, скажу, что большинство пользователей сбивает с мысли то, что исследователь сразу записывает его ответы во время интервью. Если имеете соглашение на запись — используйте диктофон на телефоне, например в личной беседе. Через пару минут человек прекращает обращать внимание на телефон, начинает погружаться в вопросы, а в конце сессии и вовсе забывает о нем. После интервью сделайте небольшой набросок ответов на бумаге.
Что еще очень важно. Не пытайтесь провести тестирование, если пользователь выбран ошибочно и не является частью целевой аудитории. Например, однажды в предварительном опроснике респондент отметил, что имеет подписку на модуль, который я исследовала. Но в начале тестирования выяснилось, что он им никогда не пользовался и не планирует.
Лучшим решением в данной ситуации был откат на этап определения целевой аудитории и выбор другого человека. Также предварительно стоит доработать неточности в опроснике.
Анализ
Во время анализа обращайте внимания на ситуации, когда пользователь:
Проведите анализ всех пометок, что осуществлялись в протоколах. Если проводились видео- и аудиозаписи, стоит сделать их транскрибацию. Это позволит в дальнейшем быстро находить нужные цитаты людей, определять облака слов для составления диаграммы сродства — определение количества тех, у кого возникли одни и те же проблемы.
Используя метод RBT, а также диаграмму сродства, вы сможете выявить похожие проблемы, сильные стороны интерфейса и общие предложения пользователей.
Метод RBT состоит из следующих показателей:
Составление диаграммы сродства — процесс группирования по значимым признакам наблюдений и выводов исследования, на которые проектировщики интерфейсов опираются во время разработки продукта.
Как это делается? Мы анализируем первую задачу одного пользователя и фиксируем конкретные замечания и цитаты на стикерах. На каждом стикере написаны имена участников. Размещаем их на стене или доске. Далее следующий пользователь вносит свои данные. После нескольких тестов появляются общие вопросы и проблемы.
Затем содержимое записок объединяют в группы по родственному признаку, а потом из групп формируют темы. Множество красных стикеров в одной категории будет указывать на то, что у нескольких человек возникли одни и те же проблемы.
Задайте рейтинг найденным проблемам (Thorn) по шкале:
В процессе анализа также будьте готовы получить интересные факты, которые не были связаны с тестирующими сценариями. Например, при тестировании сценария «создание чата» в Microsoft Teams веб-версии вы поймете, что у пользователя несколько разных рабочих аккаунтов. Ему приходится быть авторизованным в системе под разными аккаунтами в разных вкладках браузера. Сделать такое в desktop-версии невозможно, соответственно, вы получите новый инсайт о том, как пользователи с разными учетными записями «решают» эту задачу, используя ваш продукт.
При анализе обратной связи стоит задуматься над такими вопросами:
Заключение
С четкой целью исследования, правильными задачами, тщательно сформулированными вопросами вы сможете в полной мере собрать интересные советы и критику в адрес продукта, а также приоритизировать план задач по его улучшению.
Анализ и обнаружение ошибок — это всегда субъективный процесс. Те результаты, к которым придете, — это исключительно ваше понимание ситуации. Поэтому чем разнообразней будете подбирать команду исследователей, тем разностороннее истолкуете суть проблемы.
Однако не стоит забывать, что, решая проблемы, вы снова столкнетесь с необходимостью их протестировать. По сути это бесконечный процесс. Но такой подход позволит убедиться на практике, сработало ваше решение или нет.