{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

От идеи до дизайна it-продукта

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

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

Статья будет полезна не только дизайнерам, но и всем кто связан со стартапами, и разработкой it-продуктов.

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

1. Погружение (аналитика)

Подойдя к причалу я увидел Оссена. Он стоял один и смотрел на закат. Я подошел поближе. Он не поворачиваясь ко мне, сказал одну фразу: «Построй мне корабль для перевозки золота». Какой корабль, — подумал я, — что, как, я что похож на строителя? Я хотел задать ему кучу вопросов, но след Оссена простыл. Я увидел лишь небольшой клочок бумаги под ногами, на котором было написано: «Построй корабль, и твоя жизнь изменится!». Я пошёл с причала, и размышлял, я же не умею строить корабли, хм, а если бы решил построить то наверное нужны были бы пушки, чтобы защититься от пиратов… Хм, а что еще нужно… Пойду узнаю у бывалых пиратов, вроде как они что-то знают об этом!

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

Что может входить в блок погружение:

Общение с клиентом

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

Серфинг в интернете

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

Изучение конкурентов

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

CustDev

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

Подытожим

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

2. Карта (user flow)

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

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

Экран — одна страница приложения или сайта.

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

Если вы идете делать прототип, минуя этот этап, то:

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

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

3. Прототипирование. Ux.

Старый пират не сопротивлялся Ром’у, и в итоге уснул. Чертежи у нас, надеюсь они нас не подведут, теперь можно приступать к строительству корабля. Так, с чего бы начать…

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

При проектировании важно спрашивать себя: «Почему я делаю это так? Почему я размещаю этот элемент, и нужен ли он здесь вовсе? Будет ли это понятно пользователю?».

Экраны также рекомендую связать друг с другом, чтобы получить «интерфейс который можно покликать». Мне иногда лень этим заниматься, но это важно. Удобно всей команде тестировать продукт, и если есть «дыры» в интерфейсе (что-то было пропущено), то на этом этапе можно все это доработать.

4. Дизайн. Ui

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

Этот этап не такой большой, как некоторые считают, по моей практике он занимает лишь 25-30% от всей работы, если прототипирование было выполнено качественно (средняя детализация), но это не уменьшает его важность. Некоторые думают что дизайн — это про иконки, шрифты, и графику, да, верно, но хочу заметить один банальный, но важный момент.

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

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

Хочется завершить этот блок мыслью о дизайн-системе. Так вроде ее называют. Если мы говорим именно про разработку it-продуктов — это важная ее часть, которая позволяет не запутаться в дизайне, и иметь возможность масштабирования вашего продукта. Гуглите, изучайте.

5. Поддержка и аудит

Вытирая руки от краски, выхожу на палубу корабля, и вижу как народ начинает стягиваться вокруг. Все смотрят, и с восхищением обсуждают. Ну что ж… Можно сдавать работу, но, сперва нужно попросить корабельных мастеров чтобы они все проверили, и дали добро на отплытие.

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

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

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

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

Что по итогам?

Я стоял воодушевлённый, с улыбкой до ушей, на палубе великолепного корабля, и не понимал только одного: где Оссем, и когда он придёт… Я подошёл к своим строителям, и спросил:

  • Вы случайно не знаете кто такой Оссем?
  • Они странно переглянулись, улыбнулись, посмотрели на меня, и один из них сказал мне: «Оссем — это вы!»

Мой описаный путь не идеален, мой путь — это мой опыт. Если вам есть что сказать, поспорить, велком в комментарии, буду рад или может быть не рад, ответить на ваши комментарии.

Что по портфолио, мои навыкам, и какое право имею?

Заглядывайте сюда, тут ответы: g-uix.ru

0
Комментарии
-3 комментариев
Раскрывать всегда