процесс — Антон Григорьев

О фрилансе

Подборка заметок, написанных с 2017 по 2021 год и связанных с работой на фрилансе:

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

Особо не за что хвалить

В чате Саши Бизикова с интересной стороны обсудили подход к мотивации сотрудников через похвалу и её отсутствие.

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

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

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

О коммуникации

Подборка заметок, написанных с ноября 2017 по январь 2018 года и связанных с переговорами и прочими коммуникациями:

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

Тестирование на этапе проектирования

Специализация

Говорят, в AIC нет проектировщиков: дизайнеры проектируют и рисуют финальные макеты, которые увидят пользователи. Дизайнеры Яндекса верстают из готовых компонентов. Проектирование — довольно узкая специализация. Время от времени люди спрашивают меня в личных сообщениях ВКонтакте, неужели можно зарабатывать чисто проектированием?

OOUX

Участвовал в воркшопе Глеба Кушедова, посвящённом OOUX. София Войчеховски предложила этот подход в статье «OOUX: A Foundation for Interaction Design».

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

Задачи бизнеса

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

Как заставить читать документацию

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

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

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

Результат проектирования

Проектная документация

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

Заказчик видит, что получит через несколько месяцев разработки, и может оценить, правильно ли его понял исполнитель;
Исполнитель точнее оценивает объём работ;
Документы становятся частью договора. Отклонение от изначальных проектных решений со стороны заказчика или исполнителя приведёт к изменению стоимости и сроков проекта;
У заказчика появляется возможность ещё раз задуматься о будущем продукте и скорректировать своё видение.

Всё это повышает шансы проекта на реализацию.

Карл Вигерс, автор книги «Разработка требований к программному обеспечению», подсчитал, что на американском рынке разработки 40% бюджета проекта уходит на переделки из-за того, что заказчик и исполнитель плохо сформулировали требования к продукту и вообще не поняли друг друга.

Программистский подход в дизайне

Пересказ доклада Сергея Павельчука из «Проектората» на ProfsoUX 2016.

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

Как команде юиксеров работать без начальника

Пересказ доклада Ивана Серебренникова из SEMrush на ProfsoUX 2016.

Где брать проблемы

1. Почта и User Voice:

Получаем запросы на фичи. Их много, годится для оценки частотности;
Узнаём пользовательские боли;
Понимаем «пользовательский копирайтинг» — какими словами они говорят о своих задачах и действиях.

Инструмент для сбора обратной связи по почте встроен во все продукты компании.