> For the complete documentation index, see [llms.txt](https://shultse.gitbook.io/eva-konspektit/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shultse.gitbook.io/eva-konspektit/pristegnite-ramki-puteshestvie-po-processam-dizain-proekta.md).

# Пристегните рамки: путешествие по процессам дизайн-проекта

лекция в рамках встречи Dprofile & Черноголовка

## Александр Сучков

<div align="left"><figure><img src="https://148914548-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtJZqufpHNmVheNi3EM5o%2Fuploads%2FJgyPnzcEhHoFS05olxR7%2F%D1%84%D0%B4%D1%83%D1%87%D1%84%D1%82%D0%B2%D1%83%D1%87.png?alt=media&amp;token=c2763310-7897-4f02-90f0-7d92a2054b8b" alt="" width="160"><figcaption></figcaption></figure></div>

Арт-директор студии и онлайн-школы дизайна Perasperadastra&#x20;

{% embed url="<https://t.me/perasperagram>" %}

Здесь можно познакомиться с [самим кейсом](https://dprofile.ru/case/99976/10-let-pobed-promo-sait-dlia-aviakompanii-pobeda) и [сайт победы](https://10.flypobeda.ru).

### Ошибок нельзя избежать. Но их можно сделать не такими болезненными. И эта мысль должна вас успокаивать.

## Брифинг

**Задача.** Какую проблему нужно решить? Как ее решение повлияет на бизнес?&#x20;

**Решение.** Как вы хотите решить эту проблему? Какой вы ожидаете идеальный результат?

**Срок.** Когда проект должен быть готов? Какие контрольные точки?

**Ограничение.** Какие обстоятельства влияют на работу? От каких ассоциаций лучше отойти? Какие решения не использовать?

**Рефернсы.** Можно ли на кого-то ориентироваться? Должно ли быть на что-то похоже?

**Контент.** Какие есть визуальные материалы, которые можно использовать в проекте? Можно ли брать со стоков? Какую графику нужно создать?

### Принципы брифинга

* Не оставляем клиента одного и спрашивать лично
* Задаём открытые вопросы
* Шаблон нужно нарушать
* Не договариваться и отказываться от проектов — ок

### Планирование

1. Декомпозируем проект на части и расставляем контрольные точки.&#x20;
2. Планируем каждую неделю и договариваемся на еженедельные отчеты.&#x20;
3. Используйте метод [JPEG загрузки](https://t.me/perasperagram/938), чтобы все успеть.
4. Ограничайте время над задачей. В этом плане может хорошо помочь метод помодоро. Также можно завести календарь, чтобы отслеживать лучше все этапы.&#x20;

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

### Референсы

Это основа проекта, но с ними нужно грамотно работать. Референсы можно поделить на три категории:

* **Концептуальные референсы.** Что рисовать? Это про метафору и концепцию.
* **Смысловые рефернсы.** Как это визуализировать? Способы подачи конкретного блока.&#x20;
* В**изуальные рефернсы.** Как раставить контентент? Композиция, типографика, стиль.

{% embed url="<https://datavizproject.com/>" %}

Концептуальный дизайн никогда не устареет. Как бы не менялся софт - сила в идеях.&#x20;

### Дизайн&#x20;

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

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

### Презентация решений

Как лучше работать с правками

* Презентуйте лично. Не оставляйте клиента со своим дизайном 1 на 1. Отлично подойдет созвон. &#x20;
* Выписывайте и правки. Важно их фиксировать в процессе обсуждения.&#x20;
* Проговаривайте их все с клиентом. Что имеется ввиду? Как это сделает проект лучше? Насколько важная задача? Насколько срочная?
* Отсортируйте по категориям.
* Резюмируйте и согласуйте.

### Передача и релиз проекта

Основа согласований в том, что мы не можем возвращаться.&#x20;

#### Правило FFF: fixed time, fixed budget, flex scope

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

Срок важнее фич. Мы можем уменьшить функционал и сдать все в срок. А потом уже добавить.

## Ошибки = уроки, а единственный человек с которым вы должны себя сравнить - это вы вчера.