Стакан UX-писателя всегда наполовину полон.

Не «Информация исчезнет через 5 дней», а «Информация будет доступна ещё 5 дней».

Не «Договор расторгнут», а «Нужен новый договор».

Не «Заплатите, иначе услуга будет приостановлена», а «Чтобы продолжать пользоваться, заплатите до 7 марта».

Не «Услуга доступна не чаще 2 раз в год», а «Можно пользоваться 2 раза в год».

В мире и так много негатива и коронавируса, зачем ещё в приложениях нагнетать?

Найти рынок

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

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

Есть две короткие истории про это.

1. Дженифер классно писала эссе в институте. Ее одногрупница попросила помочь, но Джен была сильно занята. Тогда ей предложили выполнить работу за $20 (нащупывается рынок).

Заказ за заказом и Дженифер наняла себе в помощь других писателей. Так родился продукт EssayService.

2. Джилбоа - парень, который носит очки, как-то потерял их во время своего путешествия. Они просто выпали у него из рюкзака. Он провел небольшой ресерч для покупки новой пары и обнаружил, что наценка составляет Х10-20 от себестоимости.

Вместе со своим одноклассником Нейлом ребята основали небольшую компанию WarbyParker, которая продавала очки гораздо дешевле, чем ее конкуренты. Стоимость их бизнеса оценивается в $200 млн.

Энтони из UX Movement написал, как показать в переключателе, какой вариант выбран.

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

Вместо инвертирования цвета может быть:

  • лёгкое затенение цвета заливки,
  • более жирная и тёмная обводка,
  • полужирное начертание текста.

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

https://ux.pub/pochemu-knopki-pereklyucheniya-toggle-buttons-sbivayut-s-tolku/

Core Protocols

Когда я пришел в ManyChat, я первый раз услышал про LeSS и пошел читать методичку. А в методичке по LeSS я наткнулся на отсылку к Core Protocols, про которые не слышал раньше, и тоже пошел читать про них.

И если вкратце, Core Protocols — это система фасилитационных техник, направленных на улучшение коммуникации внутри команд.

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

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

На деле получилось 2 списка: список коммитов (обязательств) и список самих протоколов, которые выложены в открытый доступ с открытой лицензией, как софт, и которые со временем дополняются, изменяются, актуализируются.

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

Я их переведу на русский со своими комментариями, и если вы найдете более емкие формулировки, то пишите, я дополню/исправлю:

1) Я обязуюсь участвовать, когда присутствую
Это про то, что если участвуешь во встрече, то участвуешь, а не залипаешь в ноутбуке. Дополнительно расширяется на личную внутреннюю осознанность. Если что-то делаешь, то понимаешь зачем.

2) Я буду стремиться больше воспринимать, чем быть воспринимаемым
Это про то, чтобы слушать и пытаться понять аргументы, а не продавливать свою точку зрения любыми средствами.

3) Я буду использовать команды, особенно при выполнении сложных задач
Это про помощь. Ты должен пользоваться всеми видами помощи, которые можешь получить от людей вокруг, а не пытаться супергеройски вытащить проект, перегореть и уволиться.

4) Я буду говорить всегда и только тогда, когда верю, что это улучшит соотношение усилие/результат
Это про осознанное высказывание мыслей. Не нужно говорить просто, чтобы стать заметным для кого-то на встрече.

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

6) Я буду избегать непродуктивных ситуаций
Если понимаешь, что 23 встречи в неделю не приводят к результату, отмечаешь это, и стараешься не участвовать им, не мешая при этом другим.

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

8) Я буду стремиться двигаться к цели, смещая свое поведение в сторону действия
Всегда разгоняй активным действием, создавай положительную инерцию, которую сложно остановить даже самыми тупыми действиями и комментариями.

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

10) Я никому не причиню вреда—и не потерплю причинения вреда—за его или ее верность этим обязательствам
Если закомитились на core protocols, то не нужно закатывать глаза и проявлять агрессию (даже пассивную), когда тебе кто-то подсветил, что ты наваливаешь не в ту сторону.

11) Я никогда не буду делать ничего глупого нарочно
Вот да!

Это только верхушка, в следующий раз посмотрим на сами коммиты.

Вообще очень рекомендую прочитать оригинал текста с коммитами вот здесь — https://liveingreatness.com/core-protocols/the-core-commitments/

Про формальный vs реальный дизайн-процесс

Про формальный vs реальный дизайн-процесс

Цитата про формальный vs реальный дизайн-процесс из эссе Майкла Бейрута —дизайнера и сейчас партнера Pentagram, команда которого работала над новыми логотипами Mastercard, Slack, Yahoo, Verizon и дизайном предвыборной компании Хиллари Клинтон.

-----

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

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

Это могло бы звучать примерно так:
«Работая над дизайн-проектом, я поначалу внимательно слушаю, как вы рассказываете о вашей задаче, и читаю все найденные справочные материалы по проблемам, с которыми вы сталкиваетесь. Если вам повезет, у меня случайно окажется личный опыт работы в ситуации, похожей на вашу. Идея дизайна появляется в моей голове по ходу процесса, из ниоткуда. Я не могу это объяснить; это сродни магии. Иногда это случается даже раньше, чем вы успеваете рассказать мне о вашей задаче! Если идея хороша, я стараюсь придумать стратегическое обоснование такого решения, чтобы объяснить его вам, не полагаясь на хороший вкус, который у вас может отсутствовать. По ходу я могу предлагать другие идеи либо потому, что вы заставили меня согласиться на это, либо потому, что не уверен в первой идее. Во всяком случае, надеюсь, на ранних этапах я сумею заручиться вашим доверием и к этому моменту вы будете готовы принять мои рекомендации. Понятия не имею, как вы собираетесь проверять их пригодность, за исключением того, что в прошлом другие люди — по крайней мере те, о которых я вам рассказал, — последовали моему совету и преуспели. Иными словами, не могли бы вы просто, ну, знаете... верить мне?»

-----

Конец цитаты.

HTML-разметка — это просто текст, который делит страницу на смысловые (и не очень) блоки

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

Потом к узлам применяются CSS-стили и получается та страница, которую мы видим в браузере.

К любому из узлов можно обратиться через JS как к объекту, чтобы узнать и изменить их свойства или содержимое, создать новые узлы или удалить старые. Структура этих объектов и называется DOM — Document Object Model. Она нужна для того, чтобы вы могли динамически менять содержимое документа после его загрузки в браузер.

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