UX Notes

Мэтт Оуэнс из бруклинской студии Athletics (с очень знакомым лого) рассказал, что понял за 30 лет дизайна.

— Типографика решает. Дизайнеры должны уметь выбирать шрифты и правильно использовать их в проектах. Бесплатные шрифты — чушь собачья;
— Дизайнер формирует вкус с опытом, работая рядом с другими дизайнерами и вдохновляясь. Личный вкус не всегда подходит клиентским проектам, надо уметь разбираться, что хорошо для конкретного проекта;
— Не все хотят руководить, это большая ответственность. Специалист становится лидером, когда своё желание что-то сделать заменяет желанием решить комплексную задачу (для чего нужна группа специалистов);
— Работа сама за себя не говорит. Важно уметь писать и формулировать устно: презентовать, объяснять решения и убеждать, что ваши идеи лучше;
— Работа в одиночестве хороша до определённого момента. Если идея достаточно проработана, лучше её с кем-нибудь обсудить;
— Увлекаться дизайном, состоять в дизайнерских организациях, встречаться с кумирами, выступать с лекциями — это хорошо, но ваша собственная потрясающая работа должна быть на первом месте. Остальное приложится;
— Чем больше контекста вы знаете, тем обоснованнее ваше решение и тем проще его защитить;
— Если клиент платит адекватные деньги, вы оба будете уважать друг друга и играть по правилам. Почти невозможно сделать отличную работу, понимая, что вам недоплачивают;
— Чтобы стать действительно талантливым дизайнером, нужно время. Мастерство и правильные идеи приходят после множества итераций и бесчисленных неправильных идей.

https://ux.pub/moi-9-printsipov-dizayna-na-osnove-30-letnego-opyta-v-industrii/

Оливер Микингс поделился советами по дизайну лендингов. Отдельные не самые затасканные рекомендации:

— Фокусируйте лендинг на одной цели. Не предлагайте посетителям одновременно зарегистрироваться, скачать брошюру и заказать демо;
— Лендинги часто упоминают боль, которую призван снять рекламируемый продукт, но редко стараются её подчеркнуть. Старайтесь взволновать читателя эмоциональным языком и яркими образами, рассказывая о решаемой проблеме;
— Добавьте деталей в призыв к действию. Например, предлагая зарегистрироваться, напишите, сколько времени это займёт;
— Посетителям, которые собираются покинуть страницу, отображайте опрос о причине ухода;
— Ориентируйте лендинг на одну персону, то есть на максимально узкую аудиторию;
— Старайтесь ответить на все вопросы, которые могут возникнуть у посетителя. В модуле с ответами на частые вопросы разместите ответы, для которых не нашлось других модулей.

https://habr.com/ru/company/timeweb/blog/557658/

Кто о чём, а Алан Купер — о персонах, а именно, почему этот инструмент работает не у всех.

— Он написал о персонах в книге «Психбольница в руках пациентов», которую адресовал менеджерам, а не дизайнерам;
— Он не писал её как практическое руководство;
— Персоны удалялись от изначальной идеи, опираясь на мнения людей, которые ничего в них не понимали;
— В компании Алана проводили полевые исследования, а затем создавали персоны, чтобы понимать и отображать цели, мотивацию и желаемые результаты реальных пользователей. И строго ограничивали количество персон ради фокуса;
— В Майкрософте персонами инженеры, запертые в башнях из слоновой кости, защищали придуманные ими функции. Персон у них были сотни — по одной для каждой функции;
— Двое дизайнеров из этой компании опубликовали о персонах влиятельную книгу, которая способствовала удалению от изначальной идеи;
— Привлекательность персон отчасти заключена в том, насколько легко создавать «персоны», не делая этого на самом деле;
— Иногда дизайнеры доходят до правильного понимания персон и пишут в своих блогах: «[Что-то, что не является персонами, но я буду называть это персонами] действительно ужасны. Но [персоны под каким-то новым названием] — намного лучше!»;
— Есть хорошие источники информации о персонах. Они написаны бывшими работниками компании Cooper.

https://www.uprock.ru/articles/v-zashchitu-person

Александра Вельянинова сделала для Райффайзенбанка методичку о тексте в интерфейсе. Отдельные интересные рекомендации:

— Без вранья. Формулируйте аккуратно и не обманывайте ожиданий пользователя даже в мелочах. «Нужен адрес, и мы найдём счета на оплату» → «Нужен адрес, чтобы поискать счета на оплату»;
— В объяснении ставьте действия в том порядке, в котором человек будет их выполнять. «Создайте шаблон, выбрав подходящую операцию из списка» → «Выберите операцию и создайте на её основе шаблон»;
— Очеловечивая текст, не переигрывайте. Когда в последний раз вы получали «Ах да» от друга в чате?
— Без лишних восторгов, особенно в неподходящем контексте. «Ура! Теперь штрафы будут приходить в приложение [Супер!]» → «Теперь штрафы будут приходить в приложение [Хорошо]»;
— Не оценивайте чувства пользователя. «Не волнуйтесь, сейчас разберёмся» → «Сейчас разберёмся, уже смотрю, что произошло»;
— Пишите гендерно нейтрально. «Я согласен с политикой обработки данных» → «Я соглашаюсь с политикой обработки данных»;
— Заголовки проще воспринимать в именительном падеже. «Какую карту хотите? Цифровую. Пластиковую» → «Какая карта подойдёт? Цифровая. Пластиковая»;
— Не проговаривайте текстом функции знакомых элементов. Плейсхолдер в поле поиска: «Поиск по названию или ИНН» → «Поставщик или ИНН».

https://www.figma.com/proto/0JyAj15IhSa3cnf4tl2vmr/Raiffeisen-Verbal-Guide?node-id=15825:39622&scaling=scale-down

Михаил Озорнин поделился частью гайдлайна о передаче макетов разработчикам. Например:

Другие состояния:
— Понятно, как сделать все остальные состояния: переключенные вкладки, переключатели, чекбоксы и радиокнопки (если они влияют на компоновку интерфейса);
— Отрисованы или описаны (если этого достаточно) все варианты дропдаунов, селектов и других выпадаек;
— Кроме самих этих состояний описаны переходы между ними;
— Уровень «Хорошо»: если блоки меняются значительно, то лучше не пытаться описать отдельные выпадайки, а нарисовать блоки целиком, чтобы было меньше путаницы.

Загрузка:
— Понятно, как загружаются элементы экрана, в какой последовательности, как отображается процесс загрузки;
— Как должен вести себя продукт, если загрузка медленная, элементов много или загрузка не удалась.

Пустое состояние:
— Понятно, как выглядит пустое состояние всех блоков и элементов, когда в них нет данных;
— Уровень «Хорошо»: пустые состояния систематизированы, используются типовые решения.

http://mikeozornin.ru/blog/all/what-is-a-good-handoff/

Илья Бирман написал о бессмысленных действиях в интерфейсе.

В Файндере несколько лет назад появилась команда New Folder with Selection (⌃⌘N). Если выделить несколько файлов или папок и вызвать её, она создавала новую папку, перемещала в неё всё выделенное и давала назвать папку.

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

Не надо запрещать пользователям бессмысленные действия, если сами по себе они безвредны.

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

https://ilyabirman.ru/meanwhile/all/meaningless-actions/

Роман Шамин написал, как дизайнеры могут облегчить жизнь фронтам.

— Создавайте дизайн-систему и стройте дизайн из ограниченного набора стилей, переиспользуемых компонентов и последовательных правил компоновки;
— Оформляйте изменения дизайн-системы как фичи;
— Разделяйте большие фичи на небольшие задачи, которые можно дизайнить, верстать и выкатывать по очереди;
— Уважайте мнение технической команды, объясняйте им свои дизайн-решения, утверждайте у них макеты;
— Если нарисованное трудно реализовать, обсуждайте с командой и ищите выход вместе;
— Все знания о фиче собирайте в одном месте (например, на большом артборде в Фигме), все идеи объясняйте текстом и графикой: показывайте стрелками флоу и так далее;
— Будьте в курсе технологий. Например, если приложение использует геолокацию, здорово понимать, что она может быть отключена на устройстве пользователя.

https://teletype.in/@romanshamin/what-frontend-want-from-design

Роман Кирьяков рассказал о подготовке к тестированию посадочной страницы.

Тесты похожи на коридорные: исследователи узнают у респондентов, как они понимают продукт и как пользовались бы им в реальной жизни.

Программа тестирования помогает структурировать информацию, сохранять фокус тестирования, формировать правильные ожидания у заказчика исследования, получать релевантные данные.

Она включает блоки:

1. Проблемная ситуация — описание проблемы, которую хотят решить с помощью тестирования. Если сформулировать её неправильно, вся остальная программа будет некорректна. Пример: есть лендинг о страховке квартиры, конверсия на нём низкая, но мы не понимаем, в чём именно причина.

2. Цель — вытекает из проблемы. Например: понять, почему люди не оформляют страховку.

3. Задачи. Например:
— Понять, какой информации людям не хватает;
— С какими сложностями они сталкиваются при оформлении страховки;
— Как понимают информацию на странице.

4. Выборка — требования к респондентам. Когда в тестировании участвует только целевая аудитория, шансы получить полезную обратную связь возрастают.

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

https://www.it-agency.ru/academy/landing-page-ux/

Ричард Янг написал об оценке затрат на взаимодействие.

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

https://deadsign.ru/ux/interaction-design-is-more-than-just-user-flows-and-clicks/

Джон Анкарстрем раскритиковал, как сейчас работает адаптивный дизайн.

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

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

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

Можно отключить медиазапросы в браузере, но чаще всего по умолчанию будет отображаться мобильная версия (подход Mobile First).

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

https://habr.com/ru/company/macloud/blog/554650/

Николай Крылов сделал подробный конспект книги Роберта Фитцпатрика «Спроси маму».

— Мнения бесполезны;
— Любые прогнозы — ложь, причём чересчур оптимистичная;
— Некоторые проблемы не являются проблемами;
— Идеи и запросы функций надо анализировать, а не слепо реализовывать;
— Если вы рассказали о своей идее, окружающие постараются пощадить ваши чувства;
— Если вы будете настойчиво говорить о своей идее, любой скажет, что она великолепна;
— В любом разговоре задавайте хотя бы один вопрос, который приводит вас в ужас;
— «Ну да…» и «Да ну…» звучат надёжнее, чем «Вау». Нельзя построить бизнес, опираясь на восторженные отклики;
— Двигайтесь от общего к частному и углубляйтесь в детали, пока не получите мощный сигнал;
— У вас всегда должны быть готовы 3 самых важных вопроса;
— Знакомиться с клиентами и их проблемами лучше в коротких беседах, чем в долгих формальных переговорах;
— Если кажется, что собеседник делает одолжение, разговаривая с вами, возможно, беседа слишком формальна;
— Говорите об идее как можно меньше, но направляйте беседу в нужное русло;
— Если после встречи непонятно, что будет дальше, встреча была бесполезной;
— Проводите встречи до тех пор, пока слышите на них новое;
— Пока не настроитесь на поиск чётко сформулированных, непротиворечивых проблем и целей, ваш клиентский сегмент останется размытым;
— Если не понимаете, где искать собеседников, продолжайте делить выбранный сегмент на меньшие подгруппы, пока не поймёте;
— Если неясно, что вы хотите узнать, не стоит заводить разговор;
— Заметки бесполезны, если ими не пользоваться.

https://vc.ru/books/95793

В «Собаке Павловой» написали об аудите интерфейса.

Пирамида требований к интерфейсу: выполнимость → надёжность → удобство → восприятие. Она помогает спланировать исследование и приоритизировать найденные недоработки.

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

Далее надо пройтись по сценариям и проверить, соответствует ли интерфейс требованиям:

1. Выполнимость. Интерфейс позволяет пользователю выполнить базовые задачи в рамках экрана и сценария в целом. Это касается даже профессиональных интерфейсов. Кажется, что там точно всё работает (если бы что-то сломалось, кто-то рассказал бы), но нет.

2. Надёжность. Интерфейс позволяет пройти сценарии альтернативными способами, предусматривает редкие сценарии, готов к ошибкам, даёт выполнить сценарии, не заложенные в систему.

3. Удобство. В интерфейс заложены эффективные паттерны взаимодействия.

4. Восприятие. Интерфейс устанавливает положительную связь с пользователем с помощью UI, текста, голоса бренда, анимации, иллюстраций.

#audit

Пейдж Лаубхаймер из Nielsen Norman Group написал о прилипающих шапках.

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

1. Размеры такой шапки должны быть минимально возможными, особенно на мобильных. Конечно, текст в ней должен оставаться читаемым, а области нажатия быть достаточно большими.

2. Делайте её непрозрачной и отделяйте от остального содержимого страницы (фоном или рамкой). В том числе отображающиеся в ней подменю.

3. Минимум анимации. Анимировать можно замену большой шапки на более компактную прилипающую. Она должна происходить со скоростью прокрутки страницы. Также шапка должна оставаться в определённом месте экрана, а не прилетать туда с задержкой вслед за прокруткой страницы (Stalker Menu).

4. В идеале при появлении непостоянно отображающейся шапки у пользователя должно быть ощущение, будто она появляется синхронно с содержимым страницы. При прокрутке наверх для верхней шапки можно использовать анимацию Slide In длительностью примерно 300−400 мс.

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

https://ux.pub/5-sposobov-uluchsheniya-lipkoy-shapki-sticky-header-ot-nielsen-norman-group/

Брет Виктор в 2011-м написал о взаимодействии с тачскринами, а Константин Рисков перевёл (с сокращениями и дополнениями).

«Вы комбинируете разные захваты, когда откручиваете крышки на банках. Скорее всего, вы этому не учились и даже не осознавали, что и как делаете. Это ли не интуитивно понятный интерфейс?

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

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

«Имея в своём распоряжении всё тело, неужели вы всерьёз полагаете, что будущее взаимодействия заключается в одном пальце?»

https://habr.com/ru/company/dododev/blog/551474/

Фейфей Лиу из Nielsen Norman Group написала об изменении дизайна для глобальной аудитории:

— Иногда простого перевода недостаточно, нужна локализация;
— Даже люди, говорящие на одном языке, могут сильно отличаться. Например, у сайта Apple есть отдельные франкоязычные версии для пользователей из Франции и из канадской провинции Квебек;
— Культурные отличия можно оценить по шкалам Хофстеде: 1) Степень принятия неравномерного распределения власти; 2) Индивидуализм — коллективизм; 3) Мужественность — женственность; 4) Степень страха перед неопределённостью; 5) Долгосрочная — краткосрочная ориентация; 6) Потакание желаниям — сдержанность;
— На сайте Hofstede Insights можно сравнить страны по этим шкалам. Например, США схожи с Австралией и отличаются от Японии. Если отличия заметны, стоит задуматься о локализации;
— Тем больше нужна локализация, чем чаще люди пользуются продуктом, чем сложнее контекст использования (на ходу, в мобильном), если продукт создан для взаимодействия групп людей, если локальные конкуренты в чём-то сильно отличаются (например, в Индии и Китае предпочитают одноразовые пароли в интернет-магазинах);
— Но объём локального рынка должен окупить инвестиции в локализацию, так как она дороже перевода;
— Вы можете сильно отличаться от пользователей на локальном рынке, исследуйте аудиторию, тестируйте на ней продукт.

https://ux.pub/izmenite-svoy-dizayn-dlya-globalnoy-auditorii-issledovanie-kross-kulturnogo-ux-dizayn/

Юля Кондратьева написала об исследовании звуковых сигналов медицинского оборудования.

Для кардиомониторов, систем вентиляции лёгких и подобного есть стандарт по звукам. В мелодиях зашифрованы конкретные фразы, например, Car-di-ac A-larm звучит как C4 E4 G4 — G4 C5 (музыканты поймут), количество слогов и нот совпадает.

Проблема в том, что мелодии никто не тестировал. Звук раздражает пациентов, особенно, если работает несколько аппаратов (дьявольский тритон). Медикам в целом всё равно — они привыкли.

Исследователи предложили набор мелодий с метафорами и звуками из обычной жизни, например:
— Звук сердцебиения — сердечно-сосудистая система;
— Звук встряхиваемых в коробочке таблеток — для приёма лекарств;
— Непрерывный звук выключаемого двигателя — выключение питания;
— Звук аэрозоля — кислород.

Тесты показали:
— Респонденты быстрее определяют смысл таких мелодий и меньше ошибаются;
— Проще определяют направление звука. Актуально, когда врач находится в палате с несколькими пациентами.

https://habr.com/ru/post/537434/

В Usethics написали о клик-тесте скриншотов (First Click Test).

Удалённое немодерируемое юзабилити-тестирование — простой способ проверить идею интерфейса. Но без участия модератора респондент не узнает об ограничениях прототипа и качество исследования будет зависеть от его реалистичности.

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

Процесс взаимодействия надо разбить на задачи, выполняемые в один или 2−3 клика. Обычно результат — карта кликов для каждого экрана.

Такое исследование проще организовать: не нужен прототип, меньше требования к респондентам и инструменту тестирования.

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

Ограничения:
— Не всегда можно увидеть клик каждого пользователя;
— Трудно понять, почему пользователь совершил то или иное действие (спрашивать после каждого клика так себе способ);
— Разные инструменты тестирования по-разному отрабатывают клик и не дают это настроить. Например, в Фабузе респондент после клика переходит на следующий шаг.

#user_testing

Антонина Хисаметдинова рассказала, как сообщать пользователям об ошибках.

Хорошее сообщение об ошибке:
— Снижает нагрузку на техническую поддержку и персонал;
— Помогает пользователю пройти по воронке конверсии;
— Обучает работе с сервисом;
— Позволяет сохранить доверие к сервису в трудную минуту.

Если ошибка связана с глобальным сбоем:
— Сообщите, когда примерно устраните сбой: 15 минут, час, 5 часов, сутки;
— Сообщите, работают ли другие важные сервисы компании. Например, при сбое в личном кабинете банка полезно понимать, работают ли его карточки;
— Подскажите альтернативные способы выполнить целевое действие. Например, если не работает ЛК банка, баланс можно проверить с помощью смс;
— Если это профессиональный инструмент, с которым пользователь работает каждый день, сообщите о сбое.

Если ошибся пользователь:
— Разместите сообщение об ошибке в фокусе его внимания. Например, рядом с кнопкой «Войти» в форме входа;
— Сократите текст сообщения, переместите суть в самое начало;
— Подскажите, как исправить ошибку;
— Сохраните данные, которые пользователь ввёл.

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

https://habr.com/ru/company/jugru/blog/353668/

Леван Джамелашвили проанализировал тёмные паттерны в интерфейсе отмены подписки на «Яндекс Плюс».

1. На всех шагах мастера отмены подписки есть манипуляция с помощью визуальной иерархии и акцентного цвета.

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

2. На третьем шаге нельзя продолжить, не указав причину отписки.

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

От себя добавлю, что само по себе разделение процесса отписки на 5 шагов — тоже тёмный паттерн.

https://designpub.ru/630a057c60dd

Михаил Руденко написал о сложностях стартапов-маркетплейсов.

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

Но это одна из самых сложных бизнес-логик для стартапа:
— Надо привлекать людей из двух разных клиентских сегментов (продавцы и покупатели);
— Сегменты взаимосвязаны, маркетплейс без покупателей не интересен продавцам и наоборот. Пока один сегмент развит плохо, его придётся субсидировать;
— Знакомство продавца и покупателя — одноразовая ценность. После знакомства они могут работать напрямую. Нужны услуги, которые будет оказывать площадка: безопасная сделка, доставка, страховка. А значит, надо научиться их оказывать, причём, в масштабе всего маркетплейса.

https://blog.buro.cx/nie-nachinaitie-startap-s-markietplieisa/