Не могу понять — клиент в итоге принимает участие в процессе или нет? Если клиент на протяжении проекта обсуждает с вами прототипы — это прекрасно. Если он не принимает такого участия, то с высокой долей вероятностью ему а) не нужна эта работа б) у вас не получится хорошее решение.
Если выбирать из двух зол, то соглашусь полностью. Трагичные дизайнеры всегда во всем винят всех кроме себя: плохой клиент, плохая задача, скучный проект.
Вы затронули интересную тему — заточка «под одну» аудиторию. В большинстве случаев ЦА настолько размытая, что непонятно под кого делается. Или более сложный случай — выбирает продукт одна аудитория, а принимает решение о покупке — другая (жена/муж, ребенок/родитель). Удавалось ли разрешать такие проблемы? Расскажите, пожалуйста, свой опыт в этом вопросе
Хороший дизайн — это продающий дизайн. Все остальное — к Артемию и прочим ценителям искусств. Образно говоря: маленьким девочкам нравится розовое и блестящее? Пусть получат.
Внезапно, но те люди, кто делает дизайн кукол барби для маленьких девочек, очень любят их создавать, и им самим нравится результат своей работы. Ребята из Apple, Blizzard или 37Signals тоже делают то, что нравится и им и людям, или как вы их называете — ЦА. Никто из них не сделает плохой продукт, за который стыдно, прикрывшись «Это удовлетворяет ЦА».
… Проблема в одном — заказчик зачастую не профессионал в области продаж. Более того — он не разбирается в Интернете на нужном уровне.
Если заказчик не умеет заниматься своим делом — продавать свои товары/услуги, то вы ему точно ничем не поможете. На мой взгляд, интереснее работать с кем-то, кто действительно понимает свои бизнес-процессы.
Возможно, вам придется делать ужасные вещи — только чтобы пользователю было комфортно. Смиритесь;
Это все отговорки. Возьмите любой хороший дизайн — он нравится клиенту, потребителям и автору. Только когда всем нравится получается что-то хорошее. Если вам не нравится созданный продукт, значит ваш продукт плохой и нет никакой отговорки «Зато нравится аудитории».
Если вы делаете продукт, который вам не нравится -> вы быстро теряет интерес к работе и переходите в армию тех, кто считают всех клиентов дураками, мешающими работать. Возможно, не каждый продукт будет идеальным и как хотелось изначально, но в любом случае он должен нравится и вам и клиенту и потребителям.
о государственных проектах, которые пытаются сделать за неделю до Нового года, когда бюджет нужно СРОЧНО осваивать.
Если задача сформулирована как «освоить бюджет за неделю», то грех жаловаться на такую задачу :-)
Говоря серьезно, нет проблемы выполнить работу в те сроки, в которые хочет клиент, даже если это 1 неделя. Узнайте его потребности и расскажите, что вы можете за 1 неделю успеть. Удивительно, но такой диалог в 99% случаев приводит и положительному результату: клиент знает, чем вы можете ему помочь, вы знаете, что действительно нужно клиенту и не даете невыполнимые обещания.
В большинстве случаев мы, исполнители, сами виноваты в том, что не слушаем клиента, не выясняем почему надо именно через неделю и что именно он ожидает получить. Мы подписываемся под тем, что не можем сделать (зная это сразу), работаем в режиме подвига, а когда не получается выполнить обещанное, виним клиента. Не беритесь за то, что вы не можете сделать и знаете об этом сразу.
Прототип сам по себе не нужен ни вам, ни клиенту. У клиента всегда бизнес-задачи, а прототип лишь один из промежуточных результатов работ по решению задач клиента. По ценности для клиента прототип ничем не отличается от ТЗ/макетов и других промежуточных результатов
На мой взгляд клиенту нужно: а) решение его бизнес-задач с учетов всех ограничений (бюджетов, сроков, технологий) б) уверенность в том, что ваше решение верное. Для того, чтобы удовлетворить обе потребности, требуется процесс проектирования, выстроенный таким образом, чтобы клиент а) принимал участие на протяжении всего процесса б) видел не только конечный результат процесса, но и все промежуточно-промежуточные результаты процесса.
Рекламу стоит не скрывать, но показывать таргетированную на мобильных пользователей (но скрывать — тоже отличный вариант).
В любом случае начинать надо с изучения сценариев мобильных пользователей и готовить адаптивный контент для них.
Не стоит прятать части сайта только потому, что они не помещаются на экране мобильного устройства. Мобильные пользователю хотят видеть тот же контент и функционал, что и пользователи десктопов.
С игнорирования этого постулата и начинается хорошая адаптивность. У пользователей мобильных устройств в зачастую совсем другие сценарии и поведение, нежели у десктопщиков. Поэтому им нужны другие функциональные возможности и другой контент.
Почему вы решили, что вам необходимо сразу и до рубля посчитать стоимость поиска воды на Марсе? Об этом как раз идет речь во 2 части статьи: посчитать все и сразу и точно невозможно.
Вы можете с достаточной степенью точности посчитать стоимость проектирования, а на основании проработанных прототипов и ТЗ оценить стоимость разработки. Но даже в случае, если эта сумма измениться, вы можете ее пересмотреть и изменить. Все это было и у нас, пока не поменяли подход к делу.
Кстати, кто-то вообще работает по скраму и успешно продает такой подход.
ТЗ является последней работой в рамках Проектирования. Я не представляю, как можно писать ТЗ, если не определены методы достижения целей и задач проекта.
Чтобы все обкатать придуманные идеи, создается и тестируется прототип. Уже после того, как он полностью готов, оттестирован и все сценарии выполняются, он описывается в ТЗ.
Наверно, фраза ТЗ постоянно меняется некорректна, скорее ТЗ постепенно рождается в процессе проектирования.
В договоре, конечно, оговорено, что дополнительные работы, не оговоренные прототипом и ТЗ, выполняются по доп.соглашениям.
1. Интерактивный прототип.
2. Отчет о тестировании прототипа фокус-группой (если в процессе тестирования выявлены нарушения сценариев использования, они устраняются и тестирования проводится вновь).
3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
Что делать в случае неисполнения договора заказчиком каждый может определить для своей компании сам: судиться, договариваться, разрывать договор.
Главный вопрос — почему заказчик его не исполняет, возможно ответ на этот вопрос даст решение.
Другая форма договора — почему нет, если большие деньги полностью нивелируют все возможные риски. Если нет и вы не можете туда добавить то, что важно для вас, лучше отказываться от такого договора.
Опять же, нет никакого универсального метода (договора), который позволит решить все проблемы раз и навсегда.
Вы затронули интересную тему — заточка «под одну» аудиторию. В большинстве случаев ЦА настолько размытая, что непонятно под кого делается. Или более сложный случай — выбирает продукт одна аудитория, а принимает решение о покупке — другая (жена/муж, ребенок/родитель). Удавалось ли разрешать такие проблемы? Расскажите, пожалуйста, свой опыт в этом вопросе
Внезапно, но те люди, кто делает дизайн кукол барби для маленьких девочек, очень любят их создавать, и им самим нравится результат своей работы. Ребята из Apple, Blizzard или 37Signals тоже делают то, что нравится и им и людям, или как вы их называете — ЦА. Никто из них не сделает плохой продукт, за который стыдно, прикрывшись «Это удовлетворяет ЦА».
Если заказчик не умеет заниматься своим делом — продавать свои товары/услуги, то вы ему точно ничем не поможете. На мой взгляд, интереснее работать с кем-то, кто действительно понимает свои бизнес-процессы.
Это все отговорки. Возьмите любой хороший дизайн — он нравится клиенту, потребителям и автору. Только когда всем нравится получается что-то хорошее. Если вам не нравится созданный продукт, значит ваш продукт плохой и нет никакой отговорки «Зато нравится аудитории».
Если вы делаете продукт, который вам не нравится -> вы быстро теряет интерес к работе и переходите в армию тех, кто считают всех клиентов дураками, мешающими работать. Возможно, не каждый продукт будет идеальным и как хотелось изначально, но в любом случае он должен нравится и вам и клиенту и потребителям.
Если задача сформулирована как «освоить бюджет за неделю», то грех жаловаться на такую задачу :-)
Говоря серьезно, нет проблемы выполнить работу в те сроки, в которые хочет клиент, даже если это 1 неделя. Узнайте его потребности и расскажите, что вы можете за 1 неделю успеть. Удивительно, но такой диалог в 99% случаев приводит и положительному результату: клиент знает, чем вы можете ему помочь, вы знаете, что действительно нужно клиенту и не даете невыполнимые обещания.
В большинстве случаев мы, исполнители, сами виноваты в том, что не слушаем клиента, не выясняем почему надо именно через неделю и что именно он ожидает получить. Мы подписываемся под тем, что не можем сделать (зная это сразу), работаем в режиме подвига, а когда не получается выполнить обещанное, виним клиента. Не беритесь за то, что вы не можете сделать и знаете об этом сразу.
Прототип сам по себе не нужен ни вам, ни клиенту. У клиента всегда бизнес-задачи, а прототип лишь один из промежуточных результатов работ по решению задач клиента. По ценности для клиента прототип ничем не отличается от ТЗ/макетов и других промежуточных результатов
На мой взгляд клиенту нужно: а) решение его бизнес-задач с учетов всех ограничений (бюджетов, сроков, технологий) б) уверенность в том, что ваше решение верное. Для того, чтобы удовлетворить обе потребности, требуется процесс проектирования, выстроенный таким образом, чтобы клиент а) принимал участие на протяжении всего процесса б) видел не только конечный результат процесса, но и все промежуточно-промежуточные результаты процесса.
В любом случае начинать надо с изучения сценариев мобильных пользователей и готовить адаптивный контент для них.
С игнорирования этого постулата и начинается хорошая адаптивность. У пользователей мобильных устройств в зачастую совсем другие сценарии и поведение, нежели у десктопщиков. Поэтому им нужны другие функциональные возможности и другой контент.
Вы можете с достаточной степенью точности посчитать стоимость проектирования, а на основании проработанных прототипов и ТЗ оценить стоимость разработки. Но даже в случае, если эта сумма измениться, вы можете ее пересмотреть и изменить. Все это было и у нас, пока не поменяли подход к делу.
Кстати, кто-то вообще работает по скраму и успешно продает такой подход.
Чтобы все обкатать придуманные идеи, создается и тестируется прототип. Уже после того, как он полностью готов, оттестирован и все сценарии выполняются, он описывается в ТЗ.
Наверно, фраза ТЗ постоянно меняется некорректна, скорее ТЗ постепенно рождается в процессе проектирования.
В договоре, конечно, оговорено, что дополнительные работы, не оговоренные прототипом и ТЗ, выполняются по доп.соглашениям.
1. Интерактивный прототип.
2. Отчет о тестировании прототипа фокус-группой (если в процессе тестирования выявлены нарушения сценариев использования, они устраняются и тестирования проводится вновь).
3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
То же самое и с сайтостроением. Если правильно выстроен процесс, то там творчество находится на своём месте, а инженерия на своём.
Процессы создания дизайна хорошо можно рассказать на предпроектной презентации, объяснив чем грозит игра со шрифтами и какую цель несет дизайн.
Как я уже писал выше, нельзя выстроить стену, которая раз и навсегда оградит от всех проблем…
Главный вопрос — почему заказчик его не исполняет, возможно ответ на этот вопрос даст решение.
Другая форма договора — почему нет, если большие деньги полностью нивелируют все возможные риски. Если нет и вы не можете туда добавить то, что важно для вас, лучше отказываться от такого договора.
Опять же, нет никакого универсального метода (договора), который позволит решить все проблемы раз и навсегда.