ну то что не понравилось описал выше. Плюс старая как-то привычней как для такого типа сайтов. Но самое главное, что поиск вакансий и собственно вакансия сразу перед глазами.
Сложилось впечатление, что главная страница — посадочная для новых пользователей: максимальный акцент на регистрации.
Блок поиска вакансий сделан совсем второстепенным и малозаметным из-за выделеного блока.
Блоки «Вакансий дня» — превратилось в кашу: нужно выделить заголовки вакансий и увеличить пустое пространство между ними, особенно по высоте.
Да и в целом, впечатление, что поделились макетом сразу после верстки и без правок — сыровато как-то.
Добавлю: выводить на главную вакансию, которая в архиве это совсем дикость.
«Одним из искушений в подходе MVP является попытка построить мост только до середины оврага и выкатить его в свет в надежде получать итеративный фидбек. Обратная связь будет «этот мост отстой», даже если идея моста через овраг блестящая сама по себе. Без возможности перебраться по мосту «из одного конца в другой», продукт просто будет восприниматься не рабочим, либо бессмысленным, либо в случае терминологии «моста» — очень опасным.»
На самом деле MVP будет подразумевать мост не до середины оврага, а канат, натяжной мост, но через весь овраг.
Есть еще проблема в формулировках — у нас слишком много описываеться термином «дизайн».
Вот что я имею ввиду. В статье описан более глобальный вариант, но бывают задачи очень локальные. Вот лично мне доводилось делать дизайн по полностью готовым прототипам (axure). То есть это как бы и не дизайн, но все же красоту нужно было навести и выверить каждый пиксел (это, то чем занимаются люди с дриббл).
Так что задачи бывают разные и разные специ нужны.
Что касаеться статьи, то как по мне дизайнер продукта должен в первую очередь понимать цели пользователей, который продукт должен решить и это первостепенно. Мне тут не совсем понятно причем тут «миссия компании» и все такое. Если компания=продукт, то я согласен, а вот если нет, то…
И, кстати, на каком-то уровне придется делать очень качественную картинку, чтобы привлечь внимание клиента или инвестора. Каким бы гениальным не был продукт, но если на «скринах» при продаже г**но, то продаж не будет.
Лично я проектирование начинаю с миндмапа со структурой сайта и всеми возможными целями пользователя. На этом этапе можно с клиента получить почти все его «фантазии». И только когда уже ясен список страниц и цели можно начинать проектировать.
Во-первых, дает возможность получить максимум информации не отвлекая клиента на внешний вид (многим даже перед чернобелым прототипом тяжело не думать о картинке), а во-вторых экономит кучу времени и пониманием желаний клиента. Чаще всего миндмап составляеться вместе с клиентом (или отвественным лицом) за час-полтора. В редких случаях требуеться ссамостоятельная и глубокая проработка.
Лично я считаю, что на 100% поддаваться тренду и моде не совсем правильно.
И если дизайн готовиться не для дрибла, а для реальной задачи, не вижу ничего плохого в смешивании стилей. Особенно, если это помогает решать задачи и заказчику и пользователю. Главное, чтобы это смешивание было понятным и однотипным в рамках проекта.
То есть, добавить объема кнопке в плоском дизайне не так уж плохо, если это помешает пользователю заблудиться.
Ну тут значит нужно искать дизайнеров, которые умеют читать ТЗ.
И еще, для большинства проектов лично я использую схему:
0. Детализированный бриф
1. Информационная структура
2. Прототип
3. Дизайн
… далее идут этапы разаработки.
Так вот, если человек не может по прототипам нарисовать, то это уже почти клиника.
Главное, что дизайнер должен понять: он делает не картинку. Ему платят (в большинстве случаев) за достижение целей дизайна.
И как только это понимание приходит, то сразу же отпадает желание «пидорасить» картинки и сразу появляется желание сотрудничать и с клиентом и с разработчиками.
— сброс содержимого корзины;
— корявая регистрация;
Остальное может влиять на конверсию в негативную сторону, но так чтобы совсем «роковыми» эти ошибки не являются.
Блок поиска вакансий сделан совсем второстепенным и малозаметным из-за выделеного блока.
Блоки «Вакансий дня» — превратилось в кашу: нужно выделить заголовки вакансий и увеличить пустое пространство между ними, особенно по высоте.
Да и в целом, впечатление, что поделились макетом сразу после верстки и без правок — сыровато как-то.
Добавлю: выводить на главную вакансию, которая в архиве это совсем дикость.
На самом деле MVP будет подразумевать мост не до середины оврага, а канат, натяжной мост, но через весь овраг.
Вот что я имею ввиду. В статье описан более глобальный вариант, но бывают задачи очень локальные. Вот лично мне доводилось делать дизайн по полностью готовым прототипам (axure). То есть это как бы и не дизайн, но все же красоту нужно было навести и выверить каждый пиксел (это, то чем занимаются люди с дриббл).
Так что задачи бывают разные и разные специ нужны.
Что касаеться статьи, то как по мне дизайнер продукта должен в первую очередь понимать цели пользователей, который продукт должен решить и это первостепенно. Мне тут не совсем понятно причем тут «миссия компании» и все такое. Если компания=продукт, то я согласен, а вот если нет, то…
И, кстати, на каком-то уровне придется делать очень качественную картинку, чтобы привлечь внимание клиента или инвестора. Каким бы гениальным не был продукт, но если на «скринах» при продаже г**но, то продаж не будет.
Во-первых, дает возможность получить максимум информации не отвлекая клиента на внешний вид (многим даже перед чернобелым прототипом тяжело не думать о картинке), а во-вторых экономит кучу времени и пониманием желаний клиента. Чаще всего миндмап составляеться вместе с клиентом (или отвественным лицом) за час-полтора. В редких случаях требуеться ссамостоятельная и глубокая проработка.
Конверсия сайта. Превращаем посетителей в покупателей.
Очень толковая книга, советую.
И если дизайн готовиться не для дрибла, а для реальной задачи, не вижу ничего плохого в смешивании стилей. Особенно, если это помогает решать задачи и заказчику и пользователю. Главное, чтобы это смешивание было понятным и однотипным в рамках проекта.
То есть, добавить объема кнопке в плоском дизайне не так уж плохо, если это помешает пользователю заблудиться.
Причина: интеграции с кучей сервисов.
Пока сказать ничего не могу.
Только начинаем на ней работать.
И еще, для большинства проектов лично я использую схему:
0. Детализированный бриф
1. Информационная структура
2. Прототип
3. Дизайн
… далее идут этапы разаработки.
Так вот, если человек не может по прототипам нарисовать, то это уже почти клиника.
И как только это понимание приходит, то сразу же отпадает желание «пидорасить» картинки и сразу появляется желание сотрудничать и с клиентом и с разработчиками.