Создавая новый продукт, невозможно предусмотреть все детали, поэтому очень важно как можно быстрее сделать рабочую версию и протестировать ее на реальных пользователях. Обычно ее называют «минимально жизнеспособный продукт» (minimum viable product, MVP), и он нужен, чтобы диагностировать ошибки и заняться их исправлением.
В одном из проектов, над которым мне доводилось работать, мы вместо того, чтобы рисовать собственные компоненты, взяли готовую дизайн-систему Material Design. Вначале я не понимал смысла этого решения, но с каждым днем всё сильнее осознавал его пользу.
Вместо того чтобы прорисовывать все возможные состояния, достаточно было указать одно, так как компоненты уже содержали их. Например, не нужно было рисовать состояние ошибки в текстовом поле или то, как выглядит выпадающий список: достаточно было просто указать, где он должен располагаться и какие функции выполнять.
Прежде чем отрисовывать какой-либо компонент, я обращался к документации, так как велика была вероятность, что он там уже есть. Благодаря этому разработчик использовал макеты не как строгую документацию, а как справочную информацию. Ему не нужно было изучать размеры кнопки, ведь он брал ее не из макета, а из уже готовых компонентов.
Когда я сталкиваюсь с двумя одинаково хорошими вариантами, то спрашиваю, какой из них легче реализовать.
Разработчики втягиваются в разговор, и в итоге выбирается оптимальное решение.
Мы уже обсудили, насколько высока вероятность того, что продукт будет меняться благодаря обратной связи и точечным улучшениям. Чтобы подобные изменения не отнимали много ресурсов, лучше заранее продумать возможные варианты развития продукта и предусмотреть их в структуре сервиса.
Не стоит тратить много времени, придумывая уникальный фреймворк: вполне возможно, что он довольно быстро потеряет актуальность. Вместо этого лучше брать классические компоненты, которые хорошо работают на разных устройствах и адаптируются под новые требования.
Если вы хотите стать ключевым игроком в компании, что в случае успеха принесет неплохие деньги, старайтесь изучать смежные области. Начав как дизайнер, я погрузился в маркетинг и управление продуктом, что значительно повысило мою ценность и авторитет внутри компании.
Павел Дуров как-то упоминал, что в первые годы работы во «ВКонтакте» совмещал роли дизайнера, маркетолога и менеджера, что позволяло не тратить время на ненужную коммуникацию. На своем опыте я понял нечто подобное. Запуская новый сервис, лучше собрать команду универсалов, каждый из которых будет хорош в чем-то одном, но при этом сможет видеть общую картину. Когда проект «встанет на ноги», придет время нанимать специалистов узкого профиля, чьей задачей будет просто хорошо делать свою работу. Сами подумайте, насколько возрастает ценность сотрудника, который способен не только сделать удобный дизайн, но и поговорить с пользователями, вникнуть в дела разработчиков, определить необходимый функционал и предложить идеи по продвижению продукта. Каждый руководитель мечтает найти людей, которые не только выполняют поставленные задачи, но и предлагают идеи и готовы взять на себя ответственность за их реализацию.
Вам, как дизайнеру, не обязательно разбираться в этих вещах, – но если вы чувствуете подобное желание, то не нужно бояться попробовать что-то новое. Когда мне захотелось активнее участвовать в управлении продуктом, я не стал об этом просить, а просто начал понемногу браться за задачи, которые обычно выполняет менеджер продукта. Прошло несколько недель, и мою инициативу заметили. Таким же образом я начал погружаться в маркетинг и спустя месяц занялся продвижением продукта.
Помните: никто не назначит вас на новую должность, пока вы самостоятельно не начнете проявлять инициативу в решении новых задач.
Работая в стартапе, дизайнер может прийти к тому, что бобльшая часть макетов уже готова и теперь дело за разработчиками. В начале карьеры я придумывал себе новые задачи и переделывал существующие страницы, что было ошибкой, так как на данном этапе главная задача дизайнера – контролировать разработчиков. Обычно они работают спринтами по одной-две недели. После каждого спринта наступает релиз, когда в открытый доступ выкладывается новая версия продукта. В этот момент дизайнеру важно снова пройтись по всем сценариям, дабы убедиться, что его идеи были реализованы должным образом.
Некоторые дизайнеры ограничиваются рисованием макетов и обращают мало внимания на реализацию. В некоторых случаях, например во фрилансе, это нормально, так как вы не отвечаете за разработку. Однако в стартапе очень важно смотреть, каким образом реализовываются ваши идеи.
Небольшое упущение в логике может показаться незначительным, но пройдет несколько месяцев, и таких недочетов может быть уже несколько. В итоге вы даже не заметите, как гениальная задумка стала чем-то обыденным. Чтобы такого не произошло, регулярно тестируйте реализацию ваших дизайн-решений.
Важно помнить, что, каким бы опытным и талантливым ни был коллектив, оценку вашей работы могут дать реальные пользователи. Поэтому чем раньше вы протестируете первую версию, тем лучше. Можно даже не дожидаться полного релиза продукта, а протестировать готовые сценарии.
Например, сделав форму создания заказов, мы сразу пригласили представителей целевой аудитории для проверки наших гипотез. Дайте людям легкое задание, ничего не говорите, а всего лишь смотрите, каким образом они взаимодействуют с вашим интерфейсом.
Обращайте внимание на моменты, когда пользователь замирает и думает, какое решение необходимо принять. Скорее всего, что-то здесь можно упростить или переработать.
Помню, как один начинающий дизайнер написал мне, что его пригласили работать в стартап, но он не был уверен в своих силах и боялся подвести коллег. Это правда – на дизайнера в стартапе ложится большая ответственность. Если мир разработки довольно хорошо структурирован, то мир дизайна пока не может этим похвастаться. А потому, собираясь пойти в стартап, заранее осознайте ответственность, которая ляжет на ваши плечи. Если уйдете из него на середине работы, то подведете коллег, – но в то же время, если захотите, чтобы ваши решения реализовывались, смело беритесь за работу.