Ланч-тайм 269: краткий перевод свежих статей о digital

Содержание

• Как правильно ставить задачи по дизайну разработчикам
• 10 идей из руководства Apple по разработке интерфейса пользователя

#857. Как правильно ставить задачи по дизайну разработчикам

How Designers Should Give Visual QA Feedback to Developers

Источник

Дизайнеры часто наблюдают ситуацию, когда продакшн сайта «не похож на дизайн».

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

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

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

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

1. Дайте упорядоченный контекст

При просмотре большого списка задач разработчик должен быстро понять следующую информацию:

• Тип устройства
• Название страницы или экрана
• Краткое изложение проблемы

Эта информация может содержаться в названии задачи:

[Тип устройства] / [Страница / Имя экрана] / [Краткое описание проблемы]

Оформленная задача в таком виде даёт контекст. Это помогает разработчикам и менеджерам проектов лучше понять проблему, не вдаваясь в подробности.

2. Не предлагайте решение, а скажите, что не так

Хороший пример: «Фото целевых персон на странице „О нас“ увеличиваются на 70% в пределах их контейнера 400 ms и в результате часть фотографий обрезаются».

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

Плохой пример: «Фотографии становятся слишком большими, когда вы наводите на них курсор, и это не то, что в макете дизайна».

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

3. Расскажите, что хотите видеть в результате

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

Хороший пример: «При наведении мышки на фотографию руководителя на странице „О программе“, она увеличивается на 15% в рамках 750 ms. Пожалуйста, добавь замедление с помощью функции easeInOutCubic».

Плохой пример: «Сделай эффект наведения более тонким, и чтоб подольше длился. И добавь-ка еще немного смягчения».

При постановке такой задачи возникает больше вопросов типа: «Более тонкий — это какой? Подольше — это насколько? Какое смягчение я должен добавить?

Правильно сообщайте, что вы ожидаете увидеть в результате. Если вы не можете сформулировать итог работы, то как вы можете ждать, что кто-то другой это сделает за вас?

4. Должно быть ясно, кто за что несёт ответственность

Вы поставили задачу, как надо. В итоге получили не то, что ожидали. Кто виноват?

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

1. Главный дизайнер создаёт задачу.
2. Менеджер проекта назначает задачу на разработчика (при работе с одним проектом можно пропустить этот шаг).
3. Разработчик разрабатывает и отвечает за багфикс.
4. Главный дизайнер принимает работу.
5. При необходимости повторите.

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

#858. 10 идей из руководства Apple по разработке интерфейса пользователя

10 Insights from Apple's Human Interface Design Guidelines

Источник

Эти идеи будут полезны для любого начинающего и даже опытного UI/UX-дизайнеру. Само руководство не изобилует техническим жаргоном и напрямую связано с разработкой интерфейса для iOS.

1. Проверьте цветовую схему приложения в различных условиях освещения

Источник

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

2. Оттяните момент входа в систему пользователя

Источник

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

3. Оставьте внешний вид приложения, который выбран в настройках

Источник

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

4. Покажите контент как можно скорее

Источник

Не путайте экран запуска с заставкой. Экран запуска — это экран, который показывает все элементы на странице. Создайте экран запуска, который практически идентичен первому экрану приложения.

«Если вы включаете элементы, которые выглядят по-разному при завершении запуска приложения, люди могут испытывать неприятное ощущение между экраном запуска и первым экраном приложения. Также убедитесь, что экран запуска соответствует текущему режиму отображения устройства; смотрите руководство о тёмном режиме» — из руководства Apple по запуску экрана.

«Не заставляйте людей ждать загрузки контента, прежде чем они увидят ожидаемый экран. Немедленно покажите его и заполните временным текстом, графиком или анимацией, чтобы было понятно, где контент недоступен на момент загрузки. Затем после загрузки замените эти временные элементы реальным контентом. По возможности, предварительно загружайте предстоящий контент в фоновом режиме, например, когда воспроизводится анимация или при навигации по уровню или меню» — из руководства Apple по загрузке.

5. Используйте предоставляемые системой цвета для текста, заливок, глифов и разделителей

Источник

«iOS предлагает ряд системных цветов, которые автоматически адаптируются к яркости и другим изменениям в настройках, таких как „Увеличение контрастности“ и „Уменьшение прозрачности“. Цвета системы отлично смотрятся индивидуально и в комбинации, как на светлом, так и на тёмном фоне, а также в светлых и тёмных режимах».

«Не используйте жёсткие системные цветовые значения в своём приложении. Предоставленные значения цвета предназначены для справки в процессе разработки приложения. Фактические значения цвета могут колебаться от релиза к релизу, в зависимости от различных переменных среды. Всегда используйте API для применения системных цветов; для руководства разработчика, см. UIColor» — из руководства Apple по цветам.

«SF Символы — это набор из более чем 1500 последовательных, легко настраиваемых символов, которые вы можете использовать в своем приложении. Разработанные Apple символы SF легко интегрируются с системным шрифтом San Francisco, поэтому символы автоматически выравниваются по вертикали с текстом с любым весом и размером. Вы можете использовать символы SF в приложениях, работающих в iOS 13 и более поздних версиях, watchOS 6 и более поздних версиях и tvOS 13 и более поздних». — Apple SF Символы.

Если хотите узнать, как можно использовать символы SF, то вот видео, оно на английском.

6. Используйте знакомые, понятные слова и фразы

Источник

«Технологичный язык может отпугивать. Не используйте аббревиатуры и технический жаргон, которые люди могут не знать. Используйте то, что вы знаете о своей аудитории, чтобы выяснить, понятны ли им определенные слова или фразы. Приложения „для всех“ должны избегать высокотехнологичного языка. Такой язык может быть подходящим в приложениях, предназначенных для более продвинутой или технической аудитории».

«Стремитесь к неформальному, дружескому тону. Такой стиль имитирует то, как вы разговариваете с людьми за обедом. Время от времени используйте сокращения, говорите „вы“ и „ваше“, обращаясь к пользователю напрямую». — из руководства Apple по терминологии.

7. Предугадайте, где пользователю понадобится помощь (онбординг)

Источник

«Ищите заранее узкие места, где люди могут столкнуться с проблемами. Игра, например, может случайно показать полезные советы, когда она приостановлена или когда персонаж не двигается дальше. Пусть пользователи имеют возможность воспроизвести в любой момент учебный материал на случай, если они что-то упустят в первый раз» — из руководства Apple по архитектуре приложений.

8. При необходимости помогите людям избежать потери информации

Источник

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

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

9. Используйте стандартные жесты

Источник

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

10. Не включайте конфиденциальную и личную информацию в уведомления

Источник

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

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

Вчера всем офисом объедались блинчиками — пруф. Выяснили, что почти никто не знает, когда Масленица :–\

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.