Главное Свежее Вакансии   Проекты
Разместить своё объявление
😼
Выбор
редакции
2 832 11 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

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

b_5d1b30c2884c3.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге.

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

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

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

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

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

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

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

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

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Сергей Рябов
у меня были однажды проблемы с одним дизайнером, но по моему мнению это был зазвездившийся чувак, квалифицированный, но перегруженный работой, как следствие были длительные задержки и падение качества продукта, проблему решили выделением менее маститого дизайнера, но зато с более глубоким погружением в продукт, и участием нового дизайнера в общих митингах
Ответить
Ekaterina Hindikaynen
По статистике, 8 из 10 стартапов погибают. Кажется, что тот самый идейный вдохновитель и основатель вымышленного стартапа из статьи - один из тех 8, ибо не понимает, что дизайнер не может и не должен продумывать всю логику - да, на когда в проекте большая неопределенность и это стартап, у которого мало денег на взлет, а ещё может и обязательства перед инвесторами, гипотезы надо проверять быстро и желательно - вообще без разработки. Сначала минимальными усилиями проверить, если сложная логика - провести коридорные тестирования в конце концов, но не отдавать просто примерные макеты в разработку. В разработку надо отдавать то, что уже подтверждено и вся логика известна и обкатана в ручном режиме. Ну если прям в качестве mvp хочется повыпендриваться и сделать прям приложение/сайт - либо будь добр сам продумай логику (кстати, частая практика в успешных стартапах), либо найми переводчика с языка заказчиков на язык алгоритмов и логики (системного аналитика). Ну и нанимая дизайнера все же надо думать и различать - нужен прям дизайнер, ui или ux. Ценники, конечно, разные, но некоторые дизайнеры могут и в ux и логику продумать (такие, конечно, стоят максимально дорого). И нужно помнить, что ошибка и недоработка/ не продуманная логика на этапе проектирования - самая дорогая, т к наростает как снежный ком
Ответить
Top Reader
Читалка книг с переводчиком. Приложение под Андроид.
Евгений Стоичков
Я никак не могу понять почему всегда опять "водопад" и почему дизайн "передается в разработку". Да не должно этого быть во времена фронтендов и аджайлов. Почему в РА что такое "креативная пара" понимают а "стратапы" тупят? В чем проблема спаровать разработчика, который хорош в быстрой реализации интрефейса и дизайнера, который как минимум неплох в понимании технической части. Левое и правое полушарие. Но нет. Дизайнеру надо рисовать подробные чуть ли не по кадрам моменты. Далать гифочки и писать инструкции. Создавать кликабельные и презентабильные прототипы. Когда за все протраченное время на эту красоту два чувака могут вместе сесть обсудить на пальцах и заваять прототип в реальном коде, который с большой долей вероятности станет релизом.
Ответить
Miroslav Tsarev
Разработка сайтов с гарантией качества, сроков и без нервов (команда)
Miroslav Tsarev
Не совсем по теме конечно будет.

Зашел на ваш сайт и он показался мне странным, ведь при просмотре блока "Что мы делаем" он был просто пустой. Да и выглядит он на скрине не так, как должен)

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

Решил посмотреть подробнее:
Фон вместо пары строк css сделали вообще картинкой через абсолютное позиционирование, а путь к картинке присваивается через data-атрибут. Зачем!? Ну то ладно.

Но почему вылазят ошибки и сайт получается такой, как на скрине?
Все просто: кому-то пришла в голову "гениальная" идея запхать скрипт аналитики в общий js-файл.

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

Не зря ведь код аналитики рекомендуется добавлять в html или отдельный файл.

Игнорирование этой незначительной рекомендации может стоить огромных денег на реальном проекте, сведя конверсию к нулю
Ответить
Furnas
Делаем веб проекты для себя и для других
furnasteam
Спасибо большое за инфу об ошибке, обязательно поправим отображение сайта для тех, кто пользуется ublock и чем-то подобным.
Что касается верстки... Она генерировалась автоматически из sketch с помощью плагина anima, поэтому там местами такие странные решения =) Хотели попробовать ускорить процесс верстки, чтобы этим занимался только дизайнер, не привлекая разработчика и чтобы это была не тильда. Эта наша новая версия сайта, поэтому мы решили попробовать. Какие плюсы/минусы такого подхода - скоро напишем.
Ответить
Арган Абубеков
А ещё на дизайн может не остаться время или его доделывают "как нибудь потом". Сам веду стартап coderun.ru и понимаю что дизайн "говно", но больше уделяю время "экенду".
Ответить
Furnas
Делаем веб проекты для себя и для других
furnasteam
Когда делаешь сам и на свои деньги - тут все понятно. Другое дело, когда на проект выделяются большие деньги, есть возможность сделать хорошо.
Ответить
Алекс Молчанов
Тут, как бы, основатели и МП виноваты в первую очередь. Второй за то, что не может донести клиенту позицию команды. Бизнес - это конечно про деньги, но и бизнеса нет, если его вести не правильно. В данном случае алгоритм прост, клиент доносит до МП задачу. МП доносит задачу до разработчика. Разработчик корректирует задачу с учётом ограничений стэка. И задача отдается в дизайн с указанием этих ограничений. Например, если можно сэкономить взяв готовое решение, то и дизайнер должен учитывать это решение, а не рисовать от балды "я художник, я так вижу". В идеале, конечно, я считаю, что вся цепочка должна понимать, что она должна получить на выходе, присутствуя на обсуждениях, а не выполняя задачи по ТЗ. Каким бы четким оно не было, все равно наступает момент: - вы же профессионал, почему вы этого не предусмотрели!

В частности это касается новомодных "русских стартапов". Где денег нифуя, времени нет, но все обязаны выдать продукт уровня ААА. Наш бизнес, в частности малый, просто не понимает, что такое планирование и инвестиции на 5, 10 лет вперёд без чистой прибыли.
Ответить
Ерошенко Виталий
Я тоже не понимаю описанного процесса. Как можно отдавать в разработку то, что "дизайнер предоставляет макеты, которые представляют собой, как правило, просто красивые картинки. Эти картинки обсуждают, основатели вносят небольшие правки. Все, фича спроектирована".
Если дизайнер запилил на коленке, чтобы обсудить с основателями. После утверждения дизайнер должен проработать макет, чтобы отдать в разработку. Да и есть такое понятие как прототип, для обсуждения с бизнесом, а после уже проработка в деталях. Сам так работаю с дизайнером и никаких проблем!
Я вижу вашу проблему именно в этом " давайте побыстрее и абы как". Так и получается. И бизнесу в том числе это же надо доносить.
Ответить
Furnas
Делаем веб проекты для себя и для других
furnasteam
Проблема скорее в том, что основателям и менеджеру дизайн кажется завершенным, потому что они видят задачи по-своему. Они прорабатывают какие-то свои сценарии и им кажется, что все готово. Не думаю, что есть желание сделать кое-как и побыстрее, особенно, когда деньги уже есть и не требуется слишком спешить. Проблема скорее в том, что разработчик, когда берет задачу в силу своей специфики видит больше сценариев, логических проблем, потому что именно ему в конечном счете надо переводить фичу в логический язык программного кода.
Ответить
vlib.co
Публикация электронных книг для начинающих авторов
Philipp Tkachev
Ваши люди не работают вместе. У вас нет команды, а есть "ты - дизайнер, а ты - разработчик".
Если вы делаете работающие проекты, то вам нужен дизайнер интерфейсов, а не художник или иллюстратор.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.