Договор о разработке шаблонов дизайна пользовательского интерфейса

Договор о разработке шаблонов дизайна пользовательского интерфейса

Юристы сайта Правовед.ru составят договор о разработке шаблонов дизайна пользовательского интерфейса в полном соответствии с нормами закона. Вы можете ознакомиться с образцом договора о разработке шаблонов дизайна пользовательского интерфейса бесплатно.

Посмотрите пример
документа перед обращением к юристам сайта!

3 Выберите юриста

Выберите юриста, который
предложит самые выгодные
условия, и начните работу!

2 Получите предложения

Заинтересованные юристы
в течение 10-15 минут предложат
вам свои услуги и назовут цены.

1 Заполните заявку

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

• Строительство индивидуального жилого дома
• Строительного подряда с физическим лицом
• Между юридическим и физическим лицом
• Договор подряда на выполнение работ
• Проектных работ
• Передачу научно-технической продукции
• Банковской гарантии по договору подряда
• Типовой договор подряда
• Производство проектных и изыскательных работ
• Субподряда на выполнение отдельных видов и комплексов работ
• По строительству
• Договор на выполнение работ
• Строительно-отделочные работы
• Капитальное строительство
• Строительство жилого дома
• Подрядных работ
• Пошив костюма
• И услуг с передачей оборудования по акту сдачи-приемки
• С временным трудовым (творческим) коллективом
• По проведению комплекса мероприятий для продвижения услуг веб-сервера заказчика в сети интернет
• С передачей оборудования для выполнения обязательств по договору безвозмездного пользования
• Строительного подряда подрядчика с субподрядчиком
• По устройству кровли
• Проведение ремонтно-отделочных работ
• Проектных работ и оказания услуг по техническому сопровождению согласования проектной документации
• Изготовление и доставку деревянного сруба
• Изготовление доставка и монтаж комплекта дачного дома
• Строительство фундамента
• По изготовлению пластиковых карт
• По бурению скважин для воды
• Ремонт отмосток жилого дома
• Бытового подряда с использованием материалов заказчика
• Уборка места захоронения
• Монтаж пвх окон
• Разработку сайта
• Изготовление типового сайта
• Устройство фундамента для индивидуального жилого дома
• По производству конструкций и выполнение работ

• Строительного подряда из материалов подрядчика
• По дезинфекции, дезинсекции, дератизации
• Разработка программных средств учебного назначения
• Ремонт квартиры
• Проведение работ по устройству фасада жилого дома
• Производство и установка пластиковых окон
• По шеф-монтажу и пуско-наладке оборудования
• Ремонт офисных помещений
• Изготовления столешницы из искусственного камня
• По расчету свайного поля и монтажу свайно-винтового фундамента в соответствии со сметой
• Инвестирования
• Ремонтно-строительные работы
• Авторского надзора
• Строительство дома из бруса
• По организации строительства сетей инженерно-технического обеспечения для подключения к системе теплоснабжения строительных объектов
• Ландшафтные работы
• Капитальный ремонт тепловых сетей
• Предварительный договор инвестирования строительства жилого дома
• Субподряда на строительство жилых домов
• Строительство объекта
• Производство ремонтно-строительных работ офисных помещений
• О долевом участии в строительстве жилого дома с обязательным страхованием риска ответственности
• Контракт на подряд
• Строительного подряда для работы по капитальному ремонту
• С оплатой по частям
• Без права заказчика отказаться от исполнения договора в любое время
• С твердой сметой, с условием о предоставлении материалов подрядчиком и заказчиком, контроль за расходованием материалов
• С использованием материалов заказчика, заказчик не имеет права отказаться от принятия работ
• Изготовление и установка пвх-профилей
• Субподрядных работ, заключаемый между генеральным подрядчиком и субподрядчиком
• Проектно-изысканных работ по землеустройству (внутрихозяйственное землеустройство)
• Бытового подряда с использованием материалов подрядчика
• По производству продукции
• Временным творческим коллективом
• Выполнение работ с использованием материала заказчика
• Иждивением подрядчика
• Разработка и обслуживание веб-сайта

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

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

Договор на разработку мобильного приложения

Зачем нужен договор

У любого договора есть две функции — коммуникативная и юридическая. Коммуникативная помогает убедиться в том, что стороны правильно поняли друг друга. Они обсуждают условия работы, приходят к согласию и фиксируют эти договорённости на бумаге.

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

В чём особенность договора на разработку мобильного приложения

Разработка приложения — длительный и сложный процесс, на который влияет множество факторов как со стороны заказчика, так и со стороны исполнителя. Прописать все нюансы и учесть все риски в техническом задании невозможно. В ходе разработки появляются новые идеи, которые нужно учесть, меняются условия использования дополнительных сервисов, возникают технические проблемы, наступают кризисы. Это приводит к срывам сроков и изменению общей стоимости проекта.

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

Структура договора на разработку мобильного приложения

Договор на разработку мобильного приложения комбинирует два типа договоров — на оказание услуг (исполнитель работает над приложением) и на передачу права интеллектуальной собственности (заказчик получает результат чужого интеллектуального труда). Он состоит из десяти пунктов:

1. Предмет и основные условия. Что? Для кого? За сколько? В этом пункте договоритесь об обязательствах сторон, этапах работы, о процессе оплаты и об электронной подписи.

2. Расчёты. В этом пункте — про условия оплаты. Облагается ли она налогами? Когда считается завершённой? Нужно ли отправлять бумажную версию отсканированного счёта? Ответы должны устраивать обе стороны.

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

4. Передача интеллектуальной собственности. Благодаря этому пункту, заказчик получает исключительные права на всё, что было сделано в рамках проекта. Договоритесь о том, в какой момент передаются права.

В отдельном подпункте укажите, что в разработке используются результаты интеллектуального труда третьих лиц. Готовые наработки — библиотеки, тексты, иконки, иллюстрации, программные коды — делают разработку быстрее и дешевле. Часто они находятся в свободном доступе и не требуют дополнительного соглашения. Но их использование может сопровождаться условиями, которые важно учитывать. Не все готовые решения можно применять в коммерческом закрытом ПО.

Пример. Вы разрабатываете мобильный мессенджер с платной подпиской. Чтобы сэкономить время, вы используете модифицированный код Telegram, который находится в открытом доступе. Согласно его условиям распространения, вы должны открыть финальный код своего приложения для всех.

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

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

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

8. Действие и расторжение. Про сроки действия договора, возможность его продления и расторжение. В пункте говорится, что о пожелании расторгнуть договор нужно предупредить за месяц, и описывается порядок досрочного расторжения.

9. Иные условия. В пункте — стандартные вещи про документооборот: договор действует на основании ГК РФ, а дополнительные соглашения являются его неотъемлемой частью.

10. Реквизиты. Здесь указываются актуальные данные заказчика и исполнителя: адреса, налоговые идентификаторы, номера счетов, ставится дата и подпись.

Готовый договор от «Лайв Тайпинг»: скачайте и начните разработку сейчас

Компания «Лайв Тайпинг» не любит бюрократию, но любит делать свою работу хорошо. Нам важно, чтобы сотрудничество было в кайф обеим сторонам. Поэтому начинать каждую сделку мы решили с понятного и прозрачного договора, который защищает обе стороны от рисков. Мы разработали шаблон договора вместе со специалистами Центра Управления Законом — они делают документы без воды и мусора. Наш шаблон написан человеческим языком, который понимают . Он максимально короткий — 4 страницы, и в них нет места для двусмысленности и заковыристых конструкций.

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

Чтобы получить готовый договор, вам нужно:

1. Скачать шаблон договора на разработку мобильного приложения.
2. Выбрать дополнительное соглашение, которое подходит для вашего типа сотрудничества.
3. Заполнить допсоглашение конкретными деталями по вашему проекту (техническое задание, , текстовое описание проекта, смета, ).
4. Заменить данные в желтых полях на реальные данные заказчика и исполнителя.
5. Согласовать договор с партнёром.

Какое дополнительное соглашение выбрать

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

1. Fixed price. Заказчик покупает законченный продукт или его часть. Например: создание кликабельного прототипа приложения, разработку дизайна мобильного приложения или разработку приложения под iOS целиком с нуля. Это доспоглашение описывает этапы работы с фиксированными ценой и сроками. Вариант Fixed price подходит для работы над простыми проектами с понятной функциональностью, чётко прописанной в ТЗ. Выход за рамки ТЗ с сохранением прежних сроков и стоимости работы невозможен. Если заказчик хочет на лету менять требования и не зависеть от ТЗ, то лучше выбрать более свободную модель оплаты.

2. Time&Materials. Заказчик платит за время специалистов, потраченное на работу над его проектом. Круг задач и стоимость часа работы оговариваются в допсоглашении. Например, клиенту нужно создать приложение для iOS. Для этого нужны менеджер проекта, дизайнер, разработчик и тестировщик. В течение месяца эти специалисты трудятся на проекте, а в конце месяца клиент получает отчёт о количестве затраченных часов и оплачивает их. Этот вид сотрудничества хорош тем, что клиент гораздо быстрее видит результат и может вносить изменения в процессе. Этот вариант подходит для долгосрочных проектов.

Лучше разобраться в тонкостях Fixed price и Time&Materials вам поможет наша статья.

3. Time&Materials period (он же Retainer). Данная практика пришла в ИТ из юридического бизнеса. Заказчик «оптом» выкупает всю команду, нужную для ведения проекта, на долгий срок. Период, состав команды и цена фиксируются в допсоглашении. Оплата и приём работ происходят раз в месяц/неделю. Это самый эффективный вариант работы над проектом, потому что в нём не нужно бесконечно подписывать документы, скрупулёзно считать часы и согласовывать каждый шаг. В начале периода заказчик и разработчик составляют план работ, в конце — подводят итог и фиксируют результаты, подписывая акт, который передаёт клиенту права на сделанные работы. Одновременно он является актом приёмки этих работ. Способ подходит для сложных и долгосрочных проектов, на которых важна полная вовлечённость всех участников команды.

Максимально подробно договоритесь о всех условиях до начала разработки приложения. Убедитесь, что договор защищает вас и покрывает возможные риски, чтобы не возвращаться к нему в дальнейшем. Юридическая безопасность и доверие между сторонами сделают работу над приложением быстрой и спокойной. Кстати, у «Лайв Тайпинга» за 10 лет работы не было ни одного суда. Хотите разработать ваше мобильное приложение без нервов и юридических споров? Заполняйте нашу контактную форму или звоните .

Договор о разработке шаблонов дизайна пользовательского интерфейса

Людям, не искушенным в документообороте, этот текст может показаться довольно запутанным. А тем, для кого оформление контрактов — рутина, наоборот, слишком простым. Но нас часто спрашивают, как у нас организована работа по scrum с точки зрения документооборота, и как выглядят наши договоры.

Даже если вам покажется, что получается слишком много бумаг, или всё слишком сложно — это не так. Мы используем простые и понятные контракты, в которых проработаны интересы как клиента, так и студии. Адекватно. Без перегибов. На уровне здравого смысла. Моя политика простая — либо win-win, либо не связываться.

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

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

Свои шаблоны мы постепенно меняли с учетом изменений в законодательстве и новых подводных камней, на которые натыкались. Не переписывали полностью, но добавляли «заплатки». В итоге они стали громоздкими и неудобными. Поэтому в этом году мы решили сделать рефакторинг, навести порядок в шаблонах документов и практически полностью их переработали (@ПавелМищенко, спасибо).

Павел рекомендует подписаться на его канал, так что не стесняйтесь и жмакайте тут.

Мы сделали документы максимально простыми для работы (в смысле, с ними менеджерам становится сложно сделать грубую ошибку при подготовке документов). Все, что касается общих условий сотрудничества, вынесли в рамочный договор. Убрали дублирование положений. В приложениях остались только моменты, касающиеся непосредственно этапов работ. Спринтов. В конце статьи мы поделимся ссылками на шаблоны рамочного договора и некоторых приложений.

Поймали забавную реакцию на новые шаблоны наших документов от одного заказчика: он внес правки в договор, добавив в наш новый шаблон формулировки из НАШЕГО СТАРОГО шаблона.

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

Подготовка договоров и приложений

В начале работы над проектом вместе с рамочный договором мы подписываем приложение на агрегацию требований.

Мы исходим из предпосылки, что ни клиент, ни мы сами точно не знаем, как и в каком виде лучше всего сделать проект. И нужно выполнить предпроектную работу:

выделить стейкхолдеров, составить цели проекта, если возможно — оцифровать в виде KPI;

изучить пути пользователей по сайту;

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

Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах К тому же только после этапа агрегации требований у нас появляется согласованная структура, верхнеуровневый roadmap будущего проекта: мы можем уточнить список страниц, которые необходимо прототипировать.

Вторым этапом мы подписываем приложение на разработку прототипов страниц, и, если этого просит клиент, — технического задания. В классическом scrum-е технического задания не предполагается, вместо него используется бэклог — список всех хотелок, которые клиент хочет когда-нибудь реализовать. Однако многие по старинке хотели бы иметь такой документ. Проблем нет, мы его готовим, причем именно с той целью, чтобы затем раздербанить на бэклог. Наличие технического задания на проекте не заставляет нас строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.

Далее нам нужно собрать первую версию программного продукта. От которой будем дальше плясать и итеративно развивать во что-то более глобальное. Замечу, что первая версия должна быть функциональной. Она должна быть «клёвенькая», а не полуфабрикат, на который жалко смотреть. Тут — работает, тут — не работает, тут — рыбу заворачивали. Такая версия может быть разработана за несколько спринтов. То есть не факт, что итог первого же спринта пойдет реальным пользователям на боевой сервер. Это несколько противоречит концепции scrum образца года, но лучше вписывается в современные подходы и адекватнее воспринимается разработчиками и заказчиками.

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

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

В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.

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

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

Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:

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

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

Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.

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

В приложении к статье — джентльменский набор документов. Рамочный договор. Приложение на аналитику (агрегацию требований). И комплексное приложение на одну итерацию разработки. Остальные приложения (кроме, пожалуй, техподдержки и работы по канбану) логично вытекают из этих документов (да и нам просто жадно). Шутка.

Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем курсе управления digital-проектами. Присоединяйтесь!

Договор авторского заказа с дизайнером

Тип документа: Защита авторских прав

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

Размер файла документа: 15,2 кб

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

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

Существенные условия договора

Чтобы такой договор надежно защищал интересы всех сторон, важно учесть в нем основные требования, касающиеся:

• конкретных прав, передаваемых по договору;
• порядка установления и размера вознаграждения;
• сроков и территории передачи указанного права.

Можно предусмотреть в договоре права на распространение, публичный показ и многое другое использование дизайнерской продукции, как исключительные, так и неисключительные.

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

Установление вознаграждения

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

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

Бланк договора авторского заказа с дизайнером

Образец договора авторского заказа с дизайнером (заполненный бланк)

Скачать Договор авторского заказа с дизайнером

Договор авторского заказа с дизайнером №

1. ПРЕДМЕТ ДОГОВОРА

1.1. Исполнитель обязуется оформлять серию изображений « » (далее – «Произведения») согласно заданиям Заказчика и передать Заказчику исключительные авторские права на использование Произведений в обусловленных настоящим договором пределах и на определенный договором срок, а Заказчик обязуется уплачивать Исполнителю вознаграждение. Под использованием в настоящем договоре понимается реализация произведения в качестве товара или иное его использование в гражданском обороте в пределах, предусмотренных договором.

2. ПРАВА И ОБЯЗАННОСТИ СТОРОН

2.1. Исполнитель обязуется создавать произведения в соответствии с Заданиями Заказчика, форма которых установлена в Приложении № , являющемся неотъемлемой частью настоящего договора.Задания составляются в двух экземплярах, по одному для каждой из сторон, и подписываются обеими сторонами.

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

2.3. Исполнитель обязуется создавать произведения своими силами и средствами и гарантирует наличие у него авторских прав на произведения. Сроки создания произведения предусматриваются в задании.

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

2.5. С окончательного варианта произведения снимается три копии, которые передаются Заказчику. На одной из копий проставляются отметки о сдаче произведения Исполнителем и принятии его Заказчиком, подписи сторон, а также дата приемки. Произведение считается принятым с момента подписания копии произведения сторонами. Заказчику передаются права только на то произведение, которое было принято по вышеуказанной форме.

2.6. Договор на передачу исключительных авторских прав на произведение считается заключенным с момента подписания сторонами задания на создание соответствующего произведения. Договор считается заключенным на условиях задания и настоящего договора.

2.7. Исполнитель предоставляет Заказчику следующие исключительные права на создаваемые произведения:

• право на воспроизведение произведения (дублирование, тиражирование или иное размножение, т. е. неоднократное придание объективной формы, допускающей его функциональное использование) без ограничения тиража;
• право на распространение экземпляров произведения любым способом;
• право на обнародование произведения, т. е. на сообщение произведения в какой-либо иной форме или каким-либо способом неопределенному кругу лиц;
• право на публичное использование произведения и демонстрацию в информационных, рекламных и прочих целях;
• право импортировать экземпляры произведения в целях распространения;
• право использовать произведение под фирменным наименованием, производственной маркой и товарным знаком Заказчика;
• право переделывать произведение, использовать его в качестве основы для создания иных изображений и иным образом перерабатывать произведение (право на переработку).
• право переуступить на договорных условиях полученные по настоящему договору права третьим лицам.

2.8. Размер вознаграждения Исполнителю за создаваемое произведение и передачу прав на него предусматривается в задании.

2.9. Договор на передачу исключительных авторских прав заключается на срок действия авторского права на создаваемое произведение.

2.10. Действие передаваемых исключительных авторских прав не ограничивается территориальными пределами.

2.11. Исполнитель не сохраняет за собой право использовать произведение самостоятельно или предоставлять аналогичные права на его использование третьим лицам.

3. ОТВЕТСТВЕННОСТЬ СТОРОН

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

3.2. В случае нарушения договора сторона, чье право нарушено, вправе также потребовать признания права, восстановления положения, существовавшего до нарушения права, и прекращения действий, нарушающих право или создающих угрозу его нарушения.

3.3. В случаях, не предусмотренных договором, имущественная ответственность определяется в соответствии с действующим законодательством РФ.

4. КОНФИДЕНЦИАЛЬНОСТЬ

4.1. Условия настоящего договора и заданий конфиденциальны и не подлежат разглашению.

5. РАЗРЕШЕНИЕ СПОРОВ

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

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

6. СРОК ДЕЙСТВИЯ ДОГОВОРА

6.1. Настоящий договор вступает в силу с момента заключения и действует в течение лет.

7. РАСТОРЖЕНИЕ ДОГОВОРА

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

8. ЗАКЛЮЧИТЕЛЬНЫЕ ПОЛОЖЕНИЯ

8.1. Во всем остальном, что не предусмотрено договором, стороны руководствуются действующим законодательством Российской Федерации.

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

8.3. Все уведомления и сообщения должны направляться в письменной форме.

8.4. Договор составлен в двух экземплярах, из которых один находится у Исполнителя, второй – у Заказчика.

Этапы разработки пользовательского интерфейса: как сделать так, чтобы UI не лишил вас прибыли

В ноябре 2018 года студия «Лайв Тайпинг» рассказывала читателям vc.ru, из чего складывается стоимость мобильного приложения. Эта статья посвящена одному из слагаемых: пользовательскому интерфейсу.

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

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

Доказывать важность дизайна как магнита для пользователей удобно на примере соцсетей с миллионами пользователей. Резонансным случаем в рунете стал редизайн «Кинопоиска». 96% негативных отзывов на него говорят сами за себя: владельцы сайта, компания «Яндекс», сделала это без оглядки на мнение пользователей.

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

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

Редизайн «Живого журнала» в 2014 году тоже не впечатлял. Его хорошенько почистили от лишних элементов, но в целом он не вызвал восторгов: типографика, модульная сетка, адаптив — всё выглядело сырым и неудобным.

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

Итак, разберём особенности разработки пользовательского интерфейса пошагово.

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

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

Ответить на большую часть этих вопросов поможет составление портрета целевой аудитории (ЦА) — тех самых людей, для которых делается продукт.

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

• Коридорный метод. Обратная связь поступает от родных, друзей и коллег дизайнеров. Собрать её легко, но этого недостаточно.
• Разговор с вами. Справедливо предполагается, что вы как никто знаете, что нужно вашей аудитории.
• Полевые исследования. В рамках метода дизайнеры идут в народ: общаются с людьми напрямую, если делают продукт для местного рынка, или читают форумы, если для зарубежного;
• Проблемное интервью. Задавая пользователям вопросы про их жизнь и место проблемы в ней, дизайнеры узнают, как эта проблема решается сейчас и насколько полезным окажется их продукт. То, что он может оказаться бесполезным — тоже ценный результат: не придётся тратить деньги на приложение, которым никто не будет пользоваться.

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

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

Такая персона становится центром user story, или пользовательской истории. Это краткий, в несколько строк, рассказ про персону и то, как она работает с функциональностью приложения и какой цели достигает. User story строится по шаблону:

Поместив нашего 23-летнего фаната оригинальных версий в этот шаблон, получим:

Компания Intercom славится не только комплексным решением по внедрению чатов в сайты и мобильные приложения, но и изобретением подхода Jobs To Be Done. В основе подхода лежит не личное качество ключевой персоны, а обстоятельства и мотивация, которые толкают персону пользоваться продуктом. «Размышления» персоны называются Job story, а шаблон выглядит так:

«Когда , я хочу »

Ситуация с кинолюбом в рамках такого подхода выглядит иначе:

Подробнее про подход Jobs To Be Done написала в своём блоге платформа Tilda.

От User story и Job story мы переходим к User scenario. Это маршрут взаимодействия пользователя с продуктом и достижения цели.

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

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

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

Будет ли вайрфрейм грубым наброском, который вы сделали с коллегами ручкой на бумаге для принтера, или созданной в графическом редакторе организованной картой экранов — решать вам. Единственное: готовьтесь объяснить клиенту, что визуально вайрфрейм не имеет отношения к финальному продукту.

Пользуясь терминами электротехнического черчения, все кнопки, тексты, медиафайлы и прочие элементы заменены в вайрфрейме на условно-графические обозначения. Это ещё не интерфейс, но уже что-то близкое — как ёлка, которая станет новогодним деревом, когда её нарядят.

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

Для презентации прототипа мало показать экраны. Нужно показать, к чему и куда приводит взаимодействие будущего пользователя с элементами интерфейса. Связав элементы линиями с другими экранами, на которые попадёт пользователь, вы получите пользовательские сценарии использования приложения, или user flow.

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

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

В качестве софта для этой задачи мы используем Overflow, чей слоган «User flows done right» даёт понять, что время за этой работой пройдёт продуктивно и с пользой. В Overflow легко импортируются экраны из Sketch или Figma, а сделать flow для 100 экранов можно за час — гораздо быстрее, чем рисовать стрелочки самому.

Нужен дополнительный уровень понимания, как продукт будет работать? С помощью таких сервисов, как Marvel, InVision, POP App и Origami Studio детализированный прототип можно превратить в интерактивный. Его польза в том, что он даёт прокликать (а в случае, если у нас мобильное приложение — прокликать прямо в телефоне) все элементы интерфейса и оценить логику работы продукта до того, как он попадёт в руки конечного пользователя.

Его создание — этап необязательный, так как с презентацией будущей работы справляются макеты и user flow. Но когда нужно показать возможности мобильного приложения и раскрыть перед клиентом предстоящий объём работ в деталях, используйте его.

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

Резюмируем: вы получаете детальный прототип, его кликабельную версию (опционально) и карту экранов. Они соответствуют выработанным и согласованным в рамках этого этапа гипотезам продукта.

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

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

Разработчики получают от дизайнеров прототип и user flow, чтобы максимально точно оценить этап разработки и ориентироваться в логике продукта. Затем на будущий продукт начинают накатывать стиль.

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

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

Уважающий дисциплину дизайнер уже давно оценил прелести работы в Sketch — ведь здесь так удобно вести макеты для iOS и Android в отдельных файлах, превращать в легко читаемые символы повторяющиеся элементы интерфейса, заранее присваивать таким элементам стили и отступы от краёв экрана и делать много чего ещё. Всё это складывается в дизайн-систему.

Как и в случае прототипа, готовый дизайн согласовывается с клиентом. Когда всех всё устраивает, дизайн готовится для передачи разработчикам. Сколько времени и сил можно сэкономить, сделав это грамотно посредством Zeplin (спойлер: очень много), можно узнать из нашей статьи.

Пользоваться продуктом в первую очередь будут простые люди, а не его создатели. Будучи людьми простыми, во время работы с продуктом они прогонят его через фильтр из трёх вопросов: «Что делать?», «Куда идти?» и «Куда нажимать?». Если вы серьёзно отнесётесь к этапам работы над интерфейсом, ваши пользователи получат ясный ответ на эти вопросы и останутся довольны продуктом.

Это вопрос о том, насколько пользователю понятна основная функция продукта. Обозначить её нужно на этапе проектирования — тогда же, когда определяется целевая аудитория.

Путь к цели лежит через взаимодействие пользователя с интерфейсом. Кнопка за кнопкой, поле ввода за полем ввода, экран за экраном — и так до заветной покупки или публикации поста. Грамотно составленный user scenario, отрепетированный на прототипе, уберёт с этого пути все ухабы.

Кнопка с целевым действием отличается от остальных элементов на экране. Чем подчеркнуть отличие — цветом, размером или формой — решать дизайнеру на этапе дизайна.

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

Желаю вам делать хорошие пользовательские интерфейсы и не делать плохие. Если у вас возникли вопросы к нашему процессу или вы хотите поделиться своим подходом к разработке интерфейса — добро пожаловать в комментарии.

Разработка приложения Microsoft Teams с помощью шаблонов пользовательского интерфейса

Быстрее Microsoft Teams приложение с помощью шаблонов пользовательского интерфейса. Шаблоны — это коллекция компонентов на основе пользовательского интерфейса fluent, которые работают в общих Teams случаях использования, что дает вам больше времени, чтобы выяснить, как лучше работать с пользователями.

Начало работы с инструментами и примерами

Следующие ресурсы помогут вам разработать и разработать приложение с помощью шаблонов пользовательского интерфейса.

Комплект разработчика для пользовательского интерфейса Microsoft Teams

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

Microsoft Teams Библиотека пользовательского интерфейса

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

Импорт этих шаблонов и связанных компонентов непосредственно в проект Teams приложения.

Пример приложения

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

Информационная панель

Панель мониторинга отображает различные типы контента в центре расположения (Teams личного приложения или вкладки). Пользователи должны иметь возможность настраивать хотя бы некоторые из того, что они видят на панели мониторинга.

Верхние случаи использования

• Анализ данных
• Показатели отчета
• Организация различных сведений в одном месте

• Desktop
• Мобильные устройства

Визуализация данных

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

Верхние случаи использования

• Отображение сложной информации
• Создание панели мониторинга

• Desktop
• Мобильные устройства

Пустое состояние

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

Верхние случаи использования

• Вход
• Приветствие сообщений и первый запуск
• Сообщения об успехе
• Сообщения об ошибках

• Desktop
• Мобильные устройства

Filter

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

Верхние случаи использования

Организация контента в:

• Списки
• Таблицы
• Панели мониторинга
• Визуализация данных

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

Верхние случаи использования

• Вход
• Профили пользователей
• Параметры
• Коллекция входных данных пользователей

• Desktop
• Мобильные устройства

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

Верхние случаи использования

• Отображение данных
• Контекстные действия в контенте приложения

• Desktop
• Мобильные устройства

Вы можете создать потоки регистрации приложений для различных Teams контекстов и поставщиков удостоверений. В следующем примере содержится один вход (SSO), который мы рекомендуем для простейшей проверки подлинности.

Пример верхнего использования

• Проверка подлинности пользователей

• Desktop
• Мобильные устройства

Параметры

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

Пример верхнего использования

• Управление функциями приложения

Доска задач

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

Верхние случаи использования

• управление проектами; Назначение задач и состояние отслеживания
• Мозговой штурм. Добавление идей в различных категориях
• Упражнения сортировки. Организация любых сведений в ведра

• Desktop
• Мобильные устройства

Мастер

Мастер направляет пользователя на несколько экранов для выполнения задачи (например, процесса настройки).