Дизайн-мышление для информационного архитектора

Вступление:

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

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

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

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

Отличия: 

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

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

Основное преимущество информационного архитектора в том, что он улучшаем бизнес-процессы, а лишь потом делаем интерфейс. Пока бизнес-процесс не эффективен, дизайн эффективным не будет. В разделе резюме «инструменты» у информационного архитектора на первом месте всегда стоят блокноты, ментальные карты для ассоцийаций (XMind), онлайн-сервисы для командной работы над проектом, специализированное ПО (Axure RP и фреймоворки для обхода ограничений Axure).

Компетенции в бизнесе:

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

Следующая важная область знаний это цикл жизни продукта. Он бывает стратегическим, тактическим и оперативным. Обычно дизайнеры занимаются оперативными стадиями жизни продукта, делая интерфейс исключительно под текущие задачи. В customer journey map принято закладывать тактический план на 9 месяцев. За стратегические сроки можно взять стандартные 18 месяцев как стадию жизненного цикла продукта.

Кто может помочь информационному архитектору в его работе? Тот, кто определяет ключевые для бизнеса метрики. В компании почти наверняка будет кто то с навыками бизнес аналитика, и нужно с ним подружиться. Он должен владеть информацией о когоротном анализе, об оттоках, и иметь сильный математический беграунд. С его помощью вы выстраиваете модели конуса неопределенности. Конус показывает динамику неопределенности в хорошо управляемых проектах. Все это позволит нам оценить ценность продукта не в моменте, а в векторе на 9 месяцев для customer journey map. Для всей описанной работы нужны метрики. Метрики это сравнение величин. Без метрик вас ждет неопределенность, одно решение = одна метрика.

Но не вся ваша команда может вас поддержать, и нужно быть к этому готовым. У большинства технических специалистов конвергентное мышление. Это линейное мышление, которое основывается на поэтапном выполнении задачи, следуя простым и понятным алгоритмам (нормально делай, нормально будет). Однако для творческих людей подобный подход неприемлем. Вам должно быть ближе диверге́нтное мышление. Этот метод творческого мышления заключается в поиске множества решений одной и той же проблемы. Достаточно полезно ознакомиться с латеральным мышлением. Этот метод основан на смещении относительно традиционного мышления.
Процесс распознавания и определения проблемы:
  • Видение
  • Бизнес-задачи
  • Метрики
  • Анализ рынка
  • Аудитория
  • Монетизация
  • Дорожная карта

На каждом этапе распознавания проблем бизнеса присутствует брейншторминг. Замечательный способ помечтать в рамках четко сформулированной задачи. Это способ генерировать идеи, непохожие на стандартные. Применяйте брейншторминг в начале стадии «Что если?». Для успешного брейншторминга участники должны быть неравнодушны к проблеме, а это значит, что необходимо показать ее последствия для людей.


 То, что вы сделаете, должно развлекать, впечатлять, интриговать и учить (идеалом может служить пикантное видео).


Во время брейншторминга поток мыслей должен подчиняться определенной модели. Хороший вариант, это модель «Пять уровней». Достаточно концептуальная модель, предложенная Джессом Гарреттом для проектирования опыта взаимодействия веб-приложений. Модель предлагает основу для обсуждения проблем, связанных с опытом взаимодействия, а также возможных путей и средств их решения.
  1. Уровень поверхности
  2. Уровень компоновок
  3. Уровень структуры
  4. Уровень фич и контента
  5. Стратегический уровень
Многие считают, что информационный архитектор в чем то похож на гейм-дизайнера. Профессия гейм-дизайнера подразумевает придумывание игр, много математики, умение писать много и хорошо, должны быть компетенции в своей профессиональной отрасли. Как у любого создателя, 90% идей гейм-дизайнера ждет мусорная корзина. Необходимо взаимодействовать с техническим директором, с арт-директором, продюсером (у которого гениальные идеи). Информационные архитекторы многое могут почерпнуть из геймдева, и это правда. Но нельзя забывать, что UX-дизайн существует для уменьшения количества проблем, а гейм-дизайн для создания проблем игроку.

Целевая аудитория. Персонаж:

Эмпатия персонажам. Чтобы появилась эмпатия, персонаж не должен быть банальным социально демографическим портретом, он должен быть архетипом в виде customer journey map. Если персонаж это мужчина 25-35 лет со средним медианным доходом в крупном городе-миллионнике, то это не персонаж. Персонажем он становится, когда мы создаем ему проблему, и он начнет себя вести определенным образом для решения проблемы. Пример: человек идет по улице и обнаруживает, что бабушка не может перейти дорогу. В этот момент проявляются его особенности: сострадание, волнение, желание помочь. Возникает вопрос: «что он делает в данной ситуации?». Правильный ответ: для удовлетворения потребностей наших персонажей существует наш заказчик.

Тестирование:

Тестирование это не такая дорогая вещь, как может показаться. Достаточно 8 человек на каждую целевую аудиторию для качественного тестирования. 5 людей достаточно для определения медианного значения. Самое важное в тестировании не количество людей, а интервью, его сложно модерировать, сложно задавать общие открытые вопросы (как это было, что вы думаете об этом функционале, что ожидали увидеть и почему нажали на эту кнопку — нужно спрашивать про мотивацию). Наблюдать за тестированием лучше в реальном времени и с командой разработки. Можно пойти дальше, замерять дыхание и сердцебиение респондентов. С тестированием смартфонов сложнее, важно создать естественные условия, чтобы человек естественно двигал смартфон. Из инструментов вам поможет UX recorder, Dscout и сервис Chalkmark.

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

По окончанию тестирования вы должны сделать вполне четкие выводы, например:
  • школьники и взрослые платят одинаковое количество денег, но школьники платят мало и часто, взрослые платят редко но много;
  • люди склонны отказываться от выбора и оставлять выбор по умолчанию;
  • никто не читает туториалы, подсказки читают только при возникновении трудностей;
  • на странице, где есть 6 цветов и 24 цвета, будут НАМНОГО больше покупать со страницы, где 6 цветов, хотя будут проявлять одинаковый интерес;
  • время ответа на клиенте. Если невозможно, то хотя бы на сервере;
  • шестеренка нажимается реже, чем текст «настройки»;
  • шрифт «Roboto» плохо себя ведет на десктопах с windows;

 

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

Но измерить качество дизайна можно и этому нужно учиться. Если в 99% случаев ошибки дизайнера небольшие, miscommunication, какие-то небольшие детали не очень хорошо были объяснены пользователю визуально или с помощью текста, то качество дизайна хорошее. Учиться нужно на статистике по регрессионной модели анализа, и если вы всю жизнь генерировали статичные макеты и к статистике вас не пускают маркетологи, то Google вам поможет. Есть и другие источники, интересные для изучения, например similarweb.

Прототип: 

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

У нас должны быть следующие документы для создания прототипа:
• Информационный план;
• Высокоуровневый (поверхностный) прототип, чтобы написать текст и расставить акценты, документ для утверждения смысла и содержания;
• Wireframe как высокий уровень абстракции;
• Для очень сложных решений, например калькуляторы тарифов или взаимосвязи в документообороте, должна быть понятная схема;
• Карта маршрутов пользователя (Journey map), для наглядного просмотра проблем пользователя;

• Персонаж. Архетип в виде Customer Journey Map или User flow. На этом этапе принято называть пользователя человеком.

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

В основе принятия правильных решений стоит комплексный Big Data-анализ. Идеальный современный digital-продукт — это конструктор. Набор UI-элементов (UI-Kit), из которых сайт динамически собирается под каждого пользователя. Большие данные уже позволяют это сделать. Основан такой подход на методологии Data-Driven Design, проектирование продукта на основе данных, исследований, тестов, проверки гипотез, Big Data. Это уже не поиск решения главной проблемы и тестирование дизайн-идей. Data-Driven Design охватывает всех пользователей, анализирует данные об их интересах, стиле жизни, ключевых проблемах и социальном статусе.

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

Творческих отпусков не существует.


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

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

В прототипе должны отражаться важные мелочи с точки зрения user experience: в ГТА 5 персонаж бегает трусцой при зажатой клавише X, но если эту кнопку быстро нажимать много раз, то персонаж будет бежать быстро. Кнопка «R1» зажимается для того, чтобы держать за руку другого персонажа. Допустим, игрок управляет потоком ветра и собирает насекомых, сделайте прототип с использованием Гироскопа и игрок телом будете ощущать все наклоны и виражи. Если управлять двумя персонажами одновременно, то можно управлять левой рукой одним персонажем, и второй рукой другим. В случае потери одного персонажа физиомоторика будет сильно сказываться на эмоциональном состоянии игрока, будет чувствоваться потеря. Зачем я привожу примеры из игровой индустрии? Эти примеры, на мой взгляд, лучше всего показывают, что не все взаимодействие можно нарисовать. Даже привычное модальное окно с кнопками «да/нет» может быть не в виде плашки с текстом, пользователю будет достаточно кивать головой для того, чтобы сказать Да или Нет. Такие интерфейсы идут в ущерб юзабилити, но это тоже интерфейс.

Дизайн и контент:

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

Основой платформой остается классический веб и мобильные устройства. Брейкпоинты для таких устройств следующие: для десктопа 1366×768, 1600×900, 1920×1080. Для планшета 1024×768 портретный и ландшафтный режим, 320×480 портретный и ландшафтный для мобильников. Для всех брейкпоинтов важна сетка. Элементы сетки это колонка (colums), отступ между колонками (gutter) и общий отступ по краям (margin). Есть два варианта проектирования:
1. сетка резиновая, количество колонок не меняется, они меняют свою ширину
2. сетка ступенчатая, на брейкпоинтах меняется количество колонок, лейаут перерисовывается.

 


Очень сложно работать с идеями, не умея их визуализировать.


Начинайте с Mobile-first. В этом случае вы рисуете интерфейс для мобильного телефона, с дальнейшим масштабированием интерфейса до таблетки и десктопа. Для телефонов оставляем только самую важную информацию, делаем все крупным и жирным (для тачабельности). И обязательно легковесный (мало графики). Но возможен подход и Desktop-first, процесс начинается с десктопа и деградирует до мобильника. Учитываем длину строки (45-75 знаков в идеале). Но не забывайте очень важный нюанс: в мобильниках не сетка, в шаг. Продумайте как могут трансформироваться блоки. По модульности я обычно вдохновляюсь идеями Саши Гладких, у него все интерфейсы тачабельные, даже десктопные.

Полезные цифры:
  • 72 основной baseline;
  • длительность микроанимаций 200 (60-200 мс выглядят очень быстро);
  • длительность мезоанимации 400-600 мс;
  • длительность макроанимаций любая, обычно используется на обучающих страницах.

На выходе вы отдаете (или получаете, в зависимости от роли в проекте) стайлгайды и шрифтовую сетку. Обязательно мокапы (высококачественные исходники). Хорошо, если вы создадите свою стилистику, как Google Material Design. Они выдвинули определенные тезисы, которые описывают их стиль. Поверхность это контейнер без текстур, у каждого объекта есть глубина, все трансформации это работа с волшебной цифровой бумагой.

Прототипы делаются для всего: микроанимаций, основных анимаций, UX-исследований, презентации проекта и проверки навигации.


Зачем это все?

Чтобы не допускать ошибок, которые убьют бизнес клиента. Немного истории на примере Microsoft. С мобильными девайсами у них не заладилось с самого начала, в 1999 году уже на рынке существовали Palm, Symbian, Apple Newton. Microsoft решили зайти на рынок со своей ОС WinCE. Не смотря на знакомый интерфейс, кучу денег, много ПО, Microsoft игнорировала работу с производителями техники (Hewlett-Packard, ASUS, Dell), что не позволило им стать заметным игроком. Со временем Microsoft поняла проблему и начала сотрудничать с HTC. Но появилась вторая проблема: компания не знала, кто ее целевая аудитория, и пыталась захватить сразу и бизнес, и простых потребителей. Ей пришлось конкурировать одновременно и с Symbian (Nokia), и с Blackberry(RIM). Помимо этого, было много ошибок по юзабилити, коммуникаторы на WinMo требовали двух рук для нормального использования, однако одна из них обязательно должна была держать стилус. И в 2007 году вышел iPhone с большим 3.5-дюймовым экраном, привычным вебом без WAP-сайтов с ограниченной функциональностью, показав, каким должен быть мобильный девайс. Грамотный информационный архитектор предвидел бы такое развитие событий, и направил усилия компании и том-менеджмента на захват сегментов рынка, в которых компания может стать лидером.

5858

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

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

41 комментарий

  1. Евгений

    Здравствуйте!! Хочу поблагодарить Вас за интересные статьи, очень полезно! Радует, что практически отсутствует вода, все кратко и по делу.

    Скажите, как можно рисовать ментальные карты в Sketch?

    • your-scorpion (Author)

      Спасибо за добрые слова)
      Карты переходов можно делать разными способами: вы можете нарисовать все макеты в любом редакторе, сохранить их как jpeg. Запустить Adobe Illustrator, и закинуть в него все экраны в виде картинок (File -> Place). Если вы внесете изменения в jpeg’и, то все файлы в Illustrator обновятся автоматически. Аналогичный прием работает и с Photoshop, и с Axure. Либо использовать сервисы для построения ментальных карт, я использую draw.io.
      Если хочется делать все в одной программе, то UserFlows вам поможет.

      • Денис Бондарцов

        Спасибо, отличный плагин!
        А можно как то починить горячие клавищи в Sketch, некоторые шорткаты в русской раскладке не работают.

        И может Вы знаете, есть ли аналог виндового «Диспетчера символов» на маке?

        • your-scorpion (Author)

          Для этого есть специальный плагин sketch-lang-fix.
          Аналог есть, вызывается по Ctrl + Cmd + Space или на бирмановской раскладке Alt + 9.

          • Рустам

            Есть ли способ упорядочить плагины? Хоть как то, а то их развелось уже под третий десяток и все нужны.

          • your-scorpion (Author)

            Sketchrunner, либо банально Cmd+Shift+/.

  2. Konstantin Shirshov

    Спасибо за статью. У нас в команде возник спор, когда допустимо использовать pull-to-refresh, а когда требуются другие способы обновить контент? Интересует не предвзятый взгляд компетентного специалиста. Спасибо!

    • your-scorpion (Author)

      Pull to refresh это решение для списков и карточного интерфейса, когда элементы строго сортируются по убыванию, например, в новостной ленте или списке писем. И индикатор обновления, соответственно, появляется под заголовком экрана.

      Pull to refresh не подойдет для карт, так как у них нет первичного источника контента, который нужно обновлять. Также не нужно пихать Pull to refresh на все экраны. Прогноз погоды не меняется так часто, чтобы его ежеминутно обновлять. В качестве примера можно посмотреть такие приложения, как Google Play, Duolingo, список контактов в телефоне.

      Иногда добавляют обычную кнопку Refresh, особенно это решение распространено в Enterprise приложениях. Она очевиднее, но ее необходимость нужно подтвердить статистикой с аудитории вашего приложения. Нельзя точно сказать, подойдет вам обычная кнопка Refresh или Pull to refresh. Причина кроется в User eXperience вашей аудитории. Так, при выборке 216 000 человек в возрасте от 16 до 65 только 5% опрашиваемых умеют использовать современные технологии достаточно хорошо, 14% могут выполнить простую цепочку действий (удалить письмо), 26% в чём-то разбираются, 29% в состоянии работать с почтой, а оставшиеся 26% не умеют пользоваться компьютером (видимо, смартфонами они тоже не сильно пользуются).

      Вот гайды material.

  3. Михаил Воронцов

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

    • your-scorpion (Author)

      Свои нынешние продукты я проектирую изначально под английский язык с пониманием того, что английский текст при переводе на русский растет на 130-140%. Чтобы избежать самой распространенной проблемы с текстом, который не влезает в отведенные ему размеры, используйте гайды IBM. И банальные правила помогают не допускать ошибок: избегать узких колонок, использовать неразрывные пробелы, не встраивать контролы в текст, избегать фиксированных размеров для элементов с текстом.

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

      Если углублятьсяв разработку, то можно использовать специальные сервисы, вроде lingohub и transifex. Я работал с crowdin, можно подключить сервис по API и заняться переводом текстов.

  4. Виктория Калышникова

    Здравствуйте, подскажите пожалуйста. На нашем портале есть домен второго и третьего уровней с одинаковыми счетчиками из гугл аналитикс. Траффик суммируется.
    Можно ли настроить таким образом, чтобы разделить траффики с двух сайтов в рамках одного счетчика?
    Спасибо!

  5. Виктор designGuru

    Доброго дня и дратути!

    У меня вопрос по приложениям для iOS. Как Вы адаптируете интерфейс приложений под iPhone с экраном 5,5? Нужно ли увеличивать размеры контролов и шрифтов для экрана в сравнении с размерами для 4.0 и 4,7?

    • your-scorpion (Author)

      Адаптировать интерфейс не обязательно, хотя и имеет смысл в некоторых ситуациях. Для 5.5 дюймов (iPhone 7 Plus) вся нарезка и так экспортируется в @3x, а для 4.Х в @2x, соответственно, разница в 1,5 раза компенсирует ресайз экрана. Это работает при условии, если делать все в поинтах, тогда xCode отлично справляется сам.

      В некоторых ситуациях создается отдельный набор размеров для iPhone Plus. Рассмотрим на примере моего проекта ViPNet Connect.
      Я спроектировал 4 базовые метрики для превью фото в чате (compact: (157, 157, 2), normal: (186, 186, 2), wide plus: (309, 309, 3), huge tablet: (262, 262, 2)). С такими дискретными значениями очень просто работать. На планшет используется huge, а при переходе в мультиоконный режим перешли в метрику wide, она же используется для iPhone6 Plus.

      Из не очевидных рекомендаций:
      В портрете на планшете на весь экран окно, как и на телефонах.
      В ландшафте на телефоне слева список шириной 320 (например), а справа большая панель, например чат. Получается левый список — compact, а правая панель — huge.

  6. Гийденко Павел

    Добрый день.
    У нас в дизайне проекта возникла проблема, появилось очень много похожих цветов. 20 оттенков красного, 40 оттенков синего и 50 оттенков серого. Можно это пофиксить автоматически?

    • your-scorpion (Author)

      Если проект в Sketch, то поможет плагин sketch-replace-colour.

      Еще можно попробовать с помощью Craft. Нажимаете create styles, переходите на страницу «styles», на которой есть все цвета. Меняете цвета на нужные и нажимаете sync styles.

      • Гийденко Павел

        Спасибо, использовал второй вариант. Работает!

      • Александра Вельянинова

        Я видел, что в Sketch можно поставить шаг перемещения объектов по стрелкам на клавиатуре. Как?)

      • Vadim Grebennik

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

        • your-scorpion (Author)

          Плагин не нужен, sketch это умеет из коробки. Нужно просто дописать после «+значение» первую букву стороны, от которой в противоположном направлении нужно увеличить объект.
          T = Top, B = Bottom, L = Left, R = Right, C = Centre.

      • Vadim Grebennik

        Спасибо за оперативные ответы! Можете подсказать, как округлить все дробные значения пикселей в скече?

        • your-scorpion (Author)

          Это делается из коробки, с помощью Round to Pixel из меню Layer. Но каждый раз лазить в меню неудобно, лучше назначить shortcut. Для этого требуется пройти в System Preferences > Keyboard > Shortcuts > App Shortcuts / выбираем Sketch / в Menu Title пишем название / записываем shortcut.

  7. Igor cloobok

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

    • your-scorpion (Author)

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

      Так, реклама влияет на новых посетителей сайта, а изменение продукта — на всех. Поэтому в первую очередь нужно сравнить конверсию разных когорт. Если она увеличилась или уменьшилась для всех когорт, это влияние юзабилити сайта, в этом случае нужно посмотреть ОС + Браузер и Разрешение экрана + Браузер, посмотреть поведение пользователей через яндекс.визор. Вероятно, в определенном браузере ваш сайт работает некорректно, эту гипотезу нужно отдать тестировщикам.

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

  8. Konstantin Kisel

    Добрый день. Проектирую окно настроек и понял, что мне не удается решить для себя, что должно быть в настройках. Можете что нибудь порекомендовать?

    • your-scorpion (Author)

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

      ● Следуйте логической цепочке:
      Является ли это предпочтением пользователя? (если да, то →) Будет ли пользователь часто менять эту опцию? (если нет, то →) Есть ли вариант, который предпочитает большинство пользователей? (если нет, то выносите это в настройки).

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

      ● Хорошие продуктовые дизайнеры по умолчанию задают те настройки, которые по метрикам максимально подходят для эффективного использования продукта.

      ● Если настроек много, то имеет смысл их разделить на группы и дать подсказки к непонятным настройкам. Названия пунктов в настройках должны описывать действия. «Общие настройки», «Настройки установок», «Сервисные настройки» — все это не информативно.

  9. Виктор Мэдит

    Спасибо за статью. Скажите, есть ли возможность открыть в скетче 43 версии исходник, сохраненный из 44?

    • your-scorpion (Author)

      Напишите в тех. поддержку Скетча, они часто помогают в таких вопросах.

      Либо попробовать опасный способ: открыть файл скетча в текстовом редакторе, таком как BBEdit, и поменять версию на 43.1 и билд сменить на 39012. Разумеется, способ опасный, вы можете убить исходник полностью или частично. Так что сделать бэкап—обязательно.

  10. Александра Вельянинова

    Добрый день. Увидел, что вы участвовали в разработке большого количества приложений для Android. Дело в том, что я давно уже ищу описание, как работают swipe for action в Android. А именно, удобны ли они пользователям, обучены ли пользователи пользоваться таким жестом, есть ли бест практикс?

    • your-scorpion (Author)

      В Material Guideline я встречал только одно упоминание о таком контроле, называется Leave-behinds.
      Я считаю поведение swipe to action не достаточно очевидным для Android. Для контекстных действий куда лучше подходит Bottom sheets. Либо делать как в inbox: смахиваешь элемент и все. А при долгом тапе показыать дополнительное меню и возможность применить действие к нескольким элементам сразу.

  11. Andrey Lebedev-Lebedev

    Здравствуйте! Скажите, вам удалось найти способ передачи макетов из скетча в фотошоп или люстру? Пробую через eps или svg, но получается ужасно.

    • your-scorpion (Author)

      Используйте Affinity Designer, как посредника между Sketch и Photoshop.
      Процесс такой: в Sketch копируете артборд, далее в Affinity Designer найдите в меню File > New from Clipboard, и экспортируете как PSD. Все текстовые и векторные слои станут растровыми.

      С Illustrator история проще: выделить в Sketch все, что нужно перенести, и вставить в Photoshop как Smart Object. Дважды кликаете на получившийся Smart Object, он весьма не дурно откроется в Illustrator.

  12. Rvatori Kor

    Доброго дня.
    Подскажите по сетке в material design, основное ее отличие от сетки в ios это шаг в 8pt, значит все отступы должны быть 8? И если ли разница между 8pt и 8 points из ios. Спасибо!

    • your-scorpion (Author)

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

      По горизонтали: классический шаг сетки в MD 8dp, отступ слева 72dp, остальные отступы по 16dp. Отступы от краев экрана по 16dp.

      По вертикали:
      Панель состояния 24dp
      Панель инструментов 56dp
      Подзаголовок 48dp
      Элемент списка 72dp

      Плавающая кнопка 56dp.

  13. Aleksandr Murzin

    Добрый день.
    Мне интересно познакомиться с вашим видением методологии Скрам. Я посмотрел множество видео-уроков про Скрам и другие методологии, прочитал пару книг. Но в итоге я так и не смог сформировать целостное представление о том, что же такое Скрам в общепринятом смысле. Чем является Скрам для вас, автор (простите, не знаю Вашего имени)?

    • your-scorpion (Author)

      В первую очередь для меня важнее информация из Agile Manifesto как из концептуального подхода к разработке, а именно:
      ● Работающий продукт важнее, чем детальная документация про продукту
      ● Каждый участник команды и взаимодействие между ними важнее, чем процессы и инструменты
      ● Работа с клиентом важнее, чем согласование каждой мелочи в контракте
      ● Проработка изменений важнее, чем доскональное следование roadmap

      А теперь о Scrum как о методике. В команде должны быть:
      Product Owner—тот, кто видит общую картину продукта, расставляет приоритеты, умеет мотивировать, следит за сроками. Смелый, наделенный властью, все понимающий человек.
      Scrum Master—тот, кто инициирует все изменения, следит за ходом проекта. Всех учит, наставляет, устраняет помехи.
      Production Team—от 3 до 9 ребят, которые все пилят, умеют самоорганизоваться и уже давно работают вместе, несут ответственность за процесс и результат.
      Бэклог—список требований с приоритетами по задачам, который постоянно пополняется и редактируется. Команда оценивает задачи не в часах, а в условных «малый», «средний», «большой» или в баллах по последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21).

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

      Спринт это 1-2 недели, за которые команда успевает сделать часть задач из Бэклога. Это и есть основная суть Scrum, когда команда договорилась об фиксированном количестве тасок на один спринт, и новые не добавляются. Команда работает автономно, прозрачно, все знают о том, кто чем занят. Диаграммы и доски в помощь. В конце спринта команда демонстрирует то, что готово. После идет обсуждение с целью выяснить, что было сделано хорошо, что можно было бы сделать лучше.

      Если кратно, это и есть весь Scrum. Подход к разработке, ориентированный на полном контроле всего процесса и быстрых спринтах.

  14. Kaspars Berzins

    Привет, есть общий айдишник пользователя в разных таблицах экселя и куча разных столбцов в разных таблицах. Как объединить эти данные по пользователю?

    • your-scorpion (Author)

      Если в Excel, то с помощью ВПР. ВПР умеет искать определённую информацию в разных таблицах Excel и подставлять значения в одну таблицу. Эта функция ищет значения в крайнем левом столбце таблицы и возвращает значения в той же строке из указанного столбца таблицы.

      Выбираем «Функции» -> «Ссылки и массив» -> «ВПР».

      Разбираемся в появившемся окне:
      Искомое значение. Надо кликнуть по искомому значению, у меня это UID.
      Таблица Надо вписать таблицу, из которой берутся данные. Надо кликнуть на кнопку с красной стрелкой справа от поля и мышкой обвести таблицу, из которой берутся данные, жмем Enter
      Номер столбца. Указывается порядковый номер столбца таблицы или выделенного диапазона ячеек на предыдущем шаге, из которой будут браться данные.
      Интервальный просмотр. True или False. 0-ЛОЖЬ, 1-ИСТИНА. Выбирает ложь (0), это дает точность.

      Чтобы данные не сбивались, их нужно закреплять через абсолютные ссылки (F4).

      Заполняем все поля и получаем результат.

  15. http://your-scorpion.ru/

    Можете простым языком объяснить, кто такие стейкхолдеры?

    • your-scorpion (Author)

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

      Интервьюируя стейкхо́лдеров, можно получить опосредованные и исторические данные.

«Нажимая на кнопку Submit Comment, я даю согласие на обработку персональных данных»