Как отличить хороший кейс от плохого и кто такая эта ваша «насмотренность»?

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

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

Я обожаю язык метафор и не могу удержаться от возможности сравнить дизайнера с автомехаником (это сравнение гораздо глубже, чем может показаться на первый взгляд, но это тема для отдельной статьи). Представьте, что механик вместо последовательного изучения автомобиля просто начинает открывать капоты разных машин и изучать их устройство визуально. С каким бы усердием он это не делал — стать хорошим автомехаником это ему вряд ли поможет. Безусловно от этого будет какой-то толк: он поймёт, где располагаются различные элементы в автомобиле и как они выглядят. Если механик талантлив, то он, вероятно, в какой-то момент даже начнёт подмечать особенности каждой марки или страны производства машин, но количество потраченного им времени будет несоизмеримо с пользой, которую он для себя выносит. В дизайне это работает примерно также — изучая что-то только глазами ты получаешь гораздо меньше пользы, чем мог бы получить за это же время. А иногда работает даже хуже. В случае с автомехаником в 99.9% случаев он хотя бы будет смотреть на что-то сконструированное и созданное профессионалами. А дизайнер (особенно дизайнер новичок) часто попадает на работы таких же дизайнеров новичков и может неосознанно запоминать и воспроизводить ошибки подобные тем, что увидел.

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

Исходя из всего вышесказанного, сам по себе формулируется вопрос:

Сначала поговорим про прямые признаки, которые работают в 100% случаев:

1. У кейса есть понятная задача

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

2. Предложено решение задачи

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

3. Описан процесс

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

4. Есть результат

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

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

5. Целевая аудитория

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

6. Контекст использования

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

7. Визуальное оформление кейса

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

8. Уникальность и инновационность решений

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

9. Качество детализации макетов

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

10. Доступность интерфейса

Про людей с ограниченным возможностями у нас принято забывать. Что почти всегда неэтично и очень недальновидно, ведь по результатам недавнего исследования VK таких людей в России — около 8% от общего числа населения, а 30% из них имеют постоянную работу.

11. Обратная связь

Круто, если в кейсе честно показана обратная связь от пользователей или клиента.

12. Роль в проекте

Если вы изучаете личный кейс, то полезно понимать, какую именно роль выполнял в нём специалист и за какую часть работ он был ответственен.

13. Инструменты и методологии

Здорово, когда в кейсе описывают, что именно используют в работе. Это может быть полезно в том случае, если мы столкнёмся с подобной задачей и запомним сервис или методологию по которой решили эту задачу другие. Но настолько подробное описание — скорее мечты, чем реальность. Люди неохотно делятся своими инструментами, ведь это часть их экспертизы, которую можно монетизировать.

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

У ребят подробнейшее описание всех кейсов и процессов. Самый мой любимый кейс — про систему мониторинга пациентов в реанимации. Там всё, как в хорошем кино: клиент пришел за UI, вместе с дизайнерами нашёл косяки в UX и, в итоге, сделал мир для врачей и пациентов чуточку лучше.

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

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

Не менее известные команды, кейсы которых полезно изучать:

Конечно, всё вышеперечисленное лишь мой субъективный опыт. Это то, что с радостью я бы сообщил себе лет 5 назад, когда только начинал вкатываться в серьёзную работу UX/UI дизайнера. Возможно, эти пункты не подходят для других областей дизайна: графического, моушена, 3D. Я допускаю, что они не универсальные и не утверждаю, что изучать визуальные решения без описательной части — плохо. В конце концов IT — это рок-н-ролл, где у каждого специалиста свой бекграунд и история. Только вам решать, как и куда вам расти, но надеюсь, кому-то эта статья поможет эффективнее прокачивать свою насмотренность и дизайнерский кругозор.

А если вам понравилась эта статья, то буду рад видеть вас на своём телеграм канале UX Lead, где я пишу о дизайне, интерфейсах, продуктах и вдохновении.