Чтобы обратиться к какому-либо узлу, его сначала надо найти

Для этого есть разные методы, но в современном прототипировании чаще всего применяются два метода:

let el = document.querySelector(selector)
и
let elems = document.querySelectorAll(selector)

Оба метода получают на вход CSS-селектор элемента. Например:

let el = document.querySelector(".someClass b");

Отличие их в том, что querySelector вернёт один узел, который попался первым, а querySelectorAll вернёт список всех узлов на странице, соответствующих селектору.

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

Если же вам всё-таки нужен метод map, то вы можете преобразовать список узлов в массив при помощи конструкции [...nodeList]:

let arr = document.querySelecroAll("a");
[...arr].map(el => el.innerText);

Подробнее в видео: https://youtu.be/KIBv7QMToP4
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Действие, не состояние

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

Неизвестная ошибка

Кажется, что просто сообщили информацию. Но мы же сделали это для какой-то цели? Наверное, чтобы пользователь сделал какое-то действие с этой информацией: обратился в поддержку, вернулся на предыдущий этап и больше не пытался или чтобы попробовал снова.

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

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

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

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Bad Blood

А я тем временем принесла вам обзор на книгу Bad Blood (в русском переводе - Дурная кровь) от Джона Каррейру.

Книга рассказывает историю стартапа-единорога "Теранос", который должен был произвести революцию в сфере здравоохранения и получил оценку в 10 миллиардов долларов – но за 15 лет существования так и не смог произвести на свет работающую и лицензированную технологию. Сейчас идет судебное разбирательство над основательницей компании Элизабет Холмс.

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

Книгу я однозначно рекомендую, хоть это и не бизнес-литература.

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

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

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

На выходе: набор задач на проектирование и разработку, привязанных к пользовательским историям.

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Хочу с вами сегодня поделиться несколькими правилами, которые помогают держать мой календарь (и встречи) под контролем.

1. У нас в команде есть no meetings Wednesday - день без встреч. Это договоренность с командой, что в этот день встречи мы не назначаем и полностью блокируем день. Очень крутая штука для фокуса! Важно, что такая традиция должна уважаться не только другими людьми в вашей компании, но и вами самим: если вам прилетает приглашение на этот день, обязательно спрашивайте – насколько это срочно? В большинстве случаев люди спокойно готовы подождать несколько дней.

2. Я также блокирую как минимум один часовой слот в день под сфокусированную работу и бронирую "встречи" на то время, когда я недоступна (например, с 6 до 10 вечера). Еще лучше, если на то время, когда вы хотите уходить с работы, у вас стоит какое-то занятие (например, спорт).

3. В пятницу вечером я смотрю на свое расписание на следующей неделе и стараюсь, чтобы все встречи организовывались в блоки. Если у вас 3 встречи и между ними по получасовому перерыву, это крайне непродуктивно: скорее всего, все эти перерывы вы либо будете прокрастинировать (так как не сможете быстро переключить контекст), либо сделаете какие-то мелкие дела типа проверки почты. Если же переставить встречи в один полуторачасовой блок, у вас появится дополнительный час, который можно потратить уже на более крупные задачи.

4. Я никогда не участвую во встречах, где непонятна повестка и ценность от моего участия. Если прилетает приглашение типа "Анна-Антон" или "Проект Х", я всегда отправляю автоматический ответ – а какая цель у этой встречи и зачем я вам там нужна? Удивительно, но часто этот вопрос приводит к тому, что вся встреча отменяется, и вопрос решается в другом формате (через чат или таски, например).

5. Дефолтная продолжительность моих встреч - 25 минут; 5 минут на то, чтобы осмыслить action items и переключить контекст на следующий митинг.

6. Если вы идете на встречу, уважайте своих коллег: будьте вовлечены в дискуссию, не сидите в телефоне и закройте-таки свой ноутбук.

@proproduct

Розыгрыш брифов!

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

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

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

Итак, посмотрим на то, какие еще проекты были представлены:

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

Revolut
Сервис по выгодному обмену курсов для путешественников. Выросли из этого, хотят быть круче, чем банк. Круто то, что проект международный. Цель проекта — предоставить пользователю различные банковские продукты в нужный момент времени (например, страховку в момент, когда пользователь приезжает в аэропорт)

SkyEng
Стартап, который уже давно не стартап. Цель проекта — удовлетворить запрос пользователей, которые хотят путешествовать.

Profi.ru
С лета 14 года помогают людям найти частных специалистов для решения любых задач. Все началось с доски объявлений на сайте университета по поиску репетиторов, сегодня это огромный сервис по поиску специалистов в любой сфере.
Сервис хорош тем, что с точки зрения специалиста в нем достаточно низкий порог входа, а с точки зрения заказчика огромная база специалистов.
Уникальность сервиса заключается в том, что взаимодействие в нем строится по принципу частник-частник.

КосмоЗоо
Однажды родился такой проект — московский космический зоопарк. Его целью является желание соединить ветеринаров и владельцев домашних животных. Ребятам предстоит изучить много нового в области домашних животных.

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