Не забывать напоминать

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

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

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

👉 Отправка почты по расписанию. Если кто-то мне что-то должен в определённый день, то я заранее отправляю отложенное письмо, которое придёт адресату за день до срока долга и напомнит. Примерно так: "Напоминаю, завтра жду от вас ...". Отложенная отправка есть и в Gmail, и в Яндекс почте и наверное, много где.

👉 Если долгов много — ставлю мероприятия в Гугл. Календарь, подключаю туда "должника" и в настройки ставлю: уведомить на почту за 1 день" (или несколько интервалов).

👉 Пару раз использовал отложенные сообщения в Телеграм (их недавняя опция) — тот же смысл, что и с почтой, но более личный.

👉 Можно задействовать Trello, подключая "должника" как исполнителя на задачи со сроком — этот путь чуть сложнее, так как требует вовлечения должника в Trello.

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

Илья Александров написал о дизайне предсерийного прототипа «Симкомата Х».

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

«Размещение сканера сверху (человеку не нужно поворачивать телефон экраном вниз) кажется более логичным, и за него были разработчики. Но в нём был огромный недостаток с точки зрения взаимодействия — сканер не виден человеку.

Мы провели быстрый „коридорный“ тест этого варианта со случайными людьми на картонном прототипе. Даже тем, кто понимал, что сканер „должен где-то быть“, требовалось визуальное подтверждение, и некоторые пытались заглянуть снизу.

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

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

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

https://vc.ru/design/80772

В какой последовательности ведётся исследование?

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

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

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

Когда наблюдения выявляют частый переход дороги в неположенном месте — проводят подсчёт, чтобы выяснить распределение потоков.

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

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

Про eng UX-тексты

Про eng UX-тексты

Про eng UX-тексты — как сделать первый шаг к тому, чтобы писать microcopy нормально, а не с помощью гугол-транслэйта. Блин, ну это такое позорище, что фу — For signature, например.

Мы дизайн-студия, которая разрабатывает дизайн для финтеха: банки и фин.сервисы. И всё. Никаких тревелов, букингов, отелей и блокчейна(боже упаси).

В конце 19-го года начали проектировать сервисы на английском. Это когда у сервиса нет русскоязычных пользователей.

Когда вот этой отмазкой уже не спастись:
— Давай сначала на русском сделаем, он же просто самый уёбищный, а потом локализуем под Eng.
Самый уёбищный потому что одни и те же элементы в русском длиннее пишутся, бюрократичнее звучат и дизайн из-за этого в целом хуже чем тот же на английском.

Итак, первый лайфхак — просто начните гуглить

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

1.Просто берите и гуглите картинки сервисов в вашей сфере. Современных и клёвых. Конкурентов и партнёров.
bank, finance, fintech, payment, chat, invoice, interface, n26, monzo

2.Просто заходите на Dribbble и ищите те же фин.сервисы не от индийских, СНГ-шных и русских студий а от локальных ребят.

3.Просто разберитесь с тем, что такое Invoice в менталитете и в mind map-е той страны, для которой вы делаете сервис.
А нет, это уже не просто. Но тогда нечего делать то, в чём вы ничего не понимаете — сначала разберитесь.

Два дня изучения картинок референсов с фокусом на тексты — и вы уже шарите.
Не ебите мозг команде и себе.

Потом расскажу про второй шаг, а то сейчас начнётся ))

Болит за тексты

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

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

Логика такая:

1 - экран (приветствие)
2 - экран (рассказываем про топ возможности нашего каталога трусов)
3 - экран (говорим, что можно купить трусняк в один клик без мозговой боли)
4 - кидаем пользователя на каталог, а лучше на топовые труселя с покупкой в один клик

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

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

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

Расскажите, как у вас это устроено? Опрос будет под постом.

А я вам статеек накидаю полезных про UX копирайтинг:

1. https://bit.ly/2OLJEKY - подробно разложена тема UX копирайтинга

2. https://bit.ly/2QQ2JhE - опыт Google по написанию текстов

3. https://bit.ly/34oMOed - про UX писателей