Шрифт «просто существует»

Шрифт «просто существует»

Ещё несколько лет назад мне казалось, что шрифт «просто существует».

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

Можно трактовать это как невежество или же отсутствие тонкой разрешающей способности.

Пару лет назад я стал интересоваться вопросом сильнее и встретил свой день рождения в кампусе Барбанеля на форкурсе Жени Юкечева.

Там впервые открыл Глифс и спроектировал(!) — точнее реконструировал — часть латинской кассы одного наборного шрифта.

Испытал «вау».

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

Оттого особенно ценно, когда они делятся своим процессом без присущего многим снобизма.

Начиная с сообщения ниже — в лучшем духе твиттер-тредов — Александр Черепанов рассказывает о создании шрифта для Рокетбанка.

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

История сравнения двух сервисов на этом не заканчивается.

Напомню, что как в юду, так и в профиру нужно заплатить за то, чтобы твое предложение увидел заказчик (в районе 20-150 рублей).

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

А что там в юду?
Тем временем в юду я, не выходя из приложения, нажал кнопку «стать мастером» и начал свой путь воина — предоставление личных данных, знакомство с внутренними правилами, небольшой тест на усвоение этих правил. И все, можно выходить на охоту за заказами.

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

И каково же было моё удивление, когда на следующий день мне перезвонил один из заказчиков! Он попросил скинуть портфолио, после чего мы минут 20 обсуждали варианты дизайна того приложения, который он задумал.
Мягко говоря я был поражен )

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

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

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

Что вообще нужно для того, чтобы научиться делать красивый UI (ну, кроме таланта, конечно)? Необходимо пройти через большое количество проб и ошибок, т.е. чем больше повторений сделано — тем более качественный результат.

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

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

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

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

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

На зачете по блоку UI наша команда предоставила три одинаково плохие концепции, и Женя Бондарев посоветовал смешать несколько идей из каждой концепции. На этом его активное участие в обучении закончилось. А мы остались один на один с очень сырым UI, и тут же стали его переделывать. Про мои страдания вы можете почитать в прошлом посте, скажу лишь, что все майские праздники я потратил на погружение в особенности работы над UI. Это время не прошло зря, я открыл для себя много нового и из зачаточных мои навыки стали чуть более крепкими.

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

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

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

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

Принцип «Направляй, а не ругайся»

Если клиент совершил ошибку, не стоит на него ругаться. Ошибки совершаются по невнимательности, но когда за них получешь — чувствуешь себя дураком. Никто не любит чувствовать себя дураком.

Если клиент не заполнил поле и жмёт на кнопку «далее» — направьте его: поставьте фокус на это поле, откройте клавиатуру. Можно написать аккуратное «Укажите» под полем ввода. Главное — не скатываться в нахально-безразличное «Обязательно для заполнения». Звучит, будто тётка на почте нахамила.

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

Иногда нужно обойти дерево узлов

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

Для этого есть набор методов:

let el = document.querySelector(".someClass")
el.childNodes // дочерние элементы
el.nextSibling // сосед справа
el.parentNode // родительский элемент

Подробнее в видео: https://youtu.be/MoEWUWIDFDs

И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO


✨Домашнее задание ✨

Взять пример из урока: https://codepen.io/detepr/pen/rQYYbx
1. Посчитать сумму цен всех подарков и вывести её в консоль
2. Отсортировать подарки по цене

Ура! Переходим к поиску решения!

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

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

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

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

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

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

На наблюдениях, казалось бы, методологи получают готовый проект, который сразу можно анализировать, но сам процесс сбора информации (3 часа в полях) и дальнейшая её обработка (2 часа за компом) занимает немало времени у полевиков, при том, что они делают, в целом, бессмысленную работу: переименовывают каждую фотографию определенным образом, вставляют её в проект, который воссоздают по своим бумажным записям.

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