VanillaTime

🧪 Друзья, я рад сообщить, что совместно с Display.epam.com мы закончили работу над циклом статей, посвященных тестированию. Без тестирования уже сложно представить процесс разработки любого продукта: от виджета в телефоне до мультитенантных нагруженных систем. И оно и немудрено, ведь тесты помогают над на раннем этапе выявить проблемы и валидировать решения, экономя денежки. Потому этот цикл и возник. Мы бы хотели привнести культуру тестирования в каждую организацию, и для этого создали абсолютно бесплатный продукт, который сможет вам в этом помочь, а также цикл статей посвященных тому, как выжать из вашего тестирования максимум. Последний мы назвали «Хроники тестирования». Внутри вы найдёте: 🔍 Пролог: Зачем нам тестировать? Узнайте, почему тестирование является неотъемлемой частью разработки и как оно влияет на успех вашего проекта. 💡 Часть 1: Тестирование идей. Узнайте, как правильно анализировать и проверять идеи, ещё до того, как вы нарисуете хоть один прямоугольник, и тем более перед тем, как приступить к разработке. 🔧 Часть 2: Пользовательское тестирование. Рассмотрим методы планирования и подготовки, предшествующие тестированию. 📝 Часть 3: Типы тестов. Исследуем различные методы тестирования, от first-click теста до ретроспективных интервью. Всё, чтобы помочь вам выбрать подходящий набор. 📊 Часть 4: Работа с аудиторией и анализ результатов. Узнайте, как правильно оценивать необходимое количество респондентов для теста и эффективно анализировать результаты, чтобы не упасть в яму фальшивого знания. Ну и конечно, после того, как вы изучите всю теорию, обязательно пустите её в ход используя темплейты внутри статей и сам инструмент Display. Надеюсь, что этот материал поможет вам вывести ваше тестирование на новый уровень.

Ребята, вот уже через 10 минут начинаем наш стрим, посвещенный дизайнеру во время дискавери фазы. Подключайтесь сразу на ютюбчик — будет интересненько и лампово. 🪔

Онлайн-встреча «UX дизайнер на фазе дискавери»! С чем сталкивается дизайнер, когда до первого макета еще далеко, а клиент и команда ломают голову над видением продукта? 6 сентября погружаемся в тайны и раскрываем секреты вместе с @ThinkUX_kz. Регистрируйтесь: UX дизайнер на фазе дискавери | Community platform (wearecommunity.io)

Давно с ребятами не собирались, и вот решили исправить это досадное недоразумение. Вечером в среду, после обеда, когда усталые взрослые люди будут спать, мы поговорим а дискавери фазе на проекте, и узнаем, что там забыли дизайнеры. Приходите, не знаю, насколько весело или душно будет, ведь это будет лайв-стрим, но интересно быть должно )

Ребята, я тут нашёл свой черновик на Medium из 2013 года. Почитать свои десятилетние рассуждения дело странное. Где-то поспорить, где-то покивать… но вот, что интересно: основная мысль осталась актуальной спустя десятилетие. Хорошо это или плохо — я не знаю.

Я начал своё воскресение с углубленного понимания SVG Paths, используя быстрый self-paced курс от Nanda Syahrasyad. Я давно не был так впечатлён подачей материала. Мало того, что всё рассказано в простой и непринуждённой манере, так ещё и упор делается на практику. Как бы я хотел, всё обучение было таким! Очень советую уделить 30 минут вашего времени, чтобы лучше понять как работает векторная графика, и как заставить её работать быстрее.

🤔 Я часто цепляюсь к словам. Я, конечно, не фанат немецкого, где для всего есть своё слово, но если кто-то говорит "шрифт", имея в виду "начертание", я тактично исправлю человека и объясню, в чём разница. Не то чтобы это доставляет мне какое-то удовольствие, просто я хочу выражать мысли наиболее ёмко и чётко. В словах кроется великая сила. Раньше я этого не замечал, но, прочитав интересную статью о том, почему нам, как дизайнерам, важно учиться писать, окончательно убедился в том, что верная формулировка мыслей может сильно влиять на восприятие информации. Я не совсем согласен, что писательство важнее эмпатии, но оно в значительной мере может усилить эту супер-силу. Это основная мысль статьи. Но это натолкнуло меня на мысль о том, почему нам важно писать, чтобы лучше понимать информацию. Во-первых, переформулирование помогает осознанию — это доказанный факт. Не диктанты, а изложения помогают переварить мысли и дают им возможность уложиться. Во-вторых, письмо заставляет нас замедлиться. В нашем безумном мире мы летим сквозь время, как в «Интерстелларе», а наш мозг не поспевает за нами. Мы хотим делать всё быстрее и эффективнее, нажатие клавиш, а тем более движение ручки не вписываются в этот концепт. Нам проще перетягивать ползунки качеств в темплейте личности, чем выразить предпочтения словами. Кажется, что проще создать прототип, чем описать взаимодействие текстом. Я считаю, что остановка и размышление важнее, чем бесконтрольное движение вперёд. Так что попробуйте что-нибудь пописать. Может показаться, что я душню... ну, возможно и душню. Но это не умаляет важности внимания к словам :)

В догонку по теме: Бенедикт Еванс ответил на вопрос почему автоматизация труда — это не угроза, а благо в долгосрочной перспективе. Развернуто, с графиками и примерами из истории. Очень круто усмиряет панические настроения :)

Опа, я всё ждал, когда же это наконец случится, когда кто-то заявит о том, что UX мёртв. Сколько подобных заявлений я видел на своём веку: web мёртв, десктопы больше никому не нужны, ui устарел и больше не канает, мониторы уступят место очкам, визуальные дизайнеры больше не котируются и самое время становится prompt-дизайнерами… и теперь вот у нас закат Experience дизайна на подходе. Если коротко изложить основную мысль автора, то "design-driven" теперь звучит смешно, а деньги говорят громче. В качестве примера, он привёл недавний редизайн Twitter → X, где без какого-либо дизайна, исключительно по инициативе Илона Маска был создан лого из Unicode символа. Якобы, вот так будет и дальше: если что-то можно сделать дешевле и без дизайна, то это и будут делать. Дизайн-системы, шаблоны, искусственный интеллект якобы уже полностью потеснили трудягу дизайнера, не оставив ему места на рынке. Но вот мой вопрос: а когда-то было иначе? Словно автор данной "оригинальной мысли" зашорен последним десятилетием. Всегда в нашей профессии было и будет самоуправление CEO и фразы "сделай, как я хочу", всегда даже сами дизайнеры стремились оптимизировать свой труд и сделать его более эффективным. Разве появление фреймворков во фронтенде сделало разработчиков не нужными? То же самое с дизайн-системами. Камон, всё это закономерное и естественное развитие домена. Называть "золотым веком UX" время, когда можно было лопатой грести заказы на однотипные шаблоны и завышать цену только потому, что никто кроме тебя не может решить задачу — лицемерие. Это закономерный виток, когда домен уравновешивает себя, стабилизируется и остывает. Думаю, дальше мы увидим ещё большее разделение труда внутри домена, будут появляться новые специализации и никуда нам от этого не уйти, но дисциплина будет расцветать. Думать, что дизайн, как дисциплина настолько самобытна, что непонятно, как она будет развиваться — надменно. Оглянитесь вокруг. Это не конец Experience дизайна, это накрывает медным тазом тех, кто не развивался и чей труд будет автоматизирован. А те, кто помимо работы в редакторе интересовался смежными доменами: психологией, эргономикой, биологией; смотрел на свою работу не как на создание красивой картинки, а как на полноценный пользовательский опыт; кто понимает проблемы пользователей и старается сделать их жизнь лучше (о чём мы, как мне кажется, стали забывать), те будут востребованы всегда, пока будет существовать взаимодействие человека, машины и среды.

Мне кажется, что сегодня все силы дизайнеров сконцентрированы, как лазер, на поиске и удержании клиентов. И немудрено, ведь рынок кричит голосами тысяч страждущих специалистов, только и ждущих, чтобы урвать свой кусок и не помереть с голода. Дизайнеры до блеска полируют свои портфели, фаршируя их кейсами и цифрами достигнутого успеха, пытаясь хоть как-то повысить шансы на заветные заказы. Простите, что утрирую, но это подводочка к тому, что порой в этой гонке дизайнеры могут оказаться в своего рода абьюзивных отношениях. Когда рынок перегрет предложениями, клиенты могут почувствовать власть и начать манипулировать условиями. Хорошо, если этого не происходит, но часто дизайнер не может полностью раскрыть свой потенциал и превращается в карандаш, ведомый волей заказчика. Такую ситуацию можно наблюдать в продуктовых компаниях, выстроенных вокруг CEO с прекрасной харизмой и/или толстым кошельком. Тогда словосочетание "командная работа" вызывает натянутую улыбку, ведь все в команде осознают, что будет так, как хочет король. Если честно, то в начале моей карьеры я сам находился в таких взаимоотношениях. Начинать звонок с фразы "Это что за говно ты нарисовал?!" или "Это всё, что ты сделал за 3 часа?!" было в порядке вещей. Ровно как и бросать трубку, оскорбляя меня насквозь. Дошло до того, что у меня, как у собаки, выработался рефлекс с замиранием сердца на звук звонка в Skype (потому что я так быстро перешёл в Teams). В общем, дело дошло до ручки, и нужно было уйти. Конечно, мой случай довольно особенный, но заставить вас расстаться с клиентом может и не только обильный слой матерной речи в ваш адрес, но и ряд менее выразительных намеков. — Вы не чувствуете, что приносите пользу продукту, хотя клиент может считать иначе. — Наоборот, вы не чувствуете, что продукт принесёт пользу этому миру. — Вы не чувствуете синергии с командой. — Вас заставляют делать то, что идёт в разрез с вашими ценностями. — Вы больше не видите своего развития в компании. — Вас достал слишком медленный или слишком интенсивный темп работы. Все эти вещи могут заставить вас задуматься о том, чтобы помахать рукой текущему заказчику. Дальше будет несколько советов о том, как правильно прощаться с клиентами и что не стоит делать. 😍 Как правильно: — Говорите честно, без утаивания, чтобы не скрывать настоящую причину ухода. Если вы начнёте лукавить, то вполне возможно, вас захотят удержать новой зарплатой, обещаниями новых возможностей или новыми тайтлами, но в итоге через время всё вернётся на круги своя. — Предупреждайте клиента заранее, чтобы у него была возможность найти вам замену. И можете даже поучаствовать в подборе кандидата. Это будет честно и вежливо с вашей стороны. — Задокументируйте решение уйти письмом или перепиской, чтобы это не стало проблемой в будущем. 😰Не нужно: — Бросать заказчика под мостом, без возможности найти замену. Образ мысли "Вот я уйду, и вы все будете плакать" здесь не очень хорошо работает. Уйти молча, без объяснения причин, по-английски, значит оставить плохое послевкусие о вашем сотрудничестве. — Выкручивать руки, требуя невероятного повышения, такого, что заказчик точно не сможет потянуть. И это как будто он не смог дать вам желаемое, поэтому вы и ушли. Перекладывание ответственности точно сделает всё сложнее. — Сжигать мосты. Посылать заказчика, ругаться, угрожать, хлопать дверями и так далее. Поверьте, даже если вы прохавали земли на этом проекте, вам лучше выплеснуть праведный гнев где-то в другом месте. Зачем поступать правильно, а неправильно не поступать? Потому, что вопреки расхожему мнению, главный инструмент дизайнера для привлечения клиентов — это не портфолио, а нетворк. И даже, если ваш клиент из ада, доставил вам много хлопот, с его стороны вы были прекрасным профессионалом, которого он с радостью порекомендует в будущем. А на все эти размышления меня натолкнула вот эта статья.

Только что прочёл интересное рассуждение от NNGroup, о том, что AI привнесли в нашу жизнь третью парадигму взаимодействия человека и компьютера. «А первые две про что?» — спросите вы. Если коротко, то первая парадигма взаимодействия появилась с возможностью пошаговой обработки больших массивов данных. Это когда инженеры ковыряли перфокарты, вставляли их на ночь в шкаф, а утром приходили и забирали кучу распечаток или других продырявленных перфокарт. То есть, для того, чтобы взаимодействовать с компьютером, нужно было скармливать ему не только данные, но и точно говорить, что с этими данными делать — компьютер был ни в зуб ногой, чё кого. Да и взаимодействие велось в одну сторону: вот те данные, вот те ответ. Вторая парадигма родилась из увеличения процессорных мощностей и упрощения взаимодействия: компьютер стал умнее, начал запоминать и хранить данные, а пользователи могли ими манипулировать используя команды. Такой сетап продержался почти 60 лет, и прошёл путь от командной строки до Apple Vision Pro, ведь даже эта новая среди использует команды пользователя, как ввод. Так вот, подползая к третьей парадигме, где на сцену выходит AI (LLM) типа GPT или Bard. По мнению авторов, сейчас происходит как раз сдвиг парадигмы взаимодействия от Команд к Намерениям. Таким образом, человек больше не говорит компьютеру, что делать, он сразу описывает результат. А компьютер уже сам думает, как ему этого гуся раздобыть. На научном, произошло смещение локуса контроля в сторону железяк. Чувствуете сдвиг? Новая эра! Третья парадигма! Я вот ничего не чувствую. Рассуждения, конечно интересны, но лично мне кажется, что они продиктованы интересом к технологии, нежели фактическим положением дел. Если всё-таки предположить, что всё так, как описано в статье, то сдвиг этот начался наааамного раньше, ещё во времена бурного развития поисковых механизмов, когда человек тоже вводил в инпут своё намерение и получал результат. Может и не такой точный или красивый, но получал. Вспомним еще и IoT, где компьютер может инициировать взаимодействие и без нашего намерения, например, когда умные часы понимают, что ваш пульс падает ниже допустимого уровня и пытается вас разбудить или вызывает вам скорую. Голова может вообще взорваться. Вы можете придраться и сказать, что это просто сложные директивные программы. Так и AI не AI, а сложная программа. Подводя черту, возможно мы действительно живём в мире третьей парадигмы взаимодействия, но началась она уже давно. Мы только сейчас заметили :)

Ну и если читать совсем не хочется, то можно позалипать на простецкие анимации, как на фабрике создают логотипы: https://www.youtube.com/watch?v=QtrZ0IZnlCc&list=PLz4AhaYv2yvf-jRT9Pw6HAhiQi07jpIqp

Ребята, привет! Лонг тайм но си :) Снова пишу после длительного перерыва, накопив ульту интересняшек. Без промедления к делу 🔥 🤑 Совсем недавно мы говорили о бизнес-моделях (буквально пост выше), где я попытался описать как эти звери работают, и какие шаблоны можно использовать. В догоночку, наткнулся на статью о том, как можно монетизировать Open-source проект. Из того, что мне понравилось: автор сперва пишет о том, что точно не сработает — просить денег у людей/компаний/спонсоров, а также невероятно занижать цену на свой продукт. Это логично, ведь получается, что компании тратят сотни и тысячи долларов на зарплаты людей, которые решают проблемы. И если ваш продукт решает точно такие же проблемы, почему он должен стоить, как пачка сигарет? 😮‍💨 В общем, автор предлагает использовать шаблоны лицензирования, урезанного функционала, оплаты за поддержку или Server-версии вашего продукта (что актуально для GA, например). Почитайте, там интересно. ⚡️У вас не было такого, что на каком-то сайте вам очень нравится транзишен, и вы бы хотели его повторить, но падлюка такая быстрая, что уловить его сложно. Вот и приходится вглядываться в экран и запускать его снова-снова-снова и снова. Благая весть, благодаря Chrome Dev Tools нашим страданиям конец. Тут лежит гайд, как нативно применять slow-mo и препарировать любые свистоперделочки. Кстати, если вы никогда не открывали Dev-tools, то я советую вам это сделать. Там теперь не только непонятный код, но и много клёвых штук, как например Lighthouse для accessibility. 🤓 Кстати, об accessibility. Обновился дизайн W3.org и теперь потреблять невероятно сложные спецификации стало проще. Вместо бескрайнего поля с буквами появился более структурированный подход к подаче информации. Пусть и не без стоковых фоток, мелкого интерлиньяжа и налёта 2000х, но эй, если помните как было, то это прям прыжок вперёд. Так что радуйтесь, если вы бы хотели в accessibility, но вас отпугивала перспектива копаться в дедовом нижнем белье (а именно так я и представляю себе старую версию). 🤪 А теперь для набивки коробочки и залипания вечером: 1. UX bites: Приятные интерфейсные приятности в виде курируемой галлереи. 2. Uncut: Галлерея бесплатных шрифтов, которых вы никогда не видели. 3. Flowbite: иконки нннада? 4. Durves: генерирует точечные паттерны со всякого рода волнами (круть) 5. SVGhub: не тот hub, но тоже неплохо, если не знаете, чем залепить дыру в вашей презе. На этом всё, приятного чтения 🛳❤️

Привет, ребята! В последнее время я что-то увлёкся чтением о бизнес-моделях и рынке в целом, и хочу поделиться своими мыслями с вами. Я решил написать короткую статью, но оказалось, что она выросла до громадных размеров! В ней я кратко описал 55 моделей, которые могут быть комбинированы и использованы для создания уникальных проектов. Также затронул вопросы конкуренции, преодоления изменений и развеял кое-какие мифы. Буду рад, если заглянете и поделитесь своими впечатлениями.

1. Научитесь отделять свою работу от вашей личности. То, что у вас не получилось с первого раза создать что-то рабочее — так редко у кого получается. все эти правки, итерации, «всё говно» к вам никакого отношения не имеют. Это грубые шаги к вашей цели — получить клёвый продукт. 2. Не привязывайтесь к решениям. Взгляните на свою работу как на итеративный процесс, где предела совершенству нет. Будьте готовы раздолбать всё к чертям. Помните, что вы не делаете решение ради решения, а хотите решить проблему наилучшим образом. 3. Измените свою перспективу. Смотрите на "дыры" не как на провал, а как на возможность создать что-то крутое. Если вас жутко задевает, что каждый ставит своей целью раздраконить пошире ваше решение, представьте, что ВЫ наняли ИХ для этой работы. Подумайте, ведь многие платят большие деньги, чтобы найти уязвимости и сделать решение лучше, вам же дастаётся это всё бесплатно. Пускай все гнут ваше решение, но слава-то достанется вам. 4. Фильтруйте критику. Оценивайте критику на основе ее конструктивности и ценности для вашего развития. Игнорируйте негативные и необоснованные комментарии, фокусируйтесь на тех, кто дает конструктивную обратную связь. 5. Общайтесь с коллегами и поддерживайте сообщество вокруг себя. Порой, боязнь критики — это проявление неуверенности, которую мы испытываем по отношению к другим. «Кто знает, чего можно ожидать от этих подлецов?!» нужно заменить на «Мы и мои креша сейчас свернём горы!» Не сопротивляйтесь друг другу, а становитесь командой. 6. Начните хвалить других. Покажите, что можно не только критиковать, но и признавать и ценить труд и успехи других людей. Поддерживайте их в их достижениях и делайте комплименты, добавьте «плюс» в систему координат команды. Надеюсь, этот небольшой пост поможем вам почувствовать себя лучше и понять, что вы не одни :)

Мне где-то попалась информация о том, что наша профессия является самой стрессогенной в ITшке. И это не просто соревнование по болячкам среди бабушек, где побеждает тот, кто ближе к смерти, а вполне логичное утверждение. Поскольку наша работа находится в самом начале цикла разработки, мы проходим через больше итераций: постоянные согласования и правки с заказчиками, ревью БА и технической команды, пользовательские валидации и даже полезные советы от коллег, родственников и троюродной бабки вашего внучатого племянника. Все эти итерации, конечно же, делают конечный продукт лучше, но блин, как сложно отделить свою личность от работы! Ты трудился, создавал решение, напрягал мозг, а потом приносишь свою работу на ревью команде и вместо ожидаемого "Вау, крутое решение!" слышишь неожиданное "Ну, это ужасное говно, ты же ещё переделаешь?!". Казалось бы, люди не понимают, что можно просто согласиться с решением, а вместо этого достают биты и начинают челленджить твою работу. Если она выжило — норм, если нет — значит, это было говно. Либо ноль, либо минус, в позитив никто никогда не уходит. Благодари бога, если ты работаешь не в такой среде, где каждый считает себя профессионалом и каждое тривиальное решение превращается в кровавую баню. Но, к сожалению, это происходит довольно часто. Никто не задумывается о чувствах дизайнера, ведь его работа — приносить решения, а мы будем их проверять, и что тут ныть-то. Дизайнеры, особенно молодые, не всегда могут воспринять критику без переноса на свой счёт. Ведь это они создали то, что команда сейчас разносит в щепы. Значит, решение не работает, а значит, я плохой дизайнер, а значит, я плохой человек, и зря я вообще встал с кровати. Я не говорю, что другим профессионалам жить проще, но такого количества критики у них нет. И что же делать?

Привет, ребята. Сегодня столкнулся с одной очень интересной проблемой, но не UX-ного, а доказательного характера. Если вам когда-либо нужно было убедить кого-то в том, что нельзя утрамбовывать весь контент десктопа в 600 пикселей высоты, то вы меня поймёте. Согласитесь, когда кто-то говорит «Мы получили фидбэк от пользователя, что на его мониторе наше приложение не показывает сразу полезный контент», довольно сложно сразу подобрать достаточно весомый аргумент, чтобы придушить эту предъяву в зародыше. Ведь получается, что ты, как дизайнер должен слушать пользователя, а он говорит, что ему ничего не видно, так что давай, пихай. Но не спешите доставать палку-трамбовалку. Худшее, что вы можете сделать — это сразу принимать какие-то решения. Сперва возьмите паузу на подумать и собрать некоторые факты. 🤔 Откуда пришёл запрос. Возможно, за пользователей фидбэк приняли обращение в суппорт с мобильного устройства, когда на продукте респонсивом и не пахнет. В таком случае, нужно не контент упаковывать, а адресовать корневую проблему. Второй возможный сценарий — это единичный всплеск злобы, когда один человек из 1997 года с монитором 11’ слишком быстро отсидел очередь в поликлинике и ему не хватило приключений в этот скучный вторник, и он решил сделать ваш сервис лучше. Такие запросы, уж простите, я рекомендую вам игнорировать, иначе вы сделаете хуже вашей основной группе пользователей. Хотя может случиться и третий сценарий, когда такие обращения — не единичный случай. Тогда идём дальше. 😰 Смотрим в аналитику. Даже если у вас стоит базовый пакет, из коробочки видно какими девайсами пользуются люди. И если вашим самым распространённым разрешением окажется 1960×1080, то на него вам и стоит ориентироваться, а не плясать под дудку меньшинства (больше о таком феномене можно узнать из книги Нассима Талеба «Рискуя собственной шкурой»). Если вооружившись этими аргументами вам всё равно кажется, что вы недостаточно готовы, то вот вам несколько «больших стволов», для придания веса вашим аргументам: 1. Above the fold — чтобы развеять миф о том, что нужно всё упихнуть в один экран (там же ссылки на доп источники). 2. Исследование NN-Group о взаимодействии со скроллом. 3. Про мощь белого пространства и его влияние на UX-метрики со ссылками на исследования. Ну теперь вы точно готовы… хотя это не 100% гарантия, но губёшками чвякать и ловить ртом воздух, аки дикий карась, вам теперь не придётся. Приятной аргументации.

Наткнулся на интригующий пресейл для Ford от Пола Ренда за март 1966 год. И пусть, насколько я знаю, этот навеянный конструктивизмом ребрендинг никогда не увидел свет, презентация вполне достойна и дня сегодняшнего. Всё на месте: и метафоры, и отсыл к эмоциям и куча мокапов, и тесты размеров и контекстов… всё, как сегодня. Особенно интересно было наблюдать за ходом питча в тексте. Советую потратить 5 минут на вдохновение.

Ребята, простите, но по лигал причинам я пока удалил пост о нашей модели оценки дизайн-процесса на продуктах, но думаю, что в ближайшее время мы утрясём вопросики и доступ снова откроется.

Ребята, как и обещал, спешу поделиться с вами рассказом о Design Excellence framework, над которым мы работали последнее время. Сперва я начал писать пост в телеге, но результат получился уж слишком длинным, так что пришлось упаковать его в статью. Ну и конечно, мой внутренний перфекционист сказал: «Сделай для ребят шаблон в коде, чтобы они могли оценить свои продукты и получить список рекомендаций…» и я не смог устоять. Потому времени ушло поболе, но вот мы здесь. 👉 Сама модель, на пробу. 👉 Форма для обратной связи. Скажите, что думаете по поводу инициативы, или поделитесь своими мыслями, как и что можно улучшить. Вместе у нас получится сделать больше и лучше :)