Зміст
- Розробники, а не користувачі
- Клієнти, а не користувачі
- Клієнт-користувач
- Новий інтернет-магазин
- Інвентарний УСП
- Заклики до дії
- Клієнт-користувач болючі точки
- Відсутність змісту
- Брак знань
- Брак ресурсів
- Відсутність інфраструктури
- Створення рішень для клієнта-користувача
- Створіть корисну систему управління вмістом
- Створюйте гнучкі компоненти дизайну
- Створіть розумніше покоління свинців
- Полюбіть дані
- Висновок
«Клієнт - не користувач» - одна з тих запальних фраз, про яку часто говорять у дискусіях та статтях про дизайн, орієнтований на користувача. Іноді формулюючись як "ви не користувач" або "компанія не є користувачем", фраза є простою декларацією, яка охоплює більшу ідею, яка визнає, що бізнес-цілі не є такими, як цілі користувача, і "добре" конструкції спрямовані на покращення досвіду громадського користувача.
Розробники, а не користувачі
На ранніх етапах дослідження та планування орієнтоване на користувача проектування (UCD) зосереджується на користувачах та їх завданнях. Проектування та впровадження, як правило, відбувається за допомогою ітеративних етапів, кожен прототип або випуск підлягає постійному спостереженню та доопрацюванню відповідно до потреб цих користувачів.
Для інженерів та розробників програмного забезпечення орієнтований на користувача дизайн висунув важливу мантру: "Ви не користувач".
Наші внутрішні знання про систему та її інтерфейси заважають нам зрозуміти, як новий користувач може взаємодіяти з продуктом. Певним чином, UCD був благословенням. Знято з нас відповідальність "розробити його правильно з першого разу". З часом навіть емоційний зв’язок та право власності на продукт чи навіть частину інтерфейсу також було знято. Ми будували і проектували речі і випускали їх на публіку, не думаючи, що відправляємо дітей до вовків. Продукту бракувало життя або цінності, поки користувачі не прийняли його, підтверджуючи, що ми правильно інтерпретували лабораторії досліджень та зручності використання.
Отже, розробники продуктів не є користувачами. Але чи означає це, що клієнти також не є користувачами?
Клієнти, а не користувачі
Попрацювавши фрілансером та працюючи в агентстві більше семи років, я, звичайно, розумію твердження: «Клієнт не є користувачем». На етапах планування багато невеликих компаній, які не мали даних про зручність використання - навіть не встановлено Google Analytics - або часу, витрат чи терпіння на тестування користувачів, часто надавали перелік вимог, які, як правило, складалися з його бізнес-цілей.
Мені було доручено "отримати більше потенційних клієнтів", а не "зробити форму запиту більш зручною для користувача". На щастя, цілі користувачів часом можуть бути прив’язані до бізнес-цілей, і в цих випадках не було надто складно аргументувати, наприклад, що ми повинні видалити непотрібні поля адреси та посади, щоб користувачі почувалися впевненіше в заповненні форму (і отримати більше потенційних клієнтів для компанії).
Інший сценарій, коли клієнтом є не користувач, трапляється тоді, коли ви насправді маєте справу не з компанією в цілому, а з представником компанії. Я називаю це тиранією HiPPO (думка найвищого заробітку). Генеральний директор компанії, директор з продажу, рада директорів: люди на цих посадах відчувають, що вони, і лише вони, знають розум замовника, і, отже, вони, і лише вони, можуть приймати рішення щодо потоку користувачів або особливість.
Насправді ці люди перебувають у тій же ситуації, що і інженери та дизайнери; вони занадто задіяні в продукті, щоб знати потреби користувача. Навіть якщо представлені зібрані мною дані показують протилежне, ніщо не може передумати, що функція повинна функціонувати певним чином. Гордість і зарплата диктують дизайн на даний момент, а не потреби користувача.
Але, нарешті, дозвольте мені перейти до суті.
Клієнт-користувач
Клієнти прив'язані до часу, грошей, людей, знань та терпіння. Функція, яку ви знаєте, буде настільки неймовірною для користувача, що повністю покладається на здатність компанії виробляти для нього вміст або наймати персонал для його підтримки. Ось кілька останніх ситуацій, які демонструють мою думку:
Новий інтернет-магазин
- Проблема: Компанія B2B продавала велике, дороге обладнання спеціалізованим малим підприємствам, але продавалась через довгий процес продажу, а не через Інтернет-магазин. Дані показали, що якість його потенційних клієнтів покращилася, коли користувач отримав більше деталей про товари після проведення онлайн-пошуку.
- Рішення: Створіть онлайн-каталог продукції компанії з фотографіями, докладними технічними характеристиками та описами.
- Результат проблеми: Компанія продавала продукцію від багатьох виробників, але не забезпечила партнерських відносин з кожною з них, що включала права або доступ до активів на зображення та копіювання товару.
Інвентарний УСП
- Проблема: Компанія хотіла бути відомою завдяки найбільшому запасу вживаного обладнання для продажу в регіоні, але її поточні списки були розподілені по окремих дилерських центрах у цьому районі. У ньому бракувало даних та центрального способу пошуку.
- Рішення: Надійний Інтернет-каталог використаних товарів, що включає фотографії та основні характеристики, а також їх розташування та близькість до запитуваного користувача.
- Результат проблеми: Було багато місць, деякі з них були краще укомплектовані, ніж інші, і в кожному з них було потрібно постійно фотографувати та вводити дані для всіх своїх товарів.
Заклики до дії
- Проблема: Національна компанія мала пристойний каталог товарів та послуг, укомплектований ціновими та технічними характеристиками, але користувач не закликав до дії.
- Рішення: Ми запропонували додати форму онлайн-запиту на товари та послуги, які не можна було придбати в Інтернеті.
- Результат проблеми: Довідки проводились раніше за телефоном, у місцезнаходженні або безпосередньо через встановлені стосунки з торговим представником. Кожне розслідування оброблялося по-різному в залежності від місцезнаходження, і не було жодної особи, яка б надсилала загальні запити чи направляла їх до торгового представника. Крім того, деякі торгові представники вперто хотіли мати справу лише з потенційними продажами по телефону.
У кожному випадку ми мали дані тестів юзабіліті та опитувань, які в переважній більшості підтверджували потребу у кожній функції. Наша контактна особа в кожному випадку також була в захваті від пропозицій, тому це не було ситуацією з кінцевим користувачем проти HiPPO. Доводити аргумент про необхідність використання цієї функції не було проблемою.
Ми як дизайнери повинні враховувати, що клієнт є користувач. У кожному проекті ми повинні брати до уваги особу «клієнта-користувача», а точніше, менеджера вмісту (або веб-майстра, або будь-якого іншого заголовка). Які їх больові точки? Що ускладнює їм досягнення своїх потреб?
Клієнт-користувач болючі точки
Відсутність змісту
Вміст просто не існує взагалі. Клієнту доведеться найняти внутрішнього або стороннього копірайтера, відеооператора, графічного дизайнера або фотографа, щоб створити необхідні активи.
Брак знань
Особа чи команда, відповідальна за управління сайтом після запуску, не має технічних навичок підтримувати те, що ви задумали. Якщо ви застосували якусь систему управління вмістом, адміністратор або адміністратори не розуміють, як писати HTML, і навіть не мають навичок з’ясовувати, як вставляти зображення, посилання чи відео.
Брак ресурсів
Іноді ресурсів не вистачає персоналу: у клієнта немає нікого, хто може виконувати функції оператора для пересилання загальних дзвінків або електронних листів, менеджер контенту для призначення тем блогу, відділ обслуговування клієнтів для вирішення питань транзакцій в Інтернеті. В інших випадках бракує ресурсу - технологія, необхідна для виконання завдання: обладнання камери та програмне забезпечення для редагування зображень, необхідне для фотографування товару чи персоналу; база даних, стрічка XML або API, що містить інформацію про товар або клієнта; підключення до Інтернету, необхідне для надсилання оновлень із їхнього складу доставки до онлайн-CRM.
Відсутність інфраструктури
У компанії не тільки не вистачає персоналу, необхідного для подолання недоліків вмісту чи знань, а структура компанії в цілому організована таким чином, що певним групам або людям не вистачає підзвітності або основного управління. Філії або дилери працюють самостійно і ведуть постійну боротьбу за владу та важелі впливу. Примушення різних груп до спільної роботи над уніфікованим досвідом для користувача зустрічається вороже чи бездіяльність.
Зустрічаючи всі ці бар’єри, я бачив, як інженери, менеджери з продуктів та дизайнери перевертаються та вирізають запропоновану функцію. "Можливо, ми можемо зробити це в майбутньому", - кажуть вони собі. "Тільки не в цьому випуску". Яке розчарування для публічного користувача.
Створення рішень для клієнта-користувача
Мета створення резервних копій та дизайну для порожніх станів. Іноді запасний варіант може бути таким простим, як «Зображення недоступне» для елемента. В інших випадках вам потрібно кодувати складну серію операторів if / else, які досягають цілі узгодженості шаблонів, але не змушують користувача розчаруватися, постійно натрапляючи на блок відсутнього вмісту. Можливо, для деяких записів у вашому вмісті є живий текст, а для інших - PDF-файли чи відео. Чи можете ви змінити дизайн так, щоб вмістити різні типи носіїв?
Іноді вмісту просто немає для одного запису, як для іншого. Як можна досягти бізнес-мети отримати більше потенційних клієнтів, а також цілі користувача - отримати більше інформації, якщо залишити це поле порожнім? Створіть рішення для цього контексту, наприклад, додайте форму запиту, де користувачі можуть запитувати певні деталі без зобов’язання купувати.
Створіть корисну систему управління вмістом
Рідко, що проект веб-сайту буде розроблений без якоїсь системи управління вмістом, будь то WordPress, Magento, ExpressionEngine або Drupal. Як дизайнер, орієнтований на користувача, турбуйтеся не тільки про те, як інтерфейс здається загальнодоступному користувачеві, але і про те, як інтерфейс функціонує для клієнта-користувача.
Занадто багато разів я бачу інженерів, які відповідають виключно за адміністративний перегляд, і клієнт-користувач залишається незрозумілим щодо того, як додати чи редагувати вміст. З часом публічний інтерфейс постраждає, оскільки клієнт-користувач продовжує не розуміти, як керувати своїм сайтом. Будьте в курсі того, як кодуються ваші проекти, і якнайшвидше визначайте проблеми для клієнта-користувача.
В одному з недавніх проектів наше агентство запровадило ExpressionEngine як систему управління вмістом для національної компанії з меншими регіональними офісами. На національному рівні менеджеру вмісту та її команді було зручно використовувати EE для редагування вмісту. Однак система була надто складною для потреб регіональних бюро та редакторів контенту. Тому ми створюємо спрощений портал та інтерфейс для цих клієнтів-користувачів для управління своїми запасами. Портал також містив навчальні документи, і ми провели тренінг для користувачів при впровадженні.
Інший приклад - коли ми використовували API із наявної інтрамережі клієнта-користувача для динамічного втягування вмісту. Замість того, щоб змусити клієнта-користувача використовувати і розуміти наш портал, ми використовували канал даних інтрамережі для автоматичного імпорту вмісту. Отже, ми змогли обійти проблему навчення нових технологій для досягнення мети.
Створюйте гнучкі компоненти дизайну
Дизайн для майбутніх потреб клієнта-користувача. Наприклад, ви створили шаблон події, який добре протестував загальнодоступних користувачів, але клієнт хоче опублікувати подію наступного місяця, яка має набагато більше додаткової інформації, як-от біографії спікерів та описи семінарів. Створюйте конструкції, які можуть підтримувати їхню зручність та ефективність при додаванні чи видаленні вмісту.
Створіть розумніше покоління свинців
Коли інфраструктура стає проблемою (наприклад, відсутність генерального менеджера з продажу), скоригуйте свій заклик до дії, щоб адаптувати його до потреб клієнта-користувача. Якщо ви збираєте поштовий індекс у формі для створення потенційних клієнтів, використовуйте ці дані, щоб визначити, на яку електронну адресу його надіслати. Традиційні торгові представники, які наполягають, що телефонні дзвінки найкраще ведуть до продажів, використовують відстеження телефонів на кожній сторінці та відстежують дані.
Якщо ви використовуєте CRM, інтегруйте запити або продажі за допомогою веб-сайтів. Принаймні, включайте дані до сповіщень про те, де знаходився загальнодоступний користувач (яка сторінка та геолокація), коли було здійснено дію.
Полюбіть дані
Незалежно від того, вирішуючи, який товар чи категорія потребує кращого вмісту, чи який торговий представник намагається використовувати систему, дані допоможуть вам створити план дій для клієнта-користувача. Подібно до того, як лабораторії користувачів, опитування або фокус-групи можуть допомогти в ітераційному розробці продукту, емпіричні дані можуть допомогти клієнту-користувачеві вирішити, куди далі спрямовувати ресурси в ітераціях розміру укусу.
Відстежуйте, де більшість користувачів бачать резервні або порожні стани, і плануйте календар, для яких продуктів чи категорій потрібен унікальний вміст. Наприклад, замість того, щоб вкладати час і гроші в фотозйомку товару для його каталогу 500+, використовуйте свої дані, щоб з’ясувати, до яких категорій з 20–30 товарів можна звернутися першими.
Якщо у клієнта-користувача виникають проблеми з персоналом або інфраструктурою, використовуйте дані, щоб передбачити, чи слід наймати додатковий персонал для досягнення цілей або для створення дошки лідерів, яка заохочує поведінку навколо відповіді на запити про потенційних клієнтів або продажі.
Висновок
Орієнтований на користувача дизайн - це не битва між публічним користувачем та клієнтом. Навчіться узгоджувати бізнес-цілі з цілями користувачів, а ділові недоліки - з потребами користувачів. Важливо визнати, що інтерфейс - це не просто зовнішній веб-сайт, а й багато інших поглядів: відсутнє зображення, електронний лист, надісланий для підтвердження замовлення, та система управління вмістом для додавання нового інвентарю.
Слова: Рен Уокер
