Ресёрчили, ресёрчили, да не выресёрчили…

Published in

Дизайн-кабак

18 min readFeb 9, 2018

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

Дратуйти…

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

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

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

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

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

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

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

…

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

Прототипирование

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

Но давайте сделаем шаг назад и разберёмся, что же такое прототипирование в исконном своём понимании. Многие, дочитав до этого места, всё ещё проводят параллель «wireframing = prototyping», хотя это не совсем верно. Приготовьтесь, сейчас ваш мир перевернётся ;)

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

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

Позвольте прояснить. У вас есть любимое мобильное приложение?

Я вот в последнее время пользуюсь Lifesum! Очень хорошая прилажка для отслеживания своих гастрономических пристрастий. Она сразу показывает, сколько калорий тебе ещё можно съесть, разбивает твой рацион на белки, жиры и углеводы. Добавить блюдо очень просто — просто тапаешь на floating button и начинаешь вводить название. Причём можно не волноваться о формулировке: куча вариантов, созданные самими пользователями сразу вываливаются в развёрнутый список. Там же сразу обозначены калории за порцию, что довольно удобно в расчётах. После добавления, сразу появляется совет о том, что можно было бы съесть ещё, или, как в моём случае «Куда тебе ещё? Не в коня корм».

Но зачем я вам всё это рассказываю?

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

Storyframing

Как можно догадаться из названия, storyframe представляет собой историю взаимодействия пользователя с продуктом. Обычно, история эта обличена в слова и принимает форму рассказа. Описывая использование моего любимого аппа, я уже привёл пример этой техники. И я уверен, что многие из вас уже её используют, описывая желаемое поведение пользователей. Обычно это происходит на этапе kick-off или уже после пилотажного исследования, когда вы уже собрали всю (как вам кажется) необходимую информацию и шестерёнки в вашей голове закрутились, формируя размытый облик нового взаимодействия. Многие оформляют эти мысли в технических требованиях, нарекая их User Stories. Но! Хороший storyframe отличается от ваших фантазий тем, что основывается он на ментальной модели пользователей, то есть на том, как они представляют взаимодействие, а не то, как его представляете вы или разработчики.

«Ну и причём тут исследование?», спросите вы. А при том, что данный вид прототипирования можно применять ещё во время исследования, точнее будет сказать, можно начинать вместе с ним.

Этап исследования у нас обычно начинается с разного рода интервью: kick-off с заказчиками, интервью с потенциальными пользователями, ретроспективные интервью, тестирование «мысли вслух». При этом, основным фокусом данных бесед является выявление проблем, барьеров и преград с которыми сталкиваются пользователи. Конечно, определив «где болит» мы можем точнее поставить диагноз и вылечить симптом. Но, почему так редко звучит вопрос «А как бы вы хотели, чтобы это работало?» или «А как вы думаете, как можно было бы сделать текущий функционал лучше?». А если такие вопросы и задаются, то для галочки и не всегда трансформируются во что-то значительное. Максимум, что берут от него — это какие-то отдельные хотелки. А ведь можно получить гораздо больше ценной информации, которая направит вас к правильному решению, а то и станет им.

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

В любом случае, после интервью, вы можете получить черновой вариант storyframe’a. Почему это будет черновик? Что ж, потому, что пользователи не всегда точно знают, чего хотят. Как говорил Генри Форд: «Если бы я спросил у людей, чего они хотят — все бы попросили лошадь побыстрее.» И мистер Генри абсолютно прав, что точной реализации цели пользователя пока не знает никто, но основной фокус выявить можно. Если применить наш метод, то storyframe Генри Форда звучал бы следующим образом: Пользователь садится в/на/между чем-то, чтобы добраться до нужного ему места, причём делает это очень быстро :)

А вот уже случай из моей практики. У нас в EPAM, есть специальный сервис, который позволяет собирать на себя обратную связь, чтобы узнать свои слабые места и поработать над ними. Звучит как благое намерение, но этот сервис не нравился никому. Ну а что может быть лучшим решением проблемы, чем редизайн… Он был успешно произведён, причём, довольно быстро, но вот насколько успешно — никто не знал.

Приблизительно полгода назад, ко мне обратились с просьбой ответить на вопрос: «Получилось?». Если в двух словах, то метрики улучшились, но отношение к пользователей осталось неизменным. Я решил провести интервью, чтобы таки докопаться до истины и, заодно, сформировать ментальную модель пользователей по методу «Слюнявого единорога». Как оказалось, пользователям не столько не нравился сам сервис, как сам процесс, лежащий в основе. То есть люди расценивали обратную связь, как обязаловку и забывали половину всего, что нужно было отразить (обратную связь можно было оставить всего 2 раза в год). Таким образом, пользователи сами сказали мне, чего хотят, но были очень поверхностны и не могли обличить свою мысль в конкретное визуальное решение, так как не обладали опытом и навыками.

Таким образом, после создания основы, мы можем наложить на чистую ментальную модель пользователя технические ограничения, бизнес-требования и ваш опыт, чтобы где-то расширить вашу историю, а где-то вписать её в существующие рамки. Лучшим способом сделать это будет встроив storyframe прямо в персону или создав UJM.

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

Если же говорить о UJM, то эта малышка уже и является дополненным сторифреймом. В нашем случае, он выглядел вот так. А с этим уже можно работать ;)

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

Но никто не идеален. Обладание сверх-абстракцией — это как дар, так и проклятье. Вместе со скоростью изменений, приходит одна сложность, которая не так хорошо видна с первого взгляда. Позвольте мне привести пример: представьте себе собаку… Я дам вам несколько секунд, чтобы образ немного оброс деталями. Готово? А теперь я попрошу вас описать то, что вы видите перед глазами: она большая? Мелкая? Черная? Рыжая? У кого-то перед глазами можно возникнуть овчарка или бульдог. Я же вижу «@».

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

Paper prototyping

И простят меня библиофилы за этот термин, ибо под исконным «Paper prototyping» кроется именно процесс создания чего-то из бумаги. Когда вы, например, вырезаете iPhone собираете его как оригами, а после диафильмом прокручиваете на нём скрины. То, о чём же пойдёт речь ниже, скорее, носит название Sketches. Или, как я люблю их называть — каляки-маляки.

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

«Палка-палка-огуречек, вот и вышел человечек» — подавите в себе вашего педантичного идеалиста и начните делать всё криво и быстро. Вспомните принцип Паретто: 20% усилий = 80% результата, а именно это вам и нужно.

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

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

Рисуем скетч…

Все вопросы, идеи, альтернативы, дополнения и ограничений выносим на поля.

Довольны? Нет? Goto step 2.

И вроде бы всё хорошо, вот мы создали один экран, второй и уже кажется всё, «Расчехляй Sketch и погнали», но я осажу ваших лошадей. Давайте вспомним об исследовании, во время которого создавалась информационная архитектура: скорее всего, у вас есть какой-нибудь артефакт, где она отражена (UJM, User flow, Workflow или Sitemap), подойдёт всё, что найдёте, а если есть выбор — останавливайтесь на Workflow диаграмме, ибо в ней отражено всё-всё взаимодействие пользователя с системой. Если ничего такого у вас нет — не беда. Просто вам нужно ещё раз надеть шляпу проектировщика-исследователя и создать её самому. Выглядит она следующим образом.

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

Основное отличие микрофреймов от скетчей в том, что они показывают переходы между состояниями системы. В дополнение, здесь очень детально проработаны всякого рода мелочи, о которых часто забывают: pop-ups, notifications, tabs и так далее. Таким образом вы тестируете систему на замкнутость и возможность достижения пользователем своих целей. И при этом, данная система не лишена недостатков, и самым главным из них, как и со сторифреймами, остаётся субъективность интерпретации. Конечно, здесь мы обернули наши слова в более конкретные образы, но такой степени детализации всё равно не хватает, чтобы адекватно оценить решение. Тут всё дело в нашем мозге, ведь даже, когда мы рисуем, то бессознательно стараемся придать наброску законченный вид, искажая форму, пропорции и даже формат данных. Нередко на деле, даже самые крутые размалёванные скетчи в цифровой среде до неузнаваемости уродуются.

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

Wireframing

Не сложно догадаться, что эта первая стадия перевода вашего концепта в цифровой мир. Наши идеи так быстро растут… Хнык. Но почему вообще выделяют wireframing на фоне визуального дизайна? В чём его отличия от готового дизайна?

А чтобы ответить на этот вопрос, давайте разберёмся, из чего состоит wireframe.

Типографика, монохромная цветовая палитра, области и простейшие формы… На этом всё. Я намеренно не включал в этот список визуальные метафоры (типа иконки), разработка которых может навредить на ранних этапах. Сразу предвижу недовольные возгласы и скажу, что wireframe — артефакт очень текучий, аки эфир. Порой и глазом не успеваю моргнуть, как передо мной уже готовое визуальное решение. И при этом, начинать я советую именно с этих элементарных частиц.

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

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

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

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

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

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

Придавать элементам больший вес, относительно других можно только одним способом: контрастом. Этот незаменимый урок я в своё время получил у Эркена Кагарова, который начал свою лекцию со слов «За все годы, что я занимаюсь дизайном, я понял одну вещь: вода течёт с высокого места в низину… Всё, можно закончить». И на самом деле я согласен с этим утверждением на 120%.

Направляя внимание человека, вы выделяете что-то на фоне всего остального, создаёте «гору», отправную точку. С неё и направится внимание пользователя вниз, к более несущественным элементам. И эта разность — это и будет контраст. Хочу заметить, что если мы захотим выделить всё, то мы не создадим динамику, а только «поднимем плато над уровнем моря». Так что, избирательно подходите к процессу создания контраста. Причём, он может быть самым разным: размер, насыщенность или яркость цвета, отдалённость от остальных элементов, да хоть движение — решать вам. Я лишь говорю о том, что вам нужно определиться с тем, куда и как вы поведёте пользователя.

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

Таким образом, связь wireframing’a с исследованием заключается в грамотном распределении внимания, основываясь на исследовательских инсайтах, а также тестировании. Ну а когда внимание течёт, как нужно вам, время подмешать ещё немного переменных!

Visual design

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

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

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

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

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

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

Данный тип анализа будет очень актуален для редизайна всех мастей. Суть его сводится к тому, что нам нужно определиться с основным(-ми) показателями эффективности интерфейса, замерять их до редизайна, и после него. Таким образом всё сводится к неравенству «До ? После». Вот и всё. Но пусть видимая простота вас не смущает, ибо определить эти показатели бывает ой как непросто. Хотя сейчас существуют целые фреймворки, на которые можно полагаться, например 10 эвристик Нильсен-Норман групп или универсальные эвристики Бена Шнейдермана, применимые к любым интерфейсам. Для себя я предпочитаю использовать именно последние, ибо они не зависят от контекста.

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

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

И в данном случае, KPI с точки зрения пользователя будет «Как быстро я смогу получить или дать фидбэк», а с точки зрения бизнеса ещё и «Получить рейтинг всех ролей». Посему, нужно провести замеры того, как быстро пользователи заполняли форму и как часто ставили оценки. Сравнив эти параметры до и после мы и получим вердикт.

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

Resume

А если более развёрнуто, то…

General:

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

Storyframing:

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

Sketching:

Удавите в себе перфекционаста,
миксуйте для лучшего понимания процесса (microframes),
рисуйте, комкайте, выбрасывайте, рисуйте…

Wireframes:

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

Visuals:

Задумайтесь, а потом принимайте решения,
проверяйте за собой (тест KPI),
будьте готовы начать сначала.

На сладенькое

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

Здесь можно узнать больше о Storyframing.

А здесь InVision собрал отличные материалы по типографике.

Познакомьтесь ближе с визуальной иерархией.

Немного о том, как создать контраст между объектами.

Перед тем, как добавить цвета — прочтите эту статью.

Ну а если хотите приступить к тестированию, то узнайте как измерить результат.

Ну и наконец, как измеряется успех.

Как маленький бонус, добавлю линк на Vanilla Time — мой тихий канал в Telegarm. Никакого спама, только ссылки на избранные материалы и короткие описания к ним.