11 вещей, которые я усвоил за первый год работы дизайнером UX/UI в компании по разработке программного обеспечения

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

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

Вот некоторые проблемы, с которыми я столкнулся в течение первого года работы в UX/UI-дизайне:

1. MVP и KPI

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

2. Бизнес-требования, сбор требований, согласование с заказчиком, оформление подтверждений

На мой взгляд, это самая важная часть работы продуктового дизайнера. В компании я частично или полностью отвечал за сбор требований и их согласование с клиентом — иногда в партнерстве с бизнес-аналитиком, который мягко вникал в структуру клиента и собирал бизнес-требования. На этом этапе важно узнать об отрасли и процессах клиента, объяснить клиенту, почему мы это делаем (если он не знает), и, собственно, последовательно собирать эту информацию о разрабатываемом продукте. Я сделал это, записав пользовательские истории, критерии приемлемости и потенциальные риски. Для клиента визуальная сторона заказанного у нас продукта уже на этом этапе важна, поэтому наиболее привлекательной формой сбора таких требований является изготовление макетов mid-fi, т.е. макеты с частично предложенным контентом. Важно помнить, что это одно из многих предложений, которые могут быть представлены, поэтому привязываться к такому варианту проекта не стоит. На этом этапе также необходимо помнить о ясности потока информации — установлении того, как требования собираются и подтверждаются клиентом. Не закрыв этот этап, вы не сможете двигаться дальше с разработкой из-за потенциальных рисков — изменение принятых решений или добавление новых требований, что влияет на график проекта. Бывает и так, что мы создаем продукт, собираем требования, может быть, мы уже на стадии приемки документации или даже разработки, и вдруг бизнес (т.е. пользователи) заявляет, что не понимает процесс.

3. Оценка времени — недооценка или переоценка

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

4. Штурвал, парус и корабль — уверенность в своих силах

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

5. Исследование на этапе UX, а точнее его отсутствие

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

6. Создание документации

Это действительно часть работы, которую должен проверить клиент. Для создания UX-документации я использовал подробную статью Autentika о подготовке документации (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/на польском).

Это было очень полезно для меня при его создании, но этого было недостаточно на 100%. Диаграммы процессов в продукте, который я создавал в то время, были ОЧЕНЬ сложными, поэтому я не просто так обратился к аналитикам и с их помощью вместо этого создал спецификацию варианта использования и более подробные требования к процессу с критериями приемки. Конечно, сейчас я бы сделал такую ​​документацию немного по-другому, но на тот момент меня это вполне устраивало.

7. Методологии? Они существуют? (Нет)

Большинство производителей программного обеспечения стараются работать итеративно, с индивидуальным подходом к клиенту. Планировать книжные процессы в таких ситуациях сложно, тем более, что сквозное исследование проводится редко, потому что «нет времени» или работаешь единственным дизайнером. В конечном счете методология проектирования основана на Agile, но фреймворки достаточно похожи друг на друга и скорее их можно разделить на этапы Discover, Define, Design, Develop и Deliver/Deploy (такой расширенный 5D со этапом от Double Diamond) .

8. Понимание клиента

Это ядро ​​сотрудничества с заказчиком на уровне дизайна приложения. Часто клиенты (особенно из не IT-отраслей) не знают, что такое UX, для чего он нужен, какие проблемы он может устранить на самых первых этапах проекта. Хорошим примером из моего опыта может быть то, что я представлял макеты lo-fi для выполнения бизнес-требований. На встрече также присутствовала маркетинговая команда клиента, которая была очень неуверенна… в дизайне лоу-файных макетов. Так как они не все были на одной странице, я снова говорил о том, что макеты были только для возможности рассказать о функциональности и о том, как должен работать продукт. К сожалению, это не помешало маркетологам прокомментировать шрифты, использованные в макетах, которые на тот момент не имели отношения к дизайну приложения . В конце концов, тема разрешилась довольно быстро и была понята, но сам факт того, что не сразу, говорит о том, что тема UX совершенно неизвестна в компаниях. В самом начале этапа проектирования стоит сделать короткую презентацию для клиента с обсуждением того, как мы работаем, что мы будем представлять и в какой степени нам нужен вклад от клиента. И, конечно же, почему оно того стоит ему.

9. Работа с разработчиками

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

10. API, JSON, LDAP, оркестраторы и другие странные слова

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

11. Работа в спринтах, ежедневные проекты, планирование спринтов и ретро (спецификация)

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

Как видите, я многое узнал, когда пришел в IT. Надеюсь, вы найдете их интересными, и, возможно, этот список будет полезен для тех, кто думает о своей карьере в области UX/UI, или даже для людей, работающих в этой отрасли!