Чтобы увидеть итог одного приложения, теперь нужна 1 строка вместо 17 (Brave Browser), и это примерно 3 секунды вместо 60. Все 3 коллеги, которые попробовали Observatory, пользуются им и спустя два месяца.
Продуктовый дизайн, исследование, айдентика и ролик к запуску. Писал спецификации и руководил разработкой с AI 2026 Релиз 0.1.1 для macOS 14 и новее, им около двух месяцев пользуются 3 коллеги.
Коротко
Ситуация. «Мониторинг системы» показывает процессы, а не приложения. Один браузер может занять 17 строк, и как только момент прошёл, ничего не остаётся.
Задача. Дать увидеть приложение целиком, а потом записать прогон и сравнить его со следующим.
Действия. Провёл 5 CustDev-интервью в логике Jobs to be Done, чтобы проверить, что проблема не только у меня. Потом скетчи, черновой прототип и три изменения после разбора сценариев.
Результат. Чтобы увидеть итог одного приложения, теперь нужна 1 строка вместо 17 (Brave Browser), и это примерно 3 секунды вместо 60. Все 3 коллеги, которые попробовали Observatory, пользуются им и спустя два месяца.
Оценка времени получена при проходе по обоим приложениям, а не в формальном исследовании.
Проблема
Во время тяжёлой работы я открывал «Мониторинг системы», чтобы найти приложение, которым пользуюсь. Его активность была раскидана по множеству процессов: найди их, сложи в уме и следи, пока цифры меняются. Не самый спокойный способ проверить память. А когда задача заканчивалась, вернуться было не к чему.
Одно и то же приложение в обоих инструментах. Названия процессов такие, как их показывает macOS, итог взят из живого просмотра Observatory.
Если записать это как job story (Jobs to be Done):
Когда я делаю тяжёлую работу, я хочу видеть, что потребляет приложение, и сохранять запись, чтобы вернуться к ней и сравнить.
Цель
Это был личный проект, и я сравнивал его с «Мониторингом системы», ведь его люди и так открывают.
Цель была отвечать на вопрос «что потребляет это приложение?» с одного взгляда и сравнивать прогоны между собой. Понять, получилось ли, я собирался по тому, сколько времени нужно, чтобы увидеть итог по приложению, могут ли люди сравнить прогоны без скриншотов и продолжают ли им пользоваться.
Исследование
Сначала я проверил, что проблема не только у меня. Прежде чем что-то делать, я провёл CustDev-интервью в логике Jobs to be Done. Пять человек рассказали, как в последний раз разбирались с производительностью: что хотели узнать, куда смотрели и чего не смогли найти. По их ответам стало ясно, что это стоит делать.
Самостоятельный диагност
Проверяет свой Mac.
Job story. Когда я смотрю, что происходит с Mac, я хочу видеть приложение целиком и замечать пики, чтобы не собирать картину по меняющемуся списку.
Проверяющий производительность
Разработчик, который сравнивает прогоны.
Job story. Когда я меняю приложение, я хочу записи до и после с понятным контекстом, чтобы сравнение действительно что-то значило.
Оба начинали с приложения или задачи, а не с процесса. Поэтому интерфейс, а с ним и мои первые скетчи, начинаются с приложения.
От россыпи процессов к группам по приложениям.Сначала итог по приложению, детали процессов уровнем ниже.Общее окно записи делает прогоны сравнимыми.Первый набросок теста и его результата.
По скетчам я собрал первый прототип с тремя разделами: «Now», «Tests» и «History».
«Now»: быстрый взгляд
«Tests»: записать прогон
«History»: вернуться к результатам
Решение 1 выросло прямо из интервью и скетчей. Решения со 2 по 4 появились после прохода по этому прототипу: из разбора сценариев и дизайн-критики, а не из формального юзабилити-исследования.
Решения
1. Процессы под своим приложением
Одно приложение занимало много строк, и его реальная нагрузка терялась.
Одна строка с итогами приложения
Процессы уровнем ниже
Сначала итоги, процессы по запросу.
Поэтому каждое приложение стало одной строкой с итогами. Процессы лежат уровнем ниже и раскрываются, только когда нужно.
Обе задачи начинались с приложения. А то, что связано, должно и выглядеть вместе: это гештальт-принцип общей области.
Другим вариантом был плоский список процессов с поиском, как в «Мониторинге системы», но складывать строки всё равно пришлось бы самому.
Brave Browser занимает 1 строку вместо 17.
измерено в живом просмотре
2. Выровненный список вместо карточек
Карточки группировали процессы, но чтобы сравнить приложения, взгляд прыгал между блоками.
AДо: карточка на приложение
BПосле: выровненный список с живым графиком
Я перешёл на компактный список с цифрами в выровненных колонках и живым графиком под ним.
В выровненных колонках одну метрику можно сравнить одним взглядом сверху вниз.
Сетка карточек из первого прототипа хорошо показывала группы, но сравнивать в ней было медленно.
3. Сначала приложения, потом режим записи
Настройка теста спрашивала про ручной или автоматический режим ещё до выбора приложения.
AДо: всё на одном экране
BПосле: выбрать, настроить, запустить
Теперь сначала выбираешь приложения, потом режим записи, а настройка и идущая запись стали отдельными экранами.
Люди начинают с того, за чем хотят наблюдать. Как инструмент это записывает, для них вторично.
4. Результаты внутри «Tests»
Тест заканчивался в «Tests», а результат жил в «History», отдельном разделе.
AДо: «History» отдельным разделом
BПосле: «Saved Results» внутри «Tests»
Я перенёс результаты в «Tests» как «Saved Results», со списком в боковой панели, пока результат открыт.
Информационная архитектура должна идти за задачей, чтобы следующий шаг всегда был сразу после предыдущего.
Разделов верхнего уровня стало 2 вместо 3.
посчитано по прототипам
Результаты
Observatory 0.1.1 работает на macOS 14 и новее. Живой просмотр держит перед глазами последние 60 секунд. «Tests» записывает от одного до четырёх приложений, с прогревом и повторными раундами по желанию, а записи остаются на Mac.
Время, чтобы ответить «сколько памяти ест Brave?»
«Мониторинг системы»: найти и сложить 17 строк
≈60 с
Observatory: прочитать одну строку
≈3 с
Одна отметка: 3 секунды. Оценка по проходу через оба приложения. К тому же «Мониторинг системы» обновляет цифры, пока ты складываешь.
Все 3 коллеги, которые попробовали Observatory, пользуются им и спустя два месяца. Чаще всего они берут «Tests», и для двух вещей: записать приложение до и после изменения и сравнить приложения одного типа, например терминалы Ghostty, kitty и Alacritty.
Каждое приложение одной строкой. Живой график хранит последние 60 секунд.
Выбрать приложения, затем режим, затем прогон.
Ручной режим ведёт по одному приложению за раз.
Сохранённые результаты хранят контекст.
Синхронизированные таймлайны делают прогоны сравнимыми.
Я бы сгруппировал приложения по назначению. Коллеги уже сравнивали приложения одного типа и выбирали их по одному. Группировка по категориям применяет ту же идею уровнем выше: похожее рядом с похожим.
Терминалы3
Ghostty
kitty
Alacritty
Редакторы кода2
Xcode
VS Code
AI-приложения2
ChatGPT
Claude
Концепция: один выбор добавляет в тест всю категорию.
Настроить сравнение терминалов
Сейчас,4 шага
Выбрать Ghostty
Выбрать kitty
Выбрать Alacritty
Запустить
С категориями,2 шага
Выбрать «Терминалы»
Запустить
Предложение, пока не сделано.
Дальше хочу проверить на людях вне моей команды: понимают ли они, что произошло в прогоне, и какие записи стоит сравнивать?
