Артур Абраров написал, чем отличаются нативные приложения на iOS и Android (Material Design).

Выжимки из части пунктов:

3. Общепринятый размер экрана для Андроида — 360 × 640 dp. Для Айоса проектируют под размеры iPhone 5 (320 × 568 pt) или iPhone X (375 × 812 pt).

5. В Андроиде есть встроенный инструмент для навигации назад — Android Navigation Bar. Стрелка «Назад» возвращает пользователя по пройденному пути на шаг назад как внутри приложения так и между ними.

6. В Material каждый компонент находится в конкретном месте на оси Z. Надо осознанно подходить к созданию теней.

8. Для верхнеуровневой навигации Айос рекомендует только Tab bar. Андроид — Navigation Drawer (если пунктов больше 5), Bottom Navigation Bar (от 2 до 5 пунктов) и Tabs.

10. В отличие от Segmented Controls в Айосе, между Tabs в Андроиде можно переключаться свайпами. Если используете Tabs, не добавляйте на экран элементы с похожими жестами: карусель картинок или карточки со взаимодействием свайпами.

12. В Андроиде пользователь может раскрыть Navigation Drawer жестом Edge Swipe слева вправо. Этот жест нельзя использовать для чего-то иного вместе с Navigation Drawer. В Айосе жест возвращает пользователя к материнской странице.

13. Поиск может быть в виде иконки. В Айосе она открывает отдельный компонент Search Bar. В Андроиде поле поиска отображается в Top App Bar. В Айосе поле поиска можно спрятать под Navigation Bar и отобразить его, сдвинув содержимое страницы свайпом вниз. Не стоит этим же жестом обновлять содержимое страницы.

15. В Айосе нет аналогов:
— Navigation Drawer — бургерное меню;
— Banner — сообщить важную информацию и предложить связанные действия;
— Snackbar — кратко сообщить о результате пользовательского действия;
— Chips — показать введённый пользователем контент вместе с дополнительными данными или элементами управления;
— Floating Action Button — закреплённая кнопка основного действия;
— Standard Bottom Sheet — страница, часть которой закреплена в нижней части экрана.

16. В Андроиде нет аналогов:
— Page Control — показать, на какой из страниц находится пользователь;
— Toolbar — панель с элементами управления;
— Steppers — кнопки увеличения и уменьшения чисел, например, количества копий для печати;
— Popover — всплывающая панель, например, для настройки текста в читалках и браузерах.

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

22. В Айосе дата выбирается с помощью барабана. В Андроиде — календаря или поля ввода.

23. В Айосе название поля находится внутри поля и исчезает во время ввода текста. Material рекомендует поднимать название при вводе текста, выделять основным цветом его и полосу под текстовым полем.

26. При работе с текстом после долгого нажатия в Андроиде можно продолжить выделение текста. В Айосе появится лупа для точного выбора места в слове.

30. В Айосе можно потрясти телефон, чтобы появился диалог отмены последнего совершённого действия.

Наталья Стурза, автор канала @UX_sturzaman, рассказала, когда продуктам полезны UX-исследования:

1. Проверить идею, не создавая продукта. Хотели запустить маркетплейс для пенсионеров. Исследование показало, что люди старше 60 лет спокойно пользуются обычными интернет-магазинами.

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

3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.

4. Сравнить между собой конкурирующие продукты или отдельные фичи.

5. Понять, сколько потенциальные клиенты готовы платить.

6. Найти ошибку в интерфейсе.

Исследования не пригодятся:

1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.

2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.

https://vc.ru/design/86942

Итог по блоку исследования

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

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

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

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

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

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

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

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

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

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

Bad Blood

А я тем временем принесла вам обзор на книгу Bad Blood (в русском переводе - Дурная кровь) от Джона Каррейру.

Книга рассказывает историю стартапа-единорога "Теранос", который должен был произвести революцию в сфере здравоохранения и получил оценку в 10 миллиардов долларов – но за 15 лет существования так и не смог произвести на свет работающую и лицензированную технологию. Сейчас идет судебное разбирательство над основательницей компании Элизабет Холмс.

Я, безусловно, слышала про этот случай, но до прочтения книги даже не подозревала про невероятный размах обмана. Нельзя не признать гений Холмс, которая заключала многомилионные контракты и поднимала инвестиции, при этом ни разу не показав свою инновацию в действии. Благодаря ее миксу умелых манипуляций, природной харизмы, инвестиций в связи и нетворк, а также готовность использовать обман и угрозы, позволили компании держаться на плаву так долго и даже работать с пациентами. Учитывая, что Холмс была на хорошем счету в Белом доме, вызывала восхищение прессы, а клиенты Theranos планировали расширять партнерство, непонятно, что случилось бы дальше, если бы не журналистское расследование Каррейру. На самом деле, страшно представить, что могло случиться, учитывая, что анализы, поставляемые Theranos и производимые на основе неработающей технологии, использовались докторами для постановки диагнозов и дозировки лекарств.

Книгу я однозначно рекомендую, хоть это и не бизнес-литература.

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

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

А пока я хочу обратить твоё внимание на парадокс

А пока я хочу обратить твоё внимание на парадокс

1. Ты часто делаешь работу не к сроку, я бы сказал систематически (ровно так же, как это делают 100% известных мне творческих специалистов).

2. Но всякий раз считаешь это случайностью и объясняешь внешними причинами.

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

Я читал об этом в книге Канемана.

Если коротко: «обычный» человек переоценивает потери и недооценивает выигрыш. Если «обычному человеку» предложить сыграть в игру с подбрасыванием монетки, где «орёл это получить 1200₽, а решка это отдать своих 1000₽», он не согласится, хотя математическое ожидание — положительное. Это «страх потери», который добавляет негативному сценарию дополнительный вес. У «обычного человека» равновесие достигается примерно в точке «выиграть 1500₽ или проиграть 1000₽».

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

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

Как же быть?

Понимать, с кем имеешь дело.

— Если имеешь дело с такими же предпринимателими, творцами и специалистами по неопределённости, то расслабиться, принять своё «несовершенство», делить с ними ответственность, давать больше обещаний про процесс и меньше про результат.

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

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

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

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

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

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

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

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

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

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