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

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

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

Но проблема в том, с чего начать? Какие принципы из психологии полезны? Каковы примеры этих принципов в работе? В этой статье мы рассмотрим основы и обсудим этические последствия использования психологии в дизайне.

В последние недели участилась волна статей на хабре о том, как проводятся собеседования.

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

Нет, я не стал рекрутером. Процесс собеседования предполагает сперва разговор с рекрутером. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).

Мне довелось создать с нуля подразделение дизайна в Альфа-Банке и поработать дизайн-директором. На это ушло пять лет. В результате у нас получилась дизайн-система (в коде) и подход к диайну цифровых продуктов. Собственно, про этот подход я и расскажу здесь. Точнее, это — текст лекции, которую я читал в начале 2018 года в Москве, Перми, Новосибирске и Петербурге. В мае я принял решение покинуть банк, теперь дошли руки опубликовать текст лекции.

В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).

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

В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.

Привет, Хабр! представляю вашему вниманию достаточно свободный перевод статьи Ника Бабича.

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

Что такое геймификация

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

«Хорошо там, где нас нет» — думают многие и годами живут на одном и том же месте. Но мир слишком разнообразен, чтобы всю жизнь провести в одной стране.

Карта каналов об эмиграции

На помощь приходит Telegram, где в последние годы появилось уникальное сообщество авторов жанра «я — эмигрант».

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

Какие на самом деле жители выбранной ими страны? Как найти жилье? Как устроится на работу? В чем отличия менталитета? Или даже Как проходят свидания? Как строится личная жизнь в другой стране? Такого нет в Google! :)

Я собрал максимально большой список таких блогов, отсортировал по странам и делюсь с вами.

Вступление

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

Я, автор, Юра Перов, занимаюсь вероятностным программированием в течение уже двух лет в рамках своей основной учебно-научной деятельности. Продуктивное знакомство с вероятностным программированием у меня сложилось, когда будучи студентом Института математики и фундаментальной информатики Сибирского федерального университета, я проходил стажировку в Лаборатории компьютерных наук и искусственного интеллекта в Массачусетском технологическом институте под руководством профессора Джошуа Тененбаума и доктора Викаша Мансингхи, а затем продолжилось на Факультете технических наук Оксфордского университета, где на данный момент я являюсь студентом-магистром под руководством профессора Френка Вуда.

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

«Обычное» программирование

Для знакомства с вероятностным программирование давайте сначала поговорим об «обычном» программировании. В «обычном» программировании основой является алгоритм, обычно детерминированный, который позволяет нам из входных данных получить выходные по четко установленным правилам.

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

В Google Play есть одно приложение, разработанное Chilango Lab, у которого больше миллиона загрузок и довольно высокий рейтинг. Называется оно Nothing, что можно перевести как «Ничто», и замечательно оно тем, что не делает абсолютно ничего. В нём, правда, спрятана приятная пасхалка, но это не меняет дела. Если проанализировать это приложение, то окажется, что его размер — 14 Мб, при установке оно занимает 19,24 Мб.

Автор материала, перевод которого мы сегодня публикуем, говорит, что глядя на это приложение, он задался вопросом о том, можно ли переписать его так, чтобы оно занимало меньше места.

Ему это удалось. А именно, он воссоздал функционал Nothing, используя HTML, CSS и JavaScript, оформив его в виде прогрессивного веб-приложения (PWA, Progressive Web App). Оно работает без подключения к интернету, вызывать его можно, как и обычное приложение, с главного экрана. Основная разница между обычным Android-приложением и его PWA-копией заключается в размерах. Первое, напомним, занимает на устройстве 19,24 Мб. Второе — 205 Кб.

Cоавтор статьи: Mike Cheng

Google Cloud Platform теперь в своем портфолио имеет образы виртуальных машин, разработанные специально для тех, кто занимается Deep Learning. Сегодня мы поговорим о том что эти образы из себя представляют, какие преимущества они дают разработчикам и исследователям, ну и само собой о том, как создать виртуальную машину на их базе.

(Art by http://www.simonstalenhag.se/)

Предыстория / Дисклеймер

Всем привет, данная статья является по факту материалом для моего выступления в понедельник на марафоне в Киеве. Но не думайте, что вы аудитория на которой я отрабатываю текст, просто мне так проще подготовиться.

На данный момент я Front-end разработчик в Conductor/WeWork. Мы не занимаемся разработкой редакторов, как собственно и я, по вечерам не разрабатываю такие вещи. Это больше об опыте который я получил на прошлом проекте в компании УТИ(сокращенно), утипути, ути-…. Это было достаточно давно, но как оказывается, тема актуальна и по сей день, как и косяки связанные с ней.

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

UTIEditor special for you <3

Зачем нам нужны такие редакторы?

Тут достаточно много ответов на этот вопрос, многие из вас, я уверен догадываются и так.
Я отвечу на этот вопрос с точки зрения УТИ, компании которая предоставляет услуги по разработке сайтов.

УТИ по сути своей — компания ширпотреб. Уверен в свое время в таких поработал каждый, десяток сайт визиток на человека, десяток интернет магазинов и фирменная вишенка — своя CMS.

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

Тут пожалуй стоит перейти к обсуждению этого функционала, ведь он очень разный.
Хотелось бы добавить, что я не буду включать в этот разговор такие CMS как WrodPress, Drupal, мы сконцентрируемся на рынке редакторов.

Человеческое тело физически не способно пробежать марафон (42 километра) меньше, чем за 1 час 58 минут. Это вычислил в 1991 году американский физик Майкл Джойнер. Он принял во внимание три фактора: максимальный объем кислорода, который способен потребить атлет, темпы распространения молочной кислоты по мышцам и максимальную эффективность бега. 1 час 58 минут – при всех идеальных условиях, и идеальном спортсмене, который не расходует энергию в своем теле ни на что, кроме бега.

В первом Олимпийском марафоне, в 1896-м, победитель, Спиридон Луис из Греции, пробежал дистанцию за 2 часа и 58 минут. Люди долго не могли поверить, что кто-то может сделать это быстрее, чем за два с половиной часа, пока в дело не вступили кенийские бегуны, славящиеся своей идеальной комплекцией для преодоления больших дистанций.

Самое быстрое время, за которое спортсмен когда-либо преодолевал марафон, сейчас составляет 2 часа, 2 минуты и 57 секунд.

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

Часто ли Вы сталкивались с таким явлением, как нерациональное распределение обязанностей? Сколько раз приходилось наблюдать за тем, как один человек «на все руки мастер» выполняет работу за пятерых? А так называемый «специалист, занимающийся не понятно чем» — знакомо? Такие варианты, а также им подобные нередко приходилось видеть ранее в отечественных реалиях. Этот же «совок» многим приходится наблюдать, и что хуже, чувствовать на своей личной шкуре и поныне во многих госструктурах.

О таком умном словосочетании, как «разделение полномочий» говорят часто. Но все ли знают, как его применять на практике, и кому удается этим реально воспользоваться? Приглядевшись внимательно, делаем вывод, что такое явление происходит по большому счету, в компаниях частного сектора, в особенности тех, кто работает с иностранным клиентом.

Именно из-за «бугра» до нас дошла любопытная аббревиатура под названием RACI. При этом, зачастую перед ней можно наблюдать разного рода умности а-ля «матрица» или «модель». Что это и с чем его едят, попытаюсь объяснить читателю далее. Возможно, кому-то уже повезло работать в коллективах, где каждый знает свои обязанности и область ответственности – за таких людей можно только порадоваться. При этом лично я верю, что далеко не у всех всё идеально в сфере разделения полномочий. Для таких людей данная статья может оказаться полезной.

Прочитал относительно недавнюю публикацию о видеонаблюдении и решил описать свой опыт. Считаю мое решение оптимальным по соотношению цена/функциональность, но с удовольствием выслушаю критику более опытных людей.

Итак, задача — минимальными материальными и временными ресурсами сделать видеонаблюдение в подъезде перед входной (в квартиру) дверью. Желательно не записывать круглые сутки “пустые” картинки, т.е. необходимо детектирование движения. Также хорошо бы иметь удаленный доступ к записям.

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

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

Ширина экрана мобильного устройства чаще всего небольшая, поэтому есть необходимость сокращать. При этом, кроме технической ширины, хочется учитывать еще и эстетическое восприятие и не грузить интерфейс лишними сущностями. Аналогичная ситуация с инпутами в вебе. Усугубляется ситуация на мелких устройствах типа часов и разного рода небольших дисплеях.

Например, получаются вот такие странные штуки:

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

В тесте принимали участие следующие программы.

Для PNG:

1. Leanify 0.4.3 (x64)
2. pingo v0.79c
3. pinga v0.09
4. OptiPNG 0.7.6
5. pngout
6. PngOptimizer 2.5 (x64)
7. advpng aka AdvanceCOMP v1.23
8. ECT 0.6 (x64)
9. TruePNG 0.6.2.2
10. pngwolf-zopfli 1.1.1 (x64)

Для JPEG:

1. Leanify 0.4.3 (x64)
2. pingo v0.79c
3. ECT 0.6 (x64)
4. mozjpeg 3.2 (x64)
5. jhead 3.00
6. jpegoptim v1.4.4 (x64)
7. jpegtran

Уже семь лет я публикую регулярные обзоры свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-февраль 2017.

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Компания Soasta предоставляет ряд сервисов для аналитики и тестирования сайтов. Специалисты компании использовали огромный массив данных, собранный их системой аналитики, в машинном обучении с целью определить, какие взаимосвязи между различными показателями обнаружит искусственный интеллект. Тэмми Эвертс из Soasta и Пэт Минан из Google представили результаты на конференции Velocity 2016, проходившей в Нью-Йорке в сентябре 2016 года.

Исследование проводилось в отношении двух конечных результатов взаимодействия пользователя с сайтом – отказов и конверсий. То есть исследователи пытались научить искусственный интеллект «отгадывать» с большой вероятностью на основании различных признаков уйдет ли пользователь со страницы не совершив никаких действий (отказ), и совершит ли он конверсию.