баги конь.png

Привет, меня зовут Владимир Серов, я QA в Mish. Делюсь с вами принципами тестирования, которые мы используем в своей работе.

<h3>1. Тестирование демонстрирует наличие дефектов, а&nbsp;не&nbsp;их&nbsp;отсутствие.</h3>
<p>Тестирование может выявить присутствие ошибок, но&nbsp;не&nbsp;может доказать в&nbsp;полной мере, что дефектов нет. Сколько&nbsp;бы успешных тестов не&nbsp;провели, нельзя утверждать, что нет таких тестов, которые&nbsp;бы не&nbsp;нашли ошибку.</p>

<h3>2. Исчерпывающее тестирование недостижимо.</h3>
<p>Сколь&nbsp;бы скрупулёзным тестирование не&nbsp;было, нельзя учесть все возможные сценарии, а&nbsp;значит и&nbsp;предвидеть все возможные ошибки.</p>

<h3>3. Заблуждение об&nbsp;отсутствии ошибок.</h3>
<p>Можно сколько угодно находить ошибки, и&nbsp;даже, казалось&nbsp;бы, не&nbsp;обнаруживая их&nbsp;больше, нет гарантии того, что ошибки найдены все и&nbsp;продукт полностью качественный и&nbsp;готовый. Надо помнить такую аксиому&nbsp;&mdash; не&nbsp;существует какого-либо продукта без багов или ошибок.</p>

<h3>4. Раннее тестирование сохраняет время и&nbsp;деньги.</h3>
<p>Этот принцип связан с&nbsp;понятием &laquo;цена дефекта&raquo;. Цена дефекта существенно растет на&nbsp;протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и&nbsp;дешевле его исправить.</p>

<h3>5. Принцип скопления или кластеризация дефектов.</h3>
<p>Принцип, который предполагает, что небольшое количество модулей содержат в&nbsp;себе большинство багов. Это яркий пример применения принципа Парето в&nbsp;тестировании: 20% модулей содержат&nbsp;80% всех багов.</p>

<h3>6. Тестирование зависит от&nbsp;контекста.</h3>
<p>Выбор методологии, техники и&nbsp;вида тестирования напрямую зависит от&nbsp;природы самой системы. К&nbsp;примеру, медицинское программное обеспечение требует более тщательной проверки, чем компьютерная игра.</p>

<h3>7. Парадокс пестицида.</h3>
<p>Если один и&nbsp;тот&nbsp;же пестицид использовать на&nbsp;протяжении долгого времени, например, для истребления неких жуков, то&nbsp;со&nbsp;временем его эффективность упадёт, так как у&nbsp;этих насекомых выработается устойчивость к&nbsp;одному и&nbsp;тому&nbsp;же пестициду.

Такая&nbsp;же ситуация и&nbsp;с&nbsp;тестами, если повторять одни и&nbsp;те&nbsp;же тесты снова и&nbsp;снова, в&nbsp;какой-то момент они перестанут выявлять новые ошибки.</p>

7 принципов тестирования

Серов Владимир

mish_server.png

Привет, меня зовут Андрей Гончаров, я Frontend Developer в Mish Product Lab. Сегодня подробно разберёмся, что такое Server/Backend-Driven UI, как с ним работать и зачем он вообще нужен.

<h3>Что такое Backend-Driven UI?</h3>
<p>Backend-Driven UI (или Server-Driven UI) — это концепция в разработке приложений с интерфейсом, при котором бэкенд управляет как данными приложения, так и его внешним видом. Например, для фронтенд-приложения BDUI будет управлять версткой.</p>
<p>Есть разные уровни «проникновения» этой концепции в фронтенд-приложение, но лучше это представить как спектр.</p>
 <img src="/uploads/1644796358_69c744440a.png" alt="enter image description here">
<p> Да, кстати, об этом статью сейчас не написал только ленивый.</p>


<h3>Кейсы</h3>
<p>Проще всего эту концепцию представить через кейсы. Вот парочка: </p>
<p><strong>Кейс #1: страница оформления заказа (aka checkout)</strong></p>
<p>Обычно заказ оформляется в несколько шагов: выясняем способ получения, способ оплаты, контактные данные, делаем оплату. Бизнесы бывают разные, и логика формирования шагов такая же. Шаги же, по сути, представляют собой формы с полями ввода. На фронтенде нам нужно организовать отрисовку полей форм, переходы между шагами и отправку данных. Остальная логика возлагается на бэкенд.</p>
<p>Яркий пример — CS-Cart.</p>
<img src="/uploads/1644796359_09b35c4805.png" alt="enter image description here">
<p>Примерная логика формирования шагов чекаута в интернет-магазинах.</p>

<p><strong>Кейс #2: пост в блоге</strong></p>
<p>Обычно посты в блогах пишут в админке блога в WYSIWYG-редакторе. Некоторые современные редакторы предоставляют многоколоночное оформление контента, кастомные компоненты, накидывают SEO, тегов и прочих ништяков. Бэкенд хранит записи, организует управление и доступ к ним. Фронтенд из структуры документа формирует верстку.</p>
<p>Яркий пример – Strapi.</p>
<p><strong>Кейс #3: быстрая доставка улучшений интерфейса без обновления приложения</strong></p>
<p>Представим, что вы — банк, который оказался под санкциями: ваше приложение скрыли из всех магазинов, вы не можете доставить пользователям новые обновления. Но у вас есть выход, ведь весь интерфейс приложения приходит в виде JSON с сервера!</p>
<p>Яркий пример — <a href="https://habr.com/ru/company/yandex/blog/683886/">DivKit.</a></p>


<h3>Зачем реализовывать эти кейсы при помощи данной концепции?</h3>
<p>Потому что мы хотим:</p>
<ul>
  <li>Значительно поменять Layout фронтенд-приложения (кейс #3)</li>
  <li>Изменить структуру какого-то экрана в приложении (кейс #3).</li>
  <li>Внедрить A/B-тестирование (кейс #3, кейс #1). Представьте, какая это боль, когда такие тесты на гипотезы надо писать руками, деплоить в отдельные версии/бандлы и так далее.</li>
  <li>Срочно добавить дополнительное промо от отдела маркетинга.</li>
  <li>Добавить страничку с каким-то контентом.</li>
</ul>

<h3>Что может пойти не так, если отказаться от BDUI</h3>
<p>Для каждого отдельного члена команды свой сценарий развития событий:</p>
<ul>
  <li>Для проджекта нужно будет учитывать сложность изменения структуры страницы. Конечно, есть тимлид, который подскажет. Но что, если он тимлид-джун без опыта?</li>
  <li>Для тестировщиков изменение глобальных частей с захардкоженной структурой практически всегда триггерит полный регресс. Нет уверенности в том, что полный ручной регресс не вызывает боль. Но точно есть сценарий с отсрочкой релиза на пару дней.</li>
  <li>Для программистов можно выделить следующие больные моменты кратко:</li>
  <li>изменения в структуре нужно зафиксировать в коде, то есть сесть и сверстать</li>
  <li>внешние источники данных нужно интегрировать для новых блоков;</li>
  <li>необходимо контролировать удаление источника данных при удалении блока;</li>
    <li>нужно встроить новый блок в существующую верстку или же адаптировать верстку при удалении блока.</li>
</ul>


<h3>Что насчет сроков? Негативный кейс</h3>
<p>Давайте рассмотрим кейс, в котором у нас заказывают небольшой сервис бронирования койко-мест. У нас есть дизайн, по которому мы верстаем, есть договор, определяющий функционал и сроки. Есть реальная действительность, где перед дедлайном просят поменять местами промоблок и компонент «селектор койки».</p>
<p>Казалось бы, в верстке меняешь два компонента местами — готово. Но есть вероятные технические блокеры:</p>
<ul>
  <li>фронтендер мог верстать страницу изначально с этими блоками, делая хардкод в размерах, отступах и так далее;</li>
  <li>источники данных могут требовать какой-то определенный порядок запроса данных;</li>
  <li>код может быть «грязным», а понимающий его синьор — в отпуске.</li>
</ul>
<p>Ещё есть минус от хардкоженной структуры UI, не очень очевидный: у страницы нет контракта с точки зрения его структуры и данных. Мы можем понять, какие данные придут, но только после изучения кода. Как и узнать раскладку блоков в верстке.</p>
<p>А как быть с добавлением новой страницы с текстовым контентом?</p>
<ul>
  <li>Нужно залезть в код и скопировать типовую страничку с её layout — по сути копипаст бойлерплейта.</li>
  <li>Может потребоваться зарегистрировать страницу в роутере приложения, закрыть за авторизацией.</li>
  <li>Необходимо подрубить источник данных.</li>
</ul>
<p>С такой ментальной моделью приложения сложно будет сделать следующее:</p>
<ul>
  <li>Проводить A/B-тестирование.</li>
  <li>Добавлять новый контент на сайт без привлечения отдела разработки.</li>
</ul>
<p>Иными словами, фронтенд превращается в программу, внешний вид которой не поддается изменению извне, он не зависит от какой-то схемы.</p>
<p>По сути, вся техника Backend-Driven UI сводится к получению схемы экрана от бэкенда, к дальнейшей обработке и рендерингу. Часто даже с получением карты сайта.</p>


<h3>Как получить удобный BDUI</h3>
<p>Что нам нужно учитывать, чтобы получить удобный Backend-Driven UI?</p>
<ul>
<li><p><strong>Контракт от бэкенда.</strong></p> Нужно понимать, в каком формате будет приходить лейаут экрана.</li>
<li><p><strong>Начальное состояние компонента.</strong></p> Если оно нужно, то как лучше его инкапсулировать?</li>
<li><p><strong>Степень, до которой BDUI описывает layout.</strong></p> Сюда входит расположение и вложенность блоков, их горизонтальное или вертикальное расположение на странице, размеры блоков.</li>
<li><p><strong>Параметры страницы. </strong></p>Среди них номер страницы, фильтры и так далее.</li>
</ul>


<h3>Как это сделать?</h3>
<p>Лучше всего, как я выяснил, выделять логику формирования интерфейса в отдельный микросервис, Backend For Frontend. Не стоит запихивать в бэкенд проекта логику для полиморфного отображения. Да, есть случаи как в кейсе #1, но мы сейчас про макет.</p>


<h3>Кто и как применяет в индустрии BDUI?</h3>
<p><strong>Пример #1. Бигтех, Ozon</strong></p>
<p>Приложение Ozon для смартфонов сделано по этой концепции. Применяют они её по ряду причин:</p>
<ul>
  <li>для A/B-тестирования;</li>
  <li>чтобы вытащить бизнес-логику из Web/Android/iOS приложений;</li>
  <li>для более быстрой доставки изменений пользователям.</li>
</ul>
<p>Вот классная статья, где они рассказывают о том, как готовили логику формирования интерфейса: <a href="https://habr.com/ru/company/ozontech/blog/661941/">Как работает Backend-Driven UI на мобильном клиенте</a></p>

 <img src="/uploads/1644796391_10708cecac.png" alt="enter image description here">
 <p>Скриншот приложения с пояснениями по виджетам на страницы, скрин из статьи Ozon.</p>
 <p><strong>Пример #2. Бигтех, Альфа</strong></p>
 <p>Хорошая статья на Хабре, где инженеры Альфа-банка делятся своим опытом: <a href="https://habr.com/ru/company/alfa/blog/668754/">Эволюция Server-Driven UI: динамические поля, хэндлеры и многошаг</a></p>
<p>Отмечу, что они рассказывают не столько про компоновку, сколько про всё остальное: обработка событий, бизнес-логика в сложных формах.</p>
 <img src="/uploads/1644796364_56d3f6c927.png" alt="enter image description here">
<p>Сриншот из статьи с примером обработки событий.</p>
<p><strong>Пример #3. Бигтех, Airbnb</strong></p>
<p>Ныне почивший в России букинг-сервис Airbnb. Да, их мобильное приложение также построено на концепции BDUI. Применяют они её для A/B-тестирования. Вот приправленная кодом статейка с их рецептом: <a href="https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5">A Deep Dive into Airbnb’s Server-Driven UI System</a></p>
<img src="/uploads/1644796365_14325dbba4.png" alt="enter image description here">
<p>Вот так Airbnb трансформирует данные в UI. Скрин из их статьи.</p>
<p><strong>Пример #4. No-code, Unflow</strong></p>
<p>Да, такая модная тема как no-code зачастую заходит в клиентские приложения через BDUI. Так, Unflow оставляет свободу для кастомизации и предоставляет SDK для мобильных платформ: <a href="https://github.com/unflowhq">Unflow</a></p>
 <img src="/uploads/1644796390_d19c4778ca.png" alt="enter image description here">
 <p>Вот как выглядит редактор экранов в Unflow.</p>
 <p><strong>Пример #5. No-code, Strapi</strong></p>
 <p>Интересный пример реализации — Strapi, Headless CMS. Она даёт интерфейс для редактирования контента и не формирует отображения, не генерирует сайт. Так можно создать сущность «макет страницы» и в него накидывать блоки страницы. Но это совсем неудобно. И ещё нет возможности удобно впилить другие источники данных.</p>
 <img src="/uploads/1644796387_5342ec13ae.png" alt="enter image description here">
 <p>Админка Strapi.</p>
 <p><strong>Пример #6. Реализация концепции в CMS CS-Cartт</strong></p>
 <p>Есть другой пример реализации, так называемый Block Manager. По сути, это упрощенный визуальный редактор макета страницы. Позволяет собрать/пересобрать страничку, вообще не прибегая к написанию кода. Настройки блоков/виджетов — отдельная мультивселенная.</p>
  <img src="/uploads/1644796360_9f4491f533.png" alt="enter image description here">
  <p>Редактор макетов страницы.</p>
  
  
  <h3>Выводы</h3>
  <p>Backend/Server-Driven UI всё же узкоспециален. Реализация полноценного интерфейса в такой парадигме — задание со звёздочкой в квадрате, готовое съесть много денег бизнеса. Поэтому отлично заходит этот подход либо для очень крупного, либо для малого бизнеса. Да и выглядит это как некий Trade-off в обоих случаях.</p>
  <ul>
  <li>Очень крупному бизнесу нужно проверять гипотезы, быстро поставлять фичи/заплатки и не сгореть в аду дублирующейся бизнес-логики в разных клиентских приложениях.</li>
  <li>У малого бизнеса нет ресурсов для своих решений, эти ребята берут no-code платформы, которые в основном BDUI, накидывают экраны, настраивают open-source клиент на свой инстанс в платформе, и всё работает.</li>
</ul>
<p>Но концепция хороша, и применять её точечно в определенных местах (типа сложных форм) — однозначно правильное решение. Чем больше бизнес-логики на сервере, и меньше на клиенте — тем крепче спится.</p>

Продаём тимлиду идею Server/Backend-Driven UI

Гончаров Андрей

tower4.png

История о том, как мы делали спецверсию сайта по ГОСТу совместно с Goose Gaming. Всё ради конкурса президентской платформы «Россия — страна возможностей» для талантов игровой индустрии. Рассказываем о том, какие подводные камни возникают при адаптировании сайта для людей с ограниченными возможностями.

<h3>История о том, как мы делали спецверсию сайта по ГОСТу совместно с Goose Gaming</h3>


<img src="/uploads/prevyu_5a1c594efd.png" alt="превью.png">


<p>Всё ради конкурса президентской платформы «Россия — страна возможностей» для талантов игровой индустрии. Рассказываем о том, какие подводные камни возникают при адаптировании сайта для людей с ограниченными возможностями.</p>
<p>Не будем грузить вас официальными требованиями по ГОСТу. Перечислим кратко: нужно было поработать с настройками для слабовидящих — разработать синтез речи, изменить размер шрифта, увеличить контрастность. При этом сделать так, чтобы сайтом можно было управлять через клавиатуру и не было ограничений по времени для нормального восприятия и использования контента.</p>
<blockquote>
  Мы рады принять участие в социально значимом проекте, ведь компании редко задумываются о специальных версиях сайта. Из-за этого люди даже с распространенными заболеваниями не могут пользоваться продуктом без посторонней помощи.
</blockquote>
<p>Юлия Семенчук, руководитель отдела разработки и продуктового менеджмента в Mish</p>


<h3>Сами проблему сделали — сами решили</h3>

<p>Доступность интерфейсов зависит от дизайна. Изначально он состоял из ломаных, пересекающихся элементов и нам это нравилось. Но когда начали адаптировать сайт под ГОСТ, красота поломалась — табы и кнопки перестали выделяться с клавиатуры. Это связано с тем, что ломаный дизайн достигался путем отсечения лишней части элемента и под отсеченный элемент попадала обводка при фокусе. Забавный опыт для нас, но не для наших фронтов — они сильно ругались, ведь им пришлось все переделывать, поэтому учитывайте требования ещё на стадии проработки дизайна.</p>
<img src="/uploads/Sami_problemu_sdelali_sami_reshili_46105ccc40.png" alt="Сами проблему сделали — сами решили.png">


<h3>Как сверстали</h3>

<p>Для начала необходимо было проработать порядок следования элементов. На планшете, в мобильной версии и в десктопе они должны располагаться в одном и том же порядке, не уезжать и не расплываться. Поэтому мы использовали адаптивную верстку и отрисовали несколько макетов под основные разрешения девайсов.</p>
<p>После этого сконцентрировались на создании ARIA-атрибутов — они позволяют явно указать, в каком состоянии находится меню и добавить читабельный текст к графическим элементам. В общем, помогают скринридерам более точно читать сайт, контекст, цитаты, кнопки, ссылки, описывать изображения, иконки и т.д. Правда, с ARIA-атрибутами нужно работать осознанно и не переборщить, чтобы не усложнять работу скринридерам.</p>
<p><em>Скринридер (screen reader) — программа, которая превращает контент интерфейсов в речь или шрифт Брайля. Они нужны людям со слепотой и слабовидящим, а также пользователям с когнитивными особенностями, которым легче воспринимать информацию на слух. Например, людям с дислексией.</em></p>
<p>И, конечно, не обошлось без использования семантических тегов, потому что это важно для SEO-оптимизации.</p>


<h3>Настрой и сохрани</h3>

<p>Очень удобно, когда настройки спецверсии сохраняются при повторном заходе на сайт, но бывают случаи, когда одним компьютером пользуются несколько человек. Поэтому в процессе разработки появился такой сценарий: когда пользователь включает специальную версию сайта, он видит ее в том состоянии, в котором сам же и настроил. Сохраняются размер шрифта, межстрочный и межбуквенный интервал, цветовая гамма. Но при повторном заходе на сайт или перезагрузке страницы, спецверсия отключается, чтобы нынешний юзер мог решить — нужна ему спецверсия или нет.</p>


<img src="/uploads/Nastroj_i_sohrani_59d509911c.png" alt="Настрой и сохрани.png">


<h3>Как быть с картинками?</h3>

<p>ГОСТ требует, чтобы на сайте была функция отключения изображений с сохранением текстового контента и озвучки. Так, пользователям с нарушениями восприятия мелких и ярких изображений будет проще пользоваться сайтом.</p>
<p>Чтобы описать то, как мы это сделали, расскажем немного матчасти, приготовьтесь:</p>
<ul>
  <li>С помощью пользовательского хука задали параметры по умолчанию для спецверсии и поместили их в локальное хранилище по ключу.</li>
  <li>Затем благодаря компоненту-обертке, в который помещаем всё приложение, через контекст передали параметры и обработчик для их изменения.</li>
  <li>Логику поиска всех DOM-элементов, соответствующих требуемым условиям и присваиванию им необходимых CSS-свойств, реализовали в отдельном пользовательском хуке.</li>
</ul>
<p>В конечном итоге просто вызываем хук на всех страницах приложения, где нужно скрыть изображения.</p>
<img src="/uploads/Kak_byt_s_kartinkami_97cc4ec4d2.png" alt="Как быть с картинками.png">
<p>Чтобы провернуть этот сценарий, пришлось проработать все возможные кейсы применения изображений на страницах сайта, что заняло немало времени. Каждый случай мы обрабатывали определенным образом с точки зрения присваивания или удаления CSS-свойств. Кроме того, возникла потребность выделить ряд изображений в качестве исключений, так как они всегда должны быть видимыми для пользователя, чтобы интерфейс оставался удобным и читаемым. Для подобных случаев изображениям был добавлен специальный data-атрибут, по которому они игнорировались при включении режима «Без изображений».</p>


<h3>Монохром и его друзья</h3>

<p>При создании дизайна спецверсии важно адаптировать его под наиболее распространенные проблемы со зрением. Для этого мы проработали варианты монохрома, возможность изменения размера шрифтов, включения и отключения картинок, звука и т.д. Также уделили много внимания ховерам, выделению активных табов. И не забыли про порядок следования элементов, чтобы он не менялся на разных разрешениях — если этого не сделать, то обязательно возникнут сложности при использовании скринридера и управлении с клавиатуры.</p>


<img src="/uploads/Monohrom_i_ego_druzya_37b53d239f.png" alt="Монохром и его друзья .png">

<p>Во всех браузерах есть готовые решения для управления с клавиатуры, и мы хотели их использовать. Но со временем поняли, что стандартные библиотеки некорректно отображают наш ломаный дизайн — обводка была кривая или вовсе не отображалась. Поэтому нам пришлось немного покреативить.</p>
<p>Чтобы создать сложные формы объектов, подошло свойство CSS, которое называется Clip-Path. Оно позволяет скрыть часть элемента, создавая область отсечения вокруг него. Но когда дело дошло до создания спецверсии, появилась ещё одна проблема — при попытке выделить элемент с помощью клавиши Tab, обводка всё равно не отображалась. Для решения этой проблемы, мы создали псевдоэлементы и разместили их поверх элементов, которые необходимо выделить.</p>
<blockquote>
  Вообще хорошая практика, когда любой сайт, и не обязательно спецверсия, доступен с клавиатуры. Если семантические теги написаны верно, то на 95% эта работа окупается.
</blockquote>
<p> Мария, frontend-разработчик в Mish</p>


<h3>Как оптимизировали работу</h3>

<p>У нас в агентстве любят, когда всё по полочкам — это упрощает работу. Поэтому не лишним была организовать процесс при настройке параметров сайта так, чтобы не бегать по всему проекту. Например, если бы мы разрабатывали все кнопки с нуля, то при настройке сайта изменения пришлось бы вносить в каждую.</p>
<p>Поэтому мы вынесли кнопку в компоненту и добавили специальное состояние. В нем указали условия и зашили всю информацию по тому, как должен выглядеть элемент при включении спецверсии. Это позволило нам прописать все требования только в одном файле и не ходить по всем остальным. Но это стандартная практика: мы на всех проектах делаем компоненты и выносим их в отдельную библиотеку — это удобно и ускоряет процесс.</p>
<p>На сайте много текста, который меняется при включении специальной версии — увеличиваются шрифт и расстояния между буквами. Поэтому с текстовыми блоками поступили так же, как с кнопками — создали компонент, в котором указали все необходимые параметры. Теперь, когда происходит переключение на специальную версию сайта, компонент сам дает команду всем файлам. Бонусом эта фишка позволяет легко добавить озвучку сайта.</p>


<img src="/uploads/Kak_my_optimizirovali_rabotu_e014821f1e.png" alt="Как мы оптимизировали работу .png">


<h3>Какой вывод можно сделать?</h3>

<p>Сложности закаляют — например, необычные требования, к которым ты не готов, короткий срок реализации и ограниченный бюджет. В таких ситуациях можно рассчитывать только на опыт и команду. Поэтому внимательно читайте требования и не бойтесь импровизировать и добавлять от себя полезный функционал, который улучшит пользовательский опыт.</p>
<p>Тем временем первый сезон проекта «Начни игру» уже закончился — финалисты съездили в Казань, защитились и получили финансовую поддержку. А создатели готовятся к новому этапу конкурса, чтобы те, кто не успел принять участие в первом или не прошел отбор, смогли попытать свои шансы во втором. Мы же добавляем новые механики и задания, чтобы ничего не помешало участникам выйти в финал.</p>

ГОСТ бастерс: как мы делали спецверсию сайта «Начни Игру»

Силаев Герман

Семенчук Юлия

Скосырская Мария

Frame 1171274527.png

Однажды наш Middle Developer Виталик решил пересмотреть «Человека-паука» и осознал, что уж слишком путь главного героя похож на его собственный. На следующий день он радостно рассказал об этом нам, и мы попросили его написать статью. Итак, почему айтишники тоже своего рода люди-пауки?

<h3>
  Пожалуй, вместо «Человека-паука» можно было&nbsp;бы выбрать другой супергеройский фильм, но&nbsp;разберем на&nbsp;примере этого.
</h3>
<p><strong>Любое кино подобного жанра строится по&nbsp;следующей структуре:</strong></p>
<ul>
<li>Главный герой по&nbsp;факту неудачник и&nbsp;не&nbsp;знает, кем он&nbsp;хочет быть.</li>
<li>Его жизнь катится на&nbsp;дно, и&nbsp;он&nbsp;понимает, что нужно что-то с&nbsp;этим делать.</li>
<li>Он&nbsp;идет к&nbsp;своему ментальному наставнику и&nbsp;получает важный урок (большая сила&nbsp;— это большая ответственность).</li>
<li>Происходит событие, которое дает ему сверхспособности. Герой кайфует от&nbsp;обретенной силы.</li>
<li> Происходит критическая ситуация (смерть или травма родственника, например), персонаж сначала сдается, но&nbsp;после понимает, что пора брать себя в&nbsp;руки.</li>
<li>Герой растет и&nbsp;становится тем, кем хотел стать, благодаря вере в&nbsp;себя и&nbsp;поддержке близких. </li>
</ul>
<p> Чем это не&nbsp;путь в&nbsp;айти до&nbsp;первой работы? Впрочем, если вы&nbsp;не&nbsp;видите сходства, давайте разберемся подробнее.</p>
<img src="/uploads/Bez_nazvaniya_6effda991f_a5feb5351b.png" alt="Bez_nazvaniya_6effda991f.png" >


<h3>Шаг номер один: жизнь «до»</h3>
<p>Итак, вы&nbsp;обычный человек, учитесь в&nbsp;школе или в&nbsp;университете, в&nbsp;свободное время залипаете в&nbsp;комп. Ваше окружение постоянно долбит вас вопросами о&nbsp;том, кем вы&nbsp;хотите стать в&nbsp;будущем и&nbsp;чего вам хочется от&nbsp;жизни. Вы&nbsp;же в&nbsp;силу возраста не&nbsp;знаете, чего хотите, но&nbsp;подозреваете, что это будет связанно с&nbsp;компьютером.
Потому что компьютер интересный: там интернет-браузеры, компьютерные игры,
видосы и&nbsp;прочие приколы&nbsp;— вам хочется работать в&nbsp;этом пространстве, но&nbsp;вы&nbsp;не&nbsp;знаете кем.</p>
<p>Время идет, но&nbsp;вы&nbsp;никак не&nbsp;можете определиться. Пробуете себя в&nbsp;монтаже видео, создании музыки, написании статей и&nbsp;прочих интересных вещах, но&nbsp;все это не&nbsp;то. Впрочем, осваивая новые навыки, вы&nbsp;учитесь учиться. Денег на&nbsp;курсы нет, поэтому всю информацию приходится добывать из&nbsp;гугла, видосов на&nbsp;ютубеи&nbsp;других открытых источников, до&nbsp;чего-то вы&nbsp;доходите сами. С&nbsp;каждым днем уверенность в&nbsp;том, что вам стоит работать с&nbsp;компьютером, растет.</p>
<p>Или представим другую картину: вы&nbsp;уже взрослый человек, но&nbsp;жизнь вас не&nbsp;устраивает. Работа вам не&nbsp;нравится, платят мало, не&nbsp;ценят ваш профессионализм, а&nbsp;коллеги по&nbsp;работе только и&nbsp;делают что говорят о&nbsp;детях и&nbsp;бытовухе. Все это начинает надоедать. Вам хочется жить по-другому и&nbsp;вы&nbsp;уверены, что способны на&nbsp;большее </p>
<img src="/uploads/Bez_nazvaniya_1_79aeb3fdd0_e1b49e4458.png"
alt="Bez_nazvaniya_1_79aeb3fdd0.png" >


<h3>Шаг номер два: кризис</h3>
<p>Время подступает к&nbsp;11&nbsp;классу или к&nbsp;первому курсу института, и&nbsp;накопленные навыки вас тяготят: от&nbsp;обилия возможностей вы&nbsp;просто не&nbsp;понимаете, чего хотите. Перед вами стоит выбор:</p>
<ul>
<li>Видеомейкер</li>
<li>Журналист</li>
<li>Сисадмин</li>
<li>Эникейщик</li>
<li>Дизайнер</li>
</ul>
<p>Возможно, вы&nbsp;делаете ошибку и&nbsp;поступаете на&nbsp;одну из&nbsp;подобных профессий в&nbsp;надежде, что универ поможет вам раскрыться и стать профессионалом.</p>
<p>Или вы&nbsp;плюете на&nbsp;это и&nbsp;поступаете на&nbsp;программиста, потому что наслушались, что они получают 300к в&nbsp;наносекунду и&nbsp;вообще крутые ребята, но&nbsp;все это абсолютно не&nbsp;знакомо для вас&nbsp;— возможно, математика вообще была вашим заклятым врагом.</p>
<p> В&nbsp;итоге в&nbsp;универе вас учат каким-то супер странным базовым штукам, непонятно зачем вам нужным: какие-то структуры данных, алгоритмы, двоичные системы, куча теории о&nbsp;том, что такое память и&nbsp;как она устроена, как компьютер считает данные,&nbsp;— и&nbsp;говорят, что все это важно. Но&nbsp;на&nbsp;практике все эти знания совершенно бесполезны. Как, собственно, создать свой фейсбук, написать свой куки кликер или разработать новый тиндер? Об&nbsp;этом в&nbsp;универе не&nbsp;рассказывают.</p>
<p>Во&nbsp;взрослом&nbsp;же возрасте непонятно, как можно променять нагретое место на&nbsp;туманные перспективы. Вам тревожно, что не&nbsp;получится, потому что уже и&nbsp;информация усваивается сложнее, и&nbsp;рисков никаких не&nbsp;хочется, и&nbsp;трудно определиться, в&nbsp;кого именно стоит переучиваться,&nbsp;— погружаться в&nbsp;новую область с&nbsp;нуля действительно страшно. К&nbsp;тому&nbsp;же, это сложно совмещать с&nbsp;работой: учеба требует времени и&nbsp;усилий, а&nbsp;при работе 5/2 фулл-тайм едва&nbsp;ли у&nbsp;вас будет пара часов в&nbsp;день на&nbsp;занятия (а&nbsp;про семью вообще можете забыть). Итак, время идет, вы&nbsp;застряли в&nbsp;тревоге, корите себя за&nbsp;нерешительность, но&nbsp;слишком боитесь, чтобы начать что-то делать. </p>
<img src="/uploads/Bez_nazvaniya_2_7f32aac4fc_69f1651210.png"
alt="Bez_nazvaniya_2_7f32aac4fc.png" >


<h3>Шаг номер три: наставник</h3>
<p>В&nbsp;универе вы&nbsp;встречаете интересного парня, который действительно работает программистом и&nbsp;получает кучу денег. Он&nbsp;делится с&nbsp;вами опытом и&nbsp;рассказывает, как он&nbsp;дошел до&nbsp;таких высот. Возможно, это душнила, заливающий про&nbsp;то, как он&nbsp;с&nbsp;детства учил паскаль. Или это 200IQ гигачад, который просто прошел курсики на&nbsp;ютубе и&nbsp;теперь бахает на&nbsp;любом языке и&nbsp;кайфует.</p>
<p>А&nbsp;может, в&nbsp;попытках нагуглить очередное домашнее задание вы&nbsp;натыкаетесь на&nbsp;статью о&nbsp;том, как вкатиться в&nbsp;программирование, увлекаетесь и&nbsp;решаете, что хотите попробовать. Друг-программист делится с&nbsp;вами советами о&nbsp;том, на&nbsp;что обратить внимание и&nbsp;как пройти собеседование.</p>
<p>Если вы&nbsp;взрослый, то&nbsp;вы&nbsp;наверняка встречаете старого друга со&nbsp;школы, который разбирался в&nbsp;компах, а&nbsp;теперь он&nbsp;гребет 300к программистом. Вы&nbsp;вдохновляетесь его примером, тут вам как раз на&nbsp;глаза попадается реклама какого-нибудь скиллбокса, и&nbsp;вы&nbsp;решаетесь: пора!</p>
<img src="/uploads/Bez_nazvaniya_3_0717eb5919_3b99a15965.png"
alt="Bez_nazvaniya_3_0717eb5919.png" >


<h3>Шаг номер четыре: обретение силы</h3>
<p>Вы&nbsp;начинаете погружаться в&nbsp;тему, и&nbsp;чем больше информации вы&nbsp;поглащаете, тем больше уверяетесь в&nbsp;том, что вы&nbsp;крутой: все получается, задачи зачастую не&nbsp;требуют глубоких знаний, новые навыки даются легко. Вы&nbsp;просто занимаетесь интересным делом вечером после учебы или работы. Именно этот момент можно назвать обретением суперсилы&nbsp;— для вас уже не&nbsp;существует преград, вы&nbsp;понимаете, что все можно нагуглить, любую задачу решить и&nbsp;получить от&nbsp;этого удовольствие. К&nbsp;вам обращаются за&nbsp;советом, просят починить чайник, как в&nbsp;тех мемах, вы&nbsp;проникаетесь сообществом и&nbsp;понимаете приколы айтишников. Новая профессия кажется вам манной небесной.</p>
<p><img src="/uploads/Bez_nazvaniya_4_d1a86fa449_d10cffd6ef.png"
alt="Bez_nazvaniya_4_d1a86fa449.png"> </p>
<p>Окрыленные успехом, вы&nbsp;твердо решили устраиваться на&nbsp;работу. Однако для этого нужно систематизировать знания, посмотреть, что спрашивают на&nbsp;собеседованиях, что требуется для выполнения тестового задания,&nbsp;—все это довольно нудно. К&nbsp;тому&nbsp;же, что вы&nbsp;вдруг понимаете, что используете одни и&nbsp;те&nbsp;же приемы от&nbsp;проекта к&nbsp;проекту, нет
никакого развития. Впрочем, это кажется незначительным: что должно меняться, если все строки и&nbsp;методы похожи? Один раз придумал решение&nbsp;— так пользуйся, зачем заново что-то изобретать?</p>
<p>Отбросив все зародившиеся сомнения, вы&nbsp;идете на&nbsp;свое первое собеседование, думая, что такое талантище оторвут с&nbsp;руками и&nbsp;ногами.</p>
<img src="/uploads/Bez_nazvaniya_5_abf89e1c7e_6328e77648.png"
alt="Bez_nazvaniya_5_abf89e1c7e.png">
 
 
<h3>Шаг номер пять: провал</h3>
<p>Ваше первое собеседование&nbsp;— это полный провал.</p>
<p>Выясняется, что ваши знания бесполезны, вам нужно было учиться с&nbsp;опорой на&nbsp;вакансии, а&nbsp;не&nbsp;на&nbsp;статьи в&nbsp;интернете. Навыков, которые действительно нужны, у&nbsp;вас не&nbsp;оказывается (или они совсем в&nbsp;зачаточном состоянии). Вы&nbsp;получаете люлей на&nbsp;нескольких собеседованиях, вас никто никуда не&nbsp;берет. Побитый и&nbsp;отчаянный, вы&nbsp;уползаете обратно в&nbsp;свою нору, не&nbsp;понимая, как жить дальше.</p>
<p>Начинается этап размышлений. Куда&nbsp;же дальше? Ни&nbsp;ютуб, ни&nbsp;гугл, ни&nbsp;курсы на&nbsp;гикбрейнз больше не&nbsp;помогут. Положение кажется безвыходным.</p>
<p>И&nbsp;тут вы&nbsp;вспоминаете про того самого чувака, который когда-то вдохновил вас стать программистом. Или про друга, который уже 3&nbsp;года работает в&nbsp;айти. Вы&nbsp;приходите к&nbsp;нему, он&nbsp;ласково гладит вас по&nbsp;голове и&nbsp;говорит, что не&nbsp;время сдаваться&nbsp;— вот тебе план действий. Вы&nbsp;подтягиваете нужные навыки, просите подробный фидбэк после собеседований, ноете близким, как вам сложно, а&nbsp;они вас поддерживают и&nbsp;радуются каждой удаче вместе с&nbsp;вами. Постепенно вы&nbsp;снова обретаете уверенность в&nbsp;том, что способны добиться желаемого.</p>
<img src="/uploads/Bez_nazvaniya_4734f2bbde_3406a77cfc.png" alt="Bez_nazvaniya_4734f2bbde.png">


<h3>Шаг номер шесть: успех</h3>
<p>И&nbsp;вот ваш старый код кажется полным говном, которое надо переписать, проекты, которые вы&nbsp;придумываете, становятся более осмысленными. Вы&nbsp;делаете себе блестящее портфолио, проходите тридцатое собеседование, и&nbsp;наконец&nbsp;— вот оно, тридцать первое, успешное! Несите шампанское, наш герой наконец добился желанной работы. Ну&nbsp;чем не&nbsp;хэппи энд супергеройского фильма?</p>
<img src="/uploads/Bez_nazvaniya_2_0237efb417_43d7d5cfba.png"
alt="Bez_nazvaniya_2_0237efb417.png">

<p><strong>Небольшие выводы</strong></p>
<p>Пытаетесь понять, тяните&nbsp;ли вы&nbsp;на&nbsp;человека-паука? Мой ответ&nbsp;— да, вы&nbsp;человек-паук, парень на&nbsp;картинке. Потому что именно вы&nbsp;сто раз упали и&nbsp;сто раз поднялись. Сто раз встречали сложную задачу и&nbsp;сто раз ее&nbsp;решали. Вы&nbsp;научились не&nbsp;сдаваться и&nbsp;сражаться до&nbsp;конца. Потому что у&nbsp;вас нет другого выбора: теперь это ваша сила, а&nbsp;как мы&nbsp;знаем, с&nbsp;великой силой приходит и&nbsp;великая ответственность.</p>
<p>Кто поднимет прод за&nbsp;джуном, который его уронил? Кто настроит серваки так, чтобы заказчик мог видеть результаты работы? В&nbsp;конце концов, кто перекрасит вот ту&nbsp;кнопку на&nbsp;главной странице в&nbsp;красный цвет, кроме вас? Правильно, никто. Именно вы&nbsp;взяли на&nbsp;себя эту ответственность перед работодателем, заказчиком и&nbsp;перед самим собой. Поэтому вы&nbsp;уже не&nbsp;можете не&nbsp;справиться с&nbsp;очередной трудностью, поэтому каждый раз проект должен быть все сложнее, реализация проще, алгоритм короче, а&nbsp;занимаемая память меньше.</p>
<p>Каждый из&nbsp;нас&nbsp;— это человек-паук, который несмотря на&nbsp;проблемы справляется с&nbsp;ними и&nbsp;учится жить с&nbsp;этим. Вы&nbsp;сто раз задолбались на&nbsp;сто лет вперед, но&nbsp;и&nbsp;не&nbsp;думаете бросать, потому что ощущение полета на&nbsp;паутине (решения задачи)&nbsp;— это&nbsp;то, ради чего вы&nbsp;стали разработчиком.</p>

«Человек-паук: Через Вселенные» как путь в ИТ

Шушкевич Виталий

article_components copy.jpg

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


<p><strong><a href="/articles/3-optimizaciya-proekta-figma-na-primere-bankovskogo-prilozheniya">В&nbsp;предыдущей статье</a> мы&nbsp;рассказали о&nbsp;нашем опыте оптимизации проекта Figma на&nbsp;примере большого банковского приложения: файл начал сильно тормозить, и&nbsp;мы&nbsp;со&nbsp;временем пришли к&nbsp;пониманию, как решить эту проблему.</strong></p>
 
<p>В&nbsp;данной&nbsp;же статье уделим внимание тому, как мы&nbsp;организовали библиотеку компонентов по&nbsp;итогам оптимизации: поговорим о&nbsp;структуре, о&nbsp;логике названий, а&nbsp;также об&nbsp;особенностях расположения элементов.</p><p>Мы, дизайн-студия Mish, продолжительное время занимались дизайном двух мобильных приложений для SBI банка: классического банкинга для взрослых и&nbsp;отдельного банковского приложения для детей.</p>
<p>Через полгода работы файлы проекта начали сильно тормозить, поэтому мы&nbsp;взялись за&nbsp;капитальную оптимизацию. Решили организовать библиотеку так, чтобы сложные компоненты состояли из&nbsp;простых, где при этом уровней вложенности компонентов может быть несколько: самые маленькие составляющие&nbsp;&mdash; иконки, шрифты, геометрические фигуры; самые большие&nbsp;&mdash; списки, карточки, экраны.</p>
<img src="/uploads/Component_structure_a9fdecec39_67873e680d.jpeg" alt="Component structure">


<h3>Строение компонента</h3>
  
<p>Покажем, из&nbsp;чего состоит компонент, на&nbsp;примере строки списка высотой 64px, одного из&nbsp;самых распространенных элементов в&nbsp;проекте.</p>
<p>Вариаций верстки такого блока списка получилось свыше тридцати: с&nbsp;иконкой и&nbsp;без, с&nbsp;одним заголовком и&nbsp;с&nbsp;заголовком и&nbsp;подстрочником, с&nbsp;суммой и&nbsp;подстрочником и&nbsp;с&nbsp;суммой без подстрочника, с&nbsp;кнопкой вместо суммы и&nbsp;со&nbsp;стрелкой вместо кнопки. Плюс для каждой вариации есть состояния загрузки и&nbsp;состояния на&nbsp;темном фоне. Все эти вариации мы&nbsp;выделили отдельными компонентами. Почему так, мы&nbsp;описали&nbsp;в <a href="https://vc.ru/design/120754-optimizaciya-proekta-figma-na-primere-bolshogo-bankovskogo-prilozheniya">предыдущей статье</a>.</p>
<img src="/uploads/Typical_List_Component_8bfee335ef_cff3fba4cd.jpeg" alt="Typical list component">
<p>Типовой компонент списка состоит из&nbsp;фона, текста, суммы и&nbsp;нескольких вложенных компонентов. Последние, в&nbsp;свою очередь, содержат в&nbsp;себе еще один уровень компонентов: компонент обложки в&nbsp;списке состоит из&nbsp;компонента круга и&nbsp;компонента иконки доллара.</p>
<p>На&nbsp;месте иконки доллара может стоять любая другая: иконка рубля, иконка категории операции или логотип закусочной. Компонент иконки&nbsp;&mdash; наименьший объект в&nbsp;структуре, а&nbsp;иконок схожего размера в&nbsp;проекте около сотни. Такая верстка списка используется во&nbsp;всех разделах приложения: на&nbsp;главном, в&nbsp;истории, в&nbsp;профиле и&nbsp;на&nbsp;внутренних экранах.</p>
<img src="/uploads/Assets_panel_23748eb706_2fc306f287.jpeg" alt="Assets panel">
<p>Чтобы вместо значка доллара поставить на&nbsp;обложку другую иконку, нужно перетащить ее&nbsp;с&nbsp;зажатым Opt+Cmd из&nbsp;панели Assets. Панель Assets&nbsp;&mdash; это второй таб левой панели слоев. Шорткат для быстрого вызова Assets&nbsp;&mdash; Opt+2. Важно, чтобы новая иконка была такого&nbsp;же размера, например, 24&times;24, иначе при замене она сожмется или растянется.</p>
<p>Фон круга под иконкой удобнее менять из&nbsp;Related components на&nbsp;правой панели инструментов. Другой&nbsp;же способ изменения фона&nbsp;&mdash; поменять его цвет через стиль или палитру. Но&nbsp;мы&nbsp;решили по&nbsp;максимуму упаковать все в&nbsp;компоненты и&nbsp;создали шесть компонентов обложек для разных цветов. Так, если понадобится изменить цвет фона на&nbsp;всем проекте, мы&nbsp;сможем сделать это быстрее.</p>
<p>Также есть отдельные случаи, когда на&nbsp;обложку списка нужно поставить логотип компании, например, сотового оператора. Для этого нужно на&nbsp;дочернем компоненте отключить видимость иконки и&nbsp;через стили изменить заливку фона на&nbsp;нужный логотип. Предварительно нужно все логотипы и&nbsp;аватарки занести в&nbsp;цветовые стили.</p>
<img src="/uploads/Component_path_d7470218f5_78214a1467.jpeg" alt="Component path">


  <h3>Путь к&nbsp;компоненту</h3>

<p>Выше мы&nbsp;упоминали, что у&nbsp;блока со&nbsp;строкой списка есть несколько вариантов верстки, и&nbsp;каждый из&nbsp;них является отдельным компонентом. На&nbsp;картинке два схожих компонента. Они немного отличаются в&nbsp;верстке.</p>
<p><strong>list64+icon/1-1</strong>&nbsp;&mdash; элемент списка с&nbsp;одним заголовком и&nbsp;суммой;</p>
<p><strong>list64+icon/2-2</strong>&nbsp;&mdash; с&nbsp;заголовком, подзаголовком и&nbsp;суммой с&nbsp;подстрочником.</p>
<p>Подобных вариаций еще около тридцати, но&nbsp;не&nbsp;будем их&nbsp;все показывать. Важно лишь отметить, что если эти элементы названы правильно, то&nbsp;ими можно легко жонглировать и&nbsp;менять один блок на&nbsp;другой. Делать это можно любым удобным способом: перетаскивать из&nbsp;панели Assets или переключать на&nbsp;панели компонентов.</p>
<p>Отличный лайфхак: чтобы при замене одного компонента на&nbsp;другой сохранялся текст заголовка и&nbsp;сумма, слои этих элементов должны быть названы одинаково. Это также очень полезно при изменении компонентов инпутов или кнопок.</p>
<img src="/uploads/123_b4474790c4_4fc0ab8ff9.gif" alt="Assets">
<p>Чтобы в&nbsp;Related components находились нужные компоненты, их&nbsp;важно правильно назвать. Например, компоненты фонов для иконок в&nbsp;нашем проекте названы примерно так:</p>
<p>componentsAndroid/lists/elements/circle40&times;40/dark</p>
<p>componentsAndroid/lists/elements/circle40&times;40/white</p>
<p>componentsAndroid/lists/elements/circle40&times;40/white15</p>
<p>componentsAndroid/lists/elements/circle40&times;40/blue</p>
<p>componentsAndroid/lists/elements/circle40&times;40/blue5</p>
<p>componentsAndroid/lists/elements/circle40&times;40/blue10</p>
<img src="/uploads/Background_components_for_icons_e051190aab_0ae1602c70.jpeg" alt="Background_components_for_icons_e051190aab.jpeg">
<p>Теперь&nbsp;же рассмотрим, из&nbsp;чего состоит полный путь к&nbsp;компонентам.</p>
<img src="/uploads/full_path_to_components_0290658f98_85ce0e30d7.jpeg" alt="full path to components">
<p><strong>componentsAndroid</strong>&nbsp;&mdash; название файла.</p>
<p><strong>lists</strong>&nbsp;&mdash; название фрейма в&nbsp;файле.</p>
<p>Дальше уже идет рукописное имя, каждый элемент которого между знаками &laquo;/&raquo; создает еще один уровень вложенности. И&nbsp;в&nbsp;конце имя самого элемента.</p>
<p>Также еще один уровень вложенности можно создать, поделив файл на&nbsp;страницы.</p>
<p>Если у&nbsp;нескольких компонентов названия всех уровней, расположенных до&nbsp;имени конечного элемента, совпадают, то&nbsp;Figma считает, что эти компоненты находятся в&nbsp;одной группе и&nbsp;предлагает в&nbsp;один клик менять один компонент на&nbsp;другой, а&nbsp;также хранит эти компоненты рядом в&nbsp;панели Assets.</p>
<img src="/uploads/nesting_level_1adf7ec501_897dc65adc.jpeg" alt="nesting level">
<p>В&nbsp;какой последовательности организовать этот путь, каждый дизайнер решает сам исходя из&nbsp;специфики проекта и&nbsp;удобства использования.</p>
<p>В&nbsp;некоторых случаях удобно сделать последним пунктом признак цвета, что, как в&nbsp;примере выше, позволяет быстро менять цвет подложки под иконкой. В&nbsp;некоторых случаях удобнее называть элементы по&nbsp;иному принципу. Например, по&nbsp;принципу состояния элемента: Enable и&nbsp;Disable, Hover и&nbsp;Active.</p>
 <p>Чтобы избежать перепроектирования, важно в&nbsp;самом начале продумать&nbsp;то, как будет устроена ваша структура, и&nbsp;схематично ее&nbsp;набросать. Но даже если вы&nbsp;ошиблись в&nbsp;структуре, не&nbsp;переживайте&nbsp;&mdash; просто переименуйте мастер-компоненты так, как вам будет удобно. Figma позволяет это сделать в&nbsp;любой момент, что не&nbsp;займет много времени. Ускорить процесс переименования также можно с&nbsp;помощью плагинов.</p> <p><strong>Путь к&nbsp;компоненту</strong></p>
<p>Библиотеку мы&nbsp;расположили в&nbsp;трех файлах:</p>
 <ul>
 <li>Файл с&nbsp;компонентами иконок и&nbsp;иллюстраций, общих для двух платформ;</li>
 <li>Файл с&nbsp;компонентами элементов iOS;</li>
 <li>Файл с&nbsp;компонентами элементов Android.</li>
    </ul>
<img src="/uploads/Library_structure_e16d67f47b_d42dce378d.jpeg" alt="Library structure">
<p>Если в&nbsp;проекте предполагается свыше тысячи экранов, мы&nbsp;рекомендуем хранить компоненты в&nbsp;отдельных файлах. Что может случиться, если хранить компоненты в&nbsp;одном файле с&nbsp;макетами&nbsp;&mdash; читайте в&nbsp;нашей предыдущей статье.</p>


<h3>Выводы</h3>
<ul>
<li>Если в&nbsp;проекте предполагается свыше тысячи экранов, храните компоненты в&nbsp;отдельных файлах.</li>
 <li>Разные состояния элемента лучше делать отдельными компонентами, а&nbsp;не&nbsp;скрытыми слоями. Иконки&nbsp;же нужно переключать в&nbsp;панели компонентов.</li>
<li>Называйте компоненты и&nbsp;слои в&nbsp;них осмысленно, используйте вложенность с&nbsp;помощью слэша &laquo;/&raquo; и&nbsp;иерархии внутри файла: название файла/название страницы/название фрейма/внутренняя иерархия с &laquo;/&raquo;.</li>
<li>Продумывайте заранее структуру библиотеки, дабы сэкономить себе время в&nbsp;будущем.</li>
</ul>

Структура библиотеки компонентов в Figma на примере банковского приложения

Крестов Иван

Кретинин Андрей

16_9.jpg

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

<h3>Расскажем, как мы&nbsp;провели оптимизацию и&nbsp;ускорили работу больших файлов Figma в&nbsp;три раза. Подтолкнули нас к&nbsp;этому тормозящие и&nbsp;не&nbsp;открывающиеся файлы у&nbsp;команды на&nbsp;проекте. Особенно это ощутили ребята с&nbsp;не&nbsp;самым мощным железом: файлы загружались по&nbsp;пять-десять минут.</h3>
<p>В&nbsp;процессе поиска решения мы&nbsp;столкнулись с&nbsp;некоторыми ограничениями и&nbsp;багами в&nbsp;Figma, о&nbsp;которых полезно знать заранее и&nbsp;которые мы&nbsp;подробно изложим ниже.</p>
<p>Статья поможет избежать фундаментальных ошибок при разработке дизайн-систем. Материал будет особенно полезен дизайнерам, разработчикам и&nbsp;бизнесу, которые работают над проектами, где свыше пятисот макетов в&nbsp;дизайне.</p>
<p>Мы&nbsp;студия Mish, преимущественно сфокусированы на&nbsp;дизайне сайтов и&nbsp;мобильных приложений. За&nbsp;время работы мы&nbsp;много сталкивались с&nbsp;крупными проектами, в&nbsp;частности, в&nbsp;банковской сфере. В&nbsp;рассматриваемом случае клиент поставил нам задачу разработать дизайн двух мобильных приложений для SBI: банкинг &laquo;для взрослых&raquo; и&nbsp;отдельное банковское приложение &laquo;для детей&raquo;, в&nbsp;котором есть полноценный счет, можно выполнять задания родителей, получать награды и&nbsp;копить на&nbsp;мечты. Разработка приложений осуществлялась для двух платформ.</p>
<p>Через полгода работы только во&nbsp;&laquo;взрослом&raquo; приложении появилось свыше шести сотен экранов для каждой платформы. Тогда мы&nbsp;столкнулись с&nbsp;проблемой: люди, задействованные на&nbsp;проекте,&nbsp;&mdash; разработчики, аналитики, тестировщики, заметили, что файлы Figma стали работать медленнее. А&nbsp;именно: долго открывались, тормозили при зуме и&nbsp;порой даже вылетали. Даже дизайнеры, работающие на&nbsp;MacBook Pro, испытывали трудности. Например, десять фреймов могли копироваться около минуты: к&nbsp;примеру, выделил&nbsp;их, нажал ⌘+C и&nbsp;ждешь&nbsp;&mdash; Figma все это время не&nbsp;двигается. Потом, если не&nbsp;повезет, выскакивало сообщение &laquo;You run out of&nbsp;memory&raquo;. После этого приходилось перезапускать Figma и&nbsp;копировать фреймы по&nbsp;одному.</p>
<p><img src="/uploads/error_Figma_3da87ea2d2.jpg?updated_at=2023-03-09T14:47:12.467Z" alt="enter image description here"></p> <blockquote>
<p>Поискав информацию в&nbsp;Интернете и&nbsp;на&nbsp;сайте Figma, мы&nbsp;нашли причину и&nbsp;поняли, как решить проблему. <a href="https://help.figma.com/hc/en-us/articles/360040528173">Статья, которая нам помогла.</a></p>
</blockquote>
<p><strong>Две основные причины тормозов:</strong></p>
<ul>
 <li>В&nbsp;одном файле расположено слишком много макетов.</li>
 <li>Основные мастер-компоненты собраны с&nbsp;большим количеством скрытых слоев.</li>
</ul>
<p>И&nbsp;то, и&nbsp;другое существенно снижало основные жизненные показатели файла: занимаемую память и&nbsp;общее количество слоев. Расскажем подробнее о&nbsp;каждом пункте.</p>
<p><img src="/uploads/stat_Figma_6c131a2528.jpg" alt="enter image description here"></p>


<h3>Причина&nbsp;1. В&nbsp;одном файле расположено слишком много макетов</h3>
<p><strong>Дизайн &laquo;взрослого&raquo; приложения состоит из&nbsp;трех файлов:</strong></p>
<ul>
<li>Файл с&nbsp;макетами и&nbsp;компонентами iOS.</li>
<li>Файл с&nbsp;макетами и&nbsp;компонентами Android.</li>
<li>Файл с&nbsp;компонентами общих для платформ иконок и&nbsp;графики.</li>
    </ul>
<p>Есть еще два файла с&nbsp;&laquo;детским&raquo; приложением, но&nbsp;мы&nbsp;не&nbsp;стали их&nbsp;оптимизировать, так как эти файлы работают быстро: в&nbsp;них меньше пяти сотен макетов.</p>
<p><img src="/uploads/arrow_Figma_f23a51acaf.jpg" alt="enter image description here"></p>
<p>Мастер-компоненты мы&nbsp;хранили в&nbsp;одном файле с&nbsp;макетами. На&nbsp;момент старта проекта это не&nbsp;казалось нам чем-то неправильным. Это достаточно удобно, так как не&nbsp;нужно переходить в&nbsp;другой файл, чтобы сдвинуть иконку на&nbsp;два пикселя. Мы&nbsp;думали, что при необходимости можно легко поделить этот файл на&nbsp;несколько: мастер-компоненты оставить в&nbsp;одном файле, а&nbsp;макеты с&nbsp;дочерними компонентами вынести в&nbsp;отдельный.</p>
<p>Но&nbsp;на&nbsp;тот момент мы&nbsp;не&nbsp;подозревали об&nbsp;одной фундаментальной баге программы Figma, о&nbsp;которой напишем чуть позже. А&nbsp;пока расскажем о&nbsp;двух известных нам способах, которыми можно поделить один большой файл на&nbsp;несколько маленьких.</p>


<h4>Способ №1</h4>
<p>Продублировать файл нужное количество раз и&nbsp;в&nbsp;каждом дубликате удалить лишние макеты или страницы.</p>
<p><img src="/uploads/tablet_Figma_00c6d3ce66.jpg" alt="enter image description here"></p>
<p>Нам это способ не&nbsp;подходил, потому что мастер-компоненты хранились в&nbsp;одном файле с&nbsp;макетами и&nbsp;при дублировании потеряли&nbsp;бы связь с&nbsp;дочерними компонентами в&nbsp;новых файлах.</p>


<h4>Способ №2</h4>
<p>Создать несколько новых файлов, подключить к&nbsp;ним командную библиотеку и&nbsp;скопировать в&nbsp;них нужные макеты из&nbsp;исходного файла. В&nbsp;исходном&nbsp;же оставить только мастер-компоненты, так как&nbsp;их, в&nbsp;отличие от&nbsp;дочерних, перенести в&nbsp;другой файл нельзя&nbsp;&mdash; это печальное ограничение Figma, о&nbsp;котором мы&nbsp;знали.</p>
<p><img src="/uploads/arrow2_Figma_8df4ce0640.jpg" alt="enter image description here"></p>
<p>Данный способ выглядит вполне жизнеспособным. Во&nbsp;всяком случае, не&nbsp;противоречит каким-либо очевидным правилам поведения программы.</p>
<p>Но&nbsp;мы&nbsp;не&nbsp;знали о&nbsp;том, что в&nbsp;Figma есть серьезная скрытая проблема: при переносе макета в&nbsp;новый файл многие дочерние компоненты, находящиеся в&nbsp;нем, теряют связь с&nbsp;мастер-компонентом, т.е. часть скопированных дочерних компонентов при вставке превращается в&nbsp;обычные фреймы. Это та&nbsp;самая фундаментальная бага, о&nbsp;которой ребята из&nbsp;Figma в&nbsp;курсе и&nbsp;с&nbsp;которой они воюют уже года два. <a href="https://spectrum.chat/figma/help/components-turning-into-frames~f758bd95-2a65-4c83-a1cd-d4838b40440e">Подробнее о проблеме</a>.</p>
<p>Подобные баги могут происходить даже при копировании и&nbsp;вставке макета внутри одного файла, если делать это через &laquo;<strong>⌘</strong>+C &rarr; <strong>⌘</strong>+V&raquo; или &laquo;Копировать &rarr; Вставить&raquo;. Нам показалось, что часто это происходит на&nbsp;сложных компонентах, а&nbsp;также если компонент уже копировался и&nbsp;вставлялся неоднократно.</p>
<p>Чтобы избежать этого бага, нужно сложные многосоставные компоненты копировать через зажатый Opt или Alt.</p>
<p>Быстро поделить файл на&nbsp;несколько и&nbsp;избавиться от&nbsp;первой причины тормозов у&nbsp;нас не&nbsp;получилось, поэтому переходим ко&nbsp;второй причине.</p>


 <h3>Причина&nbsp;2. Основные компоненты собраны с&nbsp;большим количеством скрытых слоев</h3>
 <p>Есть такие элементы, которые используются почти на&nbsp;каждом макете и&nbsp;отличаются лишь деталями. Например, списки. Список может быть с&nbsp;иконкой или без, с&nbsp;одним заголовком или с&nbsp;заголовком и&nbsp;подстрочником, с&nbsp;суммой и&nbsp;подстрочником или с&nbsp;суммой без подстрочника, с&nbsp;кнопкой вместо суммы или стрелкой вместо кнопки.</p>
<p>Не&nbsp;забываем еще про состояние загрузки, а&nbsp;также все те&nbsp;же самые состояния на&nbsp;темном фоне. Выходит, что высота элемента одна, набор основных элементов примерно тот&nbsp;же, но&nbsp;их&nbsp;комбинация и&nbsp;расположение отличаются.</p>
<p><img src="/uploads/tablet2_Figma_2f24b265c7.jpg" alt="enter image description here"></p>
<p>К&nbsp;примеру, вариаций блока списка высотой 64px в&nbsp;нашем приложении получилось свыше тридцати. Плюс в&nbsp;каждом состоянии может быть еще около ста разных иконок на&nbsp;обложке.</p>
<p>Когда мы&nbsp;создавали первые компоненты на&nbsp;проекте, мы&nbsp;обсуждали два варианта создания дизайн-системы, учитывающих все подобные состояния.</p>


<h4>Способ №1</h4>
<p><strong>Создать один компонент и&nbsp;расположить в&nbsp;нем все состояния в&nbsp;виде скрытых слоев.</strong></p>
<p>Мы&nbsp;так и&nbsp;сделали. В&nbsp;тот момент нам казалось, что это достаточно удобно: не&nbsp;нужно плодить кучу макетов в&nbsp;библиотеке, а&nbsp;переключать состояния проще в&nbsp;панели слоев, выключая видимость текущего слоя и&nbsp;включая видимость нужного.</p>
<p>Главное понятно называть слои и&nbsp;группы слоев. Первое время это действительно казалось удобным всем дизайнерам.</p>
<p>Но&nbsp;оказалось, что в&nbsp;Figma дочерний компонент является не&nbsp;просто ссылкой на&nbsp;мастер-компонент, а&nbsp;полноценным его экземпляром, занимает столько&nbsp;же памяти и&nbsp;тянет за&nbsp;собой все скрытые слои. Получилось, что один экземпляр элемента &laquo;тащил&raquo; за&nbsp;собой все тридцать скрытых и&nbsp;увеличивал размер файла.</p>


<h4>Способ №2</h4>
<p><strong>Создать отдельный мастер-компонент под каждый случай.</strong></p>
<p>При этом стоит учитывать только вариации верстки: если при одной и&nbsp;той&nbsp;же верстке есть еще пятьдесят состояний, в&nbsp;которых отличается только иконка, то&nbsp;эта иконка вставляется в&nbsp;виде вложенного компонента по&nbsp;принципу матрешки.</p>
<p>Замена иконки занимает пару кликов в&nbsp;панели компонентов. По&nbsp;такому&nbsp;же принципу можно подменять любые другие блоки, например вкл/выкл свитчер, активный/неактивный чекбокс, радио-кнопка и&nbsp;проч.</p>
<p><img src="/uploads/111_73406d3a50_217e45fbe5.gif" alt="enter image description here"></p>
<p>Изначально мы&nbsp;пошли по&nbsp;первому варианту&nbsp;&mdash; сделали &laquo;супер-компоненты&raquo;, внутри которых учитывались все возможные состояния в&nbsp;виде скрытых слоев. Это привело к&nbsp;увеличению количества слоев и&nbsp;размера файла. Лучшим решением оказался второй вариант, при котором для каждого состояния элемента создается отдельный компонент.</p>
<p>Далее мы&nbsp;решили оптимизировать проект: вынести мастер-компоненты в&nbsp;отдельный от&nbsp;макетов файл и&nbsp;оптимизировать их&nbsp;структуру&nbsp;&mdash; убрать лишние слои, а&nbsp;все состояния сделать отдельными компонентами. Это должно было решить несколько проблем: общий вес проекта сократился&nbsp;бы, и&nbsp;мы&nbsp;получили&nbsp;бы систему файлов, с&nbsp;помощью которой было&nbsp;бы удобно в&nbsp;будущем их&nbsp;делить.</p>
<p>При этом решили не&nbsp;переделывать существующие компоненты, а&nbsp;сделать все с&nbsp;нуля и&nbsp;последовательно, экран за&nbsp;экраном, целиком обновить проект. Помимо решения основной задачи мы&nbsp;также могли почистить макеты от&nbsp;ненужных слоев и&nbsp;артефактов.</p>
 
 
<h3>Процесс работы</h3>
<p>Работали на&nbsp;&laquo;живом&raquo; проекте, на&nbsp;котором параллельно присутствовали разработчики, аналитики, тестировщики и&nbsp;представители заказчика. Задачей занимался один дизайнер, параллельно разрабатывая новые фичи и&nbsp;занимаясь поддержкой разработки.</p>
<p>На&nbsp;переработку двух платформ ушло около месяца. Мы&nbsp;вели лог основных показателей файла и&nbsp;скринили табличку используемых Figma ресурсов (View &gt; Resource use) при закрытии каждого раздела. Итак, что получилось?</p>

Оптимизация проекта Figma на примере банковского приложения

2023-04-10 18.20.51.jpg

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

<h3>Ошибка №1 Встроенные в письмо pdf со всей информацией</h3>
<p>Такой документ сложно искать и выполнять необходимое, информация во всех pdf подана по-разному. Дизайнеры забывают проверять ссылки, и часто они оказываются не кликабельными, а иногда даже картинками. Как итог, HR тратит кучу времени на поиск. В какой-то момент это задалбывает, и ты перестаешь открывать файлы. Никому не хочется полдня разбираться в вашим резюме. Цените время рекрутера, пожалуйста.</p>
</div>
</div>
</div>
<h3>Ошибка №2 Отсутствие портфолио</h3>
<p>Невозможно положительно ответить на даже очень вдохновляющее письмо дизайнера, который готов на все, но не может предоставить ни единой работы. Предложения выполнить тестовое задание тоже не работают. Во-первых, тестовое задание должно оплачиваться. А все остальное – бесплатный буллшит. Я в это не верю.</p>
</div>
</div>
</div>
<h3>Ошибка №3 Портфолио на неудобном ресурсе</h3>
<p>Призываю опять же подумать о человеке, который сидит на том конце города впервые смотри Ваше портфолио. Вы присылаете ссылку на Google.disk с миллионом папок. Сколько времени, в среднем, вы думаете тратиться на оценку Вашего резюме и портфолио? Призываю руководствоваться принципом «Меньше да лучше»: приоретизируйте, систематизируете. Не старайтесь удивить работодателя количеством.</p>
</div>
</div>
</div>
<h3> Ошибка №4 Ссылки в теле письма</h3>
<p>Часто получаем длинные письма, без структуры, эдакие эссе на вольную тему из серии «Я так могу… А тут я вот так сделал» с большим количеством ссылок в теле письма. Все это производит впечатление каши в голове соискателя, усложняет работу рекрутера. Идеальный вариант подсказываю – соберите небольшую презентацию в Figma, с хорошими инструментами навигации и «зашейте» все свои ссылки в ней.</p>
</div>
</div>
</div>
<h3>Ошибка №5 Неидентифицируемое авторство</h3>

<p>Когда дизайнеры присылают нам свое портфолио, оформленное на Behance, я тихо радуюсь. Это показатель профессионального уровня и маркер уважения к потенциальному работодателю. Но потом я смотрю, что нам выслали на смотр проекты, которые шерят группа из 10 человек. Понять, какой именно вклад в этом проекте нашего соискателя невозможно.</p>
</div>
</div>
</div>
<h3>Ошибка №6 Начинать с требований</h3>
<p>Это касается не только дизайнеров, а любых соискателей. Очень отталкивают письма, которые начинаются с требований соискателя и постановки каких-то условий: в офисе вы должны предоставить мне такую-то модель ноута, обеспечивать кофе с печеньками, лояльно относится к моим опозданиям, ведь я Творец… Такие письма редко кто дочитывает до конца. Не нужно набивать себе цену таким образом.</p>
</div>
</div>
</div>
<h3>Как я вижу идеальное резюме</h3>
</div>
</div>
</div>

<p>1. Важно сразу указывать Ваш город. Есть вакансии, привязанные к локации и нет. Этот пункт экономит время рекрутера.</p>


<p>2. Оформляйте свое портфолио в Figma или выкладывайте на Behance (см предыдущие пункты). Если вы размещаете портфолио на своем сайте – навигация и отборка должны быть идеальные.</p>


<p>3. Предоставляйте ссылку на резюме (краткое и четкое).</p>


<p>
4. Ближе к концу можете описать свои «хотелки» и зарплатные ожидания.</p>


<p>
5. Перечислите свои профессиональные предпочтения, скажите, с чем и на каких проектах вам интересно работать, поделитесь тем, как вы видите свое профессиональное развитие. Всем удачи! Учите мат. часть.
</p>
</div>

Как дизайнеру правильно «упаковать» свое резюме

Пименова Миша

image 13.jpg

Меня зовут Миша, и я руковожу дизайн-студией Mish. Создавая свою студию, я грезила мечтами о больших и крутых проектах для моих ребят. Сама мысль о том, что кого-то из них мне придется "сдавать в аренду" компаниям заказчиков, казалась мне неприемлемой...

</div>
    <h3>Меня зовут Миша, и уже почти три года я руковожу дизайн-студией Mish. Создавая свою студию, я грезила мечтами о больших и крутых проектах для моих ребят. Сама мысль о том, что кого-то из них мне придется &quot;сдавать в аренду&quot; компаниям заказчиков, казалась мне неприемлемой. Но один случай из практики изменил мое отношение к аутстаффингу в корне</h3>
</div>
</div>
</div>
<p>Клиент, у которого помимо нас как агентства, был свой IT-департамент, предложил предоставить ресурсы на три месяца в его распоряжение. Как результат клиент получил отличный продукт, дизайнеры – отличный опыт, а мы улучшили наши отношения с клиентом и начали активно работать с форматом аутстаффинга. Вот только мы часто сталкиваемся с непониманием данного формата у дизайнеров, поэтому решили подробно рассказать, как же это работает.</p>
</div>
</div>
</div>
<h3>Что такое аутстаффинг</h3>
 </div>
</div>
</div>
 <p>Начнём с терминологии. Аутстафинг – это аренда персонала, при которой все юридические и финансовые вопросы решаются компанией, предоставляющей ресурсы. На практике дизайнер устраивается в одну компанию, но работы выполняет для другой. В большинстве случаев дизайнер работает в офисе заказчика, выполняет задачи, которые перед ним ставит заказчик и плотно общается с сотрудниками компании-заказчика. Компания-аутстаффер, в которую дизайнер официально нанят, занимается его зарплатой, отпуском и другими административными вопросами.</p>
</div>
</div>
</div>
<h3>Зачем это нужно</h3>
  </div>
</div>
</div>
 <p>Чем хорош такой формат сотрудничества для компании-заказчика? Этот подход можно обосновать сложной финансовой моделью, доказывающей экономичность данного подхода. Но все это скучно и абстрактно и не очень понятно нужно дизайнерам. Но кроме финансовых есть и более понятные причины.</p>
<p>Предположим, на рынке есть заказчик — крупный банк со своей штатной командой. Внезапно руководство решает провести масштабное исследование и, по его результатам, проработать несколько пользовательских сценариев. Затем протестировать их. Снимать людей с основного процесса возможности нет. Нанимать целую новую команду на проект, который, возможно, не выстрелит, — долго, дорого и не оправданно. Если все-таки будет стоп работ, не понятно, что с ними делать. В этот момент на помощь и приходит внешняя компания с дизайнерами. Похожая ситуация, когда штат нужно быстро закрыть и взять ресурсы аутстафферов.</p>
<p>Мы сотрудничаем с такими крупными игроками, как: Альфабанк, НЛМК, Газпромбанк, Спортмастер и другие. Опыт показывает, что каждая большая корпорация время от времени прибегает к услугам аустафферов. Новые запросы возникают ежедневно, а на рынке присутствует дефицит дизайнеров крепкого мидл уровня.</p>
</div>
</div>
</div>
<h3>Как происходит найм: контакт с аутстаффером</h3>
 </div>
</div>
</div>
<p>Рассмотрим пошагово ситуацию, когда условная компания X, приходит к условному аутстафферу с запросом на 2-3 дизайнеров на проект. Разные аутстафферы анонсируют вакансии по-разному: кто-то просто не останавливает набор, другие предельно четко прописывают сроки и проект. На практике аутстаффер собирается с мыслями и сначала проверяет свободные штатные ресурсы, потом идёт к дружественным компаниям, и только в случае отсутствия подходящих дизайнеров, начинает подбор персонала с рынка труда.</p>
<p>Дальше речь пойдет именно о дизайнерах с рынка труда, потому что в штате все сотрудники обычно готовы к такому повороту событий. Мы в Mish практикуем уход наших кадров на сторону клиента на время, поработать на продукте и немного отдохнуть, так как темпы работы в студии в несколько раз выше.</p>
<p>Итак, Вы — потенциальный соискатель — увидели анонс компании-аутстаффера, отправили своё резюме на почту и ждёте ответного письма.</p>
</div>
</div>
</div> 
<h3>Лайфхаки по оформлению резюме</h3>
 </div>
</div>
</div> 
 <ul>
 <li>заголовок письма содержит ваш уровень, либо указана должность, которая была в вакансии и ваши ФИО – думаю, тут все понятно, легче искать;</li>
<li>обозначение города и возможности релокации не первостепенно, но важно;</li>
<li>оформленное портфолио в фигме или собранное в едином месте; времени у всех мало, поэтому кандидаты с огромным списком ссылок на GoogleDisk обычно отметаются;</li>
<li>ссылка на резюме; компания-аутстаффер готовит CV специально под каждого конкретного клиента, но наличие вашего будет полезным фактором;</li>
 <li>хотелки и зарплатные ожидания лучше выносить в конец;</li>
 <li>профессиональные предпочтения важно указывать, чтобы вы не оказались на абсолютно не интересном вам проекте.</li>
 </ul>
<p>Если ваше резюме подошло, вам назначают первое собеседование с компанией-аутстаффером. К нему не нужно специально готовиться. Главная цель – проверить дизайнера на адекватность и соответствие заявленным качествам в резюме. Предположим, вы успешно прошли внутреннее собеседование, и вас отправляют на второе — уже с компанией-заказчиком.</p>
</div>
</div>
</div>    
<h3>Контакт с компанией-заказчиком</h3>
</div>
</div>
</div>
<p>Если компания-аутстаффер уже заинтересовалась Вашей персоной, используйте это преимущество. Вас могут правильно подготовить к встрече с заказчиком и передать вам всю инсайдерскую информацию. Заранее интересуйтесь, что будет на собеседованиях, сильная ли конкуренция, на каких моментах обычно кандидаты буксуют. Аутстаффер со своей стороны даст рекомендации, что лучше почитать, посмотреть, чего лучше не говорить, что спрашивали на прошлых собеседованиях.</p>
 </div>
</div>
</div>
<h3>Чек-лист перед собеседованием: топ-6 моментов</h3>
</div>
</div>
</div>
<ul>
<li>Дизайнер должен знать свои сильные и слабые стороны и уметь их емко формулировать;</li>
<li>Несмотря на NDA, свои работы придется продемонстрировать;</li>
<li>Обычно у аутстаффера есть несколько вакансий совершенно по разным отраслям бизнеса. Если вы работали со сложными админками, знаете все про оптовые продажи и хотите продолжать работать в этой сфере – самое время это сообщить;</li>
<li>Вы должны задать все интересующие по трудоустройству вопросы: белая зарплата, репутация компании. Детали о самом проекте: сроки, функционал и сценарии развития событий. Если вас торопят с принятием решения и ничего толком не сообщают, знайте, ничем хорошим это не закончится;</li>
<li>Вы должны внимательно посмотреть то резюме, которое подготовила компания-аутстаффер. Там может оказаться неожиданная для вас информация;</li>
 <li>На созвон лучше выходить с видео – это сильно повышает лояльность. И желательно с компьютера, чтобы при необходимости показать какие-то свои проекты.</li>
 </ul>
 </div>
</div>
</div>
<h3>Тест</h3>
<p>Остался третий этап – тестовое задание. Это опциональный пункт, объём его не всегда предсказуем. Мы в Mish стараемся оплачивать тестовые задания. Иногда они бывают действительно большими, и, если кандидат прошёл предыдущие этапы, то правильно его поощрять, таким образом поднимая уровень его мотивации. Некоторые компании сильно помогают кандидатам с подсказками. Мы – никогда. Обычно наш уровень подсказки выглядит «тут нужно подумать ещё» или «тут расписать подробнее». Почему? Предположим, мы сделаем тестовое за кандидата, он выйдет на работу и через пару месяцев обман раскроется. У нас в штате окажется слабый дизайнер, которого мы никуда не сможем пристроить. Мы испортим отношения и с ним, и с клиентом. Наша репутация на рынке тоже пострадает. Никто не выигрывает. Поэтому с заданием придется справляться самостоятельно.</p>
</div>
</div>
</div>
<h3>Рабочий процесс</h3>
 </div>
</div>
</div>   
<p>Итак, вы прошли все этапы и получили job offer. Что дальше? Кто за что отвечает и к кому идти со своими вопросами и проблемами?</p>
 <p>C одной стороны, компания Х должна обеспечить вас работой и управлять вашим таймингом, с другой стороны, — это задача аутстаффера тоже. На его стороне обычно выделен менеджер или hr (или и тот, и другой), которые отвечают за ваше моральное состояние, своевременно выплаченную зарплату, оформление больничных и отпусков, другие финансовые и кадровые вопросы. Компания-аутстаффер — адвокат дизайнера на стороне заказчика: она беспокоится за вашу зарплату и премии, заступается за вас в конфликтных ситуациях.</p>
<p>За такие технические аспекты как оборудование, рабочее место и онбординг тоже отвечает компания-аутстаффер. Она должна подготовиться к моменту вашего оформления: обеспечить все доступы и оборудование.</p>
<p>Процесс интеграции нового сотрудника в компанию зависит от задач и корпоративной культуры каждого отдельного клиента. У нас есть компании-заказчики, где нашим дизайнерам предоставлена свобода. Они рисуют сложные системы без участия арт-директоров: cами проектируют, сами проводят исследования, периодически привлекают ресурсы студии для каких-то иллюстраций, или, например, текстовок. Есть заказчики, у которых дизайнеры становятся частью команды, приживаются и работают там по 1,5—2 года. Мы периодически узнаем, как у них дела, и чем мы можем помочь, но они уже стали полноценной частью коллектива компании для которой делают дизайн.</p>
<p>Они так же ходят на корпоративы и тренинги. Их рабочий процесс отличается только одним – он может закончиться.</p>
</div>
</div>
</div>  
<h3>Что происходит, когда проект заканчивается</h3>
</div>
</div>
</div> 
<p><strong>Здесь всегда есть несколько вариантов сценариев:</strong></p>
<ul>
<li>Если на проекте все шло хорошо, и есть новый беклог, компания X может продлить проект на долгие годы.</li>
<li>Если дизайнер приглянулся, компания может предложить ему уйти в штат. В этой ситуации аутстаффер обычно получает небольшую компенсацию, и остается без сильного ресурса, но в отличных отношениях с заказчиком.</li>
 <li>Третий вариант – аутстаффер может забрать сотрудника к себе в студию, на свои внутренние проекты. У нас сейчас есть ребята, которые после годовой «ссылки» вернулись в &quot;семью&quot; и занимаются исследованиями на аутсорсных проектах.</li>
  <li>Аутстаффер предлагает перейти на проект в другую компанию. В этом случае Вы возвращаетесь к изначальным пунктам с внешним собеседованием и тестовым заданием. В интернете вы найдете много историй про обман при работе на аутстафиинговую компанию. В большинстве случаев это представители низкооплачиваемых профессий, устраивающиеся через кадровые агентства. Компании пропадали, не выплатив зарплаты, трудовой договор отсутствовал – все по классике. В IT-индустрии все живет по другим законам. Если кто-то не платит зарплату, то об этом узнает весь рынок. Имиджевые риски здесь гораздо выше зарплаты сотрудника, поэтому все игроки рынка это прекрасно понимают. Если вы устраиваетесь через крупную или известную компанию, вы на 99% защищены.</li>
</ul>
 </div>
</div>
</div>
<h3>Плюсы работы через аутстаффера</h3>
<ul>
 <li>Вам помогают устроиться, потому что кроме вас в этом заинтересован аутстаффер.</li>
 <li>Чтобы попасть условно в Яндекс, нужно пройти около 5-6 собеседований; через аутстаффинг все ограничится двумя.</li>
 <li>Есть возможность поработать в разных командах и набраться опыта, при этом смена команды и проекта не приводит к увольнению.</li>
</ul>


Аутстаффинг: опыт студии Mish

выбор пользователя2.png

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

<img src="/uploads/1_e77eee4493.webp">

<h3>1. Портрет идеального респондента</h3>
<p>Искать кого-то абстрактного сложно. Гораздо проще, когда вы&nbsp;четко знаете, кто вам нужен. На&nbsp;начальном этапе исследования составьте портрет идеального респондента. Определите факторы, на&nbsp;которые будете опираться при поиске. Оформите их&nbsp;в&nbsp;четкий список и&nbsp;удостоверьтесь, что у&nbsp;всех, кто участвует в&nbsp;поиске, есть доступ к&nbsp;этому списку. В&nbsp;Mish при поиске респондентов мы&nbsp;руководствуемся такими критериями:</p>
<ul>
  <li>Пользование продуктом.</li>
  <li>Соотношение мужчин и женщин.</li>
  <li>Возраст респондентов.</li>
  <li>Географическое положение.</li>
</ul>
<p>Проводя исследование для компаний с&nbsp;широкой целевой аудиторией, мы&nbsp;охватываем все сегменты этой аудитории.</p>

<img src="/uploads/2_e0a551c83b.webp">

<h3>2. Количество имеет значение</h3>
<p>Чем больше респондентов вы&nbsp;найдете, тем больше информации получите, но... Всегда нужно помнить, что во&nbsp;главе угла стоят сроки и&nbsp;бюджет. Для качественного исследования имеет смысл организовывать процесс так, чтобы интервью не&nbsp;длилось дольше часа. Иначе внимание респондента рассеивается, он&nbsp;устает, и&nbsp;качество получаемой информации падает. Еще мы&nbsp;ограничиваем количество вопросов для одного респондента. К&nbsp;тому&nbsp;же с&nbsp;каждым следующим опрошенным это количество уменьшается, потому что большую часть информации мы&nbsp;уже получили.</p>

<img src="/uploads/3_7ffc0fd580.webp">

<h3>3. Без вознаграждения никак</h3>
<p>Время и&nbsp;мнение респондента&nbsp;&mdash; его главная ценность, а&nbsp;вы&nbsp;эту ценность покупаете. Во&nbsp;многих случаях материальное вознаграждение респондента&nbsp;&mdash; главный гарант его участия. Мы&nbsp;платим за&nbsp;знания и&nbsp;опыт, которых у&nbsp;нас нет. Это не&nbsp;обязательно должны быть деньги: могут быть баллы, купоны, скидки. Иногда респонденты могут согласиться на&nbsp;интервью и&nbsp;без оплаты, если им&nbsp;интересно повлиять на&nbsp;развитие продукта. В&nbsp;идеале для исследования следует составить выборку с&nbsp;респондентами из&nbsp;обеих групп.</p>

<img src="/uploads/4_f17cc8f53e.webp">

<h3>4. Площадки для поиска</h3>
<p>Пробуйте нестандартные площадки для поиска респондентов. Вы, конечно, можете сделать упор на&nbsp;неустаревающую классику и&nbsp;искать респондентов в&nbsp;социальных сетях или через HeadHunter. Но&nbsp;нестандартный подход может открыть для вас много нового. Например, можно изучить Avito, чтобы найти людей, которые интересуются определенными товарами в&nbsp;определенном городе. Поиск респондентов&nbsp;&mdash; это системный и&nbsp;логически выстроенный процесс. Это бывает долго, но&nbsp;всегда результативно. </p>

<img src="/uploads/5_df1b077038.webp">

<h3>5. Доверяй, но в некоторых случаях проверяй</h3>
<p>Иногда нужно проверить полученную от&nbsp;респондентов информацию. Если для&nbsp;исследования не&nbsp;важны какие-то специфические навыки и&nbsp;знания респондента, то&nbsp;их&nbsp;проверять не&nbsp;нужно. Если такие навыки и&nbsp;знания нужны, их&nbsp;сначала нужно оценить. Как мы&nbsp;делаем это в&nbsp;Mish:</p>
<ul>
  <li>Делаем тест&nbsp;&mdash; набор вопросов по&nbsp;теме исследования. Это может быть Google форма, отдельный файл или сообщение со&nbsp;списком вопросов в&nbsp;мессенджере.</li>
  <li>Планируем звонок&nbsp;&mdash; первую коммуникацию голосом и&nbsp;подтверждение будущего интервью.</li>
  <li>Проводим интервью&nbsp;&mdash; общаемся с&nbsp;респондентом по&nbsp;вопросам исследования.</li>
</ul>

<img src="/uploads/6_6e1516bfc8.webp">

<h3>6. Респондент респонденту рознь</h3>
<p>Даже если респондент на&nbsp;100% совпадает с&nbsp;вашим идеальным портретом, если ему будет некомфортно во&nbsp;время интервью, данные не&nbsp;будут иметь ценности. Поэтому сначала убедитесь, что время интервью подходит всем. Перед созвоном наладьте контакт с&nbsp;респондентом и&nbsp;прощупайте почву. Если во&nbsp;время интервью респондент отвечает с&nbsp;агрессией или, наоборот, безразличием, не&nbsp;удивляйтесь, что у&nbsp;данных не&nbsp;будет ценности.</p>

<img src="/uploads/7_7c257d6451.webp">

<h3>7. Один респондент — одно направление исследования</h3>
<p>Не&nbsp;важно, насколько универсального и&nbsp;уникального респондента вы&nbsp;нашли. Не&nbsp;стоит водить его по&nbsp;всем интервью. Одни и&nbsp;те&nbsp;же респонденты ведут к&nbsp;искаженным данным. Потому что так вы&nbsp;сами ограничиваете свои источники. Но&nbsp;сохранять контакты опрошенных стоит, чтобы вернуться к&nbsp;ним потом, когда проблема будет решена.</p>

<img src="/uploads/8_08eae798b9.webp">

<p>Надеемся, среди этой золотой семерки вы&nbsp;смогли найти что-то, что откликнулось вам. Придерживайтесь этих советов&nbsp;&mdash; и&nbsp;вы&nbsp;получите эффективные исследования с&nbsp;качественными данными для развития вашего продукта или компании.</p>

Как подобрать респондента для диджитал-исследования

Lifehack-figma.jpg

В прошлом году мы полностью перешли со Sketch на Figma, уже обжились в новом редакторе и очень его любим. Статья будет полезна как новичкам, так и уже опытным пользователям.

<h3>1. Делаем структуру страниц</h3>

<p>На небольших проектах мы всю работу ведем в одном файле: храним в нем черновики, концепты и чистовые макеты с компонентами. Чтобы разработчик и заказчик понимали, где лежит готовый для верстки макет, а где концептуальный черновик, мы делим файл на страницы.</p>
<p>Список страниц дробим на условные разделы. Для лучшего считывания используем эмодзи, а названия страниц отбиваем пробелами от начала строки. Получается что-то вроде структуры с вложенностью.</p>
<p>На самом деле эта структура лишь визуальное решение, так как Figma не позволяет создавать дополнительные уровни вложенности в станицах. В качестве названия раздела используется пустая страница</p>
<p>Ниже несколько примеров такой структуры.</p>

<p><img src="/uploads/2_0fcfc29644_c00e3265a4.png" alt="2_0fcfc29644.png"<em>С помощью эмодзи 🟢 или 🟠 можно отмечать степень готовности раздела для передачи в разработку.</em></p> 


<h3>2. Называем одинаково слои на двух связанных компонентах</h3>
  
<p>Чтобы при смене состояний элемента сохранялись тексты, слои текстовых элементов должны быть названы одинаково. Это удобно при изменении состояний кнопок, элементов списка и инпутов.
<img src="/uploads/gif1_a31ffe4bfc_bdee87fc89.gif" alt="gif1_a31ffe4bfc.gif"></p>

<p>Мы меняем пустое состояние инпута на состояние фокуса, лейбл «Address» переезжает на верх инпута и сохраняет название, а не сбрасывает его на дефолтное.</p>
<p>Чтобы так работало, слои текстовых элементов должны быть названы одинаково, например, Title и Title, как в примере ниже.
<img src="/uploads/3_9b0b21b80a_4e427ea4f2.png" alt="3_9b0b21b80a.png"</p>



<h3>3. Все картинки заводим в цветовые стили</h3>
<p>Чтобы быстро сделать заливку фигуры логотипом, флагом или аватаром, удобно хранить эти картинки в качестве цветовых стилей.
<img src="/uploads/4_e0f12b6320_0f4e076a98.png" alt="4_e0f12b6320.png"> </p>


<h3>4. Быстро находим все элементы с похожими свойствами</h3>
 
 <p>Можно в два клика найти на странице все элементы с похожими свойствами, например, заливкой, обводкой или шрифтом. Для этого нужно выделить элемент, нажать системный Edit &gt; Select All with the Same… и выбрать, с каким конкретно свойством выделить элементы.</p>
 <p>Это удобно, если нужно найти и заменить неактуальный цвет, шрифт или заменить все экземпляры компонента на другие.
<img src="/uploads/5_d1867a25f9_ce947e319b.png" alt="5_d1867a25f9.png"></p>
<p>Также этот способ можно использовать, чтобы перенести мастер-компонент в другой файл. Как — читайте в следующем совете.</p>
  
  
  <h3>5. Переносим мастер-компонент в другой файл</h3>

<p>В Figma нет встроенной возможности перенести используемый мастер-компонент в другой файл, поэтому вам придется делать это вручную. Но есть надежный способ, как ускорить этот процесс.</p>
<p>Для этого нужно:</p>
    <ul>
      <li>Скопировать мастер-компонент в нужный файл;</li>
      <li>Присоединить этот файл в качестве библиотеки к текущему;</li>
      <li>Выбрать любой экземпляр старого мастер-компонента;</li>
      <li>Нажать Edit &gt; Select All with the Same Instance;</li>
      <li>Через меню Instance на панели инструментов заменить выделенные экземпляры на новый компонент;</li>
      <li>Готово! Осталось просмотреть все экземпляры на предмет слетевших текстов и стилей, а чтобы тексты при замене компонента сохранялись, называйте одинаково слои на двух связанных компонентах (об этом мы писали выше).</li>
    </ul>
<p><img src="/uploads/6_7fc92fed3f_fcb22460cb.png" alt="6_7fc92fed3f.png"</p>
<p>По такому же принципу можно перенести из одного файла в другой цветовые и текстовые стили. Для цветовых стилей также можно использовать плагин <ahref="https://www.figma.com/community/plugin/816627069580757929/Style-Organizer">Style Organizer</a> или его аналог.</p>


<h3>6. Делаем автолейауты из списков</h3>

<p>Если список сделать автолейаутом, то работать с ним становится гораздо удобнее: можно быстро увеличить количество строк через Cmd+D или удалить строки из середины списка, при этом отступы между элементами сохранятся </p>
<p><img src="/uploads/gif2_edaddde0b0_e210f9c736.gif?updated_at=2023-03-15T12:14:30.185Z" alt="gif2_edaddde0b0.gif"></p>
 
 
<h3>7. Делаем автолейауты из всего</h3>
 
<p>Знакомая ситуация? 👇</p>
<p><img src="/uploads/gif3_5b2c747874_d353e3d29c.gif?updated_at=2023-03-15T12:15:22.137Z" alt="gif3_5b2c747874.gif"></p>
<p>Все это очень просто решается созданием автолейаута из всех трех элементов.</p>
<p><img src="/uploads/gif4_d3a121f425_46f3b574e7.gif?updated_at=2023-03-15T12:16:14.830Z" alt="gif4_d3a121f425.gif"></p>
 <p>Еще пара примеров:</p>
 <p><img src="/uploads/gif5_bc5c564ae3_ca286a0665.gif?updated_at=2023-03-15T12:17:29.082Z" alt="gif5_bc5c564ae3.gif"></p>
 <p><img src="/uploads/gif3_5b2c747874_d353e3d29c.gif?updated_at=2023-03-15T12:15:22.137Z" alt="gif6_4e257c573f.gif"></p>
 <p><img src="/uploads/gif7_c8f57944c0_b0db50f4d7.gif?updated_at=2023-03-15T12:17:28.615Z" alt="gif7_c8f57944c0.gif"></p>
 <p>Такой прогресс-бар создается из автолейаута и невидимого текста. Такой способ пригодится, когда прогресс находится внутри компонента и нужно показать несколько состояний без детача.</p>
 
 
<h3>8. Растягиваем автолейауты</h3>
  
<p>Чтобы при растягивании блоков контент внутри них адаптировался под размер, нужно при настройке автолейаута использовать параметр «Strech Left &amp; Right» сверху на панели инструментов.</p>
<p><img src="/uploads/gif8_5129a53089_95559dd5ed.gif?updated_at=2023-03-15T12:20:40.099Z" alt="gif8_5129a53089.gif"></p>
 
 
<h3>9. Открываем больше одного окна в десктопном клиенте</h3>

<p>Не все знают, что можно открывать несколько окон десктопного приложения Figma. Делается это простым шорткатом Cmd+Shift+N.</p>
<p>Это удобно, если вы работаете одновременно с несколькими файлами, например, iOS, Android и библиотекой компонентов.</p>
<p>Кстати, почему большие проекты лучше держать в разных файлах, читайте в другой нашей <a href="https://mish.design/blog/2--optimizaciya-proekta-figma-na-primere-bolshogo-bankovskogo-prilozheniya">статье</a>.</p>
<p><img src="/uploads/8_9cb8117241_ca9c42c193.png?updated_at=2023-03-15T12:22:10.113Z" alt="8_9cb8117241.png"></p>
  
  
<h3>10. Не считаем в уме</h3>

<p>Поля, в которых можно редактировать значения, понимают простейшие арифметические операции. Можно увеличить ширину элемента в два раза или прибавить к значению 50%. Это сильно ускорит процесс и поможет не ошибиться в устных подсчетах.</p>
<p><img src="/uploads/9_a349a438ba_92da5dec3b.png?updated_at=2023-03-15T12:22:10.224Z" alt="9_a349a438ba.png"></p>
<p>Мы ввели эти простые правила у себя в Mish. Результат превзошел сам себя: многие задачи стали выполняться сильно быстрее и эффективнее. Также введение единых правил и внутренних гайдлайнов позволили переключать дизайнеров с проекта на проект без потерь времени, что оценили не только коллеги внутри студии, но и клиенты.</p>


10 лайфхаков Figma, чтобы сделать работу эффективнее

large_photo_2024-11-29_14-55-22.jpg

medium_photo_2024-11-29_14-55-22.jpg

small_photo_2024-11-29_14-55-22.jpg

thumbnail_photo_2024-11-29_14-55-22.jpg

photo_2024-11-29_14-55-22.jpg

Mish Let's Play — все! 

Спасибо, что были с нами эти три дня. 30000 уникальных зрителей — это сильно.

Потратьте 3 минутки на опрос по впечатлениям от мероприятия. И ставьте реакции, если хотите второй сезон. Будем знать, куда развиваться и двигаться

Провели мероприятие на 30000 зрителей

large_IMG_5283.PNG

medium_IMG_5283.PNG

small_IMG_5283.PNG

thumbnail_IMG_5283.PNG

IMG_5283.PNG

Так мы согласовывали дизайн для «Цифрового диктанта». Оформление их подкаста «Digital Утро» — тоже наша работа. А в гостях нового выпуска побывал наш дизайн-директор коммуникационного направления, Артем Кожевников. Он рассказал о связи графического дизайна и digital-грамотности. А еще ответил на вопрос, выходить ли замуж за дизайнера — девочки, это нам надо!

Создали визуальный концепт для Цифрового диктанта 

large_photo_2025-02-10_14-51-01.jpg

medium_photo_2025-02-10_14-51-01.jpg

small_photo_2025-02-10_14-51-01.jpg

thumbnail_photo_2025-02-10_14-51-01.jpg

photo_2025-02-10_14-51-01.jpg

Лут с подкаста: про бизнес, деньги, отношения и семью
В прошлом посте обещали рассказать о нас больше — для этого переместились в подкаст ЧТНП, где Миша Пименова поговорила о себе и о Mish. Поделилась историями о триумфах и фатальных провалах, поведала о работе на международной арене и составила свой рейтинг дизайн-студий России!

Миша Пименова в подкасте ЧТНП

medium_photo_2024-12-19_16-21-56.jpg

small_photo_2024-12-19_16-21-56.jpg

thumbnail_photo_2024-12-19_16-21-56.jpg

photo_2024-12-19_16-21-56.jpg

Золото:
Вертикаль  — лучший сайт некоммерческий или благотворительной организации
Вертикаль — развлекательный ресурс, медиапортал
Начни игру — инклюзивный дизайн сайта
Бронза:
ОТР  — сайт СМИ
ОТР  — развлекательный ресурс, медиапортал
Вертикаль  — лучший сайт созданный на конструкторах/платформах
PanClub  — сайт магазина розничной торговли 
Вместе с друзьями из Globus IT  взяли бронзу с сайтом GP Days, полюбуемся дипломом на полочке у глобуса

Поставили на полочку семь дипломов «Золотого сайта» 

large_IMG_5281 (2).PNG

medium_IMG_5281 (2).PNG

small_IMG_5281 (2).PNG

thumbnail_IMG_5281 (2).PNG

IMG_5281 (2).PNG

Ну, что тут сказать. Какие мы, такой и сайт. А теперь готовимся слышать это ещё чаще, потому что кое-что улучшили и навели там красоту. 

Обновили сайт: новые возможности и визуальные улучшения

large_news (1) (1).png

medium_news (1) (1).png

small_news (1) (1).png

thumbnail_news (1) (1).png

news (1) (1).png

В перерывах на кофе собрали хайповый ролик с маскотом Mish. Раскрутили идею и передали атмосферу нашего офиса на Дизайн-заводе…

Создали ролик с CGI

large_2.png

medium_2.png

small_2.png

thumbnail_2.png

2.png

5 сентября мы организовываем собственную секцию «Дизайн» на IT-конференции «GP Days» в Нижнем Новгороде…

Медиа

hello@mish.design

Москва

Нижний Новгород