Британка у всех на слуху, что же она из себя представляет?

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

Мы занимаемся во вторник и четверг с 19 до 22, и в субботу с 11 до 18.
Обучение очное, и это круто. Можно вновь почувствовать себя учеником: поднимать руку на занятиях, выполнять задания и хлопать выступающим.
Одна из фишек очного образования — коммуникация с другими студентами. Это здорово стимулирует — когда ты видишь, что большинство уже выполнили задание, то волей-неволей сам начинаешь шевелиться. И конечно, это новые связи и знакомства — одна из причин, по которой я пошел в британку.

В данный момент у нас во всю идет блок исследования — экспериментальный курс на 1,5 месяца. Введение подобного курса — это попытка адаптации обучения под динамично меняющуюся индустрию.

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

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

Как писать сообщения об ошибках

Как писать сообщения об ошибках

Есть простой шаблон:
В заголовок — что призошло
Основным текстом — причина и что делать дальше
Кнопкой — действия
Код ошибки, если необходим

Заголовок должен быть понятным и человечным. Задача — сразу сообщить, что ключевое действие не было выполнено. Люди читают заголовок первым и он сразу должен объяснить что произошло.

Если пользователь отправлял письмо, а оно не отправилось, то так и пишем: Письмо не отправлено

Хорошо:
✅ Не удалось загрузить сообщения
✅ Фотографии не отправлены
✅ Платёж не прошел

Плохо:
❌ Что-то пошло не так
❌ Ошибка!
❌ Память не может быть read

Основной текст должен объяснять причину и писать что делать дальше. Ориентируйтесь на ваших пользователей и место возникновения ошибки. Если вашим продуктом пользуются люди, не связанные с IT, то старайтесь избегать таких словечек, как данные, сервер, запрос. Обычно, человек поймёт это либо неверно, либо не поймёт вовсе. Если у вас профессиональный инструмент, то пишите профессиональным языком. В этом случае, конкретика поможет разобраться в ошибке. Хорошо, если вы сможете написать что делать, чтобы ошибка не возникала.

✅Хорошо для простого человека:
Не удалось сохранить документ. Документ слишком большой. Уменьшите размер документа до 800 символов или разбейте на части.
Разбить на 3 части
Закрыть

✅Хорошо для профессионала.
Не удалось сохранить документ. Размера файла подкачки не хватает для сохранения. Увеличьте размер файла подкачки до 1 ГБ или уменьшите размер вашего документа до 800 символов.
Увеличить файл подкачки
Разбить на 3 части
Закрыть

❌ Плохо:
Не писать причину
Писать профессиональным языком для непрофессионалов

Если причина неизвестна, то можно так и писать: Ошибка произошла по неизвестной причине. Помогите нам разобраться, отправьте отчёт.

Кнопки должны повторять действия, которые вы описали в основном тексте. Не обязательно в основном тексте описывать все кнопки, достаточно описать только предпочтительное действие.

✅Хорошо
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Позвонить в службу поддержки
Написать в службу поддержки
Закрыть

❌Плохо:
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Закрыть

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

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

Алан Купер написал, почему сейчас трудно делать удобные продукты.

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

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

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

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

Специалисты, будучи ответственными гражданами, пытаются примирить непримиримое. Они спрашивают: «Хотите, чтобы это работало быстрее?», «Хотите, чтобы я рассчитал окупаемость инвестиций?», «Хотите, чтобы я сделал это более джазовым, сексуальным, привлекательным?», «Стоит ли мне быть более гибким?», «Стоит ли мне использовать дизайн-системы, дизайн-мышление, дизайн-методы?».

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

Мы ищем ответы не в том месте.

https://vc.ru/design/97289

Вопрос читателя: “Какие образовательные программы и сертификации считаете полезными для продакта?

Не говорю про самообразование и постоянное "затачивание пилы", а именно с целью документального подтверждения навыков (например, при собеседовании) – что было и полезно вам и ценно для работодателей”.

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

Лично мой честный вам ответ – никакие. Ни в одном месте, куда я устраивалась на работу, меня не просили предъявить “корочки”. Я сама ни разу не смотрела на список законченных курсов кандидата, когда принимала решение о найме.

У меня нет ни одной сертификации или диплома (кроме как о получении высшего образования). Когда я устраивалась на работу в Яндекс, одно из собеседований было про статистику – а я в статистике была ни в зуб ногой. Когда я пришла работать в Suitepad, мне надо было проводить пользовательские исследования, что я раньше никогда не делала. В Intercom нужно было уметь работать с SQL, чего я, опять же, не знала.

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

1. По своей природе, профессия продакта похожа на любую руководящую должность. Не могу представить ситуацию, где интервьюер говорит: “Ну да, вы классный менеджер, умеете строить команды с нуля, вести людей за собой и приносить деньги компании, но вот сертификатика про Agile у вас нет. Жаль-жаль, придется вам отказать”. Des Traynor, один из основателей Intercom, успешно переключается между разнообразными C-level должностями: какое-то время был CMO, до этого – CPO, а после - COO. Многие tech компании также практикуют “взаимозаменяемость” топ менеджеров. Все потому, что их ключевые навыки, как и у продактов, в большей степени относятся к soft skills или к независимым от функции hard skills (например, стратегия или приоритезация).
2. Продакт-менеджер – это швейцарский нож; набор “инструментов”, который вам потребуется, будет сильно зависеть от нанимающей компании. Где-то будет нужен уклон в маркетинг, где-то в анализ данных, и так далее. Все знать невозможно, и адекватные работодатели это понимают.
3. Хороший продакт должен уметь быстро во всем разбираться – и иногда курс или сертификация действительно могут в этом помочь. Однако даже в этом случае “корочка” – лишь ненужный артефакт. Ни один диплом не докажет, что вы не просто усвоили знания, но и, что гораздо важнее, научились их применять на практике. Ни одной компании не нужен продакт с сертификатом по Data Science – но нужен продакт, который умеет принимать решения на основе данных. Фокусируйтесь на результате, а не на средствах его достижения. В этом случае часто оказывается, что нам не нужен курс за 20 тысяч рублей; можно прочитать книгу, пару статей, а все остальное осваивать уже в “бою” :)

Сразу также отвечу на популярный вопрос от проджект-менеджеров: нужна ли сертификация PMBOK или Agile, чтобы найти работу. Прежде всего должна сказать, что уже давно не сталкивалась с подобными вакансиями в продуктовой разработке; мне кажется, за границей это все больше и больше становится рудиментом (конечно, не говорю здесь об агентствах). Когда я работала в России, ни у кого из моих знакомых проджектов таких сертификатов не было.

И еще одна важная оговорка: мы не затронули тему MBA, так как это отдельная и очень объемная история. Приходите слушать нашу трансляцию с Юлей Нечаевой, где она будет говорить про свой опыт с MBA в одном из топовых американских университетов и как это повлияло на ее карьеру https://t.me/proproduct/956 (https://t.me/proproduct/956)

Иван Емелюшкин написал, что может предпринять дизайнер (не фрилансер), если у него кончились задачи.

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

2. Залезьте в соседнюю область. Если работаете над приложением, обратите внимание на сайт, рассылку, печатку, рекламу или интерьер магазинов.

Важно понять, почему задачей никто не занимается. Если нет ресурсов на её реализацию, ваша работа может уйти в стол. Учтите: пока вы занимаетесь задачей в соседней области, может появиться задача по основному профилю, и придётся совмещать.

3. Сядьте с аналитиком или хотя бы Вебвизором, найдите проблемы и предложите решения.

4. Проведите пользовательское тестирование с опытными пользователями и новичками. Пройдитесь по основным и второстепенным сценариям.

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

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

7. Заявите о себе: напишите статью, распишите кейс, опубликуйте работу в портфолио.

https://designpub.ru/67ac0a28a732

Качество кода и счастье

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

Вот, к примеру, качество кодовой базы. По-идее, можно очень долго жить с горами говнокода в продакшене — просто нанимаешь в 2–3 раза больше программистов, игнорируешь высокий churn, пытаясь загасить проблему корпоративами/тимбилдингами/мотивацией, и привычно умножаешь все сроки на 3.

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

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

Вчера на сайте бюро вышел первый совет в серии о качестве кода (http://bit.ly/bureau-code-quality), с детальным рассказом о том, зачем это нужно бизнесу. Особенно совет полезен тем, у кого нет времени (или кому не дают времени) на рефакторинг.