​Проблемы дизайна в стартапе

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

Процесс работы.

Давайте опишем типичный стартап, о котором идет речь.

Есть основатель стартапа или несколько основателей и команда разработки, примерно человек 7. В команду обычно входит дизайнер, 2 фронт разработчика, 2 бек разработчика, QA-инженер и менеджер проекта.

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

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

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

Почему разработка ненавидит дизайнера.

Как правило, планирование опережает разработку на какое-то время. Допустим, на 2 недели. Разработчики берут очередную задачку, начинают верстать странички. Разработчик не может не доделать свою работу. Он не может примерно накидать код. Все непонятные вопросы, все непродуманные ветки поведения пользователя в интерфейсе он должен продумывать сам.

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

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

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

Почему дизайнер ненавидит свою работу.

Дизайнер приходит в стартап и думает, что сейчас у него будет много творческих задач, будет создавать новый продукт, продумывать новую функциональность.В реальности все немного иначе, дизайнер выполняет функции “визуализатора” идей основателей. У него нет времени продумать интерфейс, нет времени его дорабатывать. У него одна функция - делать презентации идей основателя.

Кроме того, на этом этапе основатель как угодно вмешивается в работу дизайнера. Он может говорить какой толщины надо сделать бордер и какого цвета. Всем кажется, что дизайн - это очень легко и каждый чувствует себя профессионалом в этой области. У каждого есть свое мнение о цвете, размерах, шрифтах и т.д. Никто же обычно не лезет в работу программиста. В моем опыте еще ни один менеджер не подходил к разработчику со словами “давай этот for заменим тут на while”. Дизайнеру, конечно, очень неприятно, что все так лезут в его работу и учат его, как надо делать. Но ладно, здесь можно смириться, это же только начало проекта. Надо делать быстрее, идти на компромис.

Но ведь это не все =) Через 2 недели к дизайнеру приходят разработчики, которые тыкают его носом в его макеты и говорят - “вот здесь ты не прав”. Дизайнер, как бы понимает, что макеты приблизительные и его вины в этих ошибках нет. Но он не может не чувствовать свою вину.

Что в итоге.

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

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

Как не надо решать проблему.

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

Все проблемы как были, так и остались, но к ним добавилась еще одна. Теперь есть еще один человек, которого надо чем-то занять. Но никто не знает чем.

Как надо решать проблему.

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

1. Разработчики не могут сделать хороший дизайн, каким бы чувством прекрасного они не обладали
2. Доверяйте дизайнеру, не пытайтесь научить его работать так, как вам надо. Сразу наймите такого человека, который будет с вами на одной волне.
3. Не нанимайте людей, если точно не знаете зачем они нужны
4. Давайте дизайнеру время на проработку логики работы интерфейса.
5. Подключайте всю команду разработки к обсуждению фичи. Разработчики имеют другое мышление и им легче находить ошибки в логике.
6. Общайтесь с командой и ищите решение проблем вместе.

Если у вас есть потребность в разработке или дизайне, не спешите нанимать человека в штат. Попробуйте сначала поработать с кем-то со стороны: фрилансер, веб-студия или с нами на furnas.ru =)