Интерфейсы *

Дата — это всего три числа, но даже такой маленький элемент интерфейса может серьезно повлиять на пользовательский опыт.

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

В этой статье я расскажу, какие недостатки есть у локализации на этапе разработки, как их решает локализация на этапе дизайна, а также о том, с какими вызовами можно столкнуться, применяя этот подход. Статья будет интересна продакт и проджект менеджерам, UX-дизайнерам и писателям и, конечно, всем специалистам в области локализации ИТ-продуктов.

Делимся опытом работы над интерфейсами антивирусного программного обеспечения PRO32. Наша задача заключалась в обновлении дизайна и улучшении пользовательского опыта. Как мы справились с этой задачей, с какими трудностями столкнулись и как в итоге ускорили процесс работы — рассказываем в статье.

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

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

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

Привет! Я Илона Арзуманян, лид продуктового дизайна веб-канала в t2 Digital. Сегодня я хочу рассказать про такую крутую командную активность как прожарка. Если вы думаете, что это мероприятие, на котором все друг про друга шутят (и иногда очень даже обидно), то в нашем контексте это не так. Мы называем так активность, в рамках которой мы разбираем по косточкам флоу и интерфейсы других компаний, причем рассматриваем и UX, и UI. Это классно развивает критическое мышление и насмотренность. В этой статье я расскажу зачем это нужно, как мы это делаем и как на это смотрит команда.

Почему прожарка – это круто?

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

Структура мини-курса Мини-курс API-интерфейсы для самых маленьких.

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

За последние годы скорость развития технологий для создания фронтенд-приложений выросла в разы. Новые фреймворки, библиотеки, инструменты сборки и подходы к разработке появляются практически каждый год. Однако, несмотря на это, основная точка взаимодействия пользователя с продуктом остаётся неизменной — это интерфейс. Именно он формирует впечатление о продукте и, по сути, является окончательной «витриной» всей вашей работы.

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

В Главе 6 мы узнали о проектировании API, создавая свои собственные. На данный момент у нас есть много с трудом заработанных знаний, и пришло время, чтобы они начали приносить пользу. Мы готовы увидеть, как мы можем заставить API работать на нас. В этой главе мы узнаем четыре способа достижения коммуникации в реальном времени через API.

Структура мини-курса Мини-курс API-интерфейсы для самых маленьких.

Глава 6 знаменует собой поворотный момент в нашем приключении с API. Мы закончили рассматривать основы и теперь готовы увидеть, как предыдущие концепции объединяются, чтобы сформировать API. В этой главе мы обсудим компоненты API, проектируя его.

Недавно разбирал любопытные материалы про замену на атомоходе пультов управления с традиционных на сенсорные. Там персонал взвыл от плохого и непродуманного интерфейса управления силовой установкой и каким-то там важным валом. Раньше для управления этими критическими величинами использовалась приличных таких размеров очень хваткая круглая рукоятка (задатчик), оператор обхватывал её всей ладонью и её поворотом на механическом кольце выставлял нужную величину. Чтобы персоналу было привычнее, на сенсорном экране управление этими величинами сделали тоже круговым – нужно поставить пальчик на экран и двигать по кругу виртуальную ручку. Пальчиком по кругу. На корабле. Вы всё правильно поняли. Кстати, при использовании традиционных (не сенсорных) задатчика и средств отображения информации вероятность безошибочного решения оператором этой задачи составляла 0,992. Для сенсорных панелей такие исследования не проводились (почему бы это, а?).

Привет, Хабр! На связи UX-редакция ecom.tech. Наша команда занимается созданием текстов для интерфейса Самоката. Мы помогаем поддерживать голос бренда, делаем приложение и сайт удобным и понятным для пользователя. В этой статье расскажем, как сделать сайт понятным, писать просто о сложном и не раздражать пользователей текстами. Рассказываем всё на примере сайта Самоката.

В Главе 4 мы упомянули, что большинство веб-сайтов используют имя пользователя и пароль для аутентификации учетных данных. Мы также обсудили, что повторное использование этих учетных данных для доступа к API небезопасно, поэтому API часто требуют другой набор учетных данных, нежели те, которые используются для входа на веб-сайт. Распространенным примером являются ключи API. В этой главе мы рассмотрим другое решение — открытую авторизацию (OAuth), которая становится наиболее широко используемой схемой аутентификации в Интернете.

В нашем понимании API все начинает проясняться. Мы знаем, кто такие клиент и сервер, мы знаем, что они используют HTTP для общения друг с другом, и мы знаем, что они используют в определенные форматы данных, чтобы понимать друг друга. Однако знание того, как общаться, оставляет важный вопрос: как сервер узнает, что клиент — тот, за кого себя выдает? В этой главе мы рассмотрим два способа, которыми клиент может доказать свою идентичность серверу.

Глава 3: Типы и форматы API

До сих пор мы узнали, что HTTP (протокол передачи гипертекста) (Hyper-Text Transfer Protocol) является основой API в сети и что для их использования нам нужно знать, как работает HTTP. В этой главе мы рассмотрим данные, предоставляемые API, как они форматируются и как HTTP делает это возможным.

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

Что думают об этом архитекторы, разрабатывающие и принимающие эти сервисы?
Опыт показывает, что они подозревают, что что‑то идет не так. А дальше включается традиционный иерархический менталитет, где даже самое благое предложение, оспаривающее чье‑то решение, может очень быстро привести автора на мороз с нелестными рекомендациями.

Да и понятно, что не предложишь внезапно начать развивать то, чего еще нету, требований на это ниоткуда не спускалось, в списке бизнес‑целей оно тоже не наблюдается.

Что есть общение пользователя с сервисами, включая разные госуслуги?
HCI — человеко‑машинное взаимодействие.

Привет, Хабр! Это Михаил, product owner мобильного приложения М2, и Антон, продуктовый дизайнер в M2. Мы работаем над мобильным приложением, которое позволяет проводить сделки с недвижимостью онлайн как частным лицам, так и профи рынка — удобно и быстро. В 2024 году рынок недвижимости пережил кризис: льготную ипотеку отменили, количество сделок сократилось. Но нашему приложению удалось не только удержаться на рынке, но и увеличить продажи. Один из ключевых факторов успеха — редизайн главной страницы приложения.

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

Привет! Я Ваня Соловьёв, руководитель продуктового дизайна в Магните. Эта статья написана для тех, кто готовится к переходу на роль дизайн-лида или уже пробует себя в этой роли и сталкивается с первыми трудностями. Я расскажу, что вас ждёт на новой должности, какие навыки стоит развивать и как достигать бизнес-целей вместе с командой.

Так круто, что одной статьей можно сделать жизнь людей, чуть-чуть, но все же проще. Ни славы, ни благодарности, ни вознаграждения за свой вклад в развитие продукта я не получил, но разве только для этого человек живет и трудится? Я искренне убежден, что — нет. Я могу себе позволить день работы, чтобы уставшего после трудового дня, честного человека не «бесила» клавиатура VK Видео или RuTube при поиске очередной серии любимого сериала.

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