UI/UX для iOS-разработчика: неочевидные способы улучшить свои hard skills. Часть 1

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Всем привет! Я — Евгения Бондарь, iOS Department TechLead в NIX.

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

В этой статье я рассуждаю о том, почему разработчику важно разбираться в азах дизайнерского ремесла. Материал будет полезен iOS-разработчикам уровня Junior и Middle.

Вы познакомитесь с базовыми принципами и подходами, на которых строится дизайн приложений. Также узнаете, что позволит вам быстрее находить общий язык с другими участниками команды и в итоге разрабатывать более качественный UI. А чтобы лучше разобраться в теме, для примера возьмем приложение в виде Proof of Concept.

Зачем все это нужно

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

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

Также не всегда есть исчерпывающие спецификации, которые покрывают все state, flow и альтернативные кейсы приложения. Список таких «не всегда» можно продолжать еще долго.

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

Такой кейс встречается не так уж редко. Во-первых, это может быть ваш личный проект. Во-вторых, такое бывает в стартапах, где не хватает денег для найма дизайнеров. В-третьих, это распространенная ситуация для аутсорса, когда заказчику нужен Proof of Concept или Minimum Viable Product, где в приоритете проверка идеи как таковой.

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

Базовые знания о дизайне могут понадобиться разработчику по нескольким причинам:

• Демистификация дизайна. Часто разработчики не понимают принципов, которые стоят за дизайн-решением, и упускают на их взгляд несущественные вещи. Это портит дизайн, ухудшает отношения в команде и замедляет процесс разработки.
• Технический бекграунд. Кто, как не вы регулярно взаимодействуете с iOS и хорошо понимаете основные аспекты работы этой платформы? Дизайнер может не знать того, что знаете вы. Например, он может быть пользователем Android или же недавно прийти из веб-дизайна в мобильный.
• Полнота специализаций. Допустим, дизайнер из-за нехватки опыта не учел, что данные подтягиваются из сети, из-за чего возможны задержки, error cases, empty states. Разработчику надо понимать, как с ними работать, чтобы самостоятельно решить задачу, если дизайнера нет поблизости или ему недостаточно времени для исправления ошибок.
• Поиск компромисса. Если дизайнер выбрал слишком дорогое с точки зрения разработки решение, вы можете предложить компромиссный вариант. Он будет смотреться не намного хуже, но выйдет гораздо дешевле. Это огромный плюс для вас и польза команде и проекту.

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

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

Proof of Concept: что взяли в работу

Обо всех этих аспектах дизайна в статье я буду говорить на примере следующего кейса. Представьте: к вам обратился заказчик, который просит наклепать на коленке PoC для проверки жизнеспособности своей идеи и вас как провайдера услуг. Дизайнера на этом этапе привлекать он не хочет, потому что «Just make it work».

Допустим, бизнес-концепт такой: приложение подтягивает из популярных гидов заведения рядом с пользователем и показываем ему, где можно поесть. Остальные детали опустим и сосредоточимся на том, что важно с точки зрения темы нашей темы. А главное — это требования к Proof of Concept:

1. Приложение показывает агрегированные заведения.
2. У каждого места есть название, рейтинг, дистанция от пользователя и статус (открыто или закрыто).
3. Фильтр для отсеивания открытых в данный момент заведений — чтобы поесть «здесь и сейчас».
4. По тапу на заведение у пользователя должна быть возможность заказать столик.

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

Итак, как вы можете улучшить текущий результат?

Human Interface Guidelines

Начнем со святая святых — Human Interface Guidelines. Это огромный сборник информации о всех нативных компонентах, принципах нативного дизайна и фреймворках под macOS и другие продукты Apple. Для новичков это must read, но и опытному разработчику эти гайды пригодятся. Они объемные, постоянно обновляются, и стоит периодически освежать их в памяти. Например, если вы сталкиваетесь с новой или нетипичной технологией, то в HIG обязательно будут рекомендации, как с ней работать, best practices и что лучше не делать. Поэтому я буду очень часто ссылаться на HIG в разборе нашего Proof of Concept.

В первую очередь обратите внимание на верхнюю кнопку:

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

Для таких ситуаций в iOS есть Segmented Control. Судя по описанию в HIG, это оптимальный компонент для замены кнопки фильтра. Причина его использования проста: юзеры уже привыкли, что Segmented Control фильтрует контент, поэтому они не тратят дополнительные усилия, чтобы разбираться в этой части интерфейса. Люди видят знакомый элемент и получают шаблонную ассоциацию: с Segmented Control содержимое будет фильтроваться.

Парой строк кода мы заменили кнопку на Segmented Control:

Все стало симпатичнее и понятнее. Обратите внимание: Segmented Control размещен в шапке навигации, плюс появился тайтл. О каждом этом моменте мы нашли описание в гайдлайнах. Фактически на любой аспект в UI вы тоже сможете найти информацию в HIG.

Новичкам я советую начать знакомство с iOS именно с чтения этого документа. Human Interface Guidelines также стоит включить в программу обучения стажеров. Зачем? Когда я как iOS-разработчик знакомилась с разработкой на Mac, то стартовала с соответствующего пункта в Mac-гайдлайнах. Это позволило мне понять платформу с точки зрения и разработчика, и юзера, а также узнать возможности системы «из коробки».

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

Layout

Следующий момент в нашем PoC, который предстояло исправить — Layout. Здесь он выглядит минимум неаккуратно:

Если выровнять, станет гораздо лучше:

Делается это в один клик объединением лейб в stack view. Если вы пишите UI в коде, то усилий будет немногим больше. Выравнивание позволяет юзеру не цепляться взглядом за выступающие части UI. В результате при скроле он лучше фокусируется и воспринимает информацию.

Отвлечемся от PoC и рассмотрим важность правильного layout на другом примере. На иллюстрации ниже вы можете видеть приложение Picsart. В данном случае благодаря выравниванию мы понимаем, что кнопки эффектов и кнопки ниже относятся к большой картинке. По сути, это все воспринимается интуитивно. Такому приему необходимо уделить внимание.

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

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

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

Особо критично это при адаптации layout, например, под iPhone SE. Нередко дизайнеры не рисуют отдельный дизайн для небольшого экрана, и его приходится делать разработчику самостоятельно.

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

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

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

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

Также по тапу на заведение нужно предусмотреть возможность забронировать его:

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

Обратите внимание, что Call to Action Button находится внизу экрана. Это связано с тем, как мы держим девайс. Обычно для этого используем одну руку и большой палец. На примере ниже зеленым цветом помечены зоны, в которые мы можем без труда добраться именно таким способом оперирования устройством. Красным — выделены зоны, куда дотянуться практически невозможно без перехвата девайса или второй руки.

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

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

В разделе HIG про Layout вы найдете много информации в том числе об Auto Layout: от банального гида по размерам девайсов до рекомендаций, как правильно скейлить контент в зависимости от разрешения, как работать со Aspect Ratio картинок и т.д. Также там описаны правила разработки под Full Screen девайсы, начиная с iPhone 10. В этом случае есть особенности, о которых не все знают или которые не все соблюдают. Хотя Apple за нарушение таких моментов может даже реджектить приложение. Если вы вдруг не знакомы с этими правилами, обратите на них внимание.

А я же в завершении этого логического блока приведу еще несколько статей, которые помогут вам лучше усвоить принципы Layout:

• Boost Your UX with Clear Visual Hierarchy
• Design for Fingers, Touch, and People

Шрифты

Возвращаемся к PoC и понимаем: пользователю все еще не хватает фокуса на главном контенте. Здесь хотелось бы отметить момент, на который многие разработчики не тратят много сил. Речь пойдет о размере шрифта. Чтобы не терять время на пробы, я советую воспользоваться небольшим лайфхаком с применением Modular Scale — придефайненной последовательностью гармоничных размеров текста.

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

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

Чтобы пойти еще более простым и быстрым путем, для РоС мы воспользуемся стилями, которые нам предлагает Apple «из коробки». Стиль — это сочетание размера, шрифта и его жирности. В стилях Apple могут использоваться даже разные шрифты семейства San Francisco — нативного для iOS. На иллюстрации ниже показано, как мы применили к заведениям стили body, headline и subhead:

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

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

Больше об использовании SF Symbols, типографии и типографическом калькуляторе вы можете узнать по этим ссылкам:

• Typography on HIG
• SF Symbols iThink #3
• Getting Typography Right in Digital Design
• Exploring Responsive Type Scales
• Modular scale calculator

Цвет

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

Чем больше приложение, тем больше его палитра. Если же приложение будет поддерживать Dark Mode, то для каждого цвета добавляется и соответствующий оттенок в темном режиме. В данном случае также помните о настройке accessibility повышенной контрастности. Для каждого цвета следует добавить еще по два оттенка: для повышенной контрастности светлой и темной тем.

Чтобы было удобнее обращаться со всеми вариациями цветов, в Apple с 13-й версии iOS советуют использовать семантический подход к цветам. Ниже — пример такого цвета, который достался нам «из коробки». Это один из fill colors — systemGray. С точки зрения кода семантический цвет выглядит, как обычный. Но в зависимости от настроек системы, темы или настроек контрастности он адаптируется под заданный режим.

Мы применили в нашем PoC семантические цвета. Такие цвета взяли и для тинтов, и для лэйб: label, secondary label, а также для текстовок третьей и четвертой степеней важности. Для кнопки Call to Action мы использовали Indigo. Но оговорюсь: с кликабельными элементами надо соблюдать консистентность.

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

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

Таким образом вам не надо ломать голову и искать вдохновение для выбора палитры в предлагаемых вариациях:

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

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

• Color on HIG
• What’s New in iOS Design
• Color theory
• Palette generator

Proof of Concept: что получили в итоге

С учетом всех основных аспектов UI наш прототип стал выглядеть гораздо лучше, чем был на начальном этапе. Ничего сложного мы не сделали. При этом все выглядит хорошо, в том числе в Dark Mode и в accessibility с увеличенным шрифтом:

В следующем материале я коснусь концептов, которые связаны не столько с UI, сколько уже с UX.