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

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

Спасибо! Быстро Вы.
На нашем сайте статья месяц уже лежит целиком. И на тему проектирования есть еще ряд, которые я после праздников на хабре опубликую. Подписывайтесь на нас в фейсбуке, контактике и твиттере, будете видеть статьи раньше, чем другие ;)
Здесь запрещены же кросспосты
За деньги разрешены ;)
А можно рисунки 3, 4 побольше? А то не разобрать ничего.
habrastorage не поддерживает большие размеры картинок, как я понял, поэтому mind map и другие огромные элементы можно посмотреть в полном размере у нас на сайте в полной версии статьи: secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html
Картинки не обязательно через habrastorage грузить. Можно и прямые ссылки на тот же secl.com.ua. Если конечно сайт выдержит хабраэффект.
Боюсь сервер не выдержит. Просмотров статьи намного больше, чем тех, кому действительно надо посмотреть большие размеры.
Или просто ссылки на большие картинки дать (под картинками).
Либо можно дать ссылку на полную версию по клику на картинку.
При использовании Axure, на восьмом этапе, мне кажется, разумно структуру сайта делать не в сторонней программе, а внутри самого Axure. Это упростит навигацию по проекту, ведь структура будет тесно связана с прототипом.
Как вариант…
В mindmap гораздо быстрее это делать просто. И удобней.
Axure = 289$. Есть ли аналоги?
Равного аналога на мой взгляд нет. Я штук 20 пробовал разных, в основном онлайн, но и программы тоже были. Ничего сравнимого по скорости и комфорту работы не нашел.
Есть ломаная на торрентах ;)

А вообще есть разные программы для проектирования, но соглашусь с borsh — равного нет. Акшур самая лучшая.
Аналоги чего? Если откинуть создание интерактивного прототипа и мастера — есть и много. И есть довольно удобные. Воспользуйтесь поиском, этот вопрос чуть ли не каждый месяц задают.

А если искать замену всей axure целиком, то дешевле аналогов нет.

ЗЫ: Axure за 289$ — это «урезанная» версия. Ставлю кавычки, потому что доп. функционал из Pro нужен далеко не всем www.axure.com/compare
А дороже аналоги?

Какие довольно удобные? Все онлайн-версии не рассчитаны на реально быструю работу с блоками.
Аналоги Axure можно посчитать по пальцам: Justinmind, Blend + SketchFlow, iRise, GuiMachine.

Я пробовал все, кроме iRise (который вроде как 5 тыс. долларов за 1 лицензию стоит). Все они, по моему мнению, проигрывают в удобстве использования Axure. По iRise смотрел видео, есть некоторое хорошие моменты, но не увидел ряда базовых вещей, которые есть в Axure и работу без которых теперь трудно представить. К сожалению, не смог попробовать Antetype, потому что он работает только в Mac, вполне может быть, что тоже хороший инструмент.

Однако, если брать во внимание наличие обучающих материалов и типовых решений, то тут Axure вообще недосягаем.
Вот специально попробовал только что все, что вы написали. Те же проблемы, что с онлайн-продуктами: меня не устраивают самые базовые вещи вроде скорости выделения-перемещения блоков (типа выбрать группу элементов — скопировал 5 раз на 3 разных страниц, подвигал там), показа линий выравнивания, да даже списки элементов для размещения какие-то мелкие и кривые везде.

Удивительно.
По-моему это правильнее называть не «проектирование», а «макетирование», ибо результатом является не проект или его карта, а макет как наброски юзабилити и дизайна.
В опросе нужны не радиобатны, а чекбоксы — за макет могут отвечать несколько человек (и тот факт, что, например, дизайнер, раскидывает это все в красивую картинку еще не значит, что он отвечает за этот процесс)
Не соглашусь, результатов тут много, не только макеты. Первый важный результат — это концепция, сама идея.
«прототипирование» можно. Но выше правильно заметили, что тут не только прототип является результатом.
описывать очевидные вещи: что ссылка – это ссылка, конечно, не стоит

А стоит ли вообще описывать словами то, что уже есть на прототипе? Например, что здесь — «главное меню». Кому нужно такое описание? С одной стороны и так должно быть понятно, с другой формально элемент же показан на всех страницах где он должен быть, что еще надо? Зачем его обзывать текстово?
Если элемент очевиден и его поймут на следующих этапах разработки — можно и не описывать. А вот неочевидные вещи нужно обязательно описывать.
По сути прототип является важной частью ТЗ только для дизайнера (рассматриваем классический процесс дизайн-верстка-программирование). Для верстальщика главная часть уже сам дизайн. Для программиста верстка.

Так что вряд ли есть вообще смысл детально все писать заранее. Лучше наверное на каждом этапе дописывать, учитывая то, что появилось на прошлом.
Для программиста важна бизнес-логика. Например на прототипе будет рейтинг, а как он будет считаться? Это нужно описывать в ТЗ. Кроме того, ТЗ важная штука для клиента, он должен утвердить его и подписать как приложение к договору, иначе по ходу проекту начнут появляться «хотелки»…
Это справедливо для типичного многостраничного сайта. Программист будет смотреть на готовые страницы и понимать, что делать. Если же это сложное одностраничное приложение с кучей неочевидных взаимодействий, одного дизайна и даже верстки будет мало, потому что не будет понятно, что на что влияет и как организована совместная работа разных компонентов страницы. Например, сайт-визитка как пример первого варианта и Google Spreadsheet для второго другой.
Сомневаюсь, что Google Spreadsheet делали по схеме «дизайн-верстка». Скорее «прототип-верстка-css-дизайн». Тут да, другой подход к ТЗ нужен.
Насчет прототипирования. Мне в свое время очень понравился подход Влада Головача для макетов страниц: если не понимаешь сходу как оно должно быть — просто накидай на страницу кирпичиков — блок меню, блок друзей, блок сообщений и т.п. в произвольной форме.
Когда таких страниц наберется несколько штук — в голове уже так или иначе сложится структура, какие блоки общие, какие уникальные и как их правильно раскидать на каждой странице.
И проектирование меню, имхо, задача важная, но не САМАЯ важная, а на одном уровне с расположением блоков на странице и взаимодействием с ними. Здесь важно только понимать, что меню — сквозное на все страницы (по крайней мере верхний уровень) и работать с ним надо на общем шаблоне всех страниц.
Работаю по Головачу )

Меню всегда строю до проектирования. На это есть несколько причин:

1. При построении структуры сайта (меню) заодно выясняю какие будут разделы, с какой информацией (карта наполнения). Становятся понятны взаимосвязи между страницами, где, какая функциональность нужна

2. Грубо: меню может быть длинным или коротким. Соответственно становится понятно в каком виде разместить. Надо ли делать доп. меню (выделять основные вещи), нужно ли выпадающее и в каком виде и т.д.

3. Клиент начинает работать/думать о сайте ) Это такое полезное следствие. Клиент вовлечен в работу. Со структуры начать проще, чем со схем.
тогда мы немного про разное говорим.
для меня меню — это блок на странице, а то, о чем вы говорите — скорее структура сайта, которая, безусловно, должна быть понятна до прототипа (по крайней мере ключевые моменты)
Чаще всего главное меню = первый уровень структуры сайта за исключением сервисных элементов типа входа-регистрации.
// просто накидай на страницу кирпичиков //

Ха, я думал сам этот метод придумал, а тут оказывается все уже занято :)
прототипирование — процесс итеративный, т.е. от прототипа часто возвращаешься к требованиям, к структуре сайта, правишь — потом снова к прототипу и т.д.
например макетируешь страницы — раз, вылезла необходимость какого-то нового функционала, который был не очевиден на этапе создания требований (или просто профукали :)) — соответственно, добавили функционал в требования и в прототип, продолжаем.
конечно, это тесно связано с качеством собранных требований и с особенностью мышления проектировщика, мне, например, существенно удобнее думается когда я смотрю на макет страницы и представляю действия пользователя на нем.
так что в какой-то мере разработка требований, информационной структуры и прототипа — процессы параллельные и тесно взаимосвязанные.
По сути да, на каждом этапе можно вернуться и доработать прошлые, если это необходимо.
НЛО прилетело и опубликовало эту надпись здесь
Нет :) Я так привык, называю как мне удобно. В статье есть и правильное название.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за отзыв)
Ваш комментарий развернутый и, в общем-то, по делу. Но дело привычки никто не отменял. Вы, наверно, знаете, что корпус ПК — это, простите, писюк? Все от перевода PC ))

И таких примеров — привычек много.

Согласен, что «карта ума» неблагозвучно
НЛО прилетело и опубликовало эту надпись здесь
В качестве спора :-) Наберите в гугле «ментальная карта» и вы увидите, что количество ссылок легко бьет все варианты транскрипций «Майнд Мэп».
НЛО прилетело и опубликовало эту надпись здесь
Да, не в ту сторону меня понесло: mental map и mind map — не одно и то же. Mind map переводят чаще как диаграмма связей или ассоциативная карта.
ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D1%81%D0%B2%D1%8F%D0%B7%D0%B5%D0%B9
Древовидная структура :)
Это прекрасно! Википедия дает 8 вариантов перевода, упустив «карты ума» и «майнд-мэпы». С «древовидной структурой» будет уже 11! :-D
Опять 25!

Подход к определению структуры сайта — сугубо субъективный, без вовлечения пользователей.

«Карточная сортировка? Нет, не слышали!»

Как только такие лоховские подходы удостаиваются кармы.
Вовлечение пользователей, если его качественно делать, дорого стоит, нет?
Нет.

Про качественные исследования:

Обычно за часовое интервью респонденту можно дать небольшой подарок (скидку, сувенир, подарочную карту) или 200-1000 рублей, в зависимости от региона. (Время интервьюера может быть дороже).
Первые 3-7 интервью приносят максимальную пользу, отдача от следующих падает.
Три интервью существенно лучше, чем ни одного.
Семь интервью обычно лучше, чем три.
30 интервью немного лучше, чем 7, но иногда уже не нужны.

Правда, важно знать как проводить интервью. Типовая ошибка, которую делают почти все начинающие — спрашивать, чего человек хочет от сайта/продукта. Нужно исследовать его деятельность, задачи и проблемы.

Теперь про количественные исследования:

Опросы на Гугл Формах практически бесплатны.

Если говорить конкретно про проектирование навигации и карточную сортировку — то Optimal Sort, например, бесплатен до 10 респондентов, чего может хватать для простенького сайтика. Без ограничений на число респондентов он стоит 3 тр в месяц: www.optimalworkshop.com/optimalsort.htm

Вот тут можно посмотреть мою подборку методов исследования пользователя: www.slideshare.net/maieutic/ss-15137912
Про ю-тестирование на 3-х пользователях раз в месяц с объяснением, почему это дёшево, аж целая книжка у круга есть: www.ozon.ru/context/detail/id/5137749/
Хочу поинтересоваться, насколько функциональным вы делаете прототип.
Вы прописываете Axure аналоги JQuery эффектов, всплывающие менюшки там из скрытых динамических панелей?
Вид сайта под авторизованным юзером и без, и если под авторизованным, то используете ли переменные при входе?
Мы обычно его делаем без интерактива. Что касается разных состояний (авторизован или не авторизован) — это описывается в ТЗ, можно делать небольшие таблицы с возможностями для разных ролей.
Прочитал обе ваши статьи, перешел по ссылке на ваш сайт, скачал обе карты для изучения, спасибо.
К сожалению обнаружил, что для собственного сайта карты не рисовали :) иначе бы тут secl.com.ua/portfolio_web_development.html
по ссылке «Подробнее о проекте» не переходил бы обратно на эту же страницу :)
Да, там портфолио в процессе доработки и далеко не полное. На себя как обычно не хватает времени :)
Для сравнения можно посмотреть прототипы других проектов разработанных нами:

Социальная сеть по фотографии FOTO.ua: прототип и на основе этих прототипов дизайн.

Эх… Сам увлекаюсь фото. Вы умудрились сделать сайт о таком ярком деле как фотография серым и скучным.

Юзабилити тоже не ахти:
image

«Нравится» находится до контента, который необходимо оценить. Кнопки «листания» тоже в непонятном месте. В комментариях кнопка «Ответить» должна быть после текста комментария. И т д :)
http://seclgroup.ru/article_serious_design_of_the_serious_websites_2.html — наша обновленная технология проектирования. Написали продолжение этой статьи спустя почти 4 года. Визуальная часть теперь заканчивается динамическим прототипом и его тестированием.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий