Как стать автором
Обновить

Комментарии 41

MVP (минимально работающий продукт)?
Да, верно
Коллеги, думаю написать такую же статью про дизайн. Этого же проекта и с примерами всех страниц. Скажите, на сколько она будет интересна сообществу? Можно выразить желание плюсом или комментом)
Очень интересна!
Поддерживаю. Поток дизайна тут слабо развит.
Очень интересно. Дизайнеры мало делятся опытом )
Я бы прочитал с удовольствием.
Тоже поддерживаю — вообще было бы интересно все важнейшие этапы развития проекта увидеть —
прототип — дизайн — верстка(фронтенд) — кодинг(бакенд) — последнее конечно не все целиком, главное, основные принципы, с чего начинать, как поставить и разделить задачи, какие фреймворки использовать — если использовать etc. В небольших проектах часто есть необходимость натягивания верстки на популярные cms, но тут конечно не тот случай.
В общем, самое важное, как мне кажется, понять, как максимально четко грамотно и по возможности быстро планировать, структуировать, и решать подобные задачи.
Скажем, дизайнить с учетом будущей верстки, верстать с учетом будущего кодинга, seo etc.

ps. заметил маленькую ошибку у вас —
Страница: Главная
» Макет: http://wt9kcs.axshare.com/#g=1&p=9_0_0_0_glavnayam

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

За ошибку спасибо, сейчас исправлю.
Очень интересно!

"Поэтому, намного дешевле сразу продумать систему правильно" — такое бывает только в стране волшебных единорогов и любителей Axure. Ну или если вы все целиком собрались копировать у конкурента, со всеми возможными недостатками. И в целом, такая waterfall-модель, мягко говоря, не оптимальна, особенно в сложных проектах.

Я писал в начале, что проектирование не исключает аджаила. Можно проектировать частями. Ну и проектировать нужно думая, конечно. Кто ж заставляет проектировать с недостатками? :)
А как же цельное видение всего проекта? можно запроектировать так, что при проектировании последующих блоков придётся переделывать предыдущие. пример: единый интерфейс, с фичами, доступными под разными ролями.
Но, в целом такой подход возможен, если проектировать крупными блоками и сделать что-то типа пред-проектного проекта.
Для видения делается аналитика, где виден размах всего проекта. Я это описывал в прошлой статье: http://secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html
Какой-то провокационный комментарий, чесслово.

«Поэтому, намного дешевле сразу продумать систему правильно»

Понятно, что сразу сделать всё правильно — на грани невозможного, но не невозможно. Во всяком случае, следует стремиться к максимальной правильности системы в рамках имеющихся ресурсов и сроков, нет? Или тяп-ляп и в продакшн — наш путь?

такое бывает только в стране волшебных единорогов и любителей Axure.

Axure — просто инструмент, со своими преимуществами и недостатками. Что вы имеете против него, что так презрительно высказываетесь, мешая в кучу любителей единорогов и фанатов акшура?

Мой коммент, наверное, не покажется таким провокационным, если посмотреть на ситуацию исключительно в методологическом ключе. Сделать все правильно сразу, в виде абстрактных снапшотов состояний системы — именно невозможно, именно по причине абстрактности и отличии (порой очень существенном) понятия "правильно" на этапе такого проектирования и "правильно" — на этапе реализации. Я занимаюсь проектированием (и реализацией) довольно сложных систем и неоднократно (всегда) сталкивался с несоответствием усилий и затрат на решение всех проблем на этапе первоначального проектирования и затрат на исправление ошибок в итоговой реализации. Я — за итерационно-эволюционную модель разработки, где проектирование и исследовательские телодвижения, а также оценка и коррекция рисков, размазаны ровным слоем по всему процессу. Такой подход более требователен к качеству команды и затрудняет прогнозирование, но это, наверное, единственный способ реализовать сложный проект без многократного раздувания бюджета и фатальных факапов.

Для решения таких проблем и делаются динамические прототипы. А потом по ним ходит QA, по пользовательским сценариям, проверяет ошибки в логике.

Но в целом я согласен, нужно делать все итеративно. Однако, этапы разработки не отменяют проектирование. Оно просто разбивается на этапы.

Судя по комментарию — вы программист. И еще, видно что прототипы тех ресурсов, на основе которых вы сделали вывод, делались либо просто дизайнером, либо без QA. И в этом проблема. Я тоже видел теоретические прототипы, которые вообще не могли работать на живых пользователях. Но все они делались дизайнерами и без QA. При правильном подходе переделываться должно минимум, в этом и есть цель проектирования. И если эта цель не достигнута — проектирование хреновое и проектировщика вместе с менеджером нужно уволить.
Оно просто разбивается на этапы

дешевле сразу продумать систему правильно

Это ведь взаимоисключающие параграфы? Я, кстати, не программист, скорее активно программирующий продакт-дизайнер, специализируюсь как-раз на таких воркфлоу, где интерактивный прототип бесшовно эволюционирует в конечный продукт.

Нет, почему? Можно продумать небольшую часть системы (этап).
где интерактивный прототип бесшовно эволюционирует в конечный продукт.

Прототипирование с помощью production-ready кода? Что ж, подход имеет право на жизнь и в последнее время популярен. Вот только сдается мне, что первый прототип рождается очень долго, а правки внедрять или, тем более, резкая смена курса — потребуют очень много времени. Нет?

Нет. Прототип представляет собой набор модулей в прототипной стадии проработки, это код совсем не продакшн-уровня и не должен отвечать таким-же требованиям, которые предъявляются к продакшн-коду. Трудозатраты на создание первых прототипных версий не превышают тех, что требуются на создание прототипа в Aхure, но используются другие технологии, более близкие к технологиям непосредственной реализации (HTML, CSS, SVG, React, Polymer). И почему вы решили, что резкая смена курса пройдет более безболезненно при создании прототипа в Axure с максимальной степенью проработки в стиле "сразу продумать"?

И почему вы решили, что резкая смена курса пройдет более безболезненно при создании прототипа в Axure ?


Потому что WYSIWYG редакторы позволяют внедрять изменения гораздо быстрее, чем с помощью технологий непосредственной реализации (HTML, CSS, SVG, React, Polymer)

с максимальной степенью проработки в стиле «сразу продумать»


Вы как-то уж очень буквально понимаете эту фразу — «сразу продумать». Сам вид акшуровских прототипов как бы намекает, что максимальной продуманностью там не пахнет. Когда дизайнер, потирая потные ладошки, доберется до этого прототипа, там, возможно, и камня на камне уже не останется от изначальной задумки.

И когда люди говорят о «максимально продуманных» прототипах подразумевается, что эта «продуманность» выдержит критику только с точки зрения прототипа, а не реального продукта.

Это как тренажёры. Можно сколько угодно ответственно готовиться к реальности на тренажёрах (для пилотов, например) и да, про тренажёр можно сказать, что он максимально продуман, но как бы все по умолчанию понимают, что реальность будет иной, и никому специально это объяснять не нужно.

Если придираться к таким мелочам — можно сказать, что и акшуровские прототипы основаны на технологиях непосредственной реализации — ведь акшур генерит html страницы, и в прототипы можно даже дизайн внедрять, но все понимают, что это как бы чушь (код получается чудовищным).
WYSIWYG редакторы позволяют внедрять изменения гораздо быстрее

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


В остальном мне трудно продолжать дискуссию не повторяясь, мы пошли по кругу.

Действительно, спор ни о чём. У вас получается быстрее программировать, чем конструировать в WYSIWYG-редакторе. Только почему-то вы решили, что если лично у вас получается программировать быстрее, чем конструировать, следовательно все другие люди будут проигрывать вам в скорости в отличных от ваших методах прототипирования. Отсюда смешение в кучу единорогов и фанатов акшура.

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

Я прекрасно это знаю. И речь шла изначально не об этом, а о ущербности каскадного подхода в дизайне и проектировании. Быстрота в WYSIWYG — позволяет быстро менять макеты в WYSIWYG, и нигде дальше по конвейеру. От этого сами эти макеты не станут полезнее, они все равно будут нуждаться в коррекции и пересмотре при реализации приложения. Такие макеты полезны, но не более чем ваши прикидки на салфетке или почеркушки на доске: они позволяют направить вашу мысль в самых общих чертах, а детальная их проработка и тестирование на этом уровне — просто трата времени. Автор данной статьи говорит что оно того стоит и всем непременно нужно тратить на это усилия. Я же утверждаю, что вовсе нет, по причине невозможности учесть все в таком макете. Референсный макет — ужасен и полностью подтверждает мои слова. Вы можете быть несогласным с моими мнением, ваше право, но проблема в том, что вы мнения этого не слышите, цепляясь к несущественным деталям.

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

Я тоже. Только не очень понял, к чему этот ваш комментарий.
Очень интересная статья, большое спасибо.
Скоро еще будут, новые статьи) У нас в запасе есть интересное
НЛО прилетело и опубликовало эту надпись здесь
Что такое ЯП?
язык программирования
Java
НЛО прилетело и опубликовало эту надпись здесь
Java, на основе которой они сделали собственный фрейморк, если я правильно помню. Также как их Алиэкспресс, тоже на Java. Но это больше исторически так сложилось
Мне одному кажется, что алибаба — это треш, угар, помойка и пример промежуточного состояния постоянно меняющейся системы с кучей легаси, костылей и прикрученных куда-попало фич, миллионом недодумок и неудобств? И срисовывать с него что-либо, как с типа готового идеала — как минимум, спорно? Алибаба своих клиентов привлекает как-бы совсем не совсем дизайном.
Да, вы правы, поэтому в это MVP мы внесли только те вещи (по нашему мнению) с которыми проект мог нормально стартануть
А на каком этапе и как в этих вот ваших проектах будут причёсаны обозначения, например, ссылок на добавление в сравнение и в избранное, отличающиеся на макете карточек товара и услуги? Кто, когда и как этим занимается?
Причесывается когда пишем ТЗ, именно тогда видны такие ошибки, но как видите не всегда, этот прототип и тз делал один человек поэтому не доглядел я, чаще всего такие вещи проверяют несколько человек на этапах проверки прототипов и тз.
На самом деле, прототип не до конца завершенный, не все этапы пройденный. Это ж просто пример.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий