Кажуть, що "заднім розумом усі міцні". Це правда. 10 років тому я переключився з графічного дизайну на UX-дизайн, до цього пропрацювавши 10 років у друкарнях і на виробництві. Це була неймовірна подорож, але є багато речей, які я хотів би дізнатися раніше. Я вибрав 30 найважливіших і ділюся ними з вами, сподіваючись, що ви зможете уникнути багатьох підводних каменів, з якими я зіткнувся, і станете ще ефективнішими в поліпшенні життя користувачів, ніж я. Бо ми всі виграємо, коли хтось із нас стає кращим.
Я розбив ці уроки на 3 категорії: ремесло, пошук роботи та робота із зацікавленими сторонами. У кожній категорії по 10 уроків. У цій статті я зупинюся на ремеслі.
Ремесло означає вміння проявляти особливі навички у виготовленні чого-небудь. "Майстри" часто по багато років відточують своє ремесло. Вони вкладають частину своєї душі в усе, що роблять. Раніше учні часто працювали під керівництвом "майстрів-ремісників", щоб вивчити і практикуватися в обраній ними професії, перш ніж починати працювати самостійно. Думаю, ця цитата про ремесло чудово передає суть:
"Думаю, що слово "ремесло" має певну вагу. Усі види учнівства, що існували до сучасності, показують нам, що ми повинні розглядати свою роботу як відображення самого себе. Якщо ви працюєте з особливою увагою до деталей, то вам обов'язково слід розглядати цю роботу як майстерність. Якщо в коктейль вкладено чимало людино-годин, вивчення та роздумів, то, можливо, його слід визнати ремісничим коктейлем. Однак справа не тільки в тому, чи всі інгредієнти натуральні. Я думаю, що "ремесло" - це посилання на характер працівника і турботу про нього, а не тільки на якісні інгредієнти".
— Kala Alaeye Danae Ellis
UX-дизайнери теж застосовують "ремесло" у своїй роботі. Ми витрачаємо багато годин (іноді сотні), намагаючись зрозуміти користувачів і поліпшити їхнє життя певними способами, які збільшать дохід, утримання, прибутковість або прилипливість. Для цього ми співпрацюємо з безліччю інших людей. Ми працюємо в умовах безлічі обмежень. Кожен дизайнер унікальний і вносить неповторний відбиток у свою роботу.
Нижче представлено 10 найкращих уроків, що стосуються UX ремесла, які я отримав за останні 2 десятиліття.
УРОК №1: Немає єдиного процесу проектування, лише набір UX-інструментів
© Andrey Popov - stock.adobe.com
Кожен має з чогось починати, тому, коли ми навчаємо студентів UX дизайну, ми багато говоримо про "процес проектування". У багатьох книжках описуються кроки, наче при проєктуванні в реальному світі все ще використовується каскадна модель розробки (Waterfall). Це змушує багатьох дизайнерів зіткнутися з труднощами, коли вони потрапляють у реальний світ, і в них немає часу на техніку, яку вони вивчили в школі дизайну або використовували на попередньому місці роботи.
Однак правда в тому, що не існує єдиного "процесу проєктування". Є тільки інструменти та методи. Великі дизайнери знайомі з десятками різних підходів і підбирають відповідний інструмент для потрібної ситуації. Якщо ви перестанете розглядати тестування юзабіліті, вайрфрейми, карти подорожей, діаграми ментальних моделей, користувацькі інтерв'ю, мозковий штурм, прототипи високої точності тощо, як кроки в жорсткому процесі, ваше життя й ефективність роботи значно покращаться.
Природно, цього важче навчити, тому такий підхід рідко викладають у школах. Щоб зрозуміти, в якій ситуації який інструмент витягнути (а який не слід), потрібен час, але ви можете почати вчитися просто зараз. Знайдіть новий метод, з яким ви не знайомі, і поекспериментуйте з ним. Потім наприкінці проєкту знайдіть іншого дизайнера, зацікавлену або довірену особу і проведіть "розтин" або ретроспективу виконаної роботи. Визначте, що спрацювало, що ні і що ви б змінили наступного разу. Подумайте, чи була проблема в інструменті або в СПОСІБІ його використання. (Молоток був би не дуже ефективним, якби ви не тримали його за ручку - те ж саме стосується і UX-інструментів).
Можливо, ви не часто використовуєте кожен інструмент, який ви вивчаєте. Проте, БУВАЮТЬ ситуації, коли одні інструменти корисні, а інші ні. Навмисні експерименти допоможуть вам зрозуміти різницю. Якщо вам потрібна порада з підбору інструментів, для початку подивіться ці чудові списки UX методів , методів дослідження користувачів та ефективних технік мозкового штурму.
УРОК №2: Дослідження важливі, але не мають великого значення
© Rawpixel.com - stock.adobe.com
Так багато нових (і навіть досвідчених) дизайнерів відчувають страх сцени в день тестування. Ми нервуємо, бо знаємо, що дослідження важливі. Проте більшість із нас часто щотижня представляють свою роботу членам команди та іншим зацікавленим сторонам, щоб отримати фідбек. Дослідження нічим не відрізняються. Ми просто розмовляємо з людьми.
Просто потрібен значний зсув у ментальній моделі. Якщо ви нервуєте під час дослідницьких сесій, просто уявіть, що ви розмовляєте зі старим другом або колегою за обідом. Готуйтеся, але не заглиблюйтеся занадто глибоко. Це просто розмова друзів. Це проста концепція, але її вплив не можна недооцінювати. Вона може вплинути на те, наскільки ефективно і як часто ви проводите дослідження. Цей урок особливо актуальний, якщо ви, як і я, вважаєте себе інтровертом. (Існує багато інтровертів серед UX-дизайнерів і дослідників).
Інша порада, яка має допомогти, якщо ви нервуєте перед (або під час) дослідницької сесії - проводьте їх регулярно. Якщо дослідження перестануть бути "особливим явищем", то вони здаватимуться менш важливими. Намагайтеся взаємодіяти з клієнтами щотижня. Примусьте людей прийти і поспостерігати. Зробіть так, щоб ви з нетерпінням чекали досліджень і раділи їм.
УРОК № 3: Дослідження користувачів - це радше знайомство з користувачами, ніж тестування дизайну.
Коли я тільки починав займатися UX (як і більшість дизайнерів того часу), я думав, що дослідження користувачів пов'язані з "тестуванням" дизайнів перед їх запуском у виробництво. Я розглядав юзабіліті-тестування як свого роду гарантію якості, щоб переконатися, що ми вирішуємо потреби користувачів. У такого підходу є кілька проблем:
- Ви ніколи не зможете протестувати статистично значущу частину своїх користувачів. (Тож це не може слугувати ефективним "тестом").
- Незважаючи на те, що ми намагаємося проводити дослідження "рано і часто", якщо ми розглядаємо дослідження як "тестування", воно за своєю природою є реактивним. 3) Справжня цінність дослідження користувачів полягає в навчанні, а не в тестуванні.
Ви, ймовірно, захочете спростувати цю ідею. (Я теж хотів спочатку). Але якщо ви позбудетеся своїх упереджень і подивитеся об'єктивно, то зрозумієте, що вже знаєте, що це так.
Більшість UX-фахівців завжди прагнуть до загального розуміння, навчання у користувачів, важливості спостережень і всього іншого. Проте, спостереження за користувачами виключно в рамках щойно придуманих нами дизайнів змушує нас випускати з уваги всю суть.
Розглянемо цитату Джареда М. Спула з його статті "Фундаментальний зсув у юзабіліті-тестуванні":
"Справжня цінність користувацьких досліджень полягає в тому, що ми краще розуміємо, хто наші користувачі. Команда розробників продукту або сервісу повинна краще розуміти своїх користувачів під час кожного дослідження, кожного інтерв'ю і кожної взаємодії з ними. Вони мають постійно поглиблювати своє розуміння того, що потрібно цим користувачам, і контекстів, у яких вони працюють.
Можна сказати, що юзабіліті-тестування, у кращому разі - це стартовий наркотик. Але якщо ми зосередимося тільки на пошуку проблем, а не на тому, щоб більше дізнаватися про користувачів, ми ніколи не зможемо привернути увагу наших команд до найважливішої цінності дослідження користувачів.
Замість цього ми закріпимо в їхніх головах ідею, що дослідження користувачів - це всього лише різновид QA тестування. Що йдеться про пошук помилок, а не про створення продуктів із досконалішим дизайном, які дійсно відповідають потребам користувачів, якими б вони не були.
Нам потрібно відійти від мислення пошуку проблем. Команди, які знають про користувачів усе можливе - це ті, які надають продукти та послуги з найкращим дизайном. Це та зміна мислення, яка нам потрібна".
- Джаред Спул, засновник школи дизайну User Interface Engineering & Center Center
Я переконався, що це правда. Що більше ви розумієте користувачів, то правильніші дизайн-рішення ви можете приймати, і то менше вам потрібно "тестувати". Це тому, що ви більше не робите припущень, а приймаєте рішення, ґрунтуючись на знаннях. Це не означає, що ви коли-небудь зможете припинити дослідження користувачів, тому що завжди є чому вчитися, але ви можете зосередити свої дослідження на тому, щоб бути більш проактивними. Це також значнополіпшує міжфункціональні відносини, оскільки більшість проблем юзабіліті вирішуються на ранньому етапі та завдяки більшій єдності між міжфункціональними членами команди.
УРОК №4: Ви не можете (і не повинні) досліджувати все
Багато UX-фахівців відчувають стрес, оскільки більшість коледжів і навчальних таборів переконує, що дослідження життєво важливі. Це правда, дослідження дуже важливі для отримання відмінного досвіду. Ми всі повинні розуміти завдання і результати, яких намагаються досягти наші клієнти (а також те, що заважає їм досягти цих результатів).
Проблема виникає, коли ми сприймаємо це, ніби ми повинні досліджувати все. Ідея, що ми не можемо запускати код у виробництво без його юзабіліті-тестування або почати розв'язувати проблему без опитування користувачів, несумісна з реальним світом бізнесу. Крім того, ціна помилки не завжди однакова. Деякі речі можна протестувати в продакшені. Інші взагалі не потрібно тестувати, бо їх уже визначили наявні дані або дослідження. Як уже було сказано, справжня цінність дослідження в будь-якому разі полягає в проактивному розумінні клієнтів.
Це призводить до ситуацій, коли ви починаєте з підкріпленого даними припущення про те, що вплине на клієнтів. Ми повинні витрачати свій час на вивчення тих речей, помилка в яких призведе до провалу всього проєкту. Через це я дізнався 2 важливих підходи корисних, коли у вас менше часу на дослідження, ніж хотілося б.
Розставте пріоритети у своїх дослідженнях
Оцініть кожну мету дослідження за тим, наскільки ви впевнені / не впевнені у своїх припущеннях І / АБО наскільки великим буде вплив, якщо ви виявитеся неправі. Змініть порядок у списку і вирішіть, на що у вас є час, а на що немає. Якщо у вас немає часу на щось важливе, у вас є вагомі аргументи, чому вам потрібно більше часу. З мого досвіду можу сказати, якщо потрібен компроміс, найчастіше це оцінювальне "тестування", яке в кінцевому підсумку поступається місцем відкриттю або "генеративному" дослідженню для формування ваших проєктів.
Складіть план дослідження як перший крок будь-якого дослідницького проєкту
Мене завжди дивує, як багато дизайнерів, яких я зустрічаю, проводять свої дослідження, але ніколи не сідають за створення формального плану дослідження. План дослідження має безліч переваг, зокрема:
- Команда буде в курсі, що ви збираєтеся вивчати, на які питання ви хочете отримати відповіді і який метод допоможе вам у цьому.
- Ви формуєте мету, на яку можна орієнтуватися, коли ваше дослідження буде завершено, щоб показати його цінність.
- Це допоможе вашому дослідженню бути більш сфокусованим, що призведе до глибшого розуміння.
- За необхідності може виявитися великою підмогою в забезпеченні фінансування досліджень.
Основна ідея полягає в тому, щоб визначити мету, припущення/питання, метод, учасників, ролі, сценарій і підхід (та необхідний бюджет). В Інтернеті є безліч ресурсів про створення планів досліджень, але якщо вам потрібна ідея для початку, я описую процес, якого дотримуюся для створення планів дослідження користувачів, і надаю односторінковий шаблон плану дослідження у своїй статті тут.
Якщо ви змиритеся з обмеженнями за часом на дослідження, ви відкриєте шлях до інновацій. Це сфокусує ваше дослідження і зробить вас більш ефективним. Це також допоможе вам переконати керівництво в тих ситуаціях, коли вам дійсно потрібно більше часу для дослідження. Можливо, найголовніше, це допоможе вам менше нервувати, стати щасливішими і працювати в команді з вашими діловими партнерами.
УРОК № 5: Забезпечте баланс між потребами бізнесу та результатами користувачів
© Андрій Яланський - stock.adobe.com
Можливо, одна з найбільших проблем, з якими стикаються дизайнери - це очевидний конфлікт між бізнес-потребами та результатами користувачів. З одного боку, зацікавлені сторони (часто керівники відділів продажів, фінансів або продуктів) висловлюють думку, що ми повинні зосередитися на задоволенні потреб тих, хто оплачує рахунки - наших "клієнтів". Проблема в тому, що підхід, який вони часто застосовують, полягає в тому, щоб просто прийняти запити функцій і підписати технічне завдання (Statement Of Work), перш ніж з ким-небудь проконсультуються. Часто вони більше орієнтовані на функції, а не на проблеми.
З іншого боку UX-фахівці, зазвичай вважають, що ми повинні вирішувати проблеми користувачів. Хороший UX - хороший бізнес. Ми бачимо сотні необхідних змін, щоб покращити життя користувачів. Проблема, яку бачать у цьому керівники бізнесу, полягає в тому, що найчастіше рахунки оплачують не користувачі, тому такий підхід їм не підходить.
Отже, яка точка зору найбільш ефективна? Одним словом: обидві.
Можливо використовувати потреби клієнтів для визначення проблем, які необхідно розв'язати, але робити це таким чином, щоб поліпшити життя користувачів. Це вимагає, щоб керівники бізнесу визначали проблеми, які необхідно розв'язати (результати) для команди, що виконує роботу, а не конкретні функції. І, щоб UX-фахівці зосередилися на поліпшенні життя користувачів тільки тією мірою, якою це допоможе досягти бажаного результату. (Все інше може почекати).
Це окрема стаття - і я розповім про це докладніше в другій частині, але я хотів би згадати ще одну річ: якщо ви зіштовхнулися з цією проблемою, я б порадив припинити спроби переконати зацікавлені сторони допомогти вам у розв'язанні ваших проблем і почати показувати їм, як ви можете допомогти їм у розв'язанні їх проблем. Дізнайтеся, на чому вони зараз найбільше зосереджені, і знайдіть спосіб стати частиною вирішення.
УРОК № 6: Уміння стисло подати і "продати" продукт - критично важливі навички ДИЗАЙНУ
Подобається вам це чи ні, але здатність "просувати" і "продавати" свої ідеї є важливою частиною роботи дизайнера. Коли я починав займатися дизайном, я недостатньо добре розумів, що моя робота полягала не тільки в тому, щоб створювати чудовий дизайн, а й у тому, щоб пропонувати чудовий досвід (або, іншими словами, покращувати результати для моїх клієнтів).
Коли ви розглядаєте свою роботу як доставку, весь ваш світогляд змінюється. Ви розумієте, що кожна взаємодія з членом команди, кожен огляд дизайну, кожна демонстрація - це шанс продати цінність того, що ви намагаєтеся зробити. Шляхом ВЕЛИКОГО числа спроб і помилок я виявив, що найвигідніше продавати мету, яку я намагався досягти в конкретній ітерації дизайну, тож якщо в когось є інша ідея, як я можу досягти тієї самої мети, про яку я, можливо, не подумав, вони можуть поділитися нею.
Ще один спосіб навчитися "продавати" і доставляти чудовий досвід - це навчитися розповідати історії. Люди зазвичай не запам'ятовують факти і цифри, але пам'ятають історії. Особливо, якщо їх уміло розповіли. Використовуйте розповідну структуру з сюжетною аркою, і зробіть презентацію такою, що запам'ятовується. Якщо ви презентуєте дизайн групі зацікавлених осіб, за можливості використовуйте історії реальних людей з вашого дослідження, їхні обличчя, відео та цитати.
У коледжі в мене був професор, яка викладала після дуже успішної кар'єри у світі бізнесу. Одного разу вона сказала мені, що письмове або усне спілкування, або і те, і інше відігравали важливу роль майже в кожному підвищенні, яке вона отримувала. Це одна з причин, чому я намагаюся писати якомога більше на професійні теми. Щоб відточити будь-яку навичку, потрібна практика. Продаж і спілкування нічим не відрізняються.
УРОК № 7: Зосередьтеся на методах, а не на софті
Одна з найбільших помилок, які я бачу у дизайнерів - і її дуже легко зробити - це те, що вони плутають "інструменти" з "програмним забезпеченням". Частково в цій тенденції я звинувачую школи, а частково - рекрутерів. Набагато простіше навчати програмного забезпечення за допомогою безлічі методів проєктування і досліджень, і багато рекрутерів запитують, "які програмні пакети" знають кандидати, тому що це логічний еквівалент мов програмування для розробника. Але такий підхід вкрай помилковий.
Хороший дизайнер може розв'язувати завдання дизайну на серветці так само добре, як і в новітній програмі. Думаю, що дізнавався про новий програмний пакет (або кілька) у кожній компанії, в якій коли-небудь працював. Це дуже мало вплинуло на мій підхід до дизайну. Усе тому, що проблеми вирішує мислення, а не інструмент, який ви використовуєте для створення макетів.
Пам'ятаю, як був здивований на початку своєї кар'єри, коли дізнався, що приблизно 80% зусиль із розроблення було "проектуванням" коду - або, іншими словами, з'ясуванням того, як підійти до реалізації конкретної проблеми. Щойно вони це зрозуміють, написання коду стане простим для всіх, окрім розробників-початківців junior розробників.
Дизайн нічим не відрізняється. Вам буде набагато краще витратити час на експерименти з методами проєктування і дослідження, розуміння ваших користувачів і розвиток багатьох інших навичок, згаданих у цій статті, ніж на вивчення новітнього софту. Будь-який хороший UX-лідер буде припускати, що ви вже знаєте або можете вивчити програми, водночас ви знаєте, як розв'язати складну проблему проєктування зі списком обмежень, очолити дослідження, згуртувати команду навколо вашого, заснованого на дослідженнях, бачення та переконатися, що бажаного для клієнтів результату було досягнуто. Це набагато складніше і важливіше.
Просто пам'ятайте, успіх = результат, а НЕ мокапи.
УРОК №8: Не існує єдино правильного способу щось зробити
© New Africa - stock.adobe.com
Я витратив так багато часу, намагаючись докорінно змінити спосіб ведення бізнесу в компаніях. Ви чуєте на конференціях кейс-стаді або презентації про Scrum, або Kanban, або Lean UX, або дизайн-мислення, або дизайн-спринти, або Jobs To Be Done, або модель Spotify, або SAFe, або OKR, тощо, тощо. І ви негайно спробуєте змусити свою команду або організацію змінити підходи, що використовувалися протягом багатьох років. Коли ваш досвід у реальному світі не відповідає грандіозному баченню, яке намалював доповідач на конференції (або автор статті), ви надзвичайно засмучуєтеся і переконуєте себе, що ваша компанія просто не "розуміє" цього. Потім ви переходите в іншу компанію, і цикл повторюється.
Чому? По суті, це та ж сама причина, через яку ви не можете просто сліпо застосовувати патерн дизайну, який вам подобається в Apple, Google, Microsoft або Facebook. Це була їхня відповідь на їх проблеми, а не ваша.
Джо Натоли однажды сказал:
"Той, хто говорить вам, що ви зможете радикально змінити основні процеси компанії - за допомогою заплутаних, пропрієтарних UX методологій, які потребують більше часу, більшого бюджету і повноти повноважень - Бреше вам.
Візьміть частини з кількох підходів, які працюють для ВАШОЇ ситуації, ВАШИХ користувачів, ВАШОГО клієнта, ВАШОЇ організації, і відмовтеся від усього іншого.
Не існує єдино правильного способу зробити ЩОСЬ-ЯКЕСЬ".
- Джо Натолі, Give Good UX
УРОК № 9: Дизайн-системи мають підтримувати, а не примушувати
© ZinetroN - stock.adobe.com
Це одна з множинимножинипричин, через які багато хто з нас помиляється, коли вперше створює дизайн-систему. Дуже заманливо спроектувати бібліотеку компонентів таким чином, щоб забезпечити повну узгодженість, але такий підхід зазвичай призводить до такої жорсткості, що інші дизайнери ніколи не дотримуються шаблонів так, як вам хотілося б. Якщо система занадто жорстка, вони можуть взагалі не використовувати її.
Суперечка, який підхід обрати для дизайн-систем, триває, але врахуйте таке: я сам створив 3 дизайн-системи, і розмовляв із розробниками дизайн-систем у 10 із 50 компаній зі списку Fortune - і усі вони дали мені однакову відповідь на запитання "Що б ви зробили інакше, якби ви могли створити її заново?" Безсумнівно, ця відповідь була: "Я б більше зосередився на можливості, а не на узгодженості".
Дизайн-система - це продукт для створення інших продуктів, і, як і будь-який продукт, вона має працювати для своїх користувачів і потребує досліджень. Багато дизайн-систем нагадують мені старі пакети для редагування фотографій, випущені Microsoft у 1990-х роках, у спробах конкурувати з Adobe Photoshop, який багатьом здався занадто складним для вивчення. Так чому ж усі ці програми застаріли і забуті, тоді як Photoshop процвітає? Тому що вони були занадто жорсткими. В ім'я простоти вони забрали всю ефективність з рук користувачів. Багато сучасних дизайн-систем роблять теж саме.
Перша річ, про яку забувають багато творців дизайн-систем, - це те, що існує безліч різних підходів до проєктування і безліч різних варіантів використання (особливо дизайн-систем для корпоративного програмного забезпечення). Узгодженість можна легко підтримувати, поки компанія або відділ, що використовує її, невеликі, але щойно ви спробуєте масштабувати її для кількох команд і технічних стеків, вона розвалиться, якщо не буде гнучкою. Дизайнери та розробники хочуть відчувати підтримку, а не обмеження.
УРОК №10: Завжди ставте під сумнів усе і дійте навмисно
Цей урок, мабуть, найважливіший з усіх. Найпотужніший інструмент в арсеналі UX-дизайнера - це запитання "чому"? Це те, що багато хто з нас дізнається надто пізно, коли в розпачі висмикує волосся. Той факт, що той, хто перевершує вас на кілька рівнів, просить вас зробити щось, не означає, що у вас немає повноважень ставити йому запитання.
Основне завдання UX-дизайнера або лідера - втішати тих, хто страждає, і виводити із зони комфорту. Одна з моїх улюблених фраз, які я використовую, щоб пом'якшити удар: "Я тут, щоб ставити запитання". Ви не можете вирішувати проблеми, яких не розумієте.
Якщо керівник просить вас розробити дизайн футболки, запитайте, навіщо. Щоб було що роздати на наступній конференції? Щоб подякувати клієнтам? Для співробітників, щоб вони носили її як безкоштовну рекламу? Щоб викликати у співробітників почуття гордості та єдності? Розберіться в суті мети, а потім дослідіть, чи підходить цей засіб для досягнення мети.
Одне з моїх улюблених занять із керівниками вищої ланки - (чемно) попросити їх сісти і сформулювати своє прохання у форматі "Як ми можемо...". Це робить кілька речей. По-перше, це змушує їх замислитися над проблемою, яку потрібно розв'язати, а по-друге, вона несе в собі конотацію, що є кілька рішень. Я також люблю використовувати такі фрази, як "ми знайдемо рішення, але я просто намагаюся зрозуміти проблему, щоб розв'язати її найефективнішим способом".
Як керівник відділу дизайну, щоразу, коли я отримую негативний відгук про дизайнера від зацікавлених сторін або бачу неефективність його дій зі створення чудового досвіду, майже завжди, принаймні частково, причина в тому, що дизайнер недостатньо добре постарався запитати, чому.
Ненаситна цікавість - одна з відмінних рис великих дизайнерів. Один із моїх найулюбленіших методів роботи із зацікавленими сторонами і критики роботи дизайнера - "5 чому". По суті, ідея полягає в тому, щоб сформулювати проблему або ідею, а потім запитати "чому?" Стільки разів, скільки буде потрібно, щоб зрозуміти, що, на вашу думку, є основною причиною проблеми. Ви можете звучати як 5-річна дитина, але це дуже ефективно.
Є що додати? Ви можете зв'язатися з автором у LinkedIn або Twitter. Потрібен UX-лідер, який допоможе вашій компанії досягти UX-зрілості? Потрібен спікер для заходу? Подивіться портфоліо автора і зв'яжіться з ним.
Переклад статті uxdesign.cc
Топ коментарі (0)