Обзор книги Runing Lean

Недавно прочитал Runing Lean от Ash Muraya поделюсь впечатлениями.

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

Внутри вам предлагают посмотреть на свой будущий продукт через Lean Canvas. Это таблица/шаблон, которая позволяет последовательно отвечать на ключевые вопросы. Ниже под постом положил сам канвас. Если читали Остервальдера с его бизнес моделями, то это версия немного с другого ракурса.

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

Как это работает

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

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

UX

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

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

Если продолжать тему про любимые занятия, то в первом семестре Антон в начале каждого занятия давал нам прокачку, после которой я теперь не боюсь сталкиваться с поиском быстрого и креативного решения любой проблемы. В этих прокачках нужно было очень быстро, за 10-15 минут, придумать, нарисовать и сделать бумажный прототип конкретной задачи. Например, придумать приложение по разделению счета в баре, по поиску собутыльника, приложение для знакомства в общественном транспорте, для настройки фортепиано и т.д. Круто, когда через 5 занятий до тебя наконец доходит алгоритм по которому нужно действовать, и ты начинаешь играться этими кейсами в своё удовольствие, но это уже отдельная история.
___________

Так вот, закончили мы исследовать наш продукт и настало время для конкретных действий. За блок UX нам было необходимо:

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

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

Но не все так просто. По ходу работы над вайрфреймами и прототипом очень остро встает вопрос какие ограничения у нас есть и какую конечную цель мы хотим достигнуть.

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

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

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

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

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

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

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

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

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

Дизайн 21 века

Дизайн 21 века

Дон Норман в новом видео рассказывает о будущем дизайна и проблемах дизайн-образования:

https://youtu.be/7FJNsqoC4tI (https://youtu.be/7FJNsqoC4tI?fbclid=IwAR2L5_Q8sum7igZyKP2-VXXTWuh8dAC3vwU95yIP6-OeGRRJKxYFoWvGDLg)

«Дизайн 21 века»

1. Изначально дизайн пришёл к нам из века 20, когда дизайнеры преимущественно создавали физические объекты.

2. Сейчас же новый век, всё в компьютере → и поменялась профессия. Появились сервисы, а не только предметы.

3. Service design introduced two great components: journey map and service blueprint.

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

5. Я посмотрел на лучших мировых дизайнеров и обнаружил, что лучшие — это физики, медики, инженеры, филологи...

6. Эти профессии дают широкое понимание мира → и потом это понимание мира уже применяется на практике.

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

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

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

10. Ещё большая проблема: как помочь другим сделать это? Какие у людей есть возможности и потребности?

11. Если бы меня попросили решить эту же проблему в отдаленном регионе Африки или Америки — здесь были бы другие решения.

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

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

14. Но именно дизайнеры лучше всего могут решить эти проблемы.

Дизайнеры думают широко.

Дизайн — это метод, а не набор компонентов.

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

16. Мы должны думать о том, что где-то разрывают город, чтобы проложить трубы, которые, возможно, и не нужны. Какие ещё есть решения?

Что насчёт воды?

Как получить чистую воду там, где нет электричества?

17. Это — будущее дизайна: работа над комплексными социо-технологическими системами.

Это то, чему мы должны учить молодых начинающих дизайнеров.

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

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

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

— Дизайн инструментарий полниться каждый день. Помню времена, когда у нас был только Фотошоп. Фотошоп, Карл! И ничего больше. И я даже боялся открывать Иллюстратор, чтобы ни дай Бог не забыть ФШ. А сейчас? Плодятся как религии и кто знает, где отрасль будет через пару лет.

— Тренды меняются ещё быстрее, чем тулы. Я уже давно перестал за ними следить. Думаю комментарии здесь излишни.

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

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

Хорошая коммуникация ещё один из столпов, на которых зиждется профессия.

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

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

https://www.abstract.com/blog/design-career-growth/

HTML-разметка — это просто текст, который делит страницу на смысловые (и не очень) блоки

Когда браузер получает HTML-документ, он на его основе создаёт древовидную структуру блоков, вложенных друг в друга. Каждый объект при этом называется узлом.

Потом к узлам применяются CSS-стили и получается та страница, которую мы видим в браузере.

К любому из узлов можно обратиться через JS как к объекту, чтобы узнать и изменить их свойства или содержимое, создать новые узлы или удалить старые. Структура этих объектов и называется DOM — Document Object Model. Она нужна для того, чтобы вы могли динамически менять содержимое документа после его загрузки в браузер.

Подробнее в видео: https://youtu.be/TKxR2tNxTcA
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Идеальный процесс

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

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

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

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

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

Usability test
Тестирование всего продукта и финальные изменения — Женя советует писать гипотезы в гугл-доке на протяжении всего исследования, чтобы во время тестирования не упустить что-то важное.
По итогу тестирования выявляются критичные и не очень ошибки, после чего нужно решить, с чем можно выходить на рынок, а что требует обязательной доработки. На этом шаге может всплыть много неожиданностей, на эту тему как-то писал Костя Горский — t.me/desprod/239

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

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

1. Погружение

1. Связаться с заказчиком
Сделать:
- интервью с заказчиком
- запросить метрики
Итог:
- утвержденное направление работу
- утвержденные с заказчиком сроки
Срок: 4.03

2. Поиск референсов/конкурентов
Срок: 04.03

3. Интервью с пользователями
Сделать:
-подготовить вопросы
-найти респондентов
На выходе:
- уточненный портрет
- проблемы пользователей
Срок: 13.03

4. Попробовать
Сделать:
- Сделать заказ (понять процесс, опросить мастера)
- Зарегаться как мастер (понят, процесс, взять заказ)
На выходе:
- проблемы
- полное понимание бизнес-процесса
Срок: 11.03

Анализ полученных инсайтов
Артефакты: понять на каких проблемах фокусируемся, список инсайтов, фичерлист
Показываем заказчику — 12.03
— Ретро —


2. UX — проектирование

1. Информационная архитектура — 20.03
2. Структура — 20.03
3. Карта экранов — 31.03
4. Сценарии
5. Прототип
6. Тестирование прототипа (проверка гипотез) - 7.04

Анализ полученных решений
Артефакты: протестированный прототип, карта экранов, структура, информационная архитектура
Показываем заказчику — 9.04

— Ретро —


3. UI — визуальный язык

1. Существующие гайды продукта
2. Мудборд
3. Дизайн концепт 3-5 экранов — 14.04
4. Масштабирование
5. Анимация

Анализ полученных решений
Артефакты: финальный дизайн продукта, анимация
Показываем заказчику — 30.04

— Ретро —


4. Передача в разработку
5 занятий 10.05-19.05

5. Подготовка портфолио
9 занятий 22.05-09.06

6. Презентация
3 занятия

7. Защита
23 июня


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