Привет! Меня зовут Сергей Федоричев, я младший проектировщик интерфейсов в Selectel. Когда я был студентом, у меня, как и у многих, было довольно романтизированное представление о работе UX-дизайнера в IT. Казалось, что главное — уметь проектировать интерфейсы, знать паттерны и аккуратно работать с макетами.
Практика быстро расставила все по местам. Реальные пользователи вели себя совсем не так, как в учебных кейсах, задачи оказывались глубже, чем просто «сделать красиво», а любое решение требовало учитывать ограничения продукта, бизнеса и инфраструктуры. Внезапно стало понятно, что настоящий мир IT гораздо сложнее, но при этом намного интереснее, чем кажется со стороны.
В этой статье я расскажу о своем пути от студенческой практики до стажировки в продуктовой команде, о первых успехах и неудачах, о работе с командой и пользователями — и о тех инсайтах, которые, надеюсь, помогут другим новичкам, особенно UX-дизайнерам, чуть увереннее чувствовать себя на старте.
Знакомство с S3 и первые шаги в Selectel
Я начал свой путь в Selectel в команде S3. На первый взгляд интерфейс такого продукта кажется простым: загрузить файл, настроить доступ, получить ссылку. Но на практике UX в S3 — это всегда работа на стыке технических ограничений, API-логики, безопасности и десятков сценариев, которые используют разные категории клиентов: от разработчиков до крупных компаний с инфраструктурой в облаке.
У меня уже был опыт работы веб-дизайнером в проектной деятельности. Но там при сборке интерфейса или сайта редко находишь возможность задаться вопросом «А как этим будут пользоваться?». В первую очередь заказчики обращали внимание именно на визуал, а не на проработку комфортного сценария использования. Мне же было интересно посмотреть на проектирование с продуктовой точки зрения, поэтому опыт работы в команде продукта показался полезным для дальнейшего развития.
Итак, в команду S3 я пришел практикантом UX-проектировщиком. В мои задачи входили отрисовка макетов в Figma и пользовательские исследования. Проще говоря, нужно было направить силы на то, чтобы пользователь мог с комфортом работать в панели управления.
До практики мои представления об облачных хранилищах были, мягко говоря, не полны: открыл страницу, перетащил туда файлы, создал папку при необходимости. А тут какие-то бакеты, API, сервисные пользователи и вот это все. В итоге первые дни практики были посвящены изучению продукта. Что я делал:
-
подключал утилиты и проверял, как устроено взаимодействие с бакетами;
-
проходил через основные пользовательские сценарии — создание бакетов, загрузка объектов, настройка доступа;
-
разбирался в терминологии, принципах хранения и устройстве панели управления.
Иллюзия, что можно прочитать документацию и все понять, растворилась буквально за пару часов. S3 — это не кнопки и формочки, а целая экосистема. И если хочешь проектировать интерфейсы, нужно разбираться в реальных действиях пользователя, а не только в макетах. Первые шаги давались непросто: огромное количество документации и спецификаций по работе S3 могут быть понятны далеко не с первого раза. Именно поэтому для начала можно устроить себе сеанс полного погружения в продукт вместо чтения большого количества строк текста.
Совет тем, кто впервые заходит в новый продукт: начните с пользовательского опыта. Не с макетов, не со схем. Просто попробуйте пройти путь так, как его проходит пользователь. Это удивительно хорошо помогает сложить картину.
Спойлер: первые задачи привели меня к важным инсайтам, которые актуальны для любого новичка. Я опишу процесс решения, но не буду концентрироваться на технических нюансах работы с S3. Предлагаю сохранить фокус на процессе обучения и выводах, которые удалось извлечь.
Первая задача: паттерн Show More
Казалось бы, что может быть проще использования иконки шеврона для скрытия информации? Оказывается, за ней кроется множество подводных камней.
Первой моей задачей стала разработка паттерна Show More для панели управления. Это иконка, по клику на которую можно показать или скрыть информацию. Паттерн не связан напрямую с S3 — скорее со всей дизайн-системой. Именно эта особенность позволила мне впервые понять, как работают интерфейсы в мультипродуктовой компании, а также пообщаться со своими коллегами-проектировщиками и получить дополнительные инсайты по их продуктам. Вот с чего я начал.
Первый шаг: аудит текущих реализаций (discovery)
Пробежался по всем продуктовым панелям компании и собрал примеры Show More в одном месте (скриншоты, ссылки на компоненты в репозитории/Storybook). Зафиксировал варианты поведения: показ части списка, состояние при пустом результате, поведение при ошибках, горячие клавиши, анимация.
Далее постарался сгруппировать получившиеся варианты по целям, для которых используется эта иконка.
Ориентируясь на получившиеся группы, проанализировал, как в данных ситуациях поступают продукты-конкуренты.
Второй шаг: сбор требований и фидбэка
Провел промежуточное ревью итогов с дизайнерами из соседних команд: выяснил, какие сценарии важны в их продуктах, и обсудил с ними, стоит ли там использовать Show More.
Третий шаг: формирование целевых сценариев использования
В ходе обсуждения разделили сценарии использования паттерна на кейсы: скрытие сущностей без иерархии (например, IP-адреса), скрытие сущностей с иерархией (например, IAM-роли) и скрытие описания конфигурации.
Четвертый шаг: концепты
Основной идеей к реализации стал полный отказ от паттерна. Проще говоря, необходимо было сделать Show More антипаттерном, который не рекомендуется использовать в других продуктах.
Почему так? Мы выяснили: необязательно скрывать информацию от пользователей и тем самым заставлять их совершать дополнительные действия. Куда прозрачнее будет либо показать все сразу, либо вовсе убрать на другую страницу информацию, которой может быть не место здесь.
Для этого по каждому из представленных кейсов необходимо было спроектировать вариант, в рамках которого информация не скрывается. На этом этапе необходимо чуть глубже погрузиться в каждый продукт и представить решение, которое не сделает пользователю хуже. К счастью, некоторые дизайнеры уже начали самостоятельно перерабатывать свой интерфейс в рамках отказа от этого паттерна.
Пятый шаг: дизайн-ревью
На этом этапе я также проводил презентацию для дизайнеров, где рассказывал, почему пришел к выводу, что от использования паттерна необходимо отказываться.
Шестой шаг: релиз
Финальным этапом разработки стало оформление паттерна в соответствующий вид спецификации и его релиз в банке решений команды дизайнеров. На данном этапе не бойтесь просить помощи у команды дизайн-системы, они помогут вам привести спецификацию к соответствующему виду и выпустить ее для дальнейшего использования другими дизайнерами.
На этапе проектирования столкнулись со сценарием, где хотелось все-таки скрывать дополнительную информацию, а именно роли в IAM. В данном случае пользователю обычно важно показать одну главенствующую роль, а остальные скрыть, но не убирать из поля зрения. Поэтому только для этого сценария оставили решение как есть.
Именно эта задача дала мне первое важное понимание: дизайн-система — это не про пиксели. Это про коммуникацию и синхронизацию. Про то, чтобы разные продукты работали согласованно и выглядели единообразно.
Глобально работа над паттерном разделилась на несколько этапов.
-
Собрать максимально возможное количество сценариев использования.
-
Сгруппировать варианты по целям.
3. Объединить эти группы единым решением, либо предложить разные решения для каждой группы.
После этого переход к задачам S3 пошел намного легче — я уже понимал, как встроить новое решение в систему.
Бесплатное S3-хранилище на 30 дней
Для всех, кто ранее не использовал услугу в Selectel.
Погружение в продуктовые задачи: кейс с SSL/TLS в S3
Когда я перешел к полноценной работе с S3, у меня появилась задача, которая стала для меня поворотной — улучшить пользовательский опыт при добавлении SSL-сертификата.
Пользователи S3 могут подключать SSL/TLS-сертификаты к бакету, чтобы обеспечить защищенный доступ к данным. Звучит просто, но за этим стоит довольно длинный путь пользователя с несколькими развилками и ограничениями.
Что нужно было сделать:
-
проработать user flow подключения сертификатов,
-
найти проблемные точки в текущем сценарии,
-
предложить улучшения,
-
спроектировать макеты интеграции подключения сертификатов с разделом создания сертификатов в панели управления Selectel.
Проблемные точки в данном сценарии стали очевидны после того, как я ознакомился с тикетами от клиентов:
-
В менеджере секретов можно создать Let's Encrypt-сертификат, но выгрузить его получится только файлами. При этом в S3 сертификаты добавляются через текстовые поля.
-
Пользователю нужно самостоятельно обновлять сертификаты через UI/API. Если он пропустит обновление, ссылки на объекты перестанут работать.
В первую очередь необходимо было понять, какой пользовательский путь проходит клиент для достижения своей цели. Первым этапом я для себя выделил более подробное изучение работы TLS/SSL-сертификатов. Для контекста опишу принцип работы.
Чтобы обращаться к объектам в бакете по HTTPS через собственный домен, необходимо подключить TLS/SSL-сертификат. Управлять сертификатами можно как в панели управления, так и через Object Storage API. Сертификат можно выпустить у любого доверенного провайдера.
Если домен пользователя обслуживается DNS-хостингом Selectel, то сертификат Let’s Encrypt можно получить в пару кликов. Однако стоит учитывать, что после каждого перевыпуска такой сертификат нужно загружать в систему вручную. Сертификаты привязываются к стране размещения бакета, то есть сертификат будет действовать только для бакетов в регионе выбранной страны.
Для одного домена может использоваться только один активный сертификат. Если пользователь загрузил несколько сертификатов, активным становится последний добавленный. В случае удаления или истечения срока действия текущего сертификата система автоматически активирует предыдущий, но только если он все еще действителен.
Одна из основных точек, где возникает проблема между выпуском и подключением сертификата к S3 — нет быстрого перехода из одной точки в другую. Если пользователь пришел на страницу подключения TLS/SSL-сертификата в продукте S3, он не узнает, что такой сертификат можно быстро и удобно оформить через ту же панель управления, где он сейчас находится. Кроме того, все данные по сертификату необходимо вводить вручную. Хотелось добавить возможность отображения оформленных в панели сертификатов прямо в форму подключения. Я решил оттолкнуться от этих точек и начал создавать user flow.
Как понять, что нужно изменить в интерфейсе
Для комфортной работы рекомендую сначала оформить user flow текущего решения, отметив для себя точки роста, а далее уже проектировать свой идеальный пользовательский путь. Чтобы найти эти точки роста, следует провести небольшой предварительный ресерч того, на каких этапах клиенты сталкиваются с проблемами. Как я уже говорил, сделать это можно с помощью анализа тикетов (обращений клиентов) или, если есть такая возможность, провести несколько интервью.
Важно отметить, что после проектирования идеального user flow не стоит сразу приступать к проектированию макетов. Как бы того ни хотелось, UX-проектировщик должен сперва представить результаты проделанной работы разработчикам. В рамках этой презентации вы сможете обсудить с ними реализуемость ваших задумок и все возможные риски. Необходимо найти тонкую грань между комфортом пользователя и реализуемостью в разработке — пожалуй, для меня это стало одним из самых важных открытий и сложностей при прохождении практики.
Прежде чем приступить к проработке макетов, покажите ваше решение разработчикам и обсудите с ними, насколько оно реализуемо. Есть вероятность, что после этой встречи первоначальную идею придется скорректировать.
Обсудив все нюансы разработки, мы пришли к общим выводам о том, как команда видит итоговую фичу в реализации. После этого уже можно начинать проектировать драфты макетов. На каждом этапе важно консультироваться с командой и презентовать результаты своей деятельности — это повышает прозрачность и дает команде понимание, как фича должна работать и как ее можно перенести из макетов в реальность. В моем случае, мы пришли к выводу о том, что необходимо интегрироваться с менеджером сертификатов и дать возможность видеть уже созданные сертификаты, а также добавить их в S3.
Что получилось в результате
-
Я построил карту текущего user flow, выявил места, где пользователь терял контекст.
-
Предложил оптимизацию: убрать лишние шаги, сделать процесс более линейным, улучшить подсказки. В данном случае — скорректировать отображение статусов и добавить возможность интеграции с менеджером секретов.
-
Подумал, как объединить часть сценариев S3 и раздела управления и создания сертификатов, чтобы пользователю не приходилось прыгать между разделами. Спроектировал драфты макетов.
По факту это была моя первая настоящая продуктовая задача, где нужно было думать не только о UI, но и о логике, взаимодействии продуктов и бизнес-сценариях.
Выводы, которые я сделал тогда
-
Стройте user flow не только из шагов, но и из API-операций. Это позволяет понять, где можно оптимизировать сценарий, а также, какие поля и значения отрисовывает фронт.
-
Предусматривайте все состояния. В моем случае операции могли быть в одном из четырех статусов: сертификат еще проверяется, сертификат устарел, домен не совпадает, сертификат нельзя прикрепить.
-
Добавляйте в макеты места для ошибок. Сценарии, которые выдают ошибку — неотъемлемая часть UX для любых продуктов.
-
Смотрите шире одной фичи. Часто улучшения находятся на стыке разделов, а не в одной кнопке или форме.
От практиканта к стажеру: первое интервью, которое не получилось
К концу практики я был уже намного глубже погружен в продукт, стал понимать, каким образом работают определенные фичи. На этом фоне предложение перейти на стажировку стало шагом логичным, но все равно неожиданным и очень вдохновляющим. На стажировке стало больше задач и они стали серьезнее, появилась ответственность за сроки и качество, я стал частью продуктовых обсуждений.
Моим первым полноценным исследованием стало изучение пользовательского пути при подключении утилит к S3. Одной из основных задач этого исследования было проведение интервью с клиентами.
Пожалуй, именно поиск респондентов стал одним из самых сложных этапов. Мне пришлось писать многим клиентам и столкнуться со стеной отказов. Принять это оказалось не очень легко. Особенно непросто было осознавать, что тратишь свое рабочее время на работу без результата. Я искал подходящих клиентов — новых пользователей, которые заходили на страницу создания бакета S3. Обычно именно они сталкиваются с проблемами в подключении утилит.
После долгих попыток и примерно 250 опрошенных человек мне удалось найти только двоих потенциальных собеседников, причем не самых репрезентативных — они не подключали сторонние утилиты, а пользовались публичными ссылками для публикации контента на сайте. Мало того, в обоих случаях я еще и забыл включить запись разговора. На рекрутинг и два интервью параллельно с другими мелкими задачами у меня ушел практически месяц работы. Из-за этого пришлось двигать более интересные и важные для продукта вещи.
В итоге исследование пришлось прекратить, чтобы не тратить на него еще больше ценного времени. Оставив его позади, я не зафиксировал никакой результат своей работы. В подобном случае у команды может сложиться неверное впечатление, словно месяц ты занимался чем-то странным и непонятным, результатов не получил и пошел дальше. Это неправильных подход.
Даже если твое исследование оказалось неуспешным, обязательно нужно зафиксировать итог. Никто не осудит за то, что ты не пришел к ожидаемым результатам, ведь твоя часть работы была выполнена. В данном случае успех зависел не только от моей работы, но и от отклика ЦА, выбранной для исследования. Если отклик получить не удалось, это тоже важный инсайт, который можно использовать, чтобы в дальнейшем не встать на те же грабли.
На основе полученного опыта хочется дать другим новичкам некоторые рекомендации.
Фиксируйте результаты даже неудачного исследования
Даже если вы не нашли респондентов или получили нерелевантные ответы — это тоже результат. Команде важно понимать, что вы делали, какие каналы рекрутинга использовали, почему не удалось собрать выборку, какие риски вы увидели, что можно улучшить в будущем.
Если этого не зафиксировать, создается ложное ощущение, словно вы потратили месяц ни на что.
Факт отсутствия ответа от ЦА — это данные, а не провал.
Закладывайте пометки о рисках и зависимостях в план исследования
Рекрутинг клиентов — это неконтролируемая переменная. Она зависит от сложности продукта, доступности клиентов, их мотивации, чувствительности темы, частоты использования фичи. Лучше сразу иметь в виду, что результат исследования зависит от отклика клиентов, а время непредсказуемо. Это защитит от неправильных ожиданий у менеджеров.
Не забывайте про самоорганизацию: записи, файлы, артефакты
Одна из ключевых ошибок — отсутствие фиксации прогресса. Чтобы ничего не потерять, сохраняйте скриншоты переписок (обезличенные), количество отправленных приглашений, процент отклика, описание узких мест (например, клиенты заходят на страницу создания бакета, но не продолжают дальше), проблемы, с которыми столкнулись.
Даже два неудачных интервью — это метрика: не подходит канал, не та ЦА, слишком узкий сценарий.
Результат исследования — это не только интервью
Инсайты могут быть разными. Например, выбранный сегмент — слишком сложный для рекрутинга. Или клиенты не вникают в детальную работу утилит, следовательно им нужна автонастройка. Может, вы выясните, что сам сценарий редко используется новичками, тогда стоит сменить аудиторию. Это важные находки, которые влияют на продукт ничуть не меньше, чем классическое интервью.
Заключение
Мой путь в IT начался как учебная практика, а стал стартом карьеры. Практика ИТМО → первые задачи в Selectel → стажировка → испытательный срок → полноценная работа. Все это за один год, который во многом построил мое профессиональное направление.
И если вы сейчас стоите на пороге практики или стажировки, помните: это может быть началом чего-то большого. Если бы я мог дать советы себе из прошлого, они были бы следующими:
-
Не бояться спрашивать. Тишина — главный враг новичка в IT.
-
Активная коммуникация. Обсуждения часто решают проблемы быстрее любых инструментов.
-
Не бояться ошибаться. Это нормальный процесс обучения в сложной IT-сфере, поэтому не бойтесь спрашивать и не бойтесь фиксировать и делиться с командой своими неудачами для дальнейшего роста.
Главный инсайт: в IT важны не только знания. Важно уметь встраиваться в систему, работать с людьми, задавать вопросы, видеть продукт шире своей задачи.
А как проходили ваши первые шаги в IT? Предлагаю вам поделиться в комментариях — будет интересно сравнить опыт.
Автор: Tsuoko
