Готовясь к первой лекции в вузе, вспоминал экстраординарные примеры интерфейсов, чтобы зажечь интерес студентов. В число примеров вошел чат головастиков, где каждый участник может подплыть к другим и что-то прокричать в надежде быть услышанным. А также два фрагмента из презентации «Изобретая на основе принципа» гениального Брета Виктора.

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

«Увидеть немедленно». Фрагмент из речи Брета Виктора «Изобретая на основе принципа»

«Сыграть анимацию собой», оттуда же

Ситуации проектирования на примерах дизайна в цифровой среде

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

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

https://ashapiro.ru/articles/design-situations

14 октября был ровно год как я начал писать книгу о Карте реализации историй. Завершил черновик за 11,5 месяцев — почти вдвое дольше, чем работал над текстом первой книги. В этот раз мне помогала небольшая группа поддержки, читавшая книгу по мере её написания и разговаривовашая со мной о её содержании. Спасибо всем, кто был рядом это время, задавал вопросы и пробовал метод.

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

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

Владислав Головач, дизайнер, автор книг «Культура дизайна» и «Искусство мыть слона»

Если вам интересна Карта реализации историй и проектирование на основе историй, то у метода есть отдельный канал — https://t.me/simapping О крупных новостях я буду рассказывать и здесь, но нюансы КРИ будут рассматриваться в отдельном канале.

Друзья, оказывается сегодня всемирный день бизнес-анализа, с чем я многих из вас и поздравляю 🤗

Узнал я об этом по случаю приятного поздравления от коллег из Казахстана.

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

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

«Я, как пользователь…» и что с этим не так. «Рабочие истории» Андрея Шапиро как апгрейд User Story

Многие аналитики писали User Stories. Каковы их слабые места? Часто «Я, как пользователь…» на самом деле прикрывает «Я, как бизнес, хочу, чтобы пользователь…», а ценность в «чтобы…» притягивается за уши просто для соблюдения формата .

Но главная боль, как по мне, в другом. В классической User Story нет предметной области. Нет данных, нет сущностей, нет «объектов». Из-за этого получается огромный разрыв между историей и тем, что потом увидят дизайнеры и разработчики.

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

Структура и содержание

Книга разделена на две части. Первая часть анализирует эволюцию пользовательских историй как инструмента сбора требований. Андрей делится практическими примерами из реальных проектов, обсуждая шаблоны, преимущества и недостатки user stories. Он подчеркивает их роль в преодолении "вавилонской башни" — языковых барьеров между стейкхолдерами, — но отмечает ограничения: краткость часто приводит к потере контекста, а отсутствие строгой структуры затрудняет работу в сложных доменах.

Новый шаблон «Рабочей истории» (НСДОЦ)

Вторая часть вводит ключевую инновацию — рабочие истории и Карту реализации историй (КРИ). Рабочие истории расширяют шаблон user stories, фиксируя не только роль, функциональность и ценность, но и ситуацию, объекты оперирования, а также каскад реализации (от замысла к форме).

Автор предлагает 5-компонентную структуру:
• Н (Носитель действия)
• С (Ситуация)
• Д (Способ действия)
• О (Объекты оперирования)
• Ц (Цель действия)

И ключевое здесь — «О (Объекты оперирования)». Нас наконец-то заставляют на уровне требования описать, с какими вещами, данными и сущностями работает носитель действия. Это сразу снимает кучу вопросов и заземляет историю.

«Карта реализации историй» (КРИ)

Это тот самый мост от «что» к «как». КРИ — это матрица , где по горизонтали идет процесс (логика следования) , а по вертикали — «каскад реализации». Каждая история раскладывается на:

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

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

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

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

Канал Андрея - https://t.me/how2scheme

Книг «Карта процесса-опыта. Проектирование услуги через её визуализацию» осталось 114 штук, 12% тиража. До Нового года их раскупят. Будет ли допечатка или переиздание пока неизвестно, мне нужно заниматься другими частями системы проектирования.

Посмотреть о книге в канале · у дизайнера книги | Купить

Прототипирование становится доступнее

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

Сегодня прототипирование на основе кода стало ближе, благодаря помощи таких языковых моделей, как, например Anthropic Cloude Sonnet 3.7. Диву даюсь, как ему удаётся программирование и исследование проблем в нём.

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

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

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

❦

Если вам нравится и не чужда разработка, то предлагаю ознакомиться с материалами Егора Гилёва о прототипировании с AI. Smashing Magazine недавно выпустил его статью о том как создавать прототипы сразу в коде: первая и вторая части

Андрей Шапиро написал о вопросах, направляющих проектирование.

— Вопрос — коммуникационный инструмент направленного размышления;
— В проектировании чаще всего имеют дело с вопросами исследовательскими (определение области, которую надо изучить подробнее) и проблематизирующими (постановка задачи);
— В начале проекта, когда идёт снятие задачи, проектировщики иногда не понимают, куда двигаться дальше;
— Чтобы задать качественные вопросы, надо начать исследование и минимально погрузиться в предметную область;
— Основа мышления — создание в голове схем, отражающих модели реальности. Обнаружив отсутствие важных деталей или нарушение логики в построении схем, мы можем это исправить;
— Вопросы позволяют подсветить себе или проектной группе эти проблемные места. Белое пятно — полное отсутствие понимания (по аналогии с картами до великих географических открытий). Серая зона — место, где понимание туманно, и мы это знаем;
— Есть практики ненаправленного интуитивного творческого поиска (вроде поиска образа в каракулях), но в проектировании нужны более надёжные направляющие;
— Ими могут быть следующие артефакты, уточняющие устройство человеческой деятельности: структура потоков, процессы как цепочки последовательных действий и событий, типичные ситуации и способы принятия решений в них, структура внутреннего устройства объекта, структура взаимодействий объектов и так далее;
— Получив новую порцию знаний в диалоге с экспертами и представителями заказчика, проектировщик обновляет картину и подсвечивает вопросами новые моменты для уточнения;
— Беглость приходит с опытом. Не страшно, если новая пачка вопросов появляется между встречами;
— Шаблонные вопросы позволяют снизить неопределённость на старте. Всегда есть фаза предварительного анализа замысла, выяснения сути задачи, её границ и целей заказчика;
— Всегда важно, как будут построены отношения, каковы у сторон ожидания друг к другу, из чего будет строиться процесс, как будет достигаться результат;
— Примеры вопросов о бизнесе клиента: Как вы работаете? На чём зарабатываете? Где вы берёте клиентов? Какой канал продаж самый эффективный?
— Есть ещё вопросы, демонстрирующие проблемы, когда вы уже увидели проблему, а собеседник — нет;
— Большую часть времени проектировщик задаёт вопросы сам себе. Это проблематизирующие вопросы, в которых сформулирована задача. Например: «Как проверяющий узнает, что по портфелю заново запущена проверка?»;
— Шаблоны таких вопросов: Как сделать так, чтобы появился <отсутствующий пока желаемый эффект> или исчез <наблюдаемый нежелательный эффект>? Как или за счёт чего будет работать <отсутствующий пока механизм> с <таким-то результатом на выходе>? Что, где и как поменять в системе, чтобы удовлетворить <новому требованию>?

#analysis

Пока идёт редактура книги про рабочие истории и Карту реализации историй (КРИ), добавляю в неё иллюстрации и поясняющие схемы.

Хочу поделиться одной такой схемой с процессом картирования историй в нотации Карты процесса-опыта. Надеюсь, эта схема войдёт в издание книги в виде развёртки. В треде прикрепляю в формате ПДФ

Сегодня немного о проектировании собственной жизни. Делюсь признаками выявления одержимости в работе и способом выхода из неё — практика «кормления коней».

Ранее рассказывал об этой практике в подкасте у Саши Ефремова. В заметке более полно удалось раскрыть тему.

Выдержка из упомянутого подкаста на тему выгорания и практики «кормления коней»

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

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

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

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

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

Пока идёт редактура и оформление новой книги «Рабочие истории. Системное проектирование с Картой реализации историй» поделюсь ещё двумя отзывами от экспертов, которые согласились прочесть её черновик.

Николай Судников, аналитик, президент IIBA Kazakhstan Chapter

Книга Андрея помогает глубже понять User Story и их ограничения. А также помогает перейти на следующий уровень — начать использовать методику автора — Рабочие истории. Рекомендую для чтения всем, кто работает с требованиями: аналитикам, разработчикам, продактам, тестировщикам, менеджерам.

Антон Григорьев, UX-дизайнер, автор канала UX Notes

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

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