Запуск проекта глазами дизайнера

Многогранность абстрактного процесса запуска IT-проекта

Традиционно после смены профессии, либо только встав на путь UI / UX, набрав базовый пакет знаний, вы сталкиваетесь с одной и той же ситуацией — запуском IT-проекта.

На самом деле под этой фразой может скрываться целая плеяда различных “запусков” 🤣

  • Запуск стартапа.
  • Включение вас как дизайнера в проект, который вроде как уже запустили, но он не вышел в общественный доступ для пользователей и плещется себе в луже Beta тестирования.
  • Запуск проекта, о котором лишь известно, что локализована проблема пользователя, приблизительно придумано решение этой проблемы и составлено техническое задание (ТЗ). И на этом все.

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

Со стартапом обычно все является непонятным и условным. Такова уж природа первопроходца — влезать по самые помидоры в холодную реку неизвестности.

А вот последний случай заслуживает особого внимания ввиду того, что в подобной ситуации в 90% случаев оказывается начинающий дизайнер, а в 100% и фрилансер.

Процесс запуска

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

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

Приблизительная схема процесса запуска проекта

Описание шагов:

  1. Локализация проблемы пользователя; выявление «пользователя» среди толп людей; рождение идеи решения проблемы; учреждение юр.лица; поиск команды и прочие орг. процессы. И составление того самого ТЗ – коллективный труд, выраженный в трех строчках, и условное понимание проекта в головах парочки учредителей.
  2. Создание из ТЗ грубого прототипа продукта. Да-да, именно на этом этапе новый дизайнер или фрилансер хватается за голову со словами «А что делать надо?». Наша вотчина!
  3. Отсмотр полученного прототипа (иногда даже прототип похож на дизайн будущего аппа) в кругу ответственных людей. Из практики следует, что, пока прототипа нет, проект будет буксовать на месте, потому что лучше вас никто не знает, как проект должен выглядеть, и, как ни странно, работать =))
  4. Спустя парочку итераций, поправив 50–70% дизайна и UX, апп (в проекте есть не только апп, но и куча всего другого) приобретает человеческий вид и, с высокой долей вероятности, в таком виде появится в версии 1.0.
  5. Процесс добавления функционала, новых фич, переделка существующих фич.
  6. Повторение предыдущего этапа. И так по кругу пока проект не продадут или он не загнется.

Фундамент проекта = этап №2

Если вспомнить известное высказывание про 1% таланта и 99% старания, то несложно догадаться, что фундаментом успеха всего проекта является этап №2.

Потому что идей миллион, а вот хороших проектов в разы меньше. А без хорошего прототипа начинать этап №3 смысла попросту не имеет. Как и этапы №4 и №5.

Самое сложное в этапе №2 то что, поскольку никто не знает что делать, то вся ответственность автоматически переезжает на вас, нравится вам это или нет.

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

  1. Проанализировать ТЗ — даже из трех строчек можно вытянуть всю необходимую информацию. Главное — понять куда смотреть.
  2. Составить архитектуру проекта — де факто это схема взаимодействия всех компонентов проекта. Например: Апп + сервер + носимый гаджет + веб сайт + CMS для суппорта. Она пригодится вам на следующем этапе.
  3. Модель данных — основа для дизайна и проектирования. Составив модельку, вы будуте рисовать прототип со скоростью света потому что все данные для каждого экрана будут аккуратно выписаны на бумажке, с которой вам надо только сверяться.

Профит от этапа №2

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

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


Хеппи энд

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

Да, получается, что роль дизайнера в проекте настолько большая, что ее предпочитают не замечать =))

Всем бобра! ❤️

Если вам понравилось, — скажите «Спасибо», кликнув на кнопку 👏🏻. Это поможет другим людям быстрее найти статью.


Like what you read? Give Nikita Morozov a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.