Как создать сайт на Тинькофф бизнес видео

Конструктор сайтов от Тинькофф банка можно использовать бесплатно, как минимум до конца 2019 года.

Предприниматели и компании, у которых нет расчётного счёта в «Тинькофф банке», могут воспользоваться сервисом бесплатно только как физлицо.

Для использования сервиса конструктор сайтов от Тинькофф банка необходимо пройти регистрацию.

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

Есть два варианта создания страницы сайта: с использованием готовых шаблонов или набора готовых блоков.

Основные моменты видео «Конструктор сайтов от Тинькофф банка»:

0:28 Регистрация в сервисе

02:31 Настройки сайта

04:05 Используем готовый шаблон

08:15 Создаем страницу из отдельных блоков

Пример сайта созданного в конструктор сайтов для предпринимателей от «Тинькофф банк» http://haski.tb.ru

Вам также может понравиться

Как создать мини-сайт для инстаграм

Конструктор сайтов Тинькофф (ВИДЕО ОБЗОР 2023) / Как создать сайт

01.09.2019

Источник: sitebiznes.ru

Конструктор сайтов Тинькофф Видео Обзор / Плюсы и Минусы

В этом видео Вы увидите обзор на конструктор сайтов Тинькофф. Он сейчас достаточно актуален в России, так как популярный конструктор сайтов Wix ушел c российского рынка, и многие пользователи находятся в поиске альтернативы.

Если Вы тоже находитесь в таком поиске, то лучшем решением для Вас , по мнению нашей студии, будет предложение от самого крупного хостинг-провайдера в России, которое называется «Сайт без программирования за пару кликов» https://clck.ru/gh24m. Они предлагают несколько вариантов на выбор в зависимости от сложности и задач Вашего сайта.

Возвращаемся к конструктору сайтов Тинькофф. Для примера, мы создадим сайт на нем и оставим свой отзыв на него.

Обзор на конструктор сайтов Тинькофф / Вход и первый взгляд

Начнем с первого взгляда на панель управления. Входим в конструктор сайтов на официальном сайте Тинькофф. И видим несколько закладок.

Первая закладка «Сайты» — Тут будут отображаться созданные Вами сайты.

Далее «Товары» — это закладка понадобится тем, кто хочет сделать интернет-магазин из своего сайта. Здесь Вы добавляйте товары, которые потом отображаются на сайте.

Далее «Чат» — в этой закладке можно настроить работу чата для общения с посетителями сайта. Чат по умолчанию подключен ко всем сайтам Тинькофф.

Следующая закладка «Команда» — здесь можно дать доступ другим пользователем к редактированию сайта.

И последняя закладка «Диалоги» — здесь отображается переписка с посетителями сайта.

Создать сайт на конструкторе Тинькофф

Переходим к созданию сайта на конструкторе Тинькофф. В закладке «Сайты» нажимаем кнопку «Добавить сайт». Здесь нам предлагают выбрать шаблон. Сначала идет пустой шаблон, где из блоков можно собрать сайт. А так же есть готовые шаблоны, заточенные под разные популярные бизнесы.

Например, берете шаблон «строительство домов», редактируете его под себя: меняете фотографии на свои, редактируете контактную информацию. И сайт готов.

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

Кликаем на нужный нам блок и меняем в нем все под себя: цвет, фото, текст, указываем свои ссылки и так далее.

Сморите, что у нас получилось. Сайт содержит название нашей студии, где мы находимся, ссылку на наш основной сайт. Список наших основных услуг. У нас получилось вставить видео с Ютуба о том, как наша студия привлекает клиентов. А так же мы вставили ссылки на все наши социальные сети.

Мы довольны результатом. Этот сайт одинаково хорошо смотрится на компьютере и на смартфоне. А главное мы потратили на создание этого сайта не более одного часа. Ссылку на созданный сайт https://profitweb.tb.ru

Плюсы конструктора сайтов Тинькофф

Пришло время оставить свой отзыв на конструктор сайтов Тинькофф. К плюсам можно отнести следующие моменты:

• Простота и скорость создания сайта, причем без опыта и знаний языков программирования . Сайт собирается из блоков, которые легко настраиваются.
• Наличие готовых шаблонов, заточенных под популярные бизнесы — это плюс, который существенно упрощает и ускоряет процесс создания сайта.
• Наличие чата с посетителями сайта по умолчанию — это плюс. На других платформах его нужно отдельно устанавливать, а иногда даже дополнительно оплачивать эту услугу.
• С легкостью можно организовать прием оплаты на сайте и получать ее на счет в Тинькофф Бизнесе.
• Конструктор бесплатный. Нет ограничений на количество страниц сайта и карточек товаров. Ваш сайт будет размещен на бесплатном поддомене tb.ru и есть возможность бесплатно подключить свой домен. Это конечно же плюс, так как поисковые системы больше доверяют сайтам без поддоменов.

Сайт со своим доменом будет проще продвигать в поисковых системах. А покупать свой домен мы рекомендуем у самого крупного провайдера в России https://clck.ru/dueuT. А промокод F12F-A1CE-5C54-6F5C даст 5% скидку на регистрацию домена.

Минусы конструктора сайтов Тинькофф

Что касается минусов, то они стандартные для всех конструкторов сайтов.

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

Второй минус. Сайты, созданные на конструкторах, либо проблематично куда-то перенести, либо вообще невозможно. Получается, что вы привязаны к конструктору и зависите от него. А если с ним, что-то случится? Как например с конструктором сайтов Wix, который ушел из России, то вам придется делать новый сайт с нуля на другой платформе.

Резюме

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

Если у Вас остались вопросы, пишите их в комментариях. Если нужна услуга по продвижению бизнеса в Интернет, обращайтесь в нашу студию «Profit Web».

Источник: profitweb.ru

Как создают и поддерживают веб-страницы tinkoff.ru

Всем привет! Меня зовут Сергей Михайлов, в Тинькофф я работаю руководителем группы дизайна привлечения: занимаюсь внутренними сервисами, а также отвечаю за дизайн-составляющую Отдела привлечения клиента. Расскажу, как мы быстро собираем страницы с помощью нашего конструктора.

Как это работает сейчас

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

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

Страницы собираются из блоков в нашем Конструкторе.

Вот пример такого блока с карточками:

В него уже вшита логика с отступами, возможность выключить заголовок или изменить стиль кнопки. Также в блок уже вшита логика растягивания. На примере — блок для экрана 1024, а при разрешении 1360 блок растянется. Так у нас работают все блоки.

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

Мы тестируем много страниц и иногда для теста создаём новые блоки. Раньше создание нового блока занимало у команды разработки до 2 недель. При этом если тест не проходит, то от блока отказываемся.

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

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

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

Как было раньше

Вернемся на пять лет назад и посмотрим, как у нас был выстроен процесс создания страниц.

В 2016 году аналитики и разработчики задались вопросом: «У нас же большая часть страниц — продающие лендинги. Почему бы не сделать сервис, который обрабатывал бы все эти страницы?».

Тогда придумали систему, назовем ее версия 0. К сожалению, ее скриншоты не сохранились. Вся страница выглядела как один большой блок с формой. Даже такой подход всех устроил, его стали активно использовать и сделали админку с Конструктором версии 1.0.

У старой админки еще не было интерфейса, в котором можно было собирать лайв-превью страниц, не было превью блоков, но она уже обладала рядом функций, которые всех устраивали. Функционала становилось все больше, добавилась, например, возможность просматривать историю публикаций и изменений, появилась сложная настройка блоков. Админка превратилась в версию 2.0.

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

Сформулировали цели для новой админки:

• Уменьшить порог вхождения новых пользователей. Нам было важно, чтобы не только контент-менеджеры могли собирать страницы, но и дизайнеры, заказчики и менеджеры.
• Сделать понятный процесс сборки страниц, а процесс подготовки пользователя не занимал больше одного дня. Важно, что человек, более или менее знакомый с любым конструктором типа «Тильды», мог сразу же собирать страницы и в нашей админке.
• Сократить время выпуска новых страниц.

Собрали команду из аналитика, дизайнера, контент-менеджера и разработчика. У нас не было привычного флоу, когда дизайнеры и аналитики придумывают интерфейс и отдают разработчикам. Вместо этого мы с самого начала собирались всей командой, проводили дважды в неделю встречи, на которых составляли разные фреймворки, писали сценарии по User Story Mapping. То есть все участники процесса имели слово и вместе собирали админку.

Результатом стала админка версии 3.0.

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

Проблема с блоками

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

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

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

Какие у этого минусы::

• Затраты на разработку. Разные команды делают одно и то же.
• Много одинаковых блоков.
• Один и тот же блок выглядит по-разному на разных страницах, из-за этого у нас нет консистентности.

Тогда мы приняли решение создать команду для разработки и поддержки блоков, которая экономила бы нам ресурсы и отвечала за то, чтобы новые блоки могли использовать все. Например, если команда инвестиций прибегает и говорит: «Нам нужен блок», то команда админки уже делает так, чтобы этот блок могли использовать и другие команды, а также следит за тем, чтобы лишних блоков не было, а в новых учитывались дополнительные кейсы.

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

Проблема с процессом сборки страниц

Из-за того, что админка настолько всем «зашла», все хотели ею пользоваться, но у нас не было унифицированного флоу, по которому бы все работали. Появилось много новых пользователей, которые сами придумали себе процесс работы.

Давайте посмотрим на средний состав участников процесса создания страниц:

• Заказчик — человек, которому нужна страница, чаще всего это product owner.
• Копирайтер — пишет текстовый прототип страницы.
• Дизайнер — собирает макет.
• Разработчики — подключаются, когда нужна разработка нового блока.
• Контент-менеджеры — все еще специалисты нашей админки, которые настраивают сложные блоки (футер, шапку, формы с различными шагами).
• Аналитики — вносят свои настройки в страницу.

Например, заказчик мог пойти в админку, собрать и опубликовать страницу. Либо он мог отдать задачу на создание текстового прототипа копирайтеру. Копирайтер все это передает контент-менеджеру, а контент-менеджер в админке собирает страницу. Либо заказчик ставит задачу дизайнеру, дизайнер в Figma собирает макет, контент-менеджер по макету из Figma собирает в админке страницу. Таких процессов у нас было очень много, но усредненно процесс выглядел так:

Заказчик ставит задачу копирайтеру, копирайтер отдает текстовый прототип дизайнеру, дизайнер собирает в Figma макет, контент-менеджер по figma-макету собирает в админке страницу, все ребята его согласовывают. Если нужен блок, ставят задачу разработчикам и затем передают аналитику для окончательной настройки, после чего страница запускается.

Минусы такого подхода:

• Планирование времени участниками. Случались ситуации, когда новый участник процесса узнавал о задаче за неделю до выпуска.
• Блоки в макетах не соответствуют реальности. Помимо сторибука, где хранятся все наши блоки, эти же блоки есть и в Figma, откуда их берут дизайнеры. Бывало так, что дизайнер собирая страницу может добавить новый элемент в блок, не зная, как он на самом деле работает. Впоследствии, когда контент-менеджер начинал собирать страницу по figma-макетам, ставил блок из админки и понимал, что блок так не работает. В итоге много времени уходило на разбирательство, как поступить в этой ситуации.
• Новый блок для страницы ждем долго. Как я упомянул выше, мы очень поздно предупреждали разработчиков о том, что нам нужен новый блок. Разработчики не успевали его подготовить либо, очень злясь на нас, были вынуждены готовить его быстро, но говорили, что это в последний раз.
• Нет консистентности. Разные участники собирают страницы, шаблонов нет, многое каждый делает по-своему — из-за этого страницы могут выглядеть по-разному.
• Нет понимания зон ответственности и результатов работы.
• Увеличивается срок выпуска страниц.

Решение

Столкнувшись с вышеописанными проблемами, мы решили:

• Описать правильный и понятный процесс выпуска страниц, потому что у ребят уже были свои чек-листы, гайды и так далее.
• Описать зоны ответственности. Собрать все вместе и превратить в нормальный процесс.
• Дизайнеры собирают страницы в Конструкторе. Перевести всех дизайнеров со сборки страниц в Figma в наш Конструктор, чтобы они понимали, как работают блоки, и из них составляли страницы.
• Все команды подключаются на старте.

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

Копирайтер может использовать артефакты: он может пойти в сторибук, посмотреть, как работают блоки, если ему так проще составлять прототип; может пойти в Figma либо в Конструктор. Результатом его работы будет текстовый прототип (на самом деле не только текстовый — прототип может быть собран в PDF или в Figma, и это будет результатом работы).

Затем этот прототип передается дизайнеру. Дизайнер может по-прежнему использовать сторибук, Figma, гайд по сборке страниц, который у нас есть, но все равно результатом его работы будет ссылка на десктопную и мобильную версии страницы.

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

Как создают новые блоки?

Дизайнер рисует мобильную версию страницы и в процессе понимает, что ему нужен блок (карточка с иконкой), которого у нас еще нет. Согласно процессу, он идет в команду дизайна и говорит: «Нам нужен новый блок». Ребята понимают, что это многофункциональный блок, который может понадобиться всем, его можно встраивать и на другие страницы. Тогда задача передается в команду админки, у которой есть два варианта:

1. Команда админки видит, что есть похожий блок, но без иконки — это просто текстовая карточка со своим набором полей. Они решают дополнить эту карточку иконкой и добавить новые настройки. После миграции все могут использовать этот блок и нет необходимости создавать и поддерживать новый.
2. Нужного блока нет, и похожего тоже нет. Тогда дизайнер идет в Figma и там собирает макет для разработчиков, отрисовывает все состояния и, когда макет собран, он передается в команду админки, которая создает схемы и UI блока. То есть команда админки решает, какие опции должны быть в настройках карточки. Команда блоков верстает и тестирует этот блок.

При разработке блоков используют инструмент Multistory, который разработала команда блоков.

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

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

Для отслеживания поведения блоков команда блоков разработала инструмент RealStory. Например, есть карточка с картинкой (заголовком, кнопкой), и мы можем в реальном времени посмотреть, на каких страницах сейчас эта карточка присутствует и как она выглядит. Это позволяет дизайнерам и разработчикам отслеживать поведение блока: как он работает и нет ли в нем ошибок.

Вернемся к процессу

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

Если, например, контент-менеджер не настроил аналитику сам, то задача аналитика — настроить эти блоки: какие блоки надо трекать, настройки шеринга либо настройки оптимизации и персонализации. После задача попадает обратно в эпик.

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

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

Что будет дальше?

Во-первых, из-за того, что у нас много команд и они большие, нельзя просто взять и сказать: «Теперь вы будете делать так, как мы решили». Конечно, так нас просто пошлют. Для начала мы решили протестировать на небольших процессах, на сборке шаблонных страниц, и процесс начал себя показывать достаточно хорошо. Конечно, есть нерешенные проблемы (например, на какой стадии подключать команды), но процесс двигается хорошо. Более того, команда блоков уже работает по новому процессу, и это экономит много ресурсов и времени.

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

• Блог компании TINKOFF
• Веб-дизайн
• Разработка веб-сайтов
• Интерфейсы
• Монетизация веб-сервисов

Источник: habr.com