Разработка и дизайн
В наше время очень трудно разделить эти два
Кажется, я постоянно возвращаюсь к этой теме дизайна, и на этот раз в рамках разработчиков, которые в конечном итоге берут на себя роль «дизайнера» для этого первоначального прототипа. Этот одноразовый, быстро сделанный, специальный прототип, который в конечном итоге немного отполируется и станет конечным продуктом.
В этом нет ничего плохого. Часто в небольших командах приходится носить несколько головных уборов. Или, по крайней мере, начать путь только для того, чтобы заставить мяч двигаться. А в небольших командах иметь преданного дизайнера — это роскошь, и даже если это так, этот дизайнер должен также перейти в сферу разработчика, чтобы он мог хорошо интегрироваться в производственный цикл, а не быть кем-то, кто занимается проектированием в одиночку. вакуум. В любом случае, дизайн — это сложно.
Мы небольшая команда в DF Studio, но на самом деле у нас есть такая роскошь, как дизайнер. Но из-за большого количества изменений и прототипов для функций, которые нам нужны для продвижения, нам часто приходится полагаться на собственный набор навыков, чтобы начать с прототипа для некоторых функций, а для других мы можем кодировать макет, который был явно разработан.
Это сложный баланс, так как разработчики не только должны говорить на языке дизайна, но мы также должны знать общую структуру правил, которые у нас есть для нашего языка дизайна. Как мы оформляем кнопки, какие классы используются, когда мы используем это вместо того? Для некоторых это нелегкий процесс, но я думаю, что это важно.
Особенно в наши дни, когда мы упаковываем код и стиль все ближе и ближе друг к другу, это имеет смысл. Дизайн, по крайней мере его основы, а иногда и возможность довести его до конца, — это новый и ценный набор инструментов для разработчика. Это не значит, что дизайнеры не нужны, поскольку будут времена, когда будут вноситься исправления, использоваться новые парадигмы и другие инструменты и приемы торговли, которые приходят больше от опыта проектирования, чем от грубой силы. Есть определенная легкость и комфорт, которые приходят с знанием того, что дизайн основан на чем-то фундаментальном, что было исследовано как UI/UX, а не на каком-то внутреннем ощущении.
Но это не значит, что правила нельзя изменить по мере необходимости. Эта часть иногда имеет тенденцию полагаться на то, что разработчик знает возможности системы и может предложить соответствующее решение, даже если это означает необходимость небольшого проектирования.
В любом случае, что-то подобное — это всегда командная работа по созданию и производству чего-то, что действительно будет работать для вашей клиентской базы. Как разработчик, будьте готовы примерить на себя множество обязанностей с небольшими командами, время от времени дизайн будет лишь одной из них.
