Заметки арт-директора продуктового дизайнера.
Личка ТГ @priymakrom
Post #21
42
Channel Public Channel
LI LIDS / Lorem ipsum dolor sitame
@lidsit
- Subscribers
- 19
- Photos
- 10
- Videos
- 4
- Links
- 2
Showing posts older than #22 · Back to latest
Older Posts 12 shown
LIDS / Lorem ipsum dolor sitame pinned a photo
Post #19
69
😡 БЕСЮЧИЕ ДЖУН ДИЗАЙНЕРЫ (Часть 2)
💬 1 место. Отсутствие инициативы
Ну и вот мой личный ТОП-1. И речь здесь даже не о предложении джуном собственных идей и решений. Я про общую инициативу в работе. Когда человек не стремится вообще ни к чему: лишний раз не спросит совета, не ходит с тобой на презентации макетов, не перенимает опыт, может вносить десять тысяч правок, ошибаясь снова и снова в одних и тех же местах, даже об отпуске может не предупредить, кинув свои задачи. Такой джун, которому плевать на все. Говорят, инициатива наказуема, но не в работе дизайнером. Хуже нет таких работников, и это действительно бесит.
💬 1 место. Отсутствие инициативы
Ну и вот мой личный ТОП-1. И речь здесь даже не о предложении джуном собственных идей и решений. Я про общую инициативу в работе. Когда человек не стремится вообще ни к чему: лишний раз не спросит совета, не ходит с тобой на презентации макетов, не перенимает опыт, может вносить десять тысяч правок, ошибаясь снова и снова в одних и тех же местах, даже об отпуске может не предупредить, кинув свои задачи. Такой джун, которому плевать на все. Говорят, инициатива наказуема, но не в работе дизайнером. Хуже нет таких работников, и это действительно бесит.
- ❤ 1
Post #18
69
😡 БЕСЮЧИЕ ДЖУН ДИЗАЙНЕРЫ (Часть 1)
Каждый ведущий дизайнер сталкивался с этим в работе с джунами. Когда к тебе в команду приходит стажер или джун, то стиль его работы, способность к обучению, мотивация - это всегда “русская рулетка”. И то, что ты собеседовал и выбирал кандидата в свою команду самостоятельно, далеко не всегда гарантия, что ты получишь супер прыткого сотрудника, понимающего с полуслова. Все пункты, что я написал ниже, прорабатываются индивидуально (кроме первого и последнего): составляется ИПР, обсуждается лично и т.д. Но все мы люди, и от эмоций никуда не деться. Поэтому вот мой ТОП-10, что бесит в джунах:
💬 10 место. Непрофессиональное поведение
Сюда входят постоянное несоблюдение сроков, систематическое опоздание на работу без предупреждения, неуважительное отношение к коллегам или попросту грубость. Такие перчики могут скрывать свою сущность на собеседовании, но, как правило, раскрываются на испытательном сроке и тут же отлетают из компании думать о своем поведении.
💬 9 место. Недостаток терпения и настойчивости
Да, так бывает, джуны выгорают. Дизайн — процесс сложный, требующий времени и усилий. Результаты и опыт работы не всегда приходят моментально. Каждый проект — это возможность для обучения и совершенствования навыков. Нетерпеливые сгорают, теряется мотивация, ухудшается качество работы.
💬 8 место. Фукусирование на мелочах
Часто джуны уделяют чрезмерное количество времени на лишние рассуждения по мелочам: какую иконку поставить в кнопку, какой цвет поставить бежевый или слоновой кости, на сколько пикселей сдвинуть баннер. Такой излишний перфекционизм и потеря фокусировки от общей задачи в целом замедляет работу.
💬 7 место. Отсутствие самостоятельности
Кому нравится, когда постоянно тыркают по мелочам? Раздражает, когда джун постоянно нуждается в детальном руководстве и не может принимать даже небольшие решения самостоятельно. Бесит не сразу, эффект накопительный.
💬 6 место. Неумение следовать инструкциям
Базовый навык. Просто прочитай ТЗ, выполни и перепроверь себя. Бесит, когда джун приходит на ревью, а там 3 из 10 пунктов ТЗ просто отсутствуют. Куда смотрим? “Повнимательнее, коллеги.”
💬 5 место. Непрофессиональное отношение к критике
Всегда важно помнить, что критикуют не тебя как человека, а твою работу. Некоторые джуны могут воспринять все как личное оскорбление и либо начать огрызаться, либо обидеться. Воспринимать критику нужно всегда с холодной головой. Но и критикующему тоже нужно следить за словами и помнить, что “художника может обидеть каждый”. Все должно быть конструктивно и обезличено. Работа есть работа.
💬 4 место. Неумение работать с обратной связью
Чем-то похож на предыдущий пункт, но немного другой. Обратная связь — это не всегда критика работы. Это и уточнения, и пожелания, и просьба погенерировать идеи. Джуны не всегда хотят быть гибкими и опускают руки.
💬 3 место. Нежелание учиться и отсутствие стремления
Джуны иногда не проявляют инициативы в изучении подходов, технологий, методов в разработке дизайна продукта. Например, не интересуются продуктовым подходом в дизайне, исследованиями на пользователях, продуктовыми метриками, а некоторые даже не знают, на каком языке собирается forntend продукта. Плохо, когда человек не хочет развиваться.
💬 2 место. Недостаток внимания к деталям
Ошибки и неточности, невнимательность, особенно когда джун проработал более полугода с тобой над одним проектом, вызывают гнев. За полгода джун просто обязан знать всю библиотеку компонентов, все спецификации, все разработанные макеты и принципы их построения. Бывает, заходишь на ревью макета, а там тултип, который испокон веков стоял снизу, вдруг оказался сверху.
Каждый ведущий дизайнер сталкивался с этим в работе с джунами. Когда к тебе в команду приходит стажер или джун, то стиль его работы, способность к обучению, мотивация - это всегда “русская рулетка”. И то, что ты собеседовал и выбирал кандидата в свою команду самостоятельно, далеко не всегда гарантия, что ты получишь супер прыткого сотрудника, понимающего с полуслова. Все пункты, что я написал ниже, прорабатываются индивидуально (кроме первого и последнего): составляется ИПР, обсуждается лично и т.д. Но все мы люди, и от эмоций никуда не деться. Поэтому вот мой ТОП-10, что бесит в джунах:
💬 10 место. Непрофессиональное поведение
Сюда входят постоянное несоблюдение сроков, систематическое опоздание на работу без предупреждения, неуважительное отношение к коллегам или попросту грубость. Такие перчики могут скрывать свою сущность на собеседовании, но, как правило, раскрываются на испытательном сроке и тут же отлетают из компании думать о своем поведении.
💬 9 место. Недостаток терпения и настойчивости
Да, так бывает, джуны выгорают. Дизайн — процесс сложный, требующий времени и усилий. Результаты и опыт работы не всегда приходят моментально. Каждый проект — это возможность для обучения и совершенствования навыков. Нетерпеливые сгорают, теряется мотивация, ухудшается качество работы.
💬 8 место. Фукусирование на мелочах
Часто джуны уделяют чрезмерное количество времени на лишние рассуждения по мелочам: какую иконку поставить в кнопку, какой цвет поставить бежевый или слоновой кости, на сколько пикселей сдвинуть баннер. Такой излишний перфекционизм и потеря фокусировки от общей задачи в целом замедляет работу.
💬 7 место. Отсутствие самостоятельности
Кому нравится, когда постоянно тыркают по мелочам? Раздражает, когда джун постоянно нуждается в детальном руководстве и не может принимать даже небольшие решения самостоятельно. Бесит не сразу, эффект накопительный.
💬 6 место. Неумение следовать инструкциям
Базовый навык. Просто прочитай ТЗ, выполни и перепроверь себя. Бесит, когда джун приходит на ревью, а там 3 из 10 пунктов ТЗ просто отсутствуют. Куда смотрим? “Повнимательнее, коллеги.”
💬 5 место. Непрофессиональное отношение к критике
Всегда важно помнить, что критикуют не тебя как человека, а твою работу. Некоторые джуны могут воспринять все как личное оскорбление и либо начать огрызаться, либо обидеться. Воспринимать критику нужно всегда с холодной головой. Но и критикующему тоже нужно следить за словами и помнить, что “художника может обидеть каждый”. Все должно быть конструктивно и обезличено. Работа есть работа.
💬 4 место. Неумение работать с обратной связью
Чем-то похож на предыдущий пункт, но немного другой. Обратная связь — это не всегда критика работы. Это и уточнения, и пожелания, и просьба погенерировать идеи. Джуны не всегда хотят быть гибкими и опускают руки.
💬 3 место. Нежелание учиться и отсутствие стремления
Джуны иногда не проявляют инициативы в изучении подходов, технологий, методов в разработке дизайна продукта. Например, не интересуются продуктовым подходом в дизайне, исследованиями на пользователях, продуктовыми метриками, а некоторые даже не знают, на каком языке собирается forntend продукта. Плохо, когда человек не хочет развиваться.
💬 2 место. Недостаток внимания к деталям
Ошибки и неточности, невнимательность, особенно когда джун проработал более полугода с тобой над одним проектом, вызывают гнев. За полгода джун просто обязан знать всю библиотеку компонентов, все спецификации, все разработанные макеты и принципы их построения. Бывает, заходишь на ревью макета, а там тултип, который испокон веков стоял снизу, вдруг оказался сверху.
Post #17
55
Post #16
61
👨💻 НУЖНО ЛИ ДИЗАЙНЕРУ ИЗУЧАТЬ ВЕРСТКУ (Часть 2)
- Если ты web-дизайнер, разрабатываешь лендинги, интернет-магазины, то ты должен более углублено понимать принципы разработки: зачем нужна сетка, почему не должно быть 10 разных по размеру кнопок, зачем этот верстальщик просит от меня планшетную версию, а не только мобильную. Тут вершки уже не прокатят. Копай глубже, но без скриптов. Как оно там что с бэкенда на фронтенд попадает, тебе не обязательно знать. Но если разрабатываешь самостоятельно, например на «Тильде», то знания JQuery тебе очень понадобятся.
Пример из практики: в моей команде джун-дизайнер разрабатывала интернет-магазин по продаже кастомных светильников. В процессе работы, на промежуточном этапе ревью макетов, я увидел, что по визуалу и юзер флоу всё хорошо, но было в работе очень много типичных ошибок по верстке, такие как разные отступы между основными типовыми блоками, одни и те же кнопки с разными внутренними отступами и толщиной текста, какие-то блоки были просто не по сетке и т. д. В итоге на ранних этапах мы всё поправили, реализовали красивый, а главное, удобный интернет-магазин, ну а коллеге в ИПР я добавил изучение верстки.
- Если ты продуктовый (ux/ui) дизайнер, то здесь уже нужно полное понимание построения интерфейсов в коде в плане верстки, и очень пригодятся знания по фреймворкам на фронте, с помощью которых происходит разработка: React, Vue, Angular и т. д. Также не лишним будет понимание бэкенда: Python, Ruby, Java. Во фреймворки можно сильно не погружаться, но все эти знания помогут тебе понимать такие вещи, как техническое ограничение, чтобы не получилось ситуации, когда фронтенд-разработчик говорит тебе «этого нельзя сделать, как ты нарисовал» и объясняет всё на своем языке, а ты прослушал, как сказку, и согласился.
Пример из моей практики: на текущем продукте, где я работаю, есть ролевая модель. Админ добавляет пользователей в таблицу, формирует доступы в другие сервисы и, соответстенно, может этих пользователей из таблицы удалить. Моей задачей было нарисовать удаление пользователей. Сам процесс удаления в техническом плане происходит так: при нажатии на кнопку «удалить», фронт отправляет запрос на бэк об удалении доступов пользователя со всех сервисов, а фронт в свою очередь убирает моментально пользователя из таблицы. Такое поведение меня не устраивало, ведь если бэк вернет ошибку при удалении, то фронт вернет этого пользователя в таблицу. Для удаляющего это неочевидно, потому что он может нажать «удалить пользователя» и уйти по другим страницам, будучи уверенным, что тот удален, ведь из таблицы пропала строчка. А если произойдет ошибка удаления, то уведомление об этом может просто пропустить. Когда вернется, удаленный пользователь вновь будет в таблице. Я же в дизайне отобразил, что удаляющий до последнего видит статус, что происходит процесс удаления. Это один из принципов юзабилити, что пользователь всегда должен понимать статус системы. Разработка доказывала мне, что это не реализуемо, однако мое понимание, что у нас в коде «под капотом», говорило об обратном. В итоге мы нашли выход и реализовали запланированное мной.
Ну и резюмируя, нужно ли дизайнеру изучать верстку? Мое мнение — однозначно стоит. Изучайте верстку, интересуйтесь фронтендом, говорите с разработчиком на одном языке и будете гарантировано получать тот результат, что запланировали в макетах.
- Если ты web-дизайнер, разрабатываешь лендинги, интернет-магазины, то ты должен более углублено понимать принципы разработки: зачем нужна сетка, почему не должно быть 10 разных по размеру кнопок, зачем этот верстальщик просит от меня планшетную версию, а не только мобильную. Тут вершки уже не прокатят. Копай глубже, но без скриптов. Как оно там что с бэкенда на фронтенд попадает, тебе не обязательно знать. Но если разрабатываешь самостоятельно, например на «Тильде», то знания JQuery тебе очень понадобятся.
Пример из практики: в моей команде джун-дизайнер разрабатывала интернет-магазин по продаже кастомных светильников. В процессе работы, на промежуточном этапе ревью макетов, я увидел, что по визуалу и юзер флоу всё хорошо, но было в работе очень много типичных ошибок по верстке, такие как разные отступы между основными типовыми блоками, одни и те же кнопки с разными внутренними отступами и толщиной текста, какие-то блоки были просто не по сетке и т. д. В итоге на ранних этапах мы всё поправили, реализовали красивый, а главное, удобный интернет-магазин, ну а коллеге в ИПР я добавил изучение верстки.
- Если ты продуктовый (ux/ui) дизайнер, то здесь уже нужно полное понимание построения интерфейсов в коде в плане верстки, и очень пригодятся знания по фреймворкам на фронте, с помощью которых происходит разработка: React, Vue, Angular и т. д. Также не лишним будет понимание бэкенда: Python, Ruby, Java. Во фреймворки можно сильно не погружаться, но все эти знания помогут тебе понимать такие вещи, как техническое ограничение, чтобы не получилось ситуации, когда фронтенд-разработчик говорит тебе «этого нельзя сделать, как ты нарисовал» и объясняет всё на своем языке, а ты прослушал, как сказку, и согласился.
Пример из моей практики: на текущем продукте, где я работаю, есть ролевая модель. Админ добавляет пользователей в таблицу, формирует доступы в другие сервисы и, соответстенно, может этих пользователей из таблицы удалить. Моей задачей было нарисовать удаление пользователей. Сам процесс удаления в техническом плане происходит так: при нажатии на кнопку «удалить», фронт отправляет запрос на бэк об удалении доступов пользователя со всех сервисов, а фронт в свою очередь убирает моментально пользователя из таблицы. Такое поведение меня не устраивало, ведь если бэк вернет ошибку при удалении, то фронт вернет этого пользователя в таблицу. Для удаляющего это неочевидно, потому что он может нажать «удалить пользователя» и уйти по другим страницам, будучи уверенным, что тот удален, ведь из таблицы пропала строчка. А если произойдет ошибка удаления, то уведомление об этом может просто пропустить. Когда вернется, удаленный пользователь вновь будет в таблице. Я же в дизайне отобразил, что удаляющий до последнего видит статус, что происходит процесс удаления. Это один из принципов юзабилити, что пользователь всегда должен понимать статус системы. Разработка доказывала мне, что это не реализуемо, однако мое понимание, что у нас в коде «под капотом», говорило об обратном. В итоге мы нашли выход и реализовали запланированное мной.
Ну и резюмируя, нужно ли дизайнеру изучать верстку? Мое мнение — однозначно стоит. Изучайте верстку, интересуйтесь фронтендом, говорите с разработчиком на одном языке и будете гарантировано получать тот результат, что запланировали в макетах.
Post #15
76
👨💻 НУЖНО ЛИ ДИЗАЙНЕРУ ИЗУЧАТЬ ВЕРСТКУ (Часть 1)
Чтобы ответить на этот вопрос, достаточно понять, для кого мы делаем дизайн. Ответ ясен и прозрачен — для пользователей. Но не стоит забывать, что процесс создания продукта, не важно, будь то приложение или сайт, подразумевает за собой создание кода для отображения твоего дизайна. Если смотреть с этой точки зрения и развернуто ответить на вопрос «Для кого мы делаем дизайн?», то получается, что мы делаем дизайн для того, чтобы передать его разработчику, а он в свою очередь воплощает задуманное тобой в жизнь.
Ты можешь работать в небольшой дизайн-студии, где нет разработчиков в штате. Или в продуктовой команде, где свой дизайн передаешь непосредственно разработчику. Но так или иначе, если хочешь классный результат, разговаривай на их «разработческом языке». Ты как мостик между идеей заказчика и реализацией.
Многие джун- и мидл-дизайнеры не знают базовых вещей в верстке. А потом получается, что в дизайне у кнопок нет hover/active/focus состояний, в мобильной версии в иконку не попадешь пальцем, потому что у иконки не показаны падинги, а блок с полупрозрачным бэкграундом сделан через opacity, а не через rgba. Если вышесказанное вызывает у тебя вопрос «Что ты, черт возьми, несешь?», то срочно изучай верстку. Это реально важно, потому что разраб зачастую сделает так, как ты нарисовал, а за визуальный результат отвечаешь ты, как перед заказчиками, так перед пользователями. Ты можешь знать всё, что я написал выше, потому что этому учат и без верстки, но поверь, пока сам не попробуешь на своей шкуре, всех тонкостей не узнаешь. Попробуй заверстать одну страницу сайта и ее мобильную версию — просто верстку, без прописывания логики скриптами, и ты всё поймешь.
Если я тебя не убедил, давай посмотрим под другим ракурсом с другой профессией. Должен ли преподаватель в школе обладать ораторским искусством? По сути, нет. Но если преподаватель высококвалифицированный, то, пожалуй, такой навык поможет донести любую информацию до учеников.
Теперь насколько глубоко погружаться в разработку. Здесь ответ кроется в том, какой ты дизайнер:
- Если ты граф-дизайнер, извини, что потратил твое время. Тебе не нужна верстка.
- Если ты дизайнер промостраниц, делаешь какие-то визуально крутые проекты а-ля «Беханс», то базовых знаний верстки и адаптивности под мобильные устройства достаточно, чтобы просто понимать состояния элементов интерфейса и принцип единообразия и повторяемости. Начнешь изучать глубже — может загнать тебя в рамки и будет не креатив, а четко «по линеечке», потому что разработка формирует перфекционизм, будешь постоянно думать, как твой креатив будут разрабатывать, что вот тут не по сетке, а тут не по базовой линии и т. д.
Пример из моей практики: участвовали с моей командой в тендере небезызвестной компании консервированных овощей, где «вот морковка ушла вперед, эстафету передает». Задачей было сделать редизайн главного сайта и описания продукции с упором на креатив. Мы подошли к задаче более серьезно, накреативили, но не стали забывать и о пользователях, загнали себя в рамки, что сайт еще разрабатывать нужно, и приглушили креатив в угоду пользователям. В итоге победила команда с вылетающими свистоперделками и горохом на весь экран.
Чтобы ответить на этот вопрос, достаточно понять, для кого мы делаем дизайн. Ответ ясен и прозрачен — для пользователей. Но не стоит забывать, что процесс создания продукта, не важно, будь то приложение или сайт, подразумевает за собой создание кода для отображения твоего дизайна. Если смотреть с этой точки зрения и развернуто ответить на вопрос «Для кого мы делаем дизайн?», то получается, что мы делаем дизайн для того, чтобы передать его разработчику, а он в свою очередь воплощает задуманное тобой в жизнь.
Ты можешь работать в небольшой дизайн-студии, где нет разработчиков в штате. Или в продуктовой команде, где свой дизайн передаешь непосредственно разработчику. Но так или иначе, если хочешь классный результат, разговаривай на их «разработческом языке». Ты как мостик между идеей заказчика и реализацией.
Многие джун- и мидл-дизайнеры не знают базовых вещей в верстке. А потом получается, что в дизайне у кнопок нет hover/active/focus состояний, в мобильной версии в иконку не попадешь пальцем, потому что у иконки не показаны падинги, а блок с полупрозрачным бэкграундом сделан через opacity, а не через rgba. Если вышесказанное вызывает у тебя вопрос «Что ты, черт возьми, несешь?», то срочно изучай верстку. Это реально важно, потому что разраб зачастую сделает так, как ты нарисовал, а за визуальный результат отвечаешь ты, как перед заказчиками, так перед пользователями. Ты можешь знать всё, что я написал выше, потому что этому учат и без верстки, но поверь, пока сам не попробуешь на своей шкуре, всех тонкостей не узнаешь. Попробуй заверстать одну страницу сайта и ее мобильную версию — просто верстку, без прописывания логики скриптами, и ты всё поймешь.
Если я тебя не убедил, давай посмотрим под другим ракурсом с другой профессией. Должен ли преподаватель в школе обладать ораторским искусством? По сути, нет. Но если преподаватель высококвалифицированный, то, пожалуй, такой навык поможет донести любую информацию до учеников.
Теперь насколько глубоко погружаться в разработку. Здесь ответ кроется в том, какой ты дизайнер:
- Если ты граф-дизайнер, извини, что потратил твое время. Тебе не нужна верстка.
- Если ты дизайнер промостраниц, делаешь какие-то визуально крутые проекты а-ля «Беханс», то базовых знаний верстки и адаптивности под мобильные устройства достаточно, чтобы просто понимать состояния элементов интерфейса и принцип единообразия и повторяемости. Начнешь изучать глубже — может загнать тебя в рамки и будет не креатив, а четко «по линеечке», потому что разработка формирует перфекционизм, будешь постоянно думать, как твой креатив будут разрабатывать, что вот тут не по сетке, а тут не по базовой линии и т. д.
Пример из моей практики: участвовали с моей командой в тендере небезызвестной компании консервированных овощей, где «вот морковка ушла вперед, эстафету передает». Задачей было сделать редизайн главного сайта и описания продукции с упором на креатив. Мы подошли к задаче более серьезно, накреативили, но не стали забывать и о пользователях, загнали себя в рамки, что сайт еще разрабатывать нужно, и приглушили креатив в угоду пользователям. В итоге победила команда с вылетающими свистоперделками и горохом на весь экран.
Post #14
77
Post #13
85
Привет! Не знаю как ты сюда попал и кто ты, но добро пожаловать!
Меня зовут Роман. Я ведущий продуктовый дизайнер в МТС Диджитал 🥚. Специализируюсь на внутренних продуктах.
Этот блог не “лайфстайл”. Здесь не будет, что я ел сегодня на завтрак, куда ездил, какую красивую вывеску я увидел и это перевернуло мой дизайнерский мир.
Этот блог не “33 совета для дизайнеров”. Здесь не будет типовых тем и советов, как стать великим дизайнером. Все это ты можешь найти самостоятельно в группах и пабликах, которых и так бесконечное количество.
Этот блог не “сборник бесплатных PSD/FIG шаблонов, иконок, мокапов”. Вдохновиться всем этим добром ты можешь так же в соответствующих пабликах.
LIDS (Lorem ipsum dolor sitame…) - это мои заметки дизайнера и мои мысли из проф. области. Сюда пишу либо в том, в чем уже разбираюсь сам, либо я разобрался и законспектировал. Стараюсь писать с примерами из личной практики. Может мемчики/видосики поскидываю)))
Если еще не задушнил, подписывайся. Если задушнил, открой форточку и все равно подписывайся 😏
Меня зовут Роман. Я ведущий продуктовый дизайнер в МТС Диджитал 🥚. Специализируюсь на внутренних продуктах.
Этот блог не “лайфстайл”. Здесь не будет, что я ел сегодня на завтрак, куда ездил, какую красивую вывеску я увидел и это перевернуло мой дизайнерский мир.
Этот блог не “33 совета для дизайнеров”. Здесь не будет типовых тем и советов, как стать великим дизайнером. Все это ты можешь найти самостоятельно в группах и пабликах, которых и так бесконечное количество.
Этот блог не “сборник бесплатных PSD/FIG шаблонов, иконок, мокапов”. Вдохновиться всем этим добром ты можешь так же в соответствующих пабликах.
LIDS (Lorem ipsum dolor sitame…) - это мои заметки дизайнера и мои мысли из проф. области. Сюда пишу либо в том, в чем уже разбираюсь сам, либо я разобрался и законспектировал. Стараюсь писать с примерами из личной практики. Может мемчики/видосики поскидываю)))
Если еще не задушнил, подписывайся. Если задушнил, открой форточку и все равно подписывайся 😏
- 🤝 3
Channel photo updated
Channel name was changed to «LIDS / Lorem ipsum dolor sitame»
Channel created