Применение процесса проектирования к веб-проекту.
Бэкграунд
Я поступил в художественную школу и получил образование в области графики и веб-дизайна. На протяжении всего обучения я встречал огромное количество действительно талантливых людей, среди которых были как учителя, так и ученики. Часто — в большей мере учителя, чем студенты — рассказывали том, как они организовывают свой процесс проектирования.
Не буду пересказывать весь курс проектирования в одной статье, потому что для этого есть книги. Тем не менее, я хотел бы поделиться методами, которые использовал для своих проектов, как личных, так и выполненных для клиентов.
О чем эта статья
Я изучил методы, читая книги, посещая занятия и беседуя с людьми. Однако, вполне возможно, уже позабыл многие из них. Я узнал, что мой подход к планированию процесса проектирования похож на методологию Agile (гибкая методология разработки). Это не удивительно, поскольку один из преподавателей приучал нас планировать процесс в похожем стиле. Вот только я забыл его имя...
В этой статье буду обсуждать процесс создания проекта, от начала и до конца. Я буду использовать множество примеров, в первую очередь статья предназначена для создания веб-сайтов или веб-приложений. Хотя, думаю, что это может быть применено и к любому творческому процессу тоже. Возьмите для себя полезные моменты и применяйте их в своей работе.
Итак, начнем.
План создания проекта
- Получить обзор проекта от клиента.
- Сделать ставку на проект.
- Создать информационную архитектуру.
- Подготовить эскизные макеты.
- Сделать рендеринг эскизов.
- Создать руководство по дизайну.
- Сделать красивые макеты.
- Подготовить прототип.
- Создать проект.
- Испытать проект.
- Запустить проект.
- Профит.
С чего начать?
Самая интересная часть любого проекта — это начало, когда «все возможно». Чаще всего, первый разговор с клиентом у меня достаточно абстрактный и не технический. Они хотят X, Y и, возможно, Z.
Важность исследования
Исследование является неотъемлемой частью любого этапа проектирования. Прежде всего, попробуйте узнать все, что вам удастся узнать о предмете, над которым будете работать. Например, когда я работал над созданием сайта по изготовлению карт, смотрел на их конкурентов, чтобы понять, что клиенты хотят получить в итоге.
Ставка на проект
Время откровений. Когда я только начинал, я недооценивал себя как специалиста. Скорее всего, все остальные тоже себя недооценивают вначале. Я думаю, явление нормальное, но не стоит зацикливаться на этом.
Что выбрать?
Тема ставок на проекты очень трудна для разработчиков-новичков, потому что очень сложно понять, сколько времени займет тот или иной проект. В основном есть два варианта: плата за час или плата за определенную часть функционала. Я работал и так и так, оба варианта мне не очень нравятся.
Почасовая оплата — это замечательно, потому что вы знаете, что вам платят действительно за то, сколько вы стоите. Но если вы не знаете, сколько времени займет что-то, это может расстроить клиента, если вы потратите на него 50 часов, а скажете, что это займет 10.
Если вы платите за функцию, та же ситуация может обернуться против вас — вы тратите 50 часов на что-то, но платят вам как за 10. «Какую часовую ставку указывать?», — честно говоря, это сложный вопрос. Никто мне не смог на него дать обоснованный ответ. Скажу только, моя внештатная ставка составляет $ 35/час как фронтенд-разработчика и $50/час как бекэнд разработчика. Не знаю, много это или мало, но это работает для меня.
Они приняли мою ставку, что теперь?
Отлично! Я знаю, чего они хотят, но что теперь? Проводить исследования, чем больше, тем лучше.
Больше исследований
Продолжайте исследования на основе того, что вы уже знаете о проекте. Если вы создаете сайт, как именно вы собираетесь его создавать? Какие фреймворки вы собираетесь использовать? Где будет размещен сайт и так далее.
Настоятельно вам рекомендую создать личную документацию по проекту. Обычно я называю это информационной архитектурой. В этом документе вы записываете все о проекте: фреймворки, язык, варианты хостинга, затраты, функции, материалы безопасности и т. д. Такой подход поможет быстрее вырасти вам как специалисту. Кроме того, поделитесь этим документом с клиентом! Не очень-то хорошо проектировать обособленно от заказчика.
Вы не можете проектировать в вакууме.
Подготовка эскизов
Хорошо, у нас есть план! Что теперь? Теперь мы можем, наконец, сделать первые наброски дизайна. Я обычно делаю дизайн в три этапа: карандашные эскизы, рендеринг, готовые макеты.
Карандашные зарисовки
Возьмите блокнот и сделайте первые наброски. Им не нужно хорошо выглядеть, это не главное. Они должны выглядеть паршиво, потому что на данном этапе важна форма, а не содержание. Вы поймете меня. Я вообще не показываю их клиенту.
Мило, не так ли?
Рендеринг
Существует множество инструментов для рендеринга эскизов. Я использовал Sketch, Figma и Adobe XD. У каждого из них есть свои преимущества, поэтому не буду говорить, какой из них выбрать. Просто выберите тот, который вам нравится. Нет смысла искать идеальный инструмент. Единственное, о чем нужно помнить, если вы планируете создавать прототип (или вам необходимо сделать прототип) — Figma и XD намного проще.
Идея здесь состоит в абстрагировании вашего дизайна таким образом, чтобы он легко менялся без тонны работы. Как видите, в приведенном ниже примере я использую «рыбу» для заполнения полей. Как правило, первая версия дизайна создается черно-белой. Довольно простой, только серой.
Попросите клиента утвердить каркас и перейдите к следующему шагу.
Руководство по дизайну
Было бы неплохо разработать руководство по дизайну, прежде чем переходить к макетам. Во-первых, вам нужно, чтобы ваш клиент утвердил цвета, шрифты и общие стили веб-сайта, а после этого уже можно переходить к макетам. Не то чтобы это большая работа, но изменять шрифты во всех ваших макетах — не очень приятно, особенно после того, как вы сделали дизайн десяти страниц. Style Tiles — довольно хороший ресурс, чтобы начать.
Это не тот продукт, который я дал клиенту. Я сделал это довольно красиво в Google Slides. Но попробовать — можно.
Макеты
Круто! Клиенту нравятся цвета и одобрены сделанные эскизы. Давайте сделаем несколько красивых макетов. Надеюсь, если вы хорошо поработали с рендерингом эскизов, все, что вам нужно сделать, это заменить «рыбу» реальными данными и добавить цветов.
Начните использовать реальные данные как можно скорее!
Иногда, бывает сложно взять контент у клиента, потому что он часто находится в процессе утверждения на протяжении длительного времени. Поместите в свои макеты реальные данные как только появится возможность. Это решит множество проблем, например, слишком длинные имена или длинный контент.
Прототип
Я использовал три разные программы для создания прототипа с Marvel, Adobe XD и Figma. Все они находятся на одном уровне, если не учитывать стоимость. Figma бесплатна.
Не думаю, что инструмент имеет значение, когда дело доходит до разработки прототипа. Тем не менее, есть моменты, которые следует иметь в виду при создании прототипа.
- Наличие целей, которые достигаются последовательными действиями. Не просто передайте прототип и скажите: «поиграйте с ним». Вы хотите проверить конкретные вещи. Например, попросите пользователя войти в систему, выйти из системы или создать новую задачу.
- Записывайте результаты. Adobe XD позволяет записывать сессии, в которых сохраняется последовательность действий пользователя.
- Помните, что разработка прототипа предназначена для тестирования удобства использования пользовательского интерфейса. Прототип не будет предоставлять средства тестирования функциональности. Не усложняйте. Для тестирования прототипа вы можете создать руководство, в котором будут даны четкие инструкции по его применению. Документ не должен быть слишком объемным. Просто убедитесь, что прототипом будет легко пользоваться.
Поправьте макеты
Мы кое-чему научились, теперь корректируем макеты.
Если требуется — создайте новый прототип
Не думаю, что необходимо создавать прототип второй раз, но если в пользовательском интерфейсе произошли серьезные изменения, создайте макет снова.
Создайте Проект
Ужас! Прошло 1000 часов, а мы даже ничего толком не создали. Надеюсь, поскольку у вас есть завершенные, проверенные макеты в руках, это так же просто, как перевод этих идей в код. Тем не менее я бы не стал создавать все сразу. Создайте столько функций, сколько вам нужно, чтобы протестировать их с реальными пользователями. Как минимум, создайте систему аутентификации и, по крайней мере, одну основную функцию проекта, прежде чем передавать ее для тестирования.
Протестируйте Проект
Эта часть процесса циклична. Вы будете создавать — тестировать, создавать — тестировать, и так пока не дойдете до версии 1.0. Здесь действуют те же правила, что и для прототипов. Не передавайте приложение без четких инструкций. Создайте руководство, которое позволит самостоятельно разобраться, как работать с приложением.
Ожидайте как полезный, так и бесполезный фидбэк. Когда дело доходит до рекомендаций, каждому кажется что он — дизайнер.
Однажды мне сказали, что заголовки должны быть выделены жирным шрифтом, а не написаны обычным. Не воспринимайте комментарии всерьез, но делайте то, что нужно. Помните: вы создаете для пользователя, не для себя.
Разверните приложение
Небольшой совет: не разворачивайте проект, если вы планируете заниматься другими приложениями помимо этого проекта. Будут баги, будут проблемы.
Независимо от того, насколько совершенен ваш код, вам всегда нужно будет его чистить.
Восхищайтесь своими достижениями
Думаю, что важно сделать шаг назад после завершения проекта и посмотреть, что вы только что сделали. Много часов ушло на то, что теперь доступно любому, у кого есть интернет соединение. Отложите на минуту все дела и в течение 60 секунд сосредоточенно получайте удовольствие от созданного вами проекта!
Напоследок
Не перестаю чувствовать себя новичком в этой игре. Не претендую на роль эксперта. Просто подумал, было бы неплохо собрать мои методы от всех экспертов, которых я слушал, в надежде, что это поможет кому-то другому. Этот процесс является незавершенным...