Всем привет! 

Меня зовут Курилкина Арина, я почти год являюсь фронтенд-разработчиком интеграционных и инфраструктурных сервисов склада. Также я 2,5 года разрабатывала мессенджер для сайтов Покупателя (Buyer Experience или же, как мы у себя говорим, — BX) и Продавца (Seller Experience — SX). Таким образом, я успела поработать с продуктами трёх крупных структур Ozon: BX, SX и Warehouse (Складские сервисы*).

Каждая структура уникальна, имеет свои потребности, свои проблемы и свои решения. И каждая является неотъемлемой частью функционирования компании Ozon. Своеобразные три кита, на которых стоит маркетплейс. Поработав с каждым из них, я посмотрела на клиентскую разработку и на работу с дизайн-системами и UI-kit’ами, в частности, с разных сторон. И теперь я хочу поделиться своим опытом.

Моя статья может быть полезна всем тем, кто хочет разобраться в принципах взаимодействия с дизайн-системами и UI-kit и научиться эффективно использовать их в своих проектах.

Представьте ситуацию: вы исследуете клиентский опыт, никого не трогаете и тут вас просят оценить, насколько участники IT-команды довольны инструментами Data Platform. Метрик вам, кстати, не дают — их вы должны выделить сами.

Случалось в вами такое? Со мной — да. Меня зовут Рамиля, я — лидер маркетинговых исследований в Додо. Сегодня расскажу, как оценить удовлетворённость сотрудников дата-инфраструктурой. Ну и гайдом обязательно поделюсь!

Совместная работа дизайнеров и разработчиков — важный аспект не только для эффективности продуктов и бизнеса, но и для комфортной работы в долгосроке. Поэтому хочу поделиться своим опытом и подходом, который поможет дизайнерам выстроить эффективный процесс взаимодействия с командами разработки. Я реализовала индивидуальный план развития в рамках работы в продуктовой команде. Мой путь к этому решению был непростым: через ошибки, которых можно было избежать, анализ и глубокую внутреннюю работу. 

Статья будет полезна не только дизайнерам, но и разработчикам. Так вы сможете посмотреть на себя и свою работу со стороны, понять, как вас воспринимают дизайнеры, и, возможно, пересмотреть свое отношение к дизайн-процессу. Давайте начнём!

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

Представьте себе страшный сон тестировщика и в целом вашей команды – пользователи пишут в поддержку, что пуши не приходят, сообщения не доходят, а вы никак не можете воспроизвести проблему и у вас даже нет понимания: а как это воспроизводить, от чего вообще зависит доставка пушей?

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

Поэтому эта статья перед вами!

На собеседованиях iOS-разработчиков часто спрашивают о сложных лейаутах коллекций. Мы решили использовать их для геймификации программы лояльности в нашем приложении.

А это возможно? Сначала казалось, что нет. Но мы это сделали. Нарисовали, анимировали и спрятали за пределы экрана ячейку с секретной акцией, у которой даже отрывается корешок! И всё с помощью UICollectionView. О том, как у нас это получилось, я сегодня и расскажу.

Привет, я Арсен – UX/UI-дизайнер. А тут я собрал плагины для Figma, которыми я пользуюсь регулярно при работп с компонентами и организации ui-китов. Это не глупенький список дизайн-инфлюенсера из линкедина, а реальный выпаренный-вываренный концентрат полезных плагинов, лучших в своей категории.

До этого года я спокойно пользовался терминалом для установки android приложений на тестовые устройства: каждый раз вручную копировал название файла, выбирал нужную команду из истории терминала, стирал старое название и вставлял новое. Это меня очень раздражало, но я не искал решений.

А ведь кроме установки, есть множество других команд ADB, которые приходится использовать время от времени. Например, отправка фалов на устройство или выгрузка последних логов из logcat на компьютер, для чего тоже нужно было прописывать путь для сохранения файла — очень неудобно и отнимает драгоценное время.

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

В конце статьи ссылки на готовые команды 🌚

Меня зовут Александра, я дизайнер из Ozon в SX — Seller Experience. Сегодня расскажу продуктовую историю о таблицах и дизайн-долге.

Иногда приходится работать с устаревшими системами, при этом ресурсов на улучшение нет, и поэтому новые доработки внедряются с минимальными изменениями. Каждая новая функциональность всё больше и больше усложняет систему, делая её сложной для использования, а новым сотрудникам тяжело вникать в проект (да, легаси бывает не только у разработчиков). 

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

Если вы не знаете, что такое don’t keep activities, и не понимаете, что может произойти с приложением, когда вы его сворачиваете или когда меняете тему системы на тёмную, то можете считать, что ваше приложение не протестировано!

Что происходит под капотом вашего android приложения, зачем это знать тестировщику, какие критические сценарии можно и нужно проверять основываясь на жизненном цикле activity, и как это убережёт вас от краша на проде.

Мы сделали гайд для создания user-friendly интерфейсов. Он будет полезен не только новичкам в UX-исследованиях, но и опытным исследователям, аналитикам и проектировщикам.

На сайт Альфа-Банка заходят миллионы посетителей. Кто-то оформит карту или кредит сразу, кто-то пойдёт сравнивать предложения на сайты других банков. Дизайн продаёт продукт и доносит ценность пользователю. Но как визуально выделиться, если за несколько лет дизайн раскопировали конкуренты?

В конце 2022 года мы взялись за редизайн. Получилось ли у нас, а главное — как вам подстелить соломку уже на старте проекта, расскажу в статье. Будет интересно не только дизайнерам, но и продактам, UX-исследователям и всем, кто собирал правки дизайна в десятки итераций.

Запускать мы будем Fooocus, но не простой, а слегка измененный мной. В Fooocus мне не нравилось две вещи: модель, которая загружается по умолчанию, и непонятное вычисление Guidance Scale.

Модель, загружаемая по умолчанию, изменена на Realism Engine SDXL v3.0 VAE. Со старта будут заданы оптимальные параметры для работы с ней.

Код вычисления Guidance Scale был изменен, т.к. в стандартной версии он вычислялся непонятным образом. Теперь все просто: задав нужную вам Guidance Scale, при генерации изображения вы получаете именно то значение, которое задали, а не что-то другое.

В presets добавлены дополнительные пресеты для загрузки стандартной модели SDXL и Realism Engine v1.0. Стандартная SDXL загружается вместе с рефайнером.

Недавно произошёл редизайн Figma⚹¹ и я решил поделиться своим очень важным мнением :)

Я UX/UI-дизайнер, то есть целевая аудитория Фигмы. На протяжении многих лет это мой основной инструмент работы, я облазил её вдоль и поперёк, был в числе первых бета-тестеров, кто пощупал авто-лэйауты и переменные. И теперь когда я заручился вашим доверием, могу переходить к критике и похвале интерфейса.

Внимание, в конце статьи есть полезные ссылки!

Привет, Хабр! Меня зовут Мария Бажина, я Android Developer в компании Звук. 

Вот уже полтора года я работаю над дизайн-системой, поэтому знаю здесь каждую мелочь. И в этой статье я хочу рассказать, зачем нам нужна дизайн-система и в каком виде она существует в нашем проекте. А также, что изменилось в архитектуре приложения и коде после ее внедрения. 

Спойлер – в результате разработка фич стала быстрее в 2 раза, сборка дизайн-макетов ускорилась в 3-4 раза, а UI приложения удалось избавить от хаоса из рандомных шрифтов и иконок и унифицировать. Подробнее – в статье. 

Logcat в Android Studio имеет множества функций, которые ускоряют отладку, тестирование и в целом поиск нужной информации в логах. Однако, большинство в лучшем случае использует только поиск по ключевому слову и даже не подозревают как сильно могут ускорить свою работу.

Здесь я расскажу про Logcat в Android Studio, какие у него есть возможности, как его кастомизировать и использовать по максимуму, с практическими советами в каких ситуациях та или иная фича может вам пригодиться. Материал будет полезен как начинающим тестировщикам, так и матёрым разработчикам, ведь это универсальный инструмент, ускоряющий работу, если знать о всех его хитростях.

Эта статья поверхностна, как водная гладь, по которой скачет камушек-блинчик. Каждый прыг — развилка на Пути дизайн-системы.

- Делать свою или взять готовую? Прыг.

- Платформенная или универсальная? Прыг.

- Версионировать компоненты или всю библиотеку? Прыг...

И ещё много таких «прыгов».

Давайте подготовимся к сложному контенту. Закроем глаза, успокоимся и представим идеальную дизайн-систему. Представили? Умные компоненты, продуманные паттерны, подробная документация. Автоматическая генерация кода. Кайф? А то! Только такая дизайн-система оставит нас без работы.

Сидит себе бизнес, кормит нейросетевой движок дизайн-системы джобс-ту-би-данами да си-джи-эмами и на выходе получает готовые экраны. Ни дизайнеров, ни фронтов нанимать не нужно.

Труднее всего тестировщику приходится в ситуациях, где даже не подозреваешь, что действуешь неправильно.

Сегодня я разберу 6 кейсов, с которыми время от времени сталкивается каждый QA, которые на первый взгляд кажутся не сложными, но потом становится ясно, что они приводят к неожиданным проблемам, незнание которых может сильно осложнить тестирование, а в худшем случае привести к проблемам релиза.

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

Некоторые события в календарной сетке являются регулярными, то есть повторяются с определённой периодичностью. Например, можно отметить в календаре день рождения бабушки, чтобы вовремя её поздравить. Бывают повторы посложнее — скажем, для тренировок в фитнес-клубе, которые проходят каждую среду и пятницу в 19:00. Чтобы не вносить в календарь каждую тренировку по отдельности, есть возможность настроить повторяющееся событие.

В ходе создания мобильного календаря для одного из наших продуктов нам требовалось проработать настройки сложного повтора — и сделать их понятными и удобными для пользователя. Под катом рассказываем о том, с какими проблемами мы столкнулись при проработке настроек сложного повтора, как проверили гипотезу с помощью исследования и выбрали в итоге оптимальное решение.