Пример прототип сайта – Как правильно показывать клиенту интерактивный прототип сайта в первый раз / Habr

Содержание

24 профессиональных примера прототипов веб- и мобильных сайтов — CMS Magazine

Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис БЕСПЛАТЕН для заказчиков.

Прототип – это первоначальный набросок сайта на бумаге. Во время разработки сайта для компьютеров или мобильников такие рисунки помогают в выборе точек фокуса внимания и расстановке элементов дизайна перед началом работы. Эскизы мобильных - и веб-шаблонов помогают сконцентрироваться на креативной составляющей проекта. Кроме того, это лучший для клиента способ понять, за что же он собирается платить. Наброски шаблона помогают дизайнеру не сбиться с пути во время работы над сайтом. Также они экономят деньги и время, которые потребовались бы для корректировки первоначальных набросков онлайн.

Прототипы могут быть выполнены с различной степенью детализации. Карандашные эскизы являются первым шагом в концептуализации проекта. В данном случае менее детальный рисунок будет более предпочтительным для разработчиков. Фактически такие эскизы, выполняемые для мобильных и веб сайтов,

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

Веб- и мобильные  наброски важны с точки зрения поиска инвесторов для проекта. Имея в своем распоряжении начальный эскиз шаблона, вам потребуются считанные секунды, чтобы определить круг вероятных инвесторов и заинтересованных лиц. Карандашные эскизы являются первым шагом в продвижении идей и налаживании связей с привлекающими вас инвесторами. Есть несколько примеров сделок, заключенных сразу же после того, как инвесторы ознакомились с эскизами сайта и посчитали проект достаточно прибыльным и привлекательным. Для того, чтобы всегда быть первым в конкурентной борьбе, очень важно уметь рисовать эффектные карандашные прототипы веб- и мобильных сайтов.

Демонстрируя проект инвесторам, вы можете вносить необходимые изменения в эскиз. Если вы достаточно опытны в создании быстрых и детальных набросков, вы сможете легко изменять исходный рисунок шаблона для достижения лучших результатов. Для создания эскизов веб- и мобильных сайтов могут быть использованы самые современные инструменты. Также в интернете можно найти множество советов по быстрому и эффективному

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

Примеры набросков веб- и мобильных сайтов

  • Эскиз приложения для iPad

  • Набросок сайта

  • Цветные наброски Early Ember

  • Эскиз страницы статьи  OnlyJames

  • Эскиз шаблона CommLogix

  • Ранний эскиз дизайна BusinessWeek.com

  • Эскиз интерфейса BPG

  • Идеи каркаса для страницы поиска версия 1

  • Набросок: страница клипа в vimeo

  • Концепт "Вычеркивания"

  • Эскиз домашней страницы Janko At Warp Speed

  • Редизайн Heartland Funds: эскиз формы входа на сайт и главной страницы

  • Эскиз шаблона UserScape

  • Эскиз каркаса CommLogix

  • Прототип главной страницы Data Techniques версия 1

  • Эскиз Coastal Capital Partners

  • Грубый набросок нового шаблона Account Planning Group

  • Редизайн Mobile Platform

  • Прототип микросайта World of Color

  • Прототип страницы Giant Hello Splash

  • Прототип интернет-магазина

Что нужно предпринять для того, чтобы выбрать надежного и опытного разработчика, который точно знает, что делать и гарантирует результат? Стоит смысл воспользоваться таким инструментом как рейтинг веб-студий.  Для построения этого рейтинга, мы изучили портфолио почти 5 тысяч веб-студий (более 90 тысяч сайтов).

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

Оригинал: designmodo.com.

Насколько отличатся прототип и конечный дизайн сайта?

СЕРИЯ СТАТЕЙ ПРО ПРОЕКТИРОВАНИЕ

ЧАСТЬ 8

Андрей Батурин,

АНДРЕЙ БАТУРИН

При ответе на данный вопрос надо учитывать тот факт, что прототип может иметь три степени проработки - низкую, среднюю, высокую. Про это было подробно описано в статье “Виды прототипов сайтов”. Повторюсь, что на практике, наиболее часто используемым прототипом, на основе которого разрабатывается дизайн, является прототип средней степени проработки. Если прототип был хорошо проработан и продуман, то отличия между ним и дизайном, разработанным на его основе, будут минимальны. Но все же, они могут быть, часто это происходит в тех случаях, когда в процессе создания дизайна приходят более удачные идеи реализации интерфейса. Каждое отступление обсуждается с заказчиком и разработчики должны обосновать его внедрение, если заказчик его утверждает, то оно реализуется в дизайне сайта. Как правило, расхождения не превышают 20% от общего объема выполненных работ. Если их больше, то значит проектирование было выполнено с ошибками, необходимо остановить работы и вернуться на стадию проектирования сайта.

Примеры прототипов и дизайна страниц сайта сделанного на их основе

Прототип главной страницы сайта ресторана.

Дизайн главной страницы сайта ресторана.

Прототип страницы медицинского сайта.

Дизайн страницы медицинского сайта.

Почему разработчики против внесения правок на этапе отрисовки дизайна?

Часто бывают ситуации, когда клиент настаивает на внесении каких-либо правок в дизайн сайта (а часто это значит, что и в его функционал). Речь идет о добавлении чего-то, что не было вовсе реализовано в прототипе и не описано в техническом задании на разработку сайта. Клиент получает мотивированный отказ от разработчиков, по причине того, что объем работ был рассчитан исходя из утвержденного прототипа и технического задания на разработку сайта. А добавление новых работ влечет за собой увеличение объема работы, который должен быть оплачен дополнительно.

Поэтому заказчику нужно очень важно внимательно относиться к утверждаемым им документам и, прототипу в том числе, дабы не возникало конфликтных ситуаций и не приходилось тратить дополнительно время и деньги на неучтенные доработки. Зачастую, разработчики идут на встречу клиентам и незначительные изменения вносятся без доплаты, но в таких случаях это их личная инициатива, но не в коем случае, не обязанность, и это надо понимать.

Другие статьи по тегам

сайты проектирование дизайн сайта

на эту тему

Что такое прототип
и прототипирование сайта Зачем надо делать прототип сайта Можно ли сделать сайт без прототипа Можно ли сделать прототип самому Подборка логотипов ресторанов и кафе Значение цвета в фирменном стиле компании

Серьезное проектирование серьезных сайтов. Часть 2. Визуализация

Это вторая часть статьи про проектирование больших сайтов. В ней мы расскажем про визуальную часть проектирования, про интерфейсы. Если вы не читали первую часть, то рекомендую это сделать тут.

Динамический прототип



Рис. 9. Демонстрация динамического прототипа для проекта «Маркетплейс».

На этом этапе мы переходим от аналитики к интерфейсам, к визуальной части. На основе Mind map необходимо спроектировать интерфейсы для каждой функции и страницы. Таких интерфейсов у нас будет много, от нескольких десятков до нескольких сотен уникальных прототипов, а еще есть раскадровки, когда одна страница может иметь ряд состояний, всплывающих окон, выпадающих блоков и т.д. В процессе все прототипы объединяются в один большой динамический прототип и связываются между собой.

В статье будет много картинок. Хабр, к сожалению, не разрешает загружать большие картинки, поэтому их можно посмотреть в полной версии статьи на нашем сайте.

На этом этапе мы переходим от аналитики к интерфейсам, к визуальной части. На основе Mind map необходимо спроектировать интерфейсы для каждой функции и страницы. Таких интерфейсов у нас будет много, от нескольких десятков до нескольких сотен уникальных прототипов, а еще есть раскадровки, когда одна страница может иметь ряд состояний, всплывающих окон, выпадающих блоков и т.д. В процессе все прототипы объединяются в один большой динамический прототип и связываются между собой.

Делается это с помощью программы Axure RP или другой, их довольно много сегодня, в том числе онлайн-сервисы. Хотя лучше Axure мы за долгие годы работы пока не нашли. Некоторые пытаются проектировать в Photoshop — это в основном дизайнеры, а не проектировщики, которые методологию проектирования используют лишь частично. Photoshop и ряд других программ не позволяют делать динамические прототипы, да и банально долго проектировать в Photoshop. Нам нужна динамика, чтобы подумать над каждой кнопочкой и ссылочкой. Сразу скажу, что красивые картинки, не собранные в динамический прототип, в том числе просто дизайн без проектирования, это первый гвоздь в гроб проекта. Мы попросту не сможем проверить работу на логические ошибки перед тем, как отдать на следующий этап, и будем вынуждены переделывать после. А классика разработки, наверное, самая известная книга «Совершенный код» нам очень наглядно показывает, как на разных стадиях исправление ошибки будет повышаться от 1$ до 10000$.

Мы должны планомерно идти по нашей Mind map и проектировать страницу за страницей. Axure слева может показывать оглавление, там мы называем страницы, делаем вложенности и нумеруем все в формате: «1.0.0», «2.0.0», «2.0.1» и т.д. Это не даст нам запутаться, когда у нас будет несколько десятков страниц. Также важно стараться проектировать целыми разделами, а не выборочно несколько страниц в одной части проекта, а потом несколько страниц в другой.

Сложнее всего спроектировать первый макет. На нем делают некоторые базовые элементы, которые будут видны на всем сайте, например, шапка сайта, меню, подвал, формы и т.д. Такие элементы нужно проектировать первыми и загонять в мастера в Axure. Начинать можно именно с этих блоков, так будет проще. После, когда мы настроили модульную сетку и спроектировали первые блоки, можно проектировать и основное содержание страницы. Для этого мы сначала выписываем список блоков, которые будут на страницы, затем примерно накидываем их расположение на странице, а затем детализируем каждый из блоков. Есть еще много правил юзабилити, которые нужно учесть, это все должен знать опытный проектировщик. Также стоит думать о целевой аудитории, накладывать опыт ЦА на каждый проектируемый нами интерфейс, ведь все их мы делаем для определенной группы людей, а не для себя.

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

Проектируя любую из страниц очень полезно смотреть на хорошие юзабильные сайты со сходным функционалом и, конечно, на конкурентов. Они натолкнут на много полезных идей. С одной стороны, люди любят то, к чему привыкли, и некоторые решения нам придется повторить у конкурентов, с другой стороны, копировать нельзя, ведь наша задача сделать лучше, чем у них.

Интерфейсы мы проектируем черно-белыми не зря, чтобы не расставлять неправильных акцентов. Цветовые акценты — это дело дизайнеров, а не проектировщиков. Про влияние цвета в дизайне мы писали отдельную большую статью: Манипуляции пользователями сайта с помощью цветов. Также не стоит использовать реальные фотографии, вместо них мы ставим заглушки определенного размера. Задача проектировщика расставить акценты без вспомогательных инструментов, исключительно удобством самого интерфейса, его логической последовательностью. Многие начинающие проектировщики и дизайнеры часто прибегают к использованию цветов в проектировании и могут загубить все этой идеей.

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

После создания всех страниц их нужно соединить их воедино. Для этого мы делаем динамику с помощью внутренних инструментов Axure, соединяя все страницы ссылками, делая всплывающие окна, выпадающие списки и т.д. Важно также забить в прототип реальный контент, чтобы максимально его приблизить к живому сайту. Так мы оживляем прототип, и у нас появляется возможность проверить логику его работы и даже показать реальным пользователям для получения первой обратной связи. Пример такого прототипа в динамике мы показывали в статье, в которой описано проектирование аналога Alibaba.com — более 200 уникальных прототипов, и это еще упрощенная версия.

Отдельно проектируется адаптив, чтобы на всех устройствах и разрешениях экранов сайт отображался корректно. Сегодня в мире более половины всех пользователей посещают сайты с мобильных устройств, так что адаптив — это давно не мода. По сути, адаптив — это несколько разных вариантов сайта, которые отображаются пользователям в зависимости от его устройства. Пользователь этого не знает, но технически мы должны спроектировать несколько отдельных версий. Минимум их должно быть три: 320 px., 768 px. и 1200 px. Реже делаются еще варианты под 420 px. и 960 px. Чем меньше экран, тем меньше функционала должно быть в прототипе, то есть для маленьких экранов мы делаем упрощенные варианты. Как альтернатива, можно не проектировать адаптив, а оставить его на этап верстки, на усмотрение верстальщика — это значительно дешевле, но и качество пострадает.

Примеры других больших спроектированных проектов, которые мы делали за последние 5 лет, правда, покажем мы их без динамики:


В общем, за последние несколько лет мы проектировали почти все, что только можно, тут далеко не полный перечень проектов. Технология проектирования универсальная и довольно близка к стандарту ISO 9241-210 «Human-centered design for interactive systems». Другими словами, это то, чем пользуются во всем мире, и оно отлично работает!

Для иллюстрации слов еще несколько прототипов разных проектов:

Рис. 10. Прототип социальной сети с элементами электронное коммерции

Рис. 11. Протопит сервиса Пуш уведомлений

Рис. 12. Прототип образовательного сервис

Рис. 13. Прототип сервиса звонков.

Рис. 14. Прототип автомобильного журнала.

Рис. 15. Прототип маркетплейса.

У опытного проектировщика всегда есть огромное количество наработок в динамике, поэтому он может создавать подобные прототипы в разы быстрее. Это целые библиотеки элементов, блоков и даже стандартных страниц.

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

Реальный контент



Рис. 16. Демонстрация реального контента для проекта «Маркетплейс».

Кто-то из известных проектировщиков сказал: «Проектирование — это во многом копирайтинг». Проектируя с 2007 года, я много раз в этом убеждался на собственном опыте. Недостаточно сделать красивую картинку и наполнить её шаблонным текстом «Lorem Ipsum», так у нас на этапе наполнения сайта начнут блоки плыть, текст не вмещаться, захочется еще что-то вставить и т.д.

Для начала нужно продумать все заголовки на каждой странице, от общего заголовка всей страницы до каждого мелкого блока. И они должны быть реальными, как на живом сайте. Это делает проектировщик, хотя можно привлечь и копирайтера. Все заголовки должны быть простые, понятные и короткие.

Вторым этапом нужно набить страницы реальным текстовым контентом, который будет использоваться на живом сайте. Так мы убедимся, что все помещается и учтено. Все тексты должны разрабатываться профессиональными копирайтерами, проектировщик их только вставляет. Также стоит утвердить каждый готовый интерфейс с маркетологом.

Можно зайти с любой стороны: сначала контент, потом меняем под него проектирование. Или сначала проектирование, потом под него подстраиваем контент. Главное его учесть.

В конце этого этапа наш прототип должен выглядеть почти как готовый сайт, только без цветов.

Сценарии поведения и Customer Journey Map


Прототип создан, и он выглядит, как живой сайт. Но каким бы опытным не был проектировщик, все в голове не удержишь, и в прототипе будут ошибки, прежде всего, неявные, логические ошибки. Для их нахождения нужно разработать сценарии поведения и Customer Journey Map, а после прогнать наш динамический прототип по ним и найти основные недочеты.

Смысл в том, что поведение каждого человека можно спрогнозировать. Хотя бы по основным шагам. Для основных групп пользователей мы должны создать сценарии поведения на сайте, которые покажут основные его шаги. Такие сценарии могут быть, как маленькими, в рамках одной страницы (Use Case), чтобы протестировать на логические ошибки отдельный кусок работы, так и большими, решение какой-то задачи в рамках сайта и его нескольких страниц. Важно покрыть такими сценариями весь сайт, все основные функции.


Рис. 17. Use Case для проекта «Маркетплейс».

Customer Journey Map — тоже сценарий поведения, его особый вид. В целом это маркетинговая технология, которую очень удобно применять для проектирования. Мы должны спланировать и затем отслеживать все шаги клиента до того, как он попал на сайт, и после того, как его покинул. По- настоящему, каждый пользователь приходит на сайт из разных мест и с разными ожиданиями. Кто-то идет целенаправленно купить наш продукт и все о нем знает, а кто-то случайно попал на сайт из социальных сетей. Также есть и история жизни человека после сайта. Например, когда он воспользовался нашим продуктом, и он ему понравился / не понравился, он может что-то дальше сделать в зависимости от своего опыта. Построив такие Customer Journey Map, мы сможем подготовиться к любым событиям до и после сайта, сможем сделать пользователя лояльным и встроить его в мультиканальную коммуникацию с проектом. Это мы должны сделать для реальных клиентов, тех, кто платит (будет платить) нам деньги. В принципе, CJM можно подготовить еще в этапе аналитики и учесть идеи до прототипирования, а на этом этапе только перепроверить себя.


Рис. 18. Customer Journey Map для проекта «Маркетплейс».

Метод важен не только на этапе проектирования, но и в живом проекте. На этапе проектирования мы можем только догадываться, а уже в работающем проекте есть возможность постоянно задавать вопросы покупателям и точно знать их шаблоны поведения. Также не забываем, что при разработке Customer Journey Map следует учесть воронку продаж, определить цели на каждом этапе воронки, выделить точки взаимодействия, особенно те, которые касаются или могут касаться сайта, и выделить KPI, чтобы понимать, чего нам нужно добиться от наших покупателей, а в конце выделить проблемные места и улучшить их. Это то самое слабое звено, устранив которое, вся система заработает лучше. Например, нашей целью может быть увеличение среднего чека покупателя путем допродажи ему сопутствующих услуг. Вот купил он телевизор, а его нужно доставить, установить, настроить и т.д. 10 лет назад каждый покупатель делал это сам, интернет-магазин ему не предлагал такой широкий сервис. Сегодня многие магазины предлагают множество дополнительных услуг к основному продукту, и люди это покупают. Как это было придумано? Ответ очевиден: кто-то начал наблюдать за покупателями и понял, что они в реальной жизни заказывают дополнительные услуги на стороне, но это не очень удобно и можно предложить комплект. Так и родилась эта функция по увеличению среднего чека, как и много подобных идей в современных веб-проектах.

Создав такие сценарии, мы их берем и прогоняем по ним наш прототип, страницу за страницей. Опять же они должны быть подробные и приближенные к жизни, иначе они нам не вскроют ошибки проектирования. Этот этап должен помочь нам найти проблемы в логике и доработать интерфейсы по мелочам. Customer Journey Map в свою очередь даст пул новых идей для проекта, часто уникальных, которых не будет у конкурентов. Все прогонки по сценариям делаются с привязкой к разработанным ранее персонажам, чтобы проектировщик думал, как типичный пользователь будущего проекта.

В конце этого этапа мы исправим ряд ошибок и доработаем наш прототип.

QA и юзабилити тесты


Мало кто знает, но у проектирования есть отдельный этап QA. Когда специально обученный менеджер по качеству, с очень большим пользовательским опытом, начинает задавать неудобные вопросы проектировщику. Задача этого человека в том, чтобы просмотреть каждую спроектированную страницу, оценить все спроектированные функции и убедиться, что все понятно и качественно.

Казалось бы — зачем? Мы же сделали динамический прототип, прогнали по нему сценарии поведения, нашли ошибки. На самом деле к этому этапу у проектировщика просто «замыливается глаз», и взгляд со стороны позволит нам найти еще ряд ошибок и спорных решений. Кроме того, QA сразу оценивает реализуемость спроектированной системы на следующих этапах.

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

В конце этапа мы исправим последние ошибки и можем продолжать работу над проектом. В частности, проект к этой стадии уже давно должен активно дизайниться, верстаться и программироваться. Разработка такого прототипа у больших проектов занимает от 150-200 часов и более. У маленьких проектов для опытного проектировщика вполне хватит нескольких десятков часов, зато он даст полную гарантию того, что мы не будем вечно переделывать и тратить драгоценные ресурсы на более поздних этапах.

Техническое задание



Рис. 19. Пример технического задания для проекта «Маркетплейс».

Имея полный динамический прототип нам нужно написать сопроводительное ТЗ. По-хорошему, оно должно писаться в процессе прототипирования, после каждого утвержденного макета. Несмотря на наглядность живого прототипа, из него будет понятно не все. ТЗ может делаться по-разному: от описания неочевидных механик прототипа до сотен страниц технических требований проекта. Главное, не писать ТЗ ради того, чтобы было, и не вписывать туда бесполезную воду. Пишем только действительно важные требования для проекта.

Структура ТЗ опять же бывает разная. Кроме описания самого интерфейса, мы обычно включаем такие блоки:

  • Архитектура сайта — прорабатывает архитектор
  • Требования по нагрузкам — прорабатывает архитектор и тим лид
  • Сервера и инфраструктура — прорабатывает системный администратор, архитектор и тим лид
  • Требования по безопасности — прорабатывает специалист по безопасности и тим лид
  • Требования по SEO — прорабатывает SEO-шник и интернет-маркетолог
  • Требования к дизайну — прорабатывает дизайнер
  • Требования к верстке — прорабатывает верстальщик
  • Микроразметка — прорабатывает верстальщик
  • UML, диаграммы робастности — прорабатывает проектировщик и программист
  • Разграничение прав доступа — прорабатывает проектировщик

Не все прорабатывают эти блоки на этапе проектирования. Но мы помним, что чем позже начнем формировать требования, тем дороже будет стоимость изменений. Если посмотреть на подавляющее большинство больших проектов, то они не формировали подобные требования в начале. Вспоминая много разных историй разных проектов, я могу выделить ряд типичных проблем, которые появлялись как раз из-за не проработанности этих вещей сразу. Думаю, ниже многие сейчас узнают себя.

Что если не прорабатывать требования, указанные выше?

  • Архитектура сайта — если её не проработать, с высокой долей вероятности мы заложим неверную архитектуру, это приведет к проблемам масштабирования проекта, и его придется переписывать.
  • Требования по нагрузкам — обычно делают проект, а потом отдельно тестируют и оптимизируют нагрузку. Но если требований нет, в архитектуре это не предусмотрено, то сайт рано или поздно начнет падать при росте посещаемости, и произойдет это в самый неудобный момент.
  • Сервера и инфраструктура — тоже самое, непродуманная инфраструктура приведет к необходимости перенастройки и падению сайта.
  • Требования по безопасности — если у нас не будет требований по безопасности, и этим никто не будет заниматься, это неизбежно приведет к взломам, последствия которых будут непредсказуемы: от кражи данных до полного стирания сайта.
  • Требования по SEO — как часто вы слышали от маркетологов, что сайт нужно переделывать под требования SEO? Если у вас был хотя бы один сайт, который вы продвигали, то с вероятностью 90% слышали. Все потому, что создавали его без требований к SEO, которые должны закладываться именно на этапе проектирования, а не позже.
  • Требования к дизайну — если мы не проработаем эти требования, то имеем риск долго переделывать дизайн. Это вообще самое скользкое, что может быть, так как у всех разные предпочтения, и все мнят себя дизайнерами. Единственный вариант снизить количество переделок дизайна — это заложить требования.
  • Требования к верстке — сегодня Google учитывает множество параметров верстки. Это и адаптивность, и стандарты W3C, и скорость загрузки, и многие другие параметры. Если мы не заложим требования к верстке, то сайт у нас будет плохо индексироваться и плохо отображаться на мобильных устройствах пользователей.
  • Микроразметка — если мы не сделаем её, то верстка у нас будет на субъективное усмотрение верстальщика, а значит, сайт не будет правильно индексироваться.
  • UML, диаграммы робастности — это больше для программистов, чтобы они ничего не упустили и опять же не переделывали.
  • Разграничение прав доступа — тоже самое, для программистов, чтобы не переделывать.

Как можно заметить, каждый пункт довольно важен для проекта, а некоторые — критичные. Вся эта детализация требований защищает от переделок, тем самым сильно экономит время и деньги. Опять же, вернусь к началу статьи, все это можно делать по Agile, постепенно формируя требования по мере старта проекта. Главное, чтобы менеджер проекта хорошо понимал этапность проектирования, когда какой этап можно начинать, и как все они связаны с дальнейшей разработкой. Зная все это, можно спланировать так, что нулевая стадия у нас займет всего 2 недели, а затем начнется постоянная работа над всеми этапами одновременно, при этом с минимумом переделок.


Рис. 20. Таблица с правами доступа для проекта «Маркетплейс».

ТЗ — это довольно объемный документ. Для примера можно посмотреть часть ТЗ, которое мы разрабатывали, в частности описание прототипа Маркетплейса. Две сотни страниц описания. Описание должно быть подробным и понятным. Нельзя допускать неточностей и двояких трактовок. Важно описать неочевидные места. Например, рейтинг пользователей может выражаться в проектировании одной цифрой, а на самом деле скрывать за собой сложную формулу его расчета. В документе обязательно должны быть ссылки на конкретные страницы прототипа и нарезка частей интерфейса.

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

В конце этого этапа мы получим полное ТЗ проекта, которое должно минимизировать риски максимально, насколько это можно, и из статьи вы сами поняли, почему именно.

Маленький бонус


В статье я показал много примеров из проекта «Маркетплей», в том числе прототип карточки товара, и дал ссылку на полный динамический прототип. После проектирования любой проект передается на дизайн. И этот проект в дизайне выглядит вот так:

Рис. 21. Дизайн страницы товара проекта «Маркетплейс».

Что должно получиться в итоге?


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

Как вы уже догадались, это тот этап, который делает целая команда. Как минимум это BI Analyst для аналитической части и UX / UI Designer для графической. Но в качестве консультантов на разных этапах нужно привлекать таких ребят, как: Digital Marketing Manager — для проработки маркетинговой составляющей и работе над интерфейсами, System Administrator — для разработки требований к аппаратному обеспечению, QA Engineer — для проверки логики прототипа, Software Architect — для разработки архитектуры, Web Designer — для консультаций по интерфейсу, Technical Writer — для разработки технического описания проекта и ряд других экспертов.

Несмотря на множество описанных здесь этапов, в целом проектирование — это не очень долгий и затратный этап, по крайней мере, для опытного проектировщика. А если оценивать его, как хорошую и почти единственную защиту от переделок и ошибок, то в итоге проектирование экономит много времени и денег владельцу продукта. Я бы сказал, что именно проектирование имеет один из самых больших ROI в проекте. Обычно проектирование применяется для новых проектов, хотя его также можно применять и для уже готовых проектов, чтобы значительно улучшить конверсию и другие базовые KPI проекта. Правда, для уже работающих проектов технология будет другой, и это тема отдельной статьи. В любом случае, это целая сложная наука со своими правилами и специалистами. Мы учились этому всей командой почти 10 лет, и учимся до сих пор, набивая на пути множество шишек.

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

P.S. На днях у нас стартовал курс по проектированию от авторов статьи: Проектирование серьезных сайтов. Еще можно записаться на курс со скидкой. Для этого пишите на [email protected]

P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на фан страницы SECL Group: Facebook, VK, и Twitter.

Автор:
Никита Семенов
CEO
Компания «SECL Group»

6 инструментов для прототипирования сайта

Из статьи вы узнаете:

  • что такое прототипирование почему об этом важно знать, даже если вы не дизайнер;
  • как прототипирование упрощает процесс создания сайта;
  • какой инструмент прототипирования сайта выбрать.

Что такое прототипирование

Прототипирование — это быстрая «черновая» реализация базовой функциональности сайта. Позволяет, в зависимости от задачи, с разным количеством деталей изобразить главные возможности будущего продукта.

Прототипирование особенно пригодится, если вам нужно создать интернет-магазин. Такие сайты всегда имеют сложную структуру, множество страниц и большой объем работы с расстановкой акцентов и управлением вниманием посетителя.

6 инструментов для прототипирования сайтаСтруктура интернет-магазина штор, сделанная в программе Xmind (источник)

Узнать, как продвигать интернет-магазин, избежать ошибок и вдохновиться на процесс можно на бесплатной онлайн-конференции “Интернет-магазин от А до Я” от обучающего центра Cybermarketing.

Вы можете рисовать схемы от руки на бумаге или презентовать идеи на доске, но есть риск, что в таком формате невозможно донести идею точно, как она была задумана.

Существует более прозрачный способ передать идею и получить обратную связь на вашу работу — инструменты прототипирования.

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

6 инструментов для прототипирования сайтаПример вайрфрейма интернет-магазина в приложении Moqups

Более продвинутые программы позволяют делать прототипы, которые практически неотличимы от реально работающего сайта или приложения. И всё это без знания кода, умения рисовать и верстать.

Понятие о прототипировании распространено среди веб-дизайнеров. Для продакт-менеджеров и владельцев бизнеса прототип позволяет за короткое время показать, как будет выглядеть и работать проект, донести идею до команды и дальнейшей реализации.

Перед созданием прототипа продумайте информационную архитектуру сайта — блок-схему с основными разделами. Это легко сделать в программе XMind. Таким образом вы расставите приоритеты для разработки и сможете отказаться от лишнего.

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

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

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

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

Зачем нужно прототипирование

  • Сэкономить время: вы не обращаете внимание на мелкие недочеты в дизайне, пока не ясна и утверждена общая концепция. Прототип станет дополнением к техническому заданию дизайнеру. Это сэкономит ваши деньги и время на последующие правки.
  • Отслеживать развитие продукта.
  • Эффективно коммуницировать внутри команды: инженеры, бизнес-партнеры и маркетологи говорят на одном языке.
  • Протестировать дополнение на реальных пользователях. Если вы не уверены в важности новой функции или раздела.

Инструменты для прототипирования

Существует множество программ для прототипирования. Одни подходят для формирования структуры, расстановки акцентов. Другие позволяют создать модель, которая практически не будет отличаться от готового магазина.

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

Principle

Приложение для MacOS, совмещающее в себе возможности дизайнерских программ Sketch и After Effects.

В Principle вы можете загрузить готовые элементы интерфейса или создать их самостоятельно, добавить связь экранов и анимацию. Позволяет создавать подробные интерактивные прототипы, а затем выгрузить их в формате видео или .gif.

Посмотрите, как работает готовый прототип модуля “Чек-лист” от SeoPult, сделанный в Principle:

Прототип модуля «Чек-лист» в Principle

Balsamiq

Balsamiq позволяет создавать прототипы с нуля без дополнительных файлов. Встроенная библиотека средств пользовательского интерфейса включает приятные мелочи типа «аккордеон» или выпадающее меню.

6 инструментов для прототипирования сайтаОглавление книги в интерфейсе приложения для чтения — пример «аккордеон»-меню, созданный в Balsamiq (источник)

Отсутствие разнообразия в визуальном дизайне (иконки, цветовая палитра, другие украшательства) дает возможность сосредоточиться на расположении элементов и функциональности страницы, а не тратить время на мелочи, например, на подбор иконки.

Balsamiq сохраняет историю изменений проекта. Вы можете управлять разными версиями и отслеживать, как менялся прототип в процессе работы. Так же, Balsamiq поддерживает сторонние расширения, что позволяет добавить в макеты готовые элементы интерфейса.

Moqups

Платформа позволяет создать дизайн от схемы до продуманного макета.

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

6 инструментов для прототипирования сайтаПрототип мобильного приложения с сайта Moqups (источник)

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

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

InVision

Если есть макеты в формате Photoshop или Sketch, и вы хотите лучше понять, как будет работать будущий сервис, то в InVision можно связать экраны и добавить анимацию. Загрузить черновые макеты в разные проекты, разделить и группировать их, чтобы следить за процессом.

Если в вашем прототипе несколько страниц, в InVision можно сделать интерфейсы кликабельными. Так вы сможете продемонстрировать основную функциональность вашего проекта и, если это необходимо, внести изменения на ранней стадии.

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

Pixate

Бесплатное приложение для рабочего стола Pixate Studio создаёт прототипы для мобильных, которые будут выглядеть как реальный продукт. Затем можно связать его с системой IOS или Android и протестировать на экране телефона.

6 инструментов для прототипирования сайтаПрототип интернет-магазина в Pixate

Чтобы делиться работой с коллегами, загрузите макеты в облако.

Axure

Дорогой, долгий, но фундаментальный. Он остаётся стандартом профессионализма для дизайнеров из России.

6 инструментов для прототипирования сайтаПример интернет-магазина в Axure

С помощью платформы можно создавать кликабельные и адаптивные прототипы для ПК и мобильных, добавлять готовые средства из библиотеки — popup, выпадающие меню и другие формы.

Вызывает противоречивые мнения: одни говорят, что Axure сложная программа для быстрого прототипирования, другие разбираются в ней за 20 минут. Вы можете попробовать Axure. Для этого в инструменте есть пробная бесплатная версия на 30 дней.

6 инструментов для прототипирования сайта

Прототипирование позволяет за несколько часов спроектировать работающую модель будущего интернет-магазина, оценить его сильные стороны, расставить акценты, продумать сценарии использования.

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

Урок 4. Прототипирование

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

Содержание:

Прототип и прототипирование

Для начала дадим определение понятию «прототип».

Простыми словами, прототип – это макет решения, который можно собрать из подручных материалов.

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

Преимущества прототипирования:

  1. Повышается гибкость производства.
  2. Повышается конкурентоспособность и качество производства.
  3. Себестоимость продукции сокращается на 100-150%.

Недостатки прототипирования:

  1. Денежные затраты. Нередко приходится делать не один прототип, а несколько. Всё это требует денег на материалы и производство.
  2. Время. Чтобы сделать прототип, в любом случае придётся потратить определённое количество времени.

Прототипирование является первой стадией Product Evolution Canvas (на русский переводится как «канвас эволюции продукта»), и дальше речь пойдет о нем.

Product Evolution Canvas

Product Evolution Canvas (PEC) – это инструмент для компаний, создающих различные продукты, отлично подходящий для мозговых штурмов. Он состоит из 2 компонентов – это:

  1. Временные рамки.
  2. Три этапа эволюции продукта.

Временные рамки – это, как понятно из названия, время. А что такое эволюция продукта? Давайте рассмотрим подробнее.

3 этапа эволюции продукта

Эволюция продукта – это весь процесс от создания прототипа до готового товара. Он делится на 3 этапа:

  1. Моделирование минимально-жизнеспособного продукта (прототипа или по-другому MVP).
  2. Создание основного продукта (который перекрывает основные потребности потенциальных клиентов).
  3. Производство полнофункционального продукта (идеальное решение проблемы пользователя).

Образно говоря, минимально-жизнеспособный продукт – это скейтборд. Основной продукт – велосипед. Полнофункциональный продукт – автомобиль. Скейтборд даёт возможность передвигаться, но не позволяет делать это достаточно быстро. С помощью велосипеда можно ездить довольно быстро и на большие расстояния. А автомобиль перекрывает все потребности, т.к. проезжает расстояния в сотни километров в считанные часы.

Канвас эволюции продукта помогает ответить на вопросы коллег, клиентов и инвесторов о функционале продукта. Например:

  1. Что может ваш продукт?
  2. Как вы будете развивать свой продукт?
  3. Что нас ждёт в будущем?
  4. Что в итоге получится?

Кроме того, Product Evolution Canvas упрощает:

  1. Разработку стратегии улучшения продукта.
  2. Установку дедлайнов.
  3. Генерацию идей.
  4. Презентацию продукта.
  5. Мотивацию команды на работу.

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

Как работать с PEC

Работа с PEC предполагает прохождение трех этапов:

1

 

На первом этапе спрашивайте себя: «Что делает мой продукт функциональным?»

2

На втором этапе задавайте вопрос: «Как мне улучшить свой продукт, чтобы он соответствовал главным пользовательским сценариям?»

3

На третьем этапе уточняйте: «Какие элементы стоит добавить в продукт, чтобы он полностью раскрыл заложенный в нём потенциал?»

Канвас можно применять для разработки продуктов и услуг практически в каждой сфере деятельности человека. Нужно выполнить всего лишь 4 простых шага:

  1. Нарисовать канвас на листе формата А4 или магнитной доске. Заполнить его элементами продукта.
  2. Повесить в комнате, в которой работает ваша команда.
  3. Постоянно дополнять.
  4. Использовать в презентациях для пользователей и инвесторов.

А чтобы было понятнее, что все это значит, приведем небольшой практический пример. Представьте, что вы разрабатываете банковское приложение и заполняете канвас. На первом этапе ваш продукт будет обладать лишь самыми необходимыми функциями, без которых невозможно представить банковское приложение – это открытие личного счёта, перевод денег и оплата различных услуг.

На втором этапе вы добавляете счета для индивидуальных предпринимателей, все виды транзакций и возможность оформлять кредиты онлайн. И на третьем – копилки, списки желаний и интеграцию с чат-ботами. Конечно, система выглядит уж очень упрощенно, но суть этот пример передает хорошо.

Прототипировать можно:

  1. Физические продукты, такие как автомобиль, зубная паста, спортивное снаряжение и т.п.
  2. Сайты. Их прототипируют, чтобы быстро получить представление о том, как они примерно будут выглядеть в готовом состоянии.
  3. Программы и приложения.
  4. Интерфейсы.
  5. Опыт.

В зависимости от того, что мы прототипируем, технологии прототипирования будут различаться.

Моделирование физических объектов

Физические объекты моделируют:

  1. С помощью подручных средств – бумаги, картона, пластилина, скотча, ножниц.
  2. С помощью «Лего».
  3. С помощью 3D принтеров.
  4. С помощью программ для 3D моделирования.

Давайте подробнее разберём каждую технологию.

Моделирование подручными средствам

При моделировании подручными средствами нужно всего лишь следовать простому алгоритму:

  1. Определите, модель какого продукта вы будете создавать.
  2. Изучите аналоги, в данный момент существующие на рынке.
  3. Изобразите прототип на листе бумаги или создайте из материалов, которые найдёте. Вспомните, например, как вы делали модели вулканов из пластилина в школе.

К плюсам данного вида моделирования можно отнести:

  1. Короткий срок создания моделей.
  2. Не нужно тратить деньги на покупку дорогих материалов.
  3. Можно дорабатывать на ходу.

Среди минусов есть следующие:

  1. Нельзя сделать анимированные и интерактивные модели.
  2. Модели быстро изнашиваются.

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

Лего-моделирование

Моделипрование с помощью «Лего» выполняется не менее просто:

  1. Найдите как можно больше наборов «Лего».
  2. Соберите из деталей прототип будущего изделия.
  3. Не зацикливайтесь на одной идее. Разбирайте, собирайте заново, экспериментируйте.
  4. Пригласите собирать модели всех членов команды.

Для получения наилучшего результата советуем вам прочитать книгу Тима Брауна «Дизайн-мышление в бизнесе», где рассказывается о том, как компания IDEO создавала из конструктора прототипы устройств для введения в кровь инсулиновых инъекций. Каждый раз создавая прототип, представляйте, что вы рассказываете историю.

Моделирование с использованием 3D печати

Для создания 3D моделей используются следующие технологии:

  • FDM (Fused Deposition Modeling). Материал выдавливается слой за слоем на поверхность. Эта технология применяется в биомедицине, кулинарии и промышленном производстве.
  • Polyjet. Материал выкладывается маленькими кубиками.
  • LENS (Laser Engineered Net Shaping). Порошковый материал выдувается из отверстия и с помощью лазера наносится на поверхность.
  • LOM (Laminated Object Manufacturing). Принтер режет материал ножом и склеивает части в модель.
  • SL (Stereolithography). Внутри принтера находится резервуар с полимером. Когда лазер проходит по нему, полимер становится твёрдым. Таким образом получается прототип.
  • Laser Sintering (лазерное спекание). Эта технология очень похожа на предыдущую. Единственное отличие – вместо полимера в ней используется порошок. Лазерное спекание позволяет, например, делать коронки для зубов.
  • 3DP (Three Dimensional Printing). На порошок наносится клей, который склеивает его в гранулы. Получившийся материал напоминает гипс.

3D-печать – это достаточно сложная технология, поэтому для ее применения лучше всего привлекать квалифицированных специалистов.

Моделирование с использованием программ

То же самое моделирование, что и в случае с 3D, только здесь не надо «марать» руки, ведь весь процесс происходит на экране компьютера. Вот список 10 лучших бесплатных программ, которые помогут вам прототипировать, не выходя из зоны комфорта:

  • Wings 3D.
  • DAZ Studio.
  • Open Scad.
  • 3DReshaper.
  • 3D Crafter.
  • PTC Creo.
  • LeoCAD. Виртуальное Лего-моделирование.
  • Houdini Apprentice.
  • FreeCAD.
  • Sculptris.

Руководство пользователя для каждой из программ можно найти в свободном доступе в Интернете.

Прототипирование сайтов и интерфейсов программ и приложений

Прототипирование сайта, главным образом, означает проектирование его интерфейса. Оно помогает облегчить задачу программистам, дизайнерам и верстальщикам. Поэтому мы объединили эти два пункта в один.

При моделировании интерфейса нужно исходить из концепции UX дизайна (UX расшифровывается как User Experience, что переводится на русский как «пользовательский опыт») – всегда помнить о том, к чему привыкли пользователи.

Например, когда вы заходите на любой сайт, то, скорее всего, ожидаете, что справа или сбоку будет меню и название проекта. Чуть-чуть правее или левее центра – контент (статьи, фотографии, видео). А снизу – надпись «Все права защищены» и правовые документы.

Если же вы зайдёте и увидите совсем другую картину (к примеру, меню будет расположено где-то снизу, контентная часть будет слишком узкой и т.п.), вероятно, вы просто уйдёте на другой сайт – более привычный.

Однако не нужно потакать пользователям во всём, ведь сайт должен решать и ваши задачи. К примеру, человек задал в поиске такой вопрос: «С чего начать саморазвитие?» Увидел ссылку на наш сайт и перешёл на него. Задача человека – получить информацию. Наша задача – не только помочь ему, но и реализовать собственные цели, в том числе и финансовые.

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

Как создать прототип

Прототип можно создать в любой программе, где можно рисовать. Если вы новичок, используйте Photoshop, Paint, Adobe Illustrator или даже Google Docs. Профессионалам рекомендуем программу Axure. И вот что нужно сделать дальше (в упрощенной форме):

  1. Отрисовать основные элементы шапки – форму поиска, логотип, кнопку обратной связи, описание проекта, кнопку действия («заказать услугу», «купить курс», «совершить звонок»), а если сайт информационный, то либо кнопку «Блог», либо меню с рубриками.
  2. Нарисовать контентную часть и сайдбар (то, что находится сбоку). Как будет располагаться текст, кнопки социальных сетей, комментарии и т.д.
  3. Обрисовать подвал сайта – дополнительные ссылки, значок копирайта и прочее.

Стиль сайта должен прослеживаться на всех его страницах. Не должно быть так, чтобы на главной странице преобладал минимализм (чёрно-белый дизайн и полное отсутствие лишнего), а в статьях – «рог изобилия», когда кажется, что попал совсем в другую реальность. Элементы нужно делать симметричными по размерам и расположению.

Не заставляйте человека ощущать себя неуютно, т.е. если пользователи мобильных устройств привыкли, что при нажатии на значок «гамбургера» (три горизонтальных черты) открывается меню, не надо выдумывать что-то новое. Если люди привыкли, что курсор мыши меняется на указательный палец, когда на блок можно нажать, делайте на своём сайте (или в приложении) точно так же.

И еще несколько советов о том, чего нужно избегать при создании сайтов и приложений:

  • Мелкие шрифты (если человеку не удобно читать у вас, он быстро найдёт, у кого читать комфортнее).
  • Горизонтальные прокрутки (особенно это вызывает неудобство на смартфонах).
  • Отсутствие мобильной версии (международное агентство Social провело исследование и выяснило, что 5,26 миллиарда пользователей (именно пользователей, а не людей) заходят в Интернет с мобильных устройств).

Подробнее читайте в материале, подготовленном крупнейшим маркетинговым агентством России Texterra. Там очень хорошо и понятно изложено, что стоит внедрить на своём сайте/приложении, а что –  убрать. Однако не старайтесь всё время следовать нашим советам: экспериментируйте и пробуйте выяснить самостоятельно, что хотят видеть потенциальные клиенты на вашем сайте или в приложении.

Прототипирование опыта

Прототипирование опыта – это тип прототипирование, которое представляет собой воссоздание ситуаций для тестирования решений. Чтобы смоделировать опыт, нужно правильно подобрать место и создать обстоятельства, при которых человеку может понадобиться ваш продукт или услуга. С помощью прототипирования опыта можно разыгрывать целые ситуации, объёмные опыты и нахождение в пространствах, где трудно обойтись одним предметом.

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

1

 

Выберите ситуацию, в которой человеку пригодится ваш продукт для решения проблемы.

2

Напишите сценарий. Опишите подробно обстоятельства, действующие лица, место действия.

3

Попробуйте получить доступ к месту из выбранной ситуации. Если нет возможности, воссоздайте его в тех условиях, которые есть.

4

Разместите прототип решения в этом месте.

5

Распределите роли среди коллег и обыграйте сценарий.

6

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

7

Понаблюдайте за их поведением и прототипом решения.

8

Попросите их описать свои мысли и ощущения.

9

Запишите результаты и сделайте выводы.

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

Теперь у вас в арсенале появились новые средства дизайн-мышления – методы, позволяющие оценивать найденные идеи и решения, выявлять их плюсы и минусы. Следующим этапом станет выбор лучшего варианта, и о том, как он осуществляется, мы поговорим в пятом уроке. А сейчас предлагаем подвести итог и пройти небольшой тест на проверку знаний.

Резюме

Прототип – это макет вашего решения. Прототипирование – создание этого макета. Также прототипирование – важная часть Product Evolution Canvas.

Существует 3 этапа эволюции продукта:

  1. Минимально-жизнеспособный продукт (MVP).
  2. Основной продукт.
  3. Полнофункциональный продукт.

Прототип – это как раз и есть MVP.

Моделировать можно:

  1. Физические продукты.
  2. Сайты.
  3. Программы и приложения.
  4. Интерфейсы.
  5. Опыт.

Физические продукты можно моделировать с помощью подручных средств, «Лего», графических редакторов и 3D принтеров.

Интерфейсы программ, приложений и сайтов моделируются с помощью карандаша и бумаги или специальным программ: Adobe Photoshop, Paint, Adobe Ilustrator и т.п.

Прототипирование опыта проводится с помощью моделирования ситуаций.

Проверьте свои знания

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

В следующем уроке мы рассмотрим следующий этап дизайн-мышления – выбор лучшего решения.      

между брифом и техническим заданием / Habr

Большинство разработчиков сайтов, с которыми мне приходилось сотрудничать, имеют хорошо налаженный процесс производства и прорабатывают все этапы создания веб-ресурсов до мелочей – начиная с ТЗ и заканчивая юридической и финансовой стороной.

Однако почти никто не рисует наброски будущего сайта — прототипы страниц. Казалось бы, очевидно, что воспринимать иллюстрации проще, чем сухой технический текст, да и время на «перевод» ТЗ для участников проекта значительно сокращается.

Когда в работе задействовано больше двух человек, «переводчик» просто необходим. У заказчика свое видение, у менеджера проекта – свое, у программиста, дизайнера, верстальщика – тоже есть собственное понимание реализации этапов разработки. И термины, которые при этом используются – у каждого тоже свои, часто непонятные остальным.

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

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

Обычно такой «концепт» готовится, когда выяснены вопросы целевой аудитории, суть работы бизнеса заказчика в целом понята, а структура будущего сайта уже определена. То есть это этап, предшествующий разработке технического задания.

Для простых сайтов с десятком типовых страниц подобные картинки можно создать за 2-3 часа работы в Visio или Axure и сэкономить недели времени на последующих исправлениях ТЗ, дизайна и контента.

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

Например, главная страница может выглядеть таким образом (на самом деле, это уже готовый дизайн, но художником быть вовсе не обязательно):

Каждой цифре соответствует определенное пояснение:

  1. Подчеркиваем, что это монобрендовый магазин с ценами фабрики.
  2. Контакты выделены в отдельный блок, т.к. по уже имеющейся статистике в карте кликов из справочной информации им уделяют больше всего внимания.
    Показывая режим работы сокращаем число неотвеченных звонков.
    Корзину смещаем наверх, чтобы не мешать ссылку на контакты и телефон с данными о товарах.
  3. Поиском по статистике старого варианта сайта у нас пользуются активно. Также это удобно также и для менеджеров при поиске по артикулам.
  4. Основное меню – выпадающее, чтобы не перегружать блок навигации.
  5. Блок баннеров с новинками и акциями. Это главный акцент на странице. Предусмотреть сортировку.
  6. Онлайн-консультант – всплывающий по клику на баннер
  7. Важная информация для покупателя, которую можно получить на любой странице.
  8. SEO-текст (для фраз типа «интернет-магазин мебели и купить мебель онлайн»), раскрывающий преимущества магазина и мебели.
  9. Записываем в историю браузера предыдущее посещение сайта и показываем те товары, которые просматривал посетитель. У 99,77% они включены. Если он впервые на сайте, ничего не показываем.
  10. Блок футера: адрес, телефоны, дублирующее меню.

Когда приносишь подобные картинки с объяснениями, заказчики часто удивляются, как все оказывается, просто: не нужно вникать в технические термины или читать десятки страниц документации. Все наглядно и можно обсуждать сайт на простом языке, понятном всем.

Интерактивный прототип в Axure за 20 минут / Habr

Пока я писал о проектировщиках и прототипах, внезапно выяснилось, что многие читатели не представляют, о чём идёт речь. Поэтому сегодня я решил рассказать о том, что такое интерактивный прототип, сделанный в Axure (произносится как «Экшер», а я привык говорить «Акшура»). И не только рассказать, но и показать.

Если совсем грубо, то интерактивный прототип — это набор связанных друг с другом html-макетов. Только работали над этими макетами не дизайнер с верстальщиком, а проектировщик в специализированной программе, позволяющей сделать эту работу в разы быстрее. В чём будет различие в результате? Прототип, подготовленный проектировщиком, в отличие от макетов, подготовленных верстальщиком, не предназначен для разработки. Он призван очень быстро и наглядно продемонстрировать то, что исполнитель будет воплощать в жизнь на следующих этапах. Это всё равно, что трёхмерная модель готовящегося к строительству здания. На её создание уйдёт гораздо меньше времени, чем на постройку, и она позволит виртуально побродить по будущему проекту.

Выгоды от прототипов сложно переоценить.

  • Простота и скорость создания. Первую версию прототипа хороший проектировщик может продемонстрировать через несколько часов после формализации задачи;
  • Хорошо сделанный прототип специально предназначен для последующих правок. Взглянув на получившийся результат, и клиент, и исполнитель, с помощью быстрых итераций верно пойдут к желаемой цели;
  • Это позволяет ещё до написания функциональной спецификации или технического задания очень точно договориться о том, что должно получиться на выходе. А документы только закрепят эту договорённость;
  • Благодаря наглядности прототипа, вероятность правок на следующих этапах создания сайта сводится к нулю. А с учётом того, в какие суммы могут обойтись правки на этапе программирования, этап проектирования ежедневно экономит огромное количество средств людям во всём мире.

Специально для Хабра я записал процесс создания простого типового прототипа. Я его взял из головы, целью было продемонстрировать, с какой скоростью проделывается подобная работа. Из видео можно понять, что за 20 минут опытный проектировщик может сделать уже что-то, что можно обсудить и дать обратную связь. Плюс видно, что все сквозные и списковые элементы сделаны с помощью мастеров, что позволит, редактируя один мастер, вносить изменения в весь прототип. Не нравится название пункта меню в шапке? Исправляем одно слово, и это исправление применяется ко всем страницам. Хочется изменить внешний вид отдельной работы в списке портфолио — то же самое. Редактируем отдельный мастер, а затем выравниваем результат на странице со списком работ.

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

Как я уже говорил, сгенерированный прототип представляет собой набор html-файлов, которые можно выложить либо на специальном сервисе, предоставляемом самой Axure, либо на любом своём хостинге. Клиенту лишь нужно будет дать ссылку. Вот ссылка на прототип, который я сделал в ролике:

http://share.axure.com/OHB5ZQ

Не знаю, готов ли тот хостинг к Хабраэффекту, но готов рискнуть.

Попробую предвосхитить некоторые ваши вопросы.

  • Axure предназначена не только для проектирования сайтов, но и подходит для мобильных приложений, десктопных приложений и других интерфейсов;
  • Позволяет делать адаптивные прототипы;
  • Не ограничивает проектировщика в создании интерактива и динамики на страницах;
  • Может генерировать прототипы не только в виде html-файлов, но и в виде набора картинок;
  • Может придать прототипу вид скетча одним нажатием кнопки.

Ну вот и видео. Использовалась бета-версия Axure RP Pro 7. Музычка ещё обрабатывается, скоро заработает.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *