VanillaTime

Если вы всё ещё иногда впадаете в ступор а-ля «Какой же контрол выбора выбрать?» то вот эта статейка от Runi Goswami может помочь структурировать знания. Runi пишет в основном о Segment Controll, который в узких кругах широко известен, как Button Bar, но попутно отвечает на извечные вопросы своей интересной инфографикой. Согласен с ней почти полностью, за исключением случая мультиселекта в дропдауне, который вовсе не покрыт. А в фильтрации e-commerce или сложных CRM используется постоянно. То есть для мультивариантного выбора я бы добавил ещё одно условие на количество пунктов превышающее 5. Конечно, задачка выбора такого сложного контрола зависит от контекста и на мобиле, например, может вообще превратиться в полноразмерный степпер, и при этом ценности работы Runi это не уменьшает. Однозначно советую к ознакомлению.

🚢 Капитанский блиц! Думаете дизайн-системы действительно помогают сделать процесс деливери эффективнее? Ну конечно! А насколько? Чуваки не поленились и провели эксперимент: оказалось, что разработка становится эна 50–75% быстрее. Больше про методологию здесь: https://sparkbox.com/foundry/design_system_roi_impact_of_design_systems_business_value_carbon_design_system

Не так давно стал свидетелем общения двух прелестных дам, одна из которых выбирала себе блузку, а вторая выступала в роли консультанта: 🤵‍♀️— Ну возьми вот эту беленькую, а? 👰‍♀️— Ты что! Я в белом жирная! И я подумал, почему белый жирнит? И это относится только к людям? Проверим! Хм… чёрное на белом, не тоже самое, что белое на чёрном. Если вбросите взгляд на пример, то возможно, вам покажется, что на белом фоне чёрное лого действительно кажется тоньше. Этот эффект называется иррадиацией и был открыт ещё в 1890 году. Если вкратце, то это связано с интенсивностью излучения белого цвета и тем, что нейроны неокортекса отвечающие за контраст чёрного и белого имеют разную степень возбудимости. И что делать с этой инфой, Дима? Упарываться по нивелированию этого эффекта за счёт снижения контраста или визуальной компенсации… Если не хотите, чтобы этот эффект возникал, то делайте чёрный не таким чёрным или утолщайте сам объект. А больше по теме вы можете узнать у Gonçalo Dias.

🤬 Люди часто ошибаются. Мы делаем это постоянно, иногда мы это замечаем, иногда нет. Порой, исправляем свои ошибки, а иногда не можем или не хотим, но в любом случае, от них не убежать и не спрятаться. И как бы мы ни старались, от всех ошибок пользователей тоже не уберечь. Но опускать руки рано, пробуем хотя бы минимизировать когнитивный ущерб. Например, прислушаемся к следующим советам: ⚡️ Поставьте взаимодействие на рельсы Сразу радикальный подход. Возьмите пользователя за руку и не давайте сходить с нужного пути, попутно отдёргивая от падения в пропасть. Дон Норман писал об этом ещё в книге «Дизайн привычных вещей», сравнив работу с ошибками и конструктор Лего — пользователь просто не соберёт модель не так. Например, валидировать поля ввода отсекая неверное. Когда банк присылает мне четырёхзначный код для подтверждения транзакции, поле принимает только цифры и буквы lowercase, а если попытаюсь ввести капсом, то поле не будет орать, а само заменит символ. ⚡️ Предлагайте и подталкивайте Более мягкий подход, где за шаг влево или вправо пользователь не схватит пулю. Здесь выступаем в роли консультантов, помогая пользователю принимать правильные решения. За примерами далеко ходить не нужно: автокомплиты поиска помогают экономить время и нервы на вспоминании как там «Saint Asonia» или «Saint Asodia»? ⚡️ Выбирайте верные дефолтные значения Ещё один способ плавно направить человека к правильному решению. Как я писал раньше, с этой вещью тоже нужно быть аккуратным, но если и ежу понятно, какое значение пользователь введёт, то почему бы и нет. У Яндекс еды есть клёвый паттерн, который можно притянуть сюда — функция «Повторим?», где видно, что раньше заказывал в этом ресторане и есть возможность повторить заказ. Очень удобно. ⚡️ Используйте стандарты Не стоит изобретать велосипед в паттернах взаимодействия. Большинство времени, люди проводят вне вашего интерфейса обогащая себя знаниями и формируя опыт. Так почему, если везде и всегда для определения цены они использовали поля ввода, у вас они будут тягать ползунки? ⚡️ Увеличьте аффорданс То есть дайте понять, что нужно с чем делать. Если это можно тягать, то поставьте там соответствующую иконку и меняйте курсор. Если что-то можно нажать, то подарите этому чему-то ховер и эктив состояния. Если что-то можно нажать, но не сейчас, то объясните, почему. ⚡️ Покажите пользователю, что получится Это поможет убедиться, что всё получится так, как задумал пользователь. На ум сразу приходит превью в Google Forms или Typeform, чтобы чекнуть результат перед отправкой. Или раньше, в InVision (когда он был ещё на волне) в дропдауне выбора скрина для перехода были не только названия, но по наведению отображалось превью. От ошибок не всегда спасало, но вероятность промазать была гораздо ниже. ⚡️ Отображайте предупреждения в реальном времени Если система видит, что человек идёт на красный свет под колёса камаза, должна-ли она что-то сделать? Думаю да. Например, когда вы превышаете лимит символов в сообщении, хотели бы вы, чтобы система вам об этом сказала, вместо блокировки дальнейшего ввода? Думаю да. Вот и я. Но только не нужно «орать» ещё до того, как ошибка совершена. Терпеть не могу, когда я только начал вводить пароль при регистрации, а мне в лицо сразу бьёт надпись «Аааа! Нужно больше символов!». Да знаю, я, сейчас введу, хватит орать. ⚡️ Подтверждайте важные действия Одно дело, когда кладёте товар в корзину, а другое, когда отправляете заявку на кредит без возможности отмены. В последнем случае, ничего, если пользователь прервётся на модалку, зато будет уверен в выборе. Ну и напоследок. Что делать, если ошибок не избежать? Например, поддерживать возможность отмены стандартным хоткеем «Cmd + Z», тостами, поповерами, как это делает Gmail после отправки письма. А также, если ошибка случается, помогайте справится с проблемой. Знать о том, что ошибка произошла — нуль. Если можете сказать, что делать, чтобы всё починилось — сделайте это. Хотите знать больше? Тогда вам вот сюда.

— Преобразование в вопрос. «Нужно узнать, пользуются-ли люди месседжерами» → «Вы пользуетесь месседжерами?».Ну, как бы семи пядей во лбу быть не нужно, и при этом не всегда такая формулировка будет наилучшей. Например, если дальше мы всё равно спросим, что это за месседжеры, то вместо двух вопросов можно собрать всё в один «Какими месседжерами вы пользуетесь?» привести список вариантов и добавить пункт «Никаким». Вариант. Но это может быть слишком сложно для восприятия и лучше будет использовать простой вопрос-затравку. В общем, думайте. — Просьба оценки. Когда вы формулируете измеряемый параметр, как утверждение и просите человека его оценить. Например. Оцените, насколько вы согласны со следующим утверждением: «Мне нравится ходить по магазинам и тащить сумки домой». Где 1 — «Категорически несогласен», а 5 — «Согласен на 100%». Но заметьте, как я считерил, выбрав для пример не месседжеры и частоту походов в магазин. Всё потому, что для них такой вопрос не подойдёт. — Использовать качественную формулировку. То есть используя слова «как», «кто», «когда» и т.д. «Нужно узнать, пользуются-ли люди месседжерами» → «Как часто вы пользуетесь месседжерами?» Наверное, самый пуленепробиваемый вариант, но смотрите в оба, порой он тоже не всегда подходит к контексту. 👉 7. Правильно подбирайте варианты ответа. От этого напрямую зависит чистота данных. На ум приходит четыре типа ответов: — Исследовательский. Подходит для вопросов открытого типа, где нужен развёрнутый ответ. Например, это может быть поле или текстовая область. — Измеряющий. Состоит из групп, диапазонов или целочисленных вариантов. — Категоризирующий. Определяет принадлежность вариантов категории. Типа радиогруппы или карточные сортировки. — Оценочный. Выражает субъективное мнение испытуемого относительно вопроса. Тут у нас шкалы и рейтинги. Вот так вот. А если захочется познакомиться с оригиналом, то милости прошу (https://measuringu.com/how-to-write-a-survey-question/).

📃 Вас не блокирует «чистый лист»? Когда пыритесь в бездну белого пространства и не можете связать мысли в слова, чтобы излить это на холст? Это наверное, самое сложное в созидании — начать. А уж если дело касается скриптов или опросов, наш ступор может и подзатянуться. Недавно (на самом деле давно) наткнулся на статью о правильном проектировании опросов, и спешу поделиться, чтобы шестерни вашего прекрасного мозга никогда не ловили клин. Семь шагов и вы в шоколаде 🍫. 👉 1. Итак, автор советует начинать с того, что вы хотите узнать или измерить. Какую цель преследует опрос, какие данные и в каком количестве необходимы, чтобы закрыть потребность. Иногда, чтобы это сделать, достаточно одного, но точного вопроса. Многие попадают в ловушку «излишней любознательности», когда хотят узнать, как можно больше. Но стоит однозначно взвешивать за и против, ведь дополнительный вопрос снижает вероятность полного прохождения опроса. Так вот и задумайтесь, так ли важно знать размер ноги испытуемого, или всё-таки можно прожить и без этой информации? Например, для того, чтобы узнать, будет-ли популярен сервис доставки продуктов из магазина, заказанных через чат-бот, нужно понять как часто люди обновляют запасы и пользуются-ли мессенджерами. При этом было бы хорошо понять распределение заинтересованных людей по районам и какими мессенджерами пользуются, чтобы знать, где начинать экспансию. ⚠️ Пример слегка общий и явно не охватывает тему совокупностей и средства распространения опроса, но суть вы поняли: думайте сперва над тем, что вы хотите получить. 👉 2. Проверьте, может нужный вопрос уже придуман? В пылу стастей так легко увлечься и начать изобретать колесо. Я помню, как я часами сидел над простым опросником, пытаясь подобрать правильные формулировки, ведь вероятность неправильной интерпретации очень высока. Особенно, когда речь идёт об измерении абстрактных вещей, вроде usability, доверия, удовлетворённости. А если человек неверно поймёт вопрос, то и ответ будет не в кассу (мусор на входе — мусор на выходе). Но не обязательно каждый вопрос прям выдавливать из себя. Гораздо проще адаптировать уже готовый фреймворк, коих сейчас развелось довольно много. Вдохновляйтесь и крадите как художники. 👉 3. Определите тип задаваемого вопроса в соответствии с выходными данными. То есть какой именно вопрос вам нужен для получения необходимых данных. Всего можно выделить 4 типа вопросов: — Атрибутные. То есть характеризующие наличие или отсутствие у респондента каких-то свойств. Например, принадлежность к организации, пол, возраст, отношения. — Поведенческие. Описывают периодичность возникновения определённого поведения. Например, как часто человек выбрасывает мусор. — Проверяющие… наличие у человека определённых навыков или знаний. Например, если человек ответит, как связаны интерлиньяж, формат и кегль, то с большей вероятностью будет обладать знаниями в типографике. — Оценочные. Узнают у пользователя о его отношении, мыслях и рассуждениях. Например, насколько просто ему было заполнить ваш опросник. 👉 4. Забрейнстормите идеи (спасибо кэп). От себя скажу, что любой вопрос стоит прогонять через себя, самостоятельно отвечать на них и подмечать, с какими затруднениями вы столкнулись и верные данные-ли вы получаете. Порой одного вопроса по теме бывает недостаточно, нужные подводки и затравки, запускающие мыслительный процесс перед основным «хедлайнером». Тестируйте на себе и смотрите, необходимы дополнения или можно лупить в лоб. 👉 5. Проводите пилотаж. Никогда. Ни-ког-да не запускайте опрос сразу в массы, так как вы «сожжёте» свою аудиторию до того, как получите хоть сколько-нибудь валидные данные. Вместо этого найдите троих бедолаг и проведите качественное ответабилити тестирование с ними. Так вы обнаружите проблемы до массовых протестов и обещаний кровной мести. 👉 6. Правильно сконструируйте свой вопрос. Это довольно просто сделать, если вы уже определили Что именно вы хотите измерить. (см. пункт 1) Конструировать вопрос можно тремя разными способами:

☀️ 🌴 Доброго денька, друзья. Надеюсь, что вы, как и я, радуетесь хорошей погоде. А я как раз с подгончиком. Прошло уже полгода с тех пор, как свет узрела моя первая книга «Ремесло счастья». И пусть первое издание вышло неидеальным, с некоторыми ошибками и неточностями, получилось оно очень человечным, ламповым, как я и хотел. Тираж хоть и был совсем небольшой, зато разлетелся, как горячие пирожки, за что многим из вас я должен сказать спасибо. Книга даже добралась до Бали, где пользуется большой популярностью… возможно из-за того, что там очень мало печатных книг 😏 Но я долго размышлял, стоит-ли на этом останавливаться? Ведь я создавал «Ремесло Счастья» для того, чтобы как можно больше людей были счастливы. Так почему я не могу сделать книгу доступной всем? Могу… и делаю. К посту прилагаю два файла: первый — свёрстанная версия для печати (на всякий случай), а второй — fb2 для читалок. ⚡️ Но предупреждаю, копирование и распространение… поощряются. Я всеми руками за, если вы поделитесь «Ремеслом» с друзьями и знакомыми, да и вообще всеми, кому книга будет полезна. А если вы ещё и обратную связь дадите, я буду безмерно благодарен. Писать можно мне в личку (@VanillaThunder), на почту (если знаете), на медиум, на ЛитРес — куда захотите, я читаю всё 😀 Спасибо, что вы есть, и приятного вам чтения! 🛳❤️

Ну вот ребята и первая статья из заказного вами. Последние недели рассуждал о том, почему так происходит, что дизайнеры стремятся в менеджмент,и рассматривают этот шаг, как органичное развитие их карьеры. Существует-ли менеджерский пузырь и стоит ли вообще становиться Principal дизайнером, ведь дальше там ничего нет? 😈 Кликай сюда, чтобы узнать ответы.

🤟 Алоха, друзья. Признаться честно, в последнее время испытываю некоторое затруднение в выборе темы. Проще говоря, я ХЗ о чём писать, чтобы было интересно и мне и вам. Не хотелось бы превращать это место в свалку однотипных статей, потому я решил узнать, а на что есть спрос. По ссылочке на tricider вы можете задать любой вопрос, предложить тему или проголосовать за уже существующую. Благодаря вашей инициативе у меня появится направление мысли, а там и до поста не далеко. Заранее спасибо всем неравнодушным :) ❤️🛳

И немного в догонку прошлого поста: наткнулся на статью Нильсен-Норман о дизайне ожидания и прерываний. Материал гораздо более полезный, например из-за практических советов: ☝️Всегда четко обозначайте прогресс и количество оставшихся шагов. Например, когда пользователь видит зацикленный лоадер, он понимает, что система работает. Однако спустя 10 секунд, он уже начнет сомневаться в этом. Для ожидания такой длины лучше использовать прям прогресс. ☝️ Всегда снабжайте конец прерывания сообщением с дополнительной информацией. Иначе, из-за незакрытого гештальта, пользователь может решить, что произошел сбой. В самом сообщении можно показывать какой путь был проделан, сколько времени это заняло, и какие дальнейшие шаги требуются. Можно также показать, что произошло, пока правителя не было (в не случае асинхронных операций). ☝️ Помогайте пользователю вспоминать, что происходило перед прерыванием: чем он занимался, к чему это делал и зачем вообще жить. Для этого можно использовать как возможность оставлять комментарии перед уходом или длительным прерыванием, например, как это делают crm системы между контактами с клиентом. ☝️ Предоставляйте быстрый доступ к прошлым действиями пользователя: так он вспомнит все быстрее. Ну нужно прятать такие действия, а лучше ставить их на видное место, можно даже с превью. ☝️ Ну и напоследок, пусть вы и блокируете флоу пользователя, но технически сервис может работать. То есть загружает пользователь файлы, пусть они обрабатываются в фоне, пока он настаивает все остальное. Не блокируете :) За деталями, как всегда добро пожаловать в статью: https://www.nngroup.com/articles/designing-for-waits-and-interruptions/

⏳А вы задумывались, когда одной из основных метрик продукта ставят время прохождения сценария: это должно быть фактическое время или субъективно воспринимаемое? 🤔 Наверное, лучше бы собирать оба, но в большинстве своем, я сталкивался только с фактическим замерами времени пересечения финишной черты. Бесспорно, если продукт направлен на то, чтобы быстрее закрывать задачи и переключаться на другие, то это верный подход. Например, в саппорт центрах или админках для обработок заказов. И при этом, во всех остальных ситуациях важнее как пользователь чувствует, нежели какую цифру видит на секундомере. Мы не автоматы для принятия решений 🤖 и смотрим мы на все, сквозь призму эмоций. Мы же не приходим на новый фильм Марвел с мыслью «Так, поскорее бы он закончился! Ставь 2х скорость!». Нам важно, просто, чтобы фильм не залипал и не подлагивал, чтобы мы могли наслаждаться процессом. Посему, внимание наше, как дизайнеров должен занимать не только фактический перформанс (а он очень важен), но и проектирование восприятия времени. Для того, чтобы это делать правильно, я очень советую книгу «Проектируем время» Стивена К. Сеова. В ней временные интервалы отклика буквально разобраны до косточек. А если вы хотите познакомиться с азами (лоадеры, анимации, скелетон), то можете попробовать эту статью: https://link.medium.com/BWEw4R2Lsjb

Адам Фард решил развеять шесть мифов в и о дизайне, которые до сих пор находят место в головах дизайнеров. 🤞 Миф 1, мой любимый: Правило 7± 2. Оно гласит, что человеку, якобы не под силу удержать в голове больше 7(±2 в зависимости от человека) единиц информации. Ведомые этим принципом, дизайнеры режут не жалея любую, даже самую ценную инфу, лишь бы не перенапрячь бедного пользователя. А то голова заботит. Авторство такого «закона» приписывают Джорджу Миллеру, хотя я бы сказал, что за его популяризацию ответственны скорее околонаучные СМИ. Они раздули отчёт Миллера, в котором никаких конкретных цифр не называлось, только предположение. Учёный лишь доказал, что существует предел оперативной памяти человека, а все вокруг... gone crazy 🤪. В общем, автор счёл достаточным просто сказать, что миф — враньё, и не работает для больших кластеров информации, типа меню. От себя добавлю, что миф-то не такой уж и миф: дальнейшие исследования в области оперативной памяти человека показали, что предел её гораздо ниже, заявленного ранее 4±1 независимых кусочка информации. Но есть оговорка, что за счёт механизмов группировки, поиска паттерна и связывания информации путём мнемоники, эти цифры могут быть увеличены. Так что вместо слепого счёта блоков на экране лучше позаботьтесь о выстраивании чёткой визуальной иерархии. 🤞 Миф 2: Люди рациональны. Я поражён, что он ещё существует. По-мне, так уже давно должен был вымереть стериотип о том, что человек — это рациональная машина принятия решений. Ты в неё данные, она тебе решение. Смешно. Любое решение эмоционально по своей природе: от выбора рубашки, до сделки на миллиард долларов. Кстати, а давайте порассуждаем, может пора пересмотреть и такие термины, как B2B и B2C? Ведь на самом деле всё происходит H2H (Human to Human). 🤞 Миф 3: Люби могут внятно объяснить, чего они хотят. Для тех, кто проводил глубинные интервью или кик-оффы с заказчиком, это утверждение будет вызывать улыбку до ушей. Да и чего удивляться, порой человек и о проблеме толком не знает, пока вы не спросите. А уж тем более о самом лучшем её решении. «А что так можно было?» — вот, что обычно говорят пользователи при виде хорошего решения. «А что, можно платить за продукты часами?», «А что, можно заряжать машины электричеством?», «А что, можно было и в космос полететь?». Думаю все эти вопросы когда-то звучали. Так что перестаньте спрашивать, чего хотят пользователи. Спрашивайте, что у них болит и работайте с проблемами. 🤞 Миф 4: Меньше кликов — счастливее пользователь. Ох как и пригорало мне от этого аккуратно упакованного гнилья в головах стейкхолдеров. «Нужно меньше кликов, четыре — это уже много, нужно до трёх.» ААААА!😡 Какая разница, сколько кликов до цели, если она достигается с улыбкой на лице? Если не нужно ломать голову и выдавливать глаза в поиске нужного элемента в свалке. Открою тайну, нет никакой корреляции, между количеством кликов и уровнем удовлетворённости пользователя. Так что самое время подыскать другие метрики для фокуса: конверсия, ROI, NSS, количество ошибок, время прохождения сценарий, retention… неплохие кандидаты. 🤞 Миф 5: UI и UX, как Инь и Ян в продуктовом дизайне. От меня тут не будет комментариев, ибо это и ежу понятно, что это бред. Да и вообще, как мне кажется, дизайнер должен уметь и проектировать и в визуале всё реализовывать, а иначе какое-то неполное взаимодействие получается. А смотрите, маленький коммент всё-таки получился. 🤞Миф 6: Less is More. Ну тут автор уже пустился в рассуждения о том, что это не всегда так, что порой такой подход может навредить, якобы в сложных системах, для людей привыкших работать со сложными данными, которым это просто необходимо. Но тут я вижу только неверную интерпретацию самого принципа. На самом же деле, less — это минимально необходимый набор данных и функция для достижения цели, а не слепое урезание всего всего подряд 🪚. Так что тут получается, что не совсем миф, и не совсем развенчан. Но в любом случае, очень рекомендую ознакомиться с оригиналом: https://adamfard.com/blog/ux-myths

Ребята, привет. Давно не виделись. Знаете, задался вопросом о том, почему пишу сюда так непостоянно, и рылся в себе в поисках ответа. Оказалось всё серьёзнее, чем кажется… Я немного покопался и понял, что мне ничего не интересно. Вообще. Это, скажу я вам, жесть ещё та. И возможно, я не один такой, ибо культура диктует нам закрыться в себе и переваривать свои проблемы самостоятельно. По правде сказать, я и сам не хотел делиться — отпустило и хорошо, но прогулялся утром и подумал, что провести ретроспективу стоит. Особенно, если она будет ещё кому-то полезна. А если кто-то сталкивался с подобным отстоем в жизни, пожалуйста, опишите в комментах, как выбрались из этого леса — я буду бить челом в благоговении! https://vanilathunder.medium.com/%D0%B3%D0%BE%D1%80%D0%B8-%D0%B3%D0%BE%D1%80%D0%B8-%D0%BC%D0%BE%D1%8F-%D0%B7%D0%B2%D0%B5%D0%B7%D0%B4%D0%B0-477a6fc4dc6b

🌴Алоха! Вышел свежий выпуск подкаста «Я считаю…», где мы решили немного похоливарить на тему трэш-дизайна. Здесь я могу добавить пару ремарочек к том, что было в выпуске, поскольку уже прослушал его 🙂 У меня вих всего два: 1. Не путайте брутализм и трэш-дизайн. Брутализм — это действительно, как расскажет Илона, имеет что-то общее с конструктивизмом, где функция ставилась на первое место. А трэш-дизайн ставит во главу угла… Эм… получается хайп. То есть не насколько удобно чем-то пользоваться, а насколько большой резонанс будет создан. 2. Я бы настороженно сравнивал искусство и дизайн, ведь для меня, исскусство — это самовыражение, а дизайн — это ремесло. А что думаете вы? ) Послушать можно везде: YouTube https://youtu.be/AeV6YHtOlws Apple https://podcasts.apple.com/by/podcast/designspot-podcast/id1521026340 Google https://clck.ru/VnAEe Яндекс https://music.yandex.ru/album/11283594 Soundcloud https://m.soundcloud.com/designspot_community/ds-09-yaschitayu-tresh-dizayn

☀️Друзья, привет! Несмотря на 🔥 адский зной 🔥, у меня получилось закончить статью о предвзятостях (Biases), которые мешают нам мыслить ясно. В статье вы найдёте 37 особенностей восприятия и то, как они искажают действительность. В наше время нужно знать о таких вещах, чтобы не попасться на крючок манипуляций, но это не значит, что пользоваться ими во благо запрещено. Это просто механизмы восприятия, инструменты, так что можете брать на вооружение и творить только добро 🙂 Приятного вам чтения в этот солнечный день. Искусство мыслить ясно

Ведётся много споров о том, сколько респондентов протестировать, чтобы покрыть наибольшее число проблем. Кто-то апеллирует к классикам называя волшебным числом 5, а кто-то погружается в волшебный мир цифр и старается математически высчитать это число. Но давайте разберемся, так сколько вешать? Прежде всего, взглянем на то, откуда родилось наша волшебная фраза «сообразить на пятерых». Еще в 1993 году, уважаемый Якоб Нильсен представил миру математические расчёты корреляции вероятности нахождения ошибки хотя бы одним человеком с количеством респондентов в выборке. Проще говоря, математически вывел, что для открытия 85% проблем взаимодействия необходимо минимум 5 респондентов. Однако, в расчётах он использовал один хитрый коэффициент — обнаруживаемость ошибки (Discoverability), который вроде как эмпирически взял равным р=0.31. И формула эта вполне себе работала, находя подтверждение в проводимых исследованиях. НО! В 2001 году Перфетти и Ландесман начали тестировать один музыкальный сайт и поняли, что 5 респондентов нашли далеко не 85% проблем, ибо даже после 18ого теста обнаруживали криты 🔥🔥🔥. Так что после исследования, они подбили сумму и обнаружили, что первая пятёрка выявила 35% проблем. Ничего себе разбежечка? А дело в этом скользком коэффициенте обнаруживаемости проблемы (р) 🐌, ведь он не статичеен и отличатся у каждой проблемы. Теже Перфетти и Ландсман предложили отталкиваться именно от этого коэффициента, чтобы формировать выборку. Даже привели сводные таблицы, где всё наглядненько: хошь открыть 95% проблем с обнаруживаемость не ниже 0.5 — собирай пятерых, хочешь 99% проблем с самой маленькой обнаруживаемостью 0.01 — тогда понадобиться 459 сессий, а лучше 662. Но как определить этот злосчастный коэффициент, ведь не обнаружив проблему не можешь и высчитать её обнаруживаемость. 🤯Парадокс. И мы поступим с этим так, как умные, образованные люди — забьём. Дело в том, что эта академичность внесит дополнительную сложность в исследования, потому наши коллеги из Human Factors рекомендуют разделить исследование на T-Shirt размеры.  S — для исследований на пять респондентов, причём эффективнее всего прогонять их по методу RITE, когда вы исправляете проблемы, найденные после теста и только потом приглашаете нового респондеента. M — среднее исследование на 10 человек и L — на 25. И используются они скорее как иснтрументы риск-менеджмента, чтобы убедиться, что большинство крупных проблем исправлены. Если вас заинтересовало, то вот тут можно почитать подробнее.

Привет друзья, только что дослушал книгу Джейсона Шрайера 🔥 «Кровь. Пот. Пиксели.», которая рассказывает истории создания 10 культовых игр современности. Игры такие разные и создавались они очень по-разному, но для себя я выделил некоторые параллели характерные для индустрии в целом: 1. Создание отличной игры невозможно без кранча — сверхурочной работы по 12-16 часов в день. Когда пукан пригорает от сжатых сроков. Это, конечно, плохо, но оказывается, не видеть родных определенный период в порядке вещей. 2. Свою игру нужно любить, верить в неё и вкладываться, пусть и свои кровные средства, а это невозможно без невероятной мотивации. 3. Игра может надоесть, вы можете выгореть, и важно делать перерывы, чтобы не суглиться плотностью. Потому после завершения проектов, многие дизайнеры уходят в долгий отпуск (до полугода), чтобы восстановиться. 4. Но работа не заканчивается на запуске игры. Нужно прислушиваться к мнению аудитории и полишить игру ещё долгое время, если вы хотите создать действительно годный продукт (как Diablo III или Shovel Knight). 5. Итерирование, итерирование и ещё раз итерирование! Сразу сделать круто не получится — смиритесь (Uncharted 4). 6. Чем-то придется жертвовать ради целостности и сроков. А иногда, игры и отменяют вовсе. Даже чаще, чем не отменяют (Star Wars 1313). 7. Шедевр невозможно завершить, его можно только бросить. 8. 120%, что сроки будут сорваны. Планировать в условиях жестокой неопределенности просто невозможно. 9. Плотная команда энтузиастов гораздо лучше огромной машины — итерации быстрее и меньше склок, хоть и не так много возможностей. 10. Создание целостного видения всей команды — залог плодотворной и хорошей работы. 11. Предпродакшеном нельзя пренебрегать, нужно определяться с общей канвой сюжета, механик и атмосферы ДО того, как начнётся разработка, чтобы получить целостный продукт. Порой это занимает до полугода. 12. Много работы делается в стол ради выставок и демо стейкхолдерам, ничего из этого не попадает в финальную сборку. А это огромные куски работы. Потому так важны хорошо настроенные инструменты быстрого итерирования, а иначе попадётесь у ловушку технологий (Dragon Age III: Inquisition). 13. Краудфаундинг — отличная альтернатива издателями, которые влазят в творческий процесс ради финансового благополучия. Кстати, именно независимость является одним из факторов создания шедевров. Но к игрокам нужно относиться соответственно, держать в курсе разработки, сдерживать обещания. А вообще книга произвела на меня очень позитивное влияние — захотелось что-то сделать, и в тоже время, это отрезвляющие истории, далёкие от романтизма наших представлений. В общем — мастрид, я считаю.

Ребята, как и обещал, постю сюда, вам первым, текстовую версию пошаренного выше подкаста, с более чёткой визуализацией и дополнительными материалами 🙂 Надеюсь, что эта модель оценки пригодится вам в работе, а советы будут полеезными и запулят вас на новый уровень профессионального роста! 🚀 https://vanilathunder.medium.com/%D0%BA%D0%B0%D0%BA-%D0%B8-%D0%BA%D1%83%D0%B4%D0%B0-%D1%80%D0%B0%D1%81%D1%82%D0%B8-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%D0%B5%D1%80%D1%83-cbde24ed2004

Друзья, в последнее время мало чего постил, но спешу исправиться. С пылу с жару новый подкаст про профессиональный рост. 📣 Ахтунг! В середине подкаста будет большой кусок с перечислением навыков и ожиданий — его очень сложно воспринять на слух. В скором времени выложу текстовую версию на Медиуме, только вот кошака дорисую. А пока можно воспользоваться тайм-кодами в описании :) https://youtu.be/hrNPZ7uRg78 • Почему мы так одержимы титулами и левелами? • Какие навыки нынче в моде, и как их правильно оценить? • Есть-ли секреты и алгоритмы качественного роста в дизайне? • Что такое профессиональный суицид и как его не допустить? На эти вопросы попробуем найти ответы вместе :) Приятного прослушивания! Слушай выпуск там, где удобно: ☑️Soundcloud ☑️Yandex Music ☑️Google Podcast ☑️Apple Podcast ☑️Youtube

Ничего не происходит… только у Framer хороший апдейт, о котором уже с начала года умоляли пользовватели — авторесайз. Казалось бы, ну уже маст-хэв фича, что тут такого, везде это давно есть. И я тоже так подумал сперва, а после пришла мысль о том, ну так а в чём теперь разница-то? Framer недавно презентовали полностью кастомизируемые рабочие инпуты, переменные и интеграцию с эйртэйбл… а Figma сделалась еще более платной. Простите за однобокость, мне нравятся оба инструемента и как они работают с пользовательскими ожиданиями, просто последние события заставляют задуматься, а не превращается-ли Figma в новый InVision. Ну ладно, оставлю это вам наподумать, а пока пойду сделаю ещё пару моделеек в Spline и вставлю их в свой прототип 🙂